This is our final post in a series on sandbox evasion techniques used by malware today. We started with a primer, and then covered the two main categories of evasion techniques sandbox detection, and exploiting malware sandbox gaps.
In this post, we will be highlighting the context-aware evasion techniques that: use time, event, and environment-based triggers that are activated during sandbox analysis).
This category of evasion techniques, like exploiting sandbox technology gaps, does not try to detect a sandbox. Nor does it try to conceal malicious behavior by circumventing a sandbox or exploiting a sandbox’s weaknesses.
Instead, it delays or postpones its malicious payload until a certain trigger/event occurs. The trigger that is chosen is very unlikely to be activated inside a sandbox. Triggers can be grouped into four categories:
One of the most common techniques is to delay execution for a certain amount of time since sandboxes usually run samples only for a few minutes. As with many other evasion techniques, the utilization of time bombs, in particular, is an ongoing cat and mouse game: the malware goes asleep, the sandbox tries to detect sleep and shorten the time, malware detects shortened time, the sandbox tries to hide time forward by also updating system timers and so on. Time bomb techniques include:
For example, Figure 1 shows a Pafish test running VM detection of certain artifacts that often exist in analysis environments. Note the timestamp checks. Malware will also run checks like this and if a difference is found in the counters, shut down on the assumption it is running inside an analysis environment.
The malware only becomes active only on shutdown, after reboot, or when someone logs on or off. Figure 2 shows an example of this, where a second-stage payload is pulled down only after a reboot. We can see in the VTI score that an executable is installed by the malware (the initial payload) that will run automatically on startup after reboot. It’s this startup process that fetches the second payload.
Sophisticated targeted malware only works on the intended target system. The identification is usually based on the current username, time zone, keyboard layout, IP address, or some other system artifacts. The check itself can be done in various ways, ranging from simple to very complex methods.
The malware will only proceed to the second stage (that downloads the main payload) if it determines it is in the expected target environment.
Related to this is the inverse scenario where the malware detects that the environment is most likely an artificial analysis environment. This can be the result of checks such as:
Of the three categories of sandbox evasion techniques we have blogged about, context-aware malware is the least sensitive to the underlying malware sandbox technology. As sandbox technology improves and finds ways to circumvent sandbox detection, environmental triggers will become increasingly important to malware authors.
It is critical for security teams to ensure they are using target analysis environments that accurately replicate in every detail the actual desktop and server environments they are protecting. Furthermore, as we wrote previously, it’s important to have pseudo-random attributes as part of the target analysis environment.
Generic sandboxes running identical standard target environments are no longer sufficient. Further, the analysis environment needs to be able to detect environment queries and identify hidden code branches. VMRay Analyzer has the ability to randomize analysis environments, including when desktop or server gold images are used as the targets. Additionally, VMRay Analyzer will flag when malware is making environment queries. Combined, these ensure that security teams get the full picture and know when they are dealing with context-aware malware.
http://theinvisiblethings.blogspot.de/2006/06/introducing-blue-pill.html
https://www.exploit-db.com/docs/34591.pdf
https://www.brokenbrowser.com/detecting-apps-mimetype-malware/
https://www.symantec.com/avcenter/reference/Virtual_Machine_Threats.pdf
https://blogs.forcepoint.com/security-labs/locky-returned-new-anti-vm-trick