Windows Server - any way to prevent file encryption?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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

Answer 6

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)

Answer 7

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.