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.
I’m a little lost in this article. How can you “look in” when you have nothing on the sandbox to monitor? You have to go inside the sandbox somehow to see registry changes or new processes.
Also, all the ransom-ware I have analyzed doesn’t download the decryption key from the C2 servers. It uploads the decryption key to the C2 server so that if the user pays, they can get it back….
Dear Concerned Reader:
To explain how we achieve our results without revealing confidential information would expose the product to future detection by malware. Simply put, our presence inside the analysis environment isn’t detectable due to the way it was built. This is what allows us to monitor and gather all of the network/process/artifact/registry info that we do.
Is the ransomware looking for a debugger process or simply whether the host has the program installed? If it’s the latter, wouldn’t an easy way to defeat (some) ransomware be by installing OllyDbg?
Is there a way to fake a virtual environment to defeat what they are looking for?
Hi Robert,
Malware authors often design their attacks to check for the presence of a debugger, as this is an indication that the malware is being analyzed. They typically do this by checking to see if a PE file imports the IsDebuggerPresent symbol.
However, this is just one of over a hundred different techniques that we are aware of, that they use to detect the presence of a sandbox. Our experienced malware team actively works on ensuring we keep up-to-date on the latest techniques being used, and we apply this knowledge so that the AMP Threat Grid malware analysis and threat intelligence platform can detect and report when we see a file submission trying to detect and/or evade a sandbox’d environment.