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 have 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:
- 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
- Context-Aware Malware: Using time/event/environment-based triggers (that are not activated during sandbox analysis)
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 analyzed here, where the sample:
- Attempts to detect if it is running inside a virtual machine (VM)
- Looks to see if there is an application sandbox running (in this 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 approach 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 that use Microsoft COM internally because most sandboxes cannot correctly analyze such samples. Other malware will use obscure file formats which cannot be handled by the sandbox or they exploit the sandbox’s inability to process files that exceed a certain size. We’ve published an example here where the malware attempts ‘blinding the monitor’ – that is, evading analysis by doing illegitimate API usage. This can be an effective method to hide from analyzers that rely on a hook or driver injected into the target machine. However, since VMRay does not use hooking, the evasion attempt was detected and scored:
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. Or, the malware may be looking for specific artifacts present on the intended target machine, such as an application, localization setting or the like as we discussed here.
In this example, we see an analyses where the malware, in addition to attempting to detect a VM environment, engaged in ‘persistence’, installing startup scripts and applications to survive reboot:
We’ll go into more detail in a series of coming blog posts on each of these categories, showcasing examples of malware leveraging a relevant evasion technique. Want to keep reading? Check out Part 2, where we dive into three types of sandbox detection techniques.
- 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