Detecting Ransomware From The Outside Looking In

Most malware analysis technologies, like sandboxes, put some sort of hook or software inside their analysis environment in order to observe what is actually happening. This could be a specific DLL file, or a debugger. The problem with this approach is that malware authors are aware of it, they look for it, and they build code into their products to identify these hooks and prevent the malware from detonating if they are present. This makes it difficult to catch malware that is environment-aware, such as ransomware.

Ransomware is some of the most evasive malware out there right now. It does everything it can to evade detection. First, it looks to see if it’s operating in a virtual environment, because why bother locking up a machine that can simply be reimaged without losing anything? Second, it will check to see if it’s in a sandbox (back to looking for specific binaries or debuggers). If it finds these conditions to exist, it will not execute. But if it thinks everything is okay, it will proceed to contact the C2 servers to get the decryption key before locking up all your precious files! And if you’re mapped to a large network drive with read/write access, it’ll take that down as well.

So how do you detect ransomware? Not all malware analysis platforms are created equally. Cisco’s AMP Threat Grid platform uses an outside-looking-in approach to analysis. That means there is no instrumentation inside the analysis environment. Not only does this help us outsmart environment-aware malware, it also provides for much richer analysis with greater context. We can see:

All DNS traffic

What domains and IP’s the malware is communicating with

Artifacts that are being created

Any processes that take place during runtime

All registry activity (add, modify, delete) that takes place during runtime

Here is a video showing execution of a sample of TeslaCrypt in Threat Grid’s malware analysis environment. In this video the ransomware executes and encrypts the sandbox incredibly quickly, completely unaware that it is both inside a virtual environment and a malware analysis platform. This highlights how Threat Grid is evading detection, and able to provide rich context about what the malware is doing.

Thanks to this outside-looking in approach, you’re able to see a host of information and take action on it. For example, looking at the behavioral indicators we see:

1. Files that are being created/dropped by the malware, as shown below. Use this to search for other potentially affected systems.

2. HTTP and DNS traffic that is being generated, connections established, and proactively block those URL’s in your web proxy while also generating a list of potentially affected endpoints.

3. What registry and filesystem activity has taken place? In this case we see an executable that was created in the user’s home directory instead of the program files path is being set to persist through a reboot. Using a group policy, such as in AMP for Networks, configured to disallow applications from running from a user’s home directory is one example of a countermeasure to this type of persistence mechanism (additionally, not letting users have administrator privileges can have a substantial positive impact in combating threats such as this ransomware).

If you are evaluating security technologies and have “sandbox” as a required item, make sure it’s not simply a check box on a vendor’s features list. If it doesn’t use an outside-looking-in approach it’s likely not effective against advanced malware, especially ransomware.

To hear how others are taking advantage of AMP Threat Grid, visit www.cisco.com/go/amptg.