NAS Crypto Ransomware Defense

With the proliferation of assorted crypto ransomware, I began to think about ways that I could secure my NAS in the event that a computer on my network were to become infected. Having recently received an email trying to trick me into clicking an attachment which probably contained a crypto ransomware trojan, I decided that it was time to stop thinking and finally take action.

Crypto ransomware can encrypt files on a NAS, whether a share is mapped to a drive letter or not, and the only way to be relatively certain of keeping files safe is to grant “Deny” or “Read Only” access. However, this creates a problem. How can one manage the files on their NAS with “Read Only” access?

Each individual’s needs will vary, but in my case the vast majority of my files only require “Read Only” access, except when I move new files to the NAS, or update existing files. Obviously, I can’t add or update files without “Read / Write” access, so I came up with a way of allowing myself the freedom to add or update files, while minimizing the risk to existing files.

Enter the dreaded Public folder, the one which many people want to delete, but Western Digital (in all their wisdom) decided to make permanent. Despite being a nuisance and a potential security risk, the Public folder can be used as a temp folder, or a staging area where files can be written, then later moved to their final destination. Fortunately, one can control whether or not the Public folder is “Public” and which users have access to it. The possible options are: “Deny”, “Read Only” and “Read / Write”. Alternatively, one could also create their own share for this purpose.

The first step is to turn off “Public” access for the Public (or custom) staging share, and it might also be a good idea to turn off the recycle bin for this share, unless you want the functionality as an additional backup.

The next step is to create a new user account which will only have “Deny” or “Read Only” access to all shares except the Public (or custom) staging share. One could use the admin user account for this, but I don’t recommend it.

Lastly, ensure that all mapped network shares are logged in using the new user account, and that they only have “Deny” or “Read Only” access to all shares except the Public (or custom) staging share. This can be tested by trying to copy a file to each mapped network share. If done correctly, an “Access Denied” error (or something similar) should appear for all shares except the Public (or custom) staging share.

Ok, but how does one manage files on the NAS? In other words, how does one move files from the Public (or custom) staging share to their final destination? To do this, there are a few possible options.

1. One could use the built-in NAS file manager, but it tends to be rather cumbersome for moving a large number of files to many different shares and/or subfolders.

2. One could use a separate computer that only has local network access (no internet), plus a NAS user account with “read / write” access to each mapped network share.

3. One could log into the NAS and enable “read / write” access on an as-needed basis when they need to move files from the Public (or custom) staging share to different shares and/or subfolders. Don’t forget to change the NAS user permission back to “Deny” or “Read Only” access when finished. Also, it’s IMPORTANT to logout or reboot the client computer for the new permissions to take effect. Note: This is currently my preferred option, at least until I find something better.

Finally, there is one more step one must take to ensure that no other user account has “Read / Write” access to other NAS shares. Most computers cache network login credentials, and it’s VITAL that these cached credentials be deleted so that a back door isn’t left open for Crypto Ransomware to exploit. Methods for doing this vary, so you’re on your own here. Alternatively, one could simply change the NAS user name that was previously used to gain “Read / Write” access to shares, which is equally effective.

Obviously, this does not mitigate all risk, largely because the Public (or custom) staging share still has “read / write” access, and user error is definitely a factor. Regardless, if done correctly, it should at least provide an additional layer of defense that Crypto Ransomware has to overcome before it can encrypt the majority of the files stored on the NAS.

This is a great subject for discussion.

Other things to keep in mind are BACKUPS!! My PCs are backed up every night to a NAS Share for which the credentials are not available in Windows credential cache. Meaning even though the share is visible, the only thing that can log into it is the backup software which maintains its own credential lockbox.

NASes can be backed up as well using similar means — using a dedicated share that only it has credentials to, or using a PC as an agent.

Finally, I never tell Windows to remember my NAS login credentials. If I remember to log out of my Windows account, there is no possibility of ransomware getting easy access to private shares the next session, even if they are mapped, as the ransomware can’t access the drive until a user authentication completes.

You are absolutely correct. Backups are an important first step. In addition, you reminded me about cached network credentials, which I had forgot to mention. To be safe, I simply changed the NAS user name, but others may not be able to do this for various reasons.