This post is the first part in a series on sandbox evasion techniques used by malware today. After this primer, in subsequent posts, we’ll drill down deeper into the details for each of the three main categories of evasion techniques.

The use of malware analysis sandboxes as the silver bullet against advanced, persistent threats became popular over a decade ago. Back then, malware authors had already found ways to evade tools based on static analysis (such as traditional antivirus software products) using techniques such as polymorphism, metamorphism, encryption, obfuscation and anti-reversing protection. As a result, malware analysis sandboxes are now considered the last line of defense against advanced threats.

The operating principle of a sandbox is simple – determine if a file is malicious or not based on its observed behavior in a controlled environment. The sandbox allows the malware to perform all of its malicious operations and records the resulting behavior. After some time, the analysis is stopped and the result is examined and scanned for typical malicious behavior patterns. Since detection is not based on signatures, sandboxes can even detect zero-day and targeted malware (which typically has never been seen before by security researchers or analyzed in an antivirus lab).

Obviously, behavior-based malware detection only works if the observed file actually performs malicious operations during its analysis. If – for whatever reason – no harmful operations are executed during the analysis, the sandbox concludes that the file under examination is benign. Malware authors are always looking for new, innovative ways to evade sandbox detection by concealing the real behavior of malware. We’ve grouped these approaches into three categories:

1. Sandbox Detection: Detecting the presence of a sandbox (and only showing benign behavior patterns on detection)
2. Exploiting Sandbox Gaps: Exploiting weaknesses or gaps in sandbox technology or in the ecosystem
3. Context-Aware Malware: Using time/event/environment-based triggers (that are not activated during sandbox analysis)

Sandbox Detection

This first approach detects the presence of a sandbox by looking for small differences between a sandbox environment and a real victim’s system. If a sandbox is detected, malware usually reacts in one of two different ways: it either terminates immediately (which is in itself suspicious) or it shows non-malicious behavior and performs only benign operations. An example of this is shown in Figure 1, where the sample: attempts to detect if it is running inside a virtual machine (VM) and looks to see if there is an application sandbox running (Sandboxie).

We can see this in the VMRay Threat Identifier (VTI) details showing that VMRay identified the sandbox detection attempts and scored this behavior as highly malicious.

Exploiting Sandbox Gaps

The second category of evasion techniques directly attacks and exploits weaknesses in the underlying sandbox technology or in the surrounding ecosystem. For example, we have recently seen a large volume of malware using Microsoft COM internally because most sandboxes cannot correctly analyze such samples.

Other malware will use obscure file formats that cannot be handled by the sandbox or they exploit the sandbox’s inability to process files that exceed a certain size. In Figure 2 we can see an example of malware ‘blinding the monitor’. Meaning it is – that is performing illegitimate API usage. This can be an effective method to hide from malware sandboxes that rely on a hook or driver injected into the target machine. However, since VMRay Platform does not use hooking, the evasion attempt was detected.

Context-Aware Malware

The third category represents malware that does not try to detect or attack the sandbox at all. Instead, it exploits the natural shortcomings of such automated systems. Because of the high volumes of unique malware seen in most environments, sandbox analysis systems usually only spend a few minutes on each file. Thus, by delaying the execution of a malicious payload by a certain amount of time, malware can remain undetected. Besides time-triggers, malware can also use other events that usually do not occur in a sandbox, e.g. a system reboot or user interaction. Additionally, the malware may be looking for specific artifacts present on the intended target machine, such as an application or localization setting.

In Figure 3, we see an analysis where the malware, in addition to attempting to detect a VM environment, engaged in ‘persistence’, installing startup scripts and applications to survive reboot: