Sandbox Evasion Techniques – Part 4
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 other main categories of sandbox evasion techniques:
- Sandbox Detection: Detecting the presence of a sandbox (and only showing benign behavior patterns on detection)
- Exploiting Sandbox Gaps: Exploiting weaknesses or gaps in sandbox technology or in the ecosystem
In this post, we drill down into the third major category:
- Context-Aware Malware: a.k.a. Environment-sensitive malware. Using time/event/environment-based triggers (that are not activated during sandbox analysis)
Context-aware or Environment-sensitive malware
Using time/event/environment-based triggers
This third approach, like sandbox gap exploitation, 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/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, sandbox tries to hide time forward by also updating system timers and so on.
- 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 or 12AM or the 12th of March.
- Slowing down execution significantly, e.g. by 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 which 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
- Become 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.
3. User Interaction
- Wait for mouse movement (but not too fast since this is a sandbox) or keyboard input.
- Interact with certain applications, e.g. browser, email, Skype, 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.
4. 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 is download 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 number of processes is < x, then don’t do anything.
Of the three categories of sandbox evasion techniques we have blogged about, context-aware malware is the least sensitive to the underlying sandbox analysis technology. As analysis technology improves and finds ways to circumvent sandbox detection, environmental triggers will become increasingly important to malware authors.
Hence, it is critical for incident responders and analysts 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 analysts get the full picture and know when they are dealing with context-aware malware.
- VMWare port: https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1009458
- Breaking the Sandbox: https://www.exploit-db.com/docs/34591.pdf
- Analysis report showing Blinding the Monitor