Detect Ransomware With Hyperionix

Ransomware has been plaguing the world for years. The dark web has a whole industry dedicated to creating on-demand ransomware variants. There are actually programs you can buy that can help you generate a brand new ransomware that won’t be detected by existing anti-virus solutions in a few clicks. This is why most ransomware prevention solutions focus on catching the behavior rather than the signature. Instead of looking for known ransomware variants, most successful solutions look for specific chain of operations. An example of this behavior chain is a user downloading an executable in a browser, the user starts the executable which immediately creates an encryption key, opens many files and rewrites them.

In this blog post we will show you how easy it is to use Hyperionix to detect such a behavior, block it and even save the encryption key so any missed files can be easily decrypted. Hyperionix makes it easy to monitor and modify low-level system behavior. Hyperionix gives you an agent and a central online management console. You can use it to deploy probes written in Lua that can monitor and modify the behavior of systems on your network. In this case, we will use it to monitor cryptographic key usage and file operations. Hyperionix will terminate processes it determines to be ransomware based on their behavior. It will also send events to Splunk notifying you of this detection. As part of the event we will include the decryption key that will allow us to unlock any files encrypted by the ransomware.

For this demo we will use the gandcrab ransomware. It is recommended that you go over the tutorial before trying to run this demo yourself.

We will be looking for this specific chain of events to detect ransomware behavior:

1. A file is created with the “Zone.Identifier” alternate data stream. All major modern browsers add this stream to downloaded files to let Windows know the file didn’t originate on the system.
2. The file was moved, renamed or copied.
3. A process was created with the downloaded file as the backing file.
4. This process exports a cryptographic key. Ransomware does that so they can send the key to their servers and give it back to you for a ransom.

It is possible to detect the actual file encryption too, but we will stop at detection of the cryptographic key for brevity.

Detect File Download

To detect file operations we hook all the relevant functions in ntdll.dll. Here we only need the NtCreateFile function which is called for creating files. This function will also be called when creating an alternate data stream. To catch the file download we can filter for creations of “Zone.Identifier” alternate streams and report them.

The resulting code defines a hook probe that installs onExit handler to be called when the probe detects an exit from a call to NtCreateFile. The interesting logic part goes into the onExit handler, where it checks the filename to see if it’s ADS, and then if it’s “Zone.Identifier”. Finally it sends an event to Splunk with the details.

Detect File Move/Copy

Next we need to detect any file movements or copies. This handles both the case of browsers giving downloaded files a temporary name before renaming to the final name, and the case where a user renames or moves the file before executing it.

To detect this event for this demo we will focus on NtSetInformationFile and its ability to move/renames files. There are a few more corner cases to be handled for production use cases and you can see those in the source code. For now we will focus on FileRenameInformation operations. Just like before we will define a hook, a probe, and the onExit handler for NtSetInformationFile.

Detect Process Creation

Next we need to detect when a user executed the downloaded file and created a process. This is where things get interesting. Detecting process creation is pretty basic and our basic packages already come with a probe that can do this. To detect that a process was created from a file that was just downloaded, we need to keep some state. We need to remember the file was downloaded from the internet and then for every process created, we need to check if its backing file was that file.

To do this we use Entity State Machines or ESM for short. These state machines are capable of detecting a certain flow of events. In our case we will detect a file being downloaded using the probe above, the same file being optionally renamed or copied, and then finally a process being created with the same file. When all three events are detected we are going to generate a new event to signify this important flow.

Detect Suspicious Operations

Now that we have a new composite event called ProcessCreateFromDownloadedFileEvent, we can further combine it with other events to detect suspicious operations by a suspicious process created from a suspicious file. All these events together should give a stronger indication of something malicious going on. When we are done, we will be detecting a chain of suspicious behavior instead of just a signature on a file like classic anti-virus solutions.

All we have left to do is create an ESM that waits for an event about a downloaded file being executed and then wait for that process to export a cryptographic key. To keep this readable, we will skip the probe code and instead point you to the source code. In this example we will simply send an alert to the backend with the encryption key, but it is possible to kill the process or combine this with even more events to get a more concrete detection.

Result

The final ESM can be viewed in our packages repositories. It handles a few more corner cases we weren’t able to cover in this short blog post. But even with this basic demo, we were still able to detect and block ransomware on a system just by its behavior patterns.

Gancrab Detection Demo

Summary

Using nothing but Lua code, we created a state machine that detects a file being downloaded, executed, and then trying to encrypt files. This event was finally reported to a central location. We used the system behavior and didn’t rely on any signatures. We didn’t have to write any low-level C code to hook anything and we didn’t have to deal with any incompatibilities with the browser. We just wrote the business logic and had a successful detection in a few simple steps.