Sandbox Evasion Techniques Blog Series

Primer | Part 2 | Part 4

This post is the third part in a series on sandbox evasion techniques used by malware today. We originally posted a primer, outlining the three main categories of evasion techniques by malware authors:

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)

We wrote that 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. Malware analysis sandboxes doing behavior-based detection are now considered the final layer of defense against advanced threats.

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. In the second part of the series, we did a deep dive into how malware can directly detect the presence of a sandbox environment.

In this post, we’ll look at how malware can exploit gaps in the sandbox environment, rather than explicitly detecting the presence of a sandbox.

Exploiting Sandbox Technology Weaknesses

Explicitly searching for the existence of a sandbox can be detected as suspicious activity during analysis. A more advanced approach for malware, therefore, exploits weaknesses in the sandbox technology to perform operations without being detected. By exploiting these sandbox weaknesses, malware does not have to worry about being detected even if it is being executed in a sandboxed system. Some of the techniques include:

Blinding the Monitor

Most sandboxes do in-guest-monitoring, i.e., they place code, processes, hooks etc. inside the analysis environments. If these modifications are undone or circumvented, the sandbox is blinded – in other words, visibility into the analyzed environment is lost. This blinding can take the following forms:

Hook Removal Hooks can be removed by restoring the original instruction or data

Hook circumvention Hooks can be circumvented by using direct system calls instead of APIs, calling private functions (which are not hooked), or performing unaligned function calls (skipping the “hook code”). We can see an example of this in this analysis report where illegitimate API usage by the malware to start and compromise explorer.exe and regedit.exe is detected. While this problem could be solved by hooks for these particular internal functions, there are many of these present in the operating system and they vary with each Windows version. Furthermore, the problem of unaligned function calls cannot be adequately solved by hooking.

System file replacement: Hooks usually reside in the system files that are mapped into memory. Some malware will unmap those files and reload them. The newly loaded file version is then “unhooked”

Kernel code. Many sandboxes are not capable of monitoring kernel code or the boot process of a system:

Obscure file formats: Many sandboxes do not support all file formats Powershell, .hta, .dzip etc. are some examples of file formats that may slip by and simply fail to execute in a sandboxed environment.

Many sandboxes do not support all technologies. While the initial infection vector (say, a Word document with a macro) may open and the macro run in the sandbox, the macro will download and run a payload that uses an obscure technology hidden from the analysis. COM, Ruby, ActiveX, JAVA are some examples that we’ve analyzed in previous blog posts.

Operating system reboots: Many sandboxes cannot survive reboots. Some systems try to emulate a reboot by re-logging in the user, however, this can be detected and not all triggers of a reboot are executed.



Blinding the Ecosystem

By simply overwhelming the target analysis environment, malware can also avoid analysis with this crude but sometimes effective approach. For example,

Some sandboxes only support files up to a certain size, e.g. 10 MB

Others don’t support multiple compression layers

Shining Light into Darkness

In order to ensure malware cannot evade analysis by these methods a sandbox analysis environment should:

Not rely on modifying the target environment.

In particular, a common approach for sandbox analysis is hooking. That presence of a hook (the injected user-mode or kernel-level driver that monitors and intercepts API calls and other malware activity) gives malware the opportunity to disable analysis.

Run gold images as target analysis environments.

For efficiency and convenience, many sandboxes have a ‘one size fits all’ approach. A single type of target environment is used for all analyses. A better approach is to use the actual gold images (that is, the standard and server OS and application configurations that your enterprise uses) as the target environment. That way, you can be assured that any malware that is targeting your enterprise and could run on your desktops or servers will also run in the analysis environment.

Monitor all malware-related activity, regardless of application or format.

Some sandbox analyzers, particularly those using a hooking-based approach, take shortcuts and compromises for the sake of efficiency in determining what activity is monitored. This can leave blind spots.

VMRay’s hypervisor-based monitoring approach accommodates all these scenarios. When used in conjunction with using real-world VM images as the target analysis machines, VMRay Analyzer will give full visibility into malware activity, regardless of attempts by the malware to obfuscate its intentions.

References: