The WannaCry/WannaCrypt ransomware/worm struck late last week and wreaked havoc with a number of important files/documents being encrypted. Can a twenty year old idea of mine actually help to restrict the damage caused by ransomware by essentially ‘hiding’ your important files so that ransomware can’t find them?
UPDATE (2017-05-22): I’ve just tried using this to protect files against a Wannacry sample, and it didn’t work (my hidden/’protected’ files were encrypted). Haven’t been able to try it with any other ransomware.
Back in my youth I came up with a way to protect my university UNIX account from password guessing/sniffing by building what I later found out was essentially a two-factor authentication system. One of the problems that I had was how to prevent a user from using the guessed/sniffed credentials to login using FTP and simply delete my challenge/response script, and to stop them from simply reading the script to obtain the challenge/response algorithm.
To combat this problem, I came up with a way of hiding the files from, basically myself — that is, someone logging in to my account could not find the challenge response script, but I knew where it was hiding so I could still access it.
Achieving this relied on the fact that UNIX has separate permissions for traversing through a directory (‘x’ — eXecute) and listing the files in a directory (‘r’ — Read). So, if you create a directory that does not have ‘r’ (read) permissions but does have ‘x’ (execute) permissions, then you can traverse through the directory to get to a subdirectory or files, but you can’t read the contents of the directory to find out what the name of any subdirectory/files are. Subdirectories will have both ‘r’ and ‘x’ permissions and will hence act as normal directories.
The question is can the same trick be used on Windows to help lessen the impact of ransomware? If so, this would be a simple, albeit slightly inconvenient (but then you can’t have everything — convenience and security seem to be inversely proportional to one another), way of protecting your more important files at least. I came up with this idea after thinking ‘can we just stop the ransomware from being able to see the files?’, which reminded me of a line from Douglas Adams’ The Hitchikers Guide to the Galaxy: “Does anyone know why Arthur can’t turn on the Improbability Drive?” — Trillian.
I’ll warn you — this blog post is very rough as I have put it together in a hurry. I wanted to let people know about a possible mitigation technique as soon as possible, following the events of the last few days, and I also don’t have any other time this week (my day job is taking up too much time, but it pays me) to write a post, nor to test this method with any malicious software. I am planning on doing some testing when I can, and I’ll then come back and tidy this post up a tad. I added a whole bunch of screenshots too, from Windows 7, but then realised that I hadn’t obfuscated the host name in them so I removed them again — I’ll hopefully be able to fix them up soon, but right now I need to get some sleep.
So, I’ve just done a few quick tests (as it’s getting late) and it looks promising. Here are the steps which I believe should result in your files being hidden from ransomware. Note that this is NOT a solution to the problem of ransomware, and I’m not going to claim that it can’t be bypassed (in fact at this point I can’t even claim that it offers any protection against ransomware at all until I can get the time to test it with some actual ransomware), but in theory it may help to protect some of your more important files (like files containing patient data for instance) at least until ransomware evolves.
General plan
- Create a folder under which you would like to hide your files. In my original UNIX implementation I called this front_gate.
- Create a second folder as a sub-folder of the first (front_gate). Again, in my original UNIX implementation, I called this folder front_door. NOTE: Do NOT name your sub-folder front_door, as now that I’ve published this fact, malware could simply look for a ‘front_gate\front_door\’ folder and it will find yours if you’ve named it the same!
- Edit the Security properties of the front_door folder to remove (untick) the ‘Include inheritable permissions from this object\’s parent’ option. If this is left on, then the front_door sub-folder will inherit the deny permission that we’re about to add to its parent (the front_gate directory).
- Select ‘Add’ (Windows 7 Professional) or ‘Copy’ (Windows XP) to add/copy the inheritable permissions from the parent object to this object. This is because this folder will no longer inherit the inheritable permissions from its parent, so we need to copy those permissions to this sub-folder. This will allow the sub-folder’s permissions to differ from those of its parent, which is good as we’re about to add a ‘Deny’ permission to its parent.
- Edit the Security properties of the front_gate directory to Deny List folder contents. Now, which users you decide to deny this permission from will depend on the level of security that you want. Basically you want to deny this permission from any user that the malware could run as. It will more than likely be the user who owns the directory (yourself). Removing the permission from the administrator should also hide the files from malware running as administrator (either as a result of an administrator accidentally running the malware, or as a result of privilege escalation).
Modify the front_door security properties
Open the ‘Properties’ dialogue box (right-click, ‘Properties’) and click on the ‘Security’ tab. If you are using Windows XP and there isn’t a ‘Security’ tab, then modify the ‘Folder options’ in Windows Explorer (‘Tools’ menu, ‘Folder options’). Click on the ‘View’ tab. Find the ‘Use simple file sharing’ setting and untick it. Then go back in to the ‘Properties’ dialogue box and there should be a ‘Security’ tab now.
Click on ‘Advanced’
Click on ‘Change Permissions…’
Untick the ‘Include inheritable permissions from this object’s parent’ option, then click ‘Apply’. You’ll get a dialogue box asking what you want to do with the permissions that were inherited.
Click on ‘Add’ (Windows 7 Professional) or on ‘Copy’ (Windows XP)
Modify the front_gate security properties
Click on ‘Edit’
Click on ‘List folder contents’ in the ‘Deny’ column
Click on ‘Apply’ and you’ll get a warning
Click on ‘Yes’
Now if you double-click to open the front_gate folder, you should get an error.
Do NOT click on ‘Continue’ — we want access to be denied.
The obvious question now is how do you actually get to your files? Simple — you can access the folder by typing the path to the sub-folder (front_door) in to the Explorer window. For example, if you have an Explorer window open in the folder containing the front_gate folder, simply type ‘front_gate\front_door’ in to the text box at the top of the Explorer window (the text box that shows the path to the current folder).
Accessing your hidden files
You can access your files from Explorer by typing the path to the hidden folder (front_door) in the text bar (which is displaying the path to the current folder). This is the folder containing the front_gate folder
Edit the path in the text bar at the top to add ‘\front_gate\front_door’
Et voila — we can now see the important-looking file that I placed in the front_door folder.
This front_door folder is a normal folder in that you can create new files/folders in it, and open files
You should also be able to open files in this folder directly from within an application
Type the path to the hidden folder (front_door) in to the ‘File name’ box
Pressing ‘Enter’ will list the contents of the folder in the dialogue box. Alternatively, you can also add the name of the file you wish to open (you can see that the dialogue box is showing a tooltip showing the names of matching files in the folder). Just pressing ‘Enter’ to list the files
You can then select the file and click on ‘Open’ to open it
Important Notes
This approach will only work (assuming it does at all!) if malware (ransomware) cannot guess, or otherwise determine, the name of the hidden directory (front_door in this example). Use something that is likely to be unique, but well known amongst the users that need to access it. The whole strength of this approach lies in the fact that the only place where the name of this hidden folder is stored, is in the heads of the users who need to access it.
If this is too troublesome, then you can write the name of this folder (or the path to it) down on a piece of paper and leave it on the desk. It doesn’t necessarily matter if this is discovered by your users because it is not providing access to the system — normal system access controls should still be in place to protect against unauthorised user access to files. I would NOT recommend leaving the path in a file on the system itself, as this would be discoverable by any adversaries who gain access to the system.
It would be possible to create a shortcut to the hidden folder which would make it easier for your users to find, but again this would be discoverable by any adversaries and hence defeat the purpose of the whole exercise. This will probably work until malware/ransomware realises what we’ve done and then starts looking for shortcut files with a directory as the target in order to discover the hidden directories.
Using the normal ‘Hidden’ attribute on a folder won’t work, as that attribute doesn’t stop the file/folder from being returned by a FindFirst()/FindNext() API call — that is, the file/folder is discoverable by anything that cares to look. My approach works because we deny the user the ability to look in to the top level directory (front_gate).
This approach will also only work until malware/ransomware realises what we’ve done and starts modifying the security settings on folders to give the current user ‘List files/folders’ permission. I suspect denying the ‘Full control’ or some such permission from the top level directory will stop this. However, like UNIX it may be possible for the owner of a directory to be able to change the security settings back again by adding ‘Full control’ and subsequently removing the ‘Deny’ on ‘List files/folders’. If this is the case, then the top level folder (front_gate) will need to be owned by a different user (get an administrator to create it). The sub-folder (front_door) can, and probably should so that it is usable, still be owned by the user.
Basically, the idea is to remove the ‘List files/folders’ permission from the top level folder (front_gate) whilst maintaining a perfectly usable sub-folder structure (front_door) underneath it, and also preventing the ability to add the ‘List files/folders’ permission back to the top level folder. I’m hoping that this then prevents malicious software from enumerating any files/folders below the top level folder (front_gate), and hence encrypting them.
Anti-virus software should still be able to scan the ‘hidden’ files because it will be running as an administrator or, more likely, as SYSTEM (the latter would be good as you can then even deny administrator access to the top level directory).
I also don’t know how this will go protecting files on a NAS/SAN system. In theory you should be able to take a similar approach — create a parent directory that doesn’t allow the listing of files/folders.
Disclaimer
I’m not guaranteeing anything in relation to this — use it at your own risk. I have done minimal testing, in that I have just tested that access appears to be restricted on both Windows XP and on Windows 7 Professional — I have not yet tested this with any ransomware or other malicious software! I’m posting this information in a hurry due to the issues caused by the WannaCry/WannaCrypt ransomware over the last few days, and now is pretty much the only time this week that I’ll get to do so. I intend to do more testing and then tidy this post up a bit when I get the time to do so. Until then, if anyone manages to test it with some ransomware and is willing to comment (to let other readers and myself know how it went), that would be appreciated.