I'm not talking about EFS or Bitlocker here.

I'm asking if there's a way to prevent files from being encrypted. I'm referring to some extent to ransomware, but specifically I want the following scenario:

  • Windows File server w/ shares (on the E: drive)

I want a way to tell the above server "don't allow files on the E: drive to ever be encrypted by anyone or any software/process."

I can't find any way to do this at the NTFS level, short of "read" access. Modify access allows files to be encrypted.

I've searched around online but get a bunch of EFS/bitlocker/ransomware links that have nothing to do with my question at hand.

So fellow experts. Any way to do the above in bold? I'm not asking about ways to prevent ransomware, etc. The bolded area is specifically what I'm after.

  • 11
    How do you suppose that the server detects that the write by the client is malicious in nature? After all, at least from what I know, ransomware in particular doesn't use system functions for the encryption. – Sven Mar 8 '16 at 17:29
  • 1
    @Sven - I knew it was a very long shot. I was hoping there was some hidden ACL or something I had never heard of. I ain't too proud to beg. :) – TheCleaner Mar 8 '16 at 20:53
  • Assuming the Crypto-locker does not perform multi-pass encryption then would you be able to save a copy of the file to a different location prior to overwriting it? In this case you would simply need double the storage and hope that the Crypto-locker bad guys don't read my comment and implement multi-pass encryption :). This also assumes that multiple users didn't get the virus and performed a distributed multi-pass encryption. – MonkeyZeus Mar 8 '16 at 21:50
  • Ah yes, if only malware would nicely tell the OS "Hello, I'm malware!" and then you could set up rules so malware could not access anything but other programs could. – immibis Mar 9 '16 at 1:15

In short: no.

As you said, if you allow users to have write access, then they can encrypt data. I couldn't conceive of a way that an operating system or filesystem could possibly even start to detect and prevent the many types of encryption that are out there.

It's a hard problem, though, and I expect OS vendors are devoting significant efforts towards rendering Cryptolocker et. al. less destructive than they currently are.

Until then, maintaining as many different types of backups as possible and ensuring that those backups can be restored reliably and quickly will be the best protection.

  • I can. write() errors out if it looks like random bits. But ... – joshudson Mar 8 '16 at 21:42
  • 6
    @joshudson Every good compression algorithm will produce output that look like random bits. – kasperd Mar 8 '16 at 23:09
  • I think you can tell the difference between compressed and encrypted but you can't tell the difference between encrypted and noise, and sometimes you really do need to store noise. – joshudson Mar 8 '16 at 23:10
  • 1
    Or recognize the block headers ... – joshudson Mar 9 '16 at 2:41
  • 1
    @joshudson: So encryption program compresses its encrypted data, then writes it out. Or alternatively, encodes the encrypted data in base64 or some word code or something else with low entropy. – Nate Eldredge Mar 9 '16 at 3:17

Yes, but also no

This is one of those weird cases where it's literally impossible to prevent every single way of doing something.

You can prevent processes like Bitlocker, Truecrypt, and other legitimate encryption programs from accessing the share. Most of the time this is done through Group Policies (Bitlocker comes to mind here) or specific 'all in one' software packages (Look at Kaseya, Labtech, or NAble).

Is it easy?

Lord no. You would have to script a response procedure for each separate encryption program. And, you would have to do so for each new program that comes on the market. It would be time intensive and painful and still only cover maybe 50% of situations. I've scripted with both Labtech and N-Able, and no it is not quick and easy to do.

Wait, you also said no?

That's right, also no. No, because most ransom ware programs aren't using an encryption program. They are just opening specific files in something akin to a text editor and changing the values according to a hash they have generated. You expressly can't stop this type of behavior unless you deny modify access to the share.

So, is it worth it?

Nope. You can probably block legitimate and helpful encryptors, but the dangerous ones are likely to still get through.


A noteworthy edit

While the actual question is handled above, what I believe the intent of the question is can be summed up a little better. Having just had another run in with a nice crypto locker today, I got a refresher for my perspective on the matter.

While we fear crypto lockers as the end all, be all of dangerous infections, sometimes we over estimate them. This particular crypto locker was caught by our enterprise anti virus software in under two minutes. In total it managed to encrypt a total of 7 folders on a network share before being detected and deleted. Strangely, it was actually smart enough to go for the network shares first, a behavior I hadn't seen in previous crypto lockers.

While some very key data could very well have been in the seven folders encrypted (It wasn't in our case), the total effect is still minimal. With a proper backup solution in place, our total recovery time will likely <4 hours and only that high because I am using the opportunity to redeploy the workstation that was infected.

If you are spending more than 4 hours trying to develop a defense against crypto lockers, it probably isn't worth the cost of developing it.

Files are just bytes.

There's no special "encrypted" status in this context. Either you have write access to the file, or you don't. Once you have any write access to a file, all bets are off. There's nothing different about encrypted bytes vs other bytes that you can guard against. You might argue that encrypted bytes are somehow "more random", but compression algorithms have pretty much the same effect... anything that might try to detect writing encrypted bytes is likely to also trigger whenever anyone edits or saves an image, video, or audio file.

If you want to guard against ransom-ware on a file server, have good anti-virus protection on the clients, at your gateway, and at the server. Follow the principle of least privilege at the local machine to limit the possibility of infection and at the file server/file share levels to limit write access and therefore the scope of the damage if/when infections occur. Take good backups (with tested restores) that are physically separated from the source so you can recover files if/when something happens.

It might be interesting to see a file share platform that only allows certain known file types, buffers write I/O, and scans the headers of the files to make sure header data matches the file extensions (jpgs have readable headers, txt files only allow ascii, etc). But this is definitely not part of your common SMB/DFS/CIFS share, and this kind of thing is easy to defeat by just always writing valid headers.

No, you cannot prevent files from being encrypted. How is the OS supposed to know if a file is encrypted vs being of some format it doesn't "know" about?

You can disable OS-level encryption, and perhaps some programs from running via GPO, but that cannot stop every program, nor users uploading already encrypted files.

What you want to do is ensure users are only putting files where they are supposed to - and no where else.

If you have Active directory, you can try a SRP (Software Restriction Policies) GPO to block executables in this paths:

%AppData%\
%AppData%\*\
%localappdata%\
%localappdata%\*\
%localappdata%\Microsoft\Windows\Temporary Internet Files\
%localappdata%\Microsoft\Windows\Temporary Internet Files\Content.Outlook\
%localappdata%\Microsoft\Windows\Temporary Internet Files\Content.Outlook\*\
%localappdata%\Microsoft\Windows\Temporary Internet Files\Content.Outlook\*\*\
%Temp%\
%Temp%\$*\
%Temp%\*.zip\
%userprofile%\

Extracted from: http://www.sysadmit.com/2015/04/windows-gpo-para-prevenir-cryptolocker.html

There is [potentially] a SIMPLE solution to this. Create (maybe through ACL) the ability for the OS to require a user approval when a modification is made to a certain file type (e.g. .mdb, .docx, etc.). Since crytpo processes do these things rapidly, without user intervention, the encryption succeeds. But if clicking on an "OK" button will allow the write, it will also PREVENT a write to a file.

It's probably not a perfect solution, but it's a start in preventing rapid file modifications from client systems on shared drives.

Just my 2¢ US (or $7.54 Canadian)

We are having similar issues. Users are coping encrypted file to our main Windows 2012 R2 File server and of course other users can't read the files. A couple weird things are: it used to prompt the user when they copying the encrypted files to give them a choice of de-crypting first, it doesn't do that anymore and copies the encrypted files directly. The other weirdness is that on my test Windows 2012 R2 server, it does not allow encrypted files instead it takes a long while to copy the file and when it is done the files is not encrypted. I'm running Windows update to see if "breaks" then.

Here's the suggestion from our Encryption software support team. I have yet to apply it since I can't duplicate the issue on our production server in our test environment.

By setting the EFS option to “Don’t Allow”, that will cause the prompts to reappear. The behavior you are describing is most likely a setting on that file server. When Microsoft completes the setup of a new server, regardless of that server’s role, the setting for EFS on the server (not the domain) will be set to “Not Defined”. Depending on the scenario, “Not Defined” could mean “enabled” or “disabled”. On the file server, open “gpedit.msc” and navigate to Computer Configuration >> Windows Settings >> Security Settings >> Public Key Policies >> Encrypting File System. Right-click on the EFS folder, and select Properties. Change the option for “File encryption using Encrypting File System (EFS)” to “Don’t Allow” or “Disable”. ***Note: Before you turn off EFS on the file server, you should have the users move the data back to his/her original machine. After you have disabled EFS, the user can copy the data back to the file share. We also recommend that EFS be disabled on all file servers that you may have in your environment.

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.