Identifying and Disrupting Crypto-Ransomware (and Destructive Malware)

In recent years, malware has become very personal. Crypto-ransomware threats, including CryptoLocker,CryptoWall and TorrentLocker (pdf), have infected home users, businesses and even police departments, all of whom have had their personal data and hard work held hostage. When we think of precious family photos or an academic thesis being wiped by pure greed, it can become rather emotive. This is nasty stuff, and we need to do something about it!

I have been giving some thought to how we can stop crypto-ransomware doing it's thing. Initially, I thought about interfering with the Windows CryptAPI, perhaps hooking the CryptEncrypt function, however page 16 of a report analysing various samples by Bromium shows that some samples use CryptoAPI, others use OpenSSL libraries and a few even use custom inline code.

I then began thinking about what else was common to all of these threats and realised that they all (by their very nature) access a LOT of files, and therefore create an above average number of handles.

This is also true of destructive malware, a growing trend which strikes fear into most enterprise administrators. This involves vast numbers of personal and system files being overwritten to prevent them from being recovered. Sure, we (should) have backups, but can you imagine rebuilding a network with 200,000 endpoints? Ouch!

Okay, so what is a handle?

Microsoft provides a neat definition of a handle on MSDN, and rather than trying to re-word it, I have attached a quote from the site below:

Microsoft - Windows Dev Center - Handles and Objects

An object is a data structure that represents a system resource, such as a file, thread,
or graphic image. An application cannot directly access object data or the system
resource that an object represents. Instead, an application must obtain an object handle,
which it can use to examine or modify the system resource. Each handle has an entry in
an internally maintained table. These entries contain the addresses of the resources and
the means to identify the resource type.

This is one of the several layers of abstraction that separate the user (and all the processes they're running), from their physical assets, such as the hard drive. Any request to access a file on disk needs to go through the Windows kernel, and if you want to modify that file in user mode, you need to create a handle—simple as that!

So how are handles going to save me?

As we've discovered, if crypto-ransomware wants to read and then encrypt your files, it needs to create a handle for every file it interacts with. It doesn't matter what encryption algorithm it uses, this is a much lower level concept based on how the Windows kernel interacts with system hardware.

If we can keep an eye on the frequency of new handles being created by every process we might be able to detect abnormal activity. This would also apply to destructive malware that has been designed to overwrite lots of files to prevent recovery. Don't forget, if it wants to write to a file, it needs a handle.

To trial this concept, I've written a tool named handle_monitor, which takes stock of every file handle, by process, across the system. It then has a little pause (at the users discretion), and checks again, identifying any new handles which haven't been seen before and tallies up the number of new handles created. If a threshold is passed within a defined number of cycles, then an alert is raised and an action (such as suspending the suspicious process) can be taken.

Demonstration

To replicate the effect of malware which makes a large number of disk read/write operations, I've written a small program called hm_test.exe, which writes the requested number of files to disk.

Figure 1. hm_test.exe writing to a large number of files

The Handles tab from the Process Hacker properties page shows the rapid creation and release of handles as the files are written.

Figure 2. Process Hacker demonstrating the open handles

Now as we launch handle_monitor, we are able to specify, in detail, every element of the analytical process and how the program will go about monitoring. Notice that in this case we are using the /suspend parameter which instructs the program to attempt to suspend any suspicious processes.

Figure 3. handle_monitor.exe being launched with custom parameters

Within seconds, the program identifies, based on our options, that hm_test is acting suspiciously and suspends the process. If this was crypto-ransomware, it would have been stopped after only encrypting approximately 30 files.

Figure 4. hm_test's activity being caught (and suspended) by handle_monitor

How about a video demo?

You can watch the tool in action by clicking on the image below, which will take you to a YouTube video demo of the tool in action.

How about false positives? I don't want to accidentally suspend my antivirus!

Good question. This isn't an exact science and the key to this tool is that the user has the power to decide:

• Whether suspicious processes are suspended, or we just raise an alert
• Whether we ignore signed processes assuming they're safe and focus only on unsigned or whether we review all of them
• What the threshold is for suspicious activity? We can set it as X new handles in Y cycles

I'd be really interested in hearing what settings work for the samples you hold. A comprehensive analysis of what settings worked against a variety of samples might be a nice idea for a GIAC Gold paper for anyone who is interested in completing one!

The default settings are fairly conservative and you may want to start with a threshold of 2 in 10 cycles with a 100ms pause (as per the example) to increase your chances of finding something. It is worth noting that the lower the pause time, the higher the amount of system resources the program will use, and the lower the threshold, the higher the chances of false positives.