Tips on How To Detect Encrypted Files (or The Battle against Ransomware)

The Problem


Even with multiple lines of defense in place, someone in your network is inevitably going to click on that attachment or link prompting them to open that scan or document they requested (if they would briefly stop and think about it, they actually did not scan or request any document) and the next thing you know every document on the shared drive is encrypted. Welcome to the wonderful world of ransomware!

The only real solution to this problem up until now once the damage has been done is to have a good backup (and/or Volume Shadow Copy). Although I have heard stories that you can actually pay the ransom fee and you will get your files back that may work for home users, but I doubt very much that an organization with hundreds of thousands of files infected is going to get off the hook for $500.

So for now restoring from the latest backup seems to be the best line of defense against ransomware, I do however anticipate a future where things will become much harder to protect against. For example, what if a crafty hacker was able to detect documents that are important, but are only opened once a year for review?

What can you do?

  1. For Windows workstations turn on System Protection and also make sure users either do not store documents locally (that is what I recommend) or have a backup in place.
  2. From servers: As I mentioned above, make sure you have backups and/or Volume Shadow Copy turned on.
  3. Read this
  4. This Scan Tool should be useful to identify encrypted files (I have never used it, though).
  5. Use Powershell to test files for Crypto. Typically it is easy to find out who is infected by checking the owner of an encrypted file and also recording the time when the file was last modified. The script below can be modified accordingly to scan through your shared folders and find what has been encrypted. Edit the file, then Dot-Source the file to your Powershell session ( then run it by using:
    Get-Postcrypto Path
    Example Get-Postcrypto “E:\shared\Company”


The Case for Antivirus Exclusion Libraries

One of the most frustrating tasks when you set up an Antivirus Management Server from any vendor (my experience is with CA, ESET, McAfee, Symantec and Trend) is setting up the scan exclusion lists. This is the painstaking task of manually entering in every folder, extension and file that should be excluded from any scan activity. There are lots of them. Microsoft alone has 15 or so Technotes on the subject to cover their products. Then every other vendor provides their own list. To make matters worse, the exclusion list has to be entered in duplicate: Once for the real time scanner and once for the scheduled scans. What a pain!

Because this is a manual task mistakes can be made. And woe is the IT person who makes a mistake: You can be sure that the antivirus scanner will eventually corrupt a critical file and crash you system or even worse. Case in point: I recently pulled an all nighter because the Trend scanner corrupted the Hyper-V configuration files on a Windows 2008 Enterprise server. Result: All Virtual Machines were lost!

So why don’t the antivirus vendors assume the responsibility of creating a library of exclusions that I can just drop into my Management Server and voila, the task is done? These would include exclusions for:

  • Domain Controllers
  • Hyper-V Hosts
  • Exchange
  • SQL
  • Cluster Servers
  • DNS, DHCP, etc
  • Pagefiles and Hibernation files

Granted, this would not be a trivial task, because after all the location of these files can change, and this is probably the main reason why this has not been attempted in the past. But the least they could do is to make editing of these exclusion lists simple.

Oh, and by the way, the details on how to fix the Hyper-V configuration file corruption issue can be found here.