Sandbox Evasion Techniques Blog Series
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).
Context-Aware Evasion Techniques
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:
Time Bombs
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:
- Simple to very complex sleeps (e.g. concurrent threads that watch each other or are dependent on each other)
- Executing only at a certain time or on a specific date (e.g. Monday at 12 AM or the 12th of March)
- Slowing down execution significantly. An example of this is injecting millions of arbitrary system calls that have no effect except to slow down execution, especially when being executed in a monitored or emulated environment.
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.
System Events
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.
User Interaction
- Waiting for mouse movements (but not too fast since this is a sandbox) or keyboard input.
- Interacting with certain applications, e.g. browser, email, Slack, or an online banking application.
- Fake installers: Malware only becomes active after a user has clicked multiple buttons and checked various checkboxes (See Figure 2).
- Office documents with malicious embedded content: The malicious content only becomes active when the user scrolls down (to see it) or clicks on it.
Detect a Specific Target System
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.
- Simple checks include string checks.
- Complex checks (e.g. decryption with hash taken from the environment settings) are nearly unbreakable if the expected target environment is not known.
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:
- If network usage statistics of the system are too low, then don’t do anything
- If ‘recently used documents’ are almost empty, then don’t do anything
- If a number of processes are < x, then don’t do anything.
How to Defeat Context-Aware Evasion Techniques
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.
References
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
