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:
We wrote that the use of malware 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.
Explicitly searching for the existence of a sandbox can be detected as a 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:
Most sandboxes do in-guest-monitoring, (i.e., they place code, processes, and/or hooks) 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:
Hooks can be removed by restoring the original instruction or data.
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 Figure 1 where illegitimate API usage is utilized by the malware. While hooks could solve this problem 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.
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”.
Many sandboxes are not capable of monitoring kernel code or the boot process of a system.
Many sandboxes do not support all file formats. Powershell, .hta, and .dzip are examples of some file formats that may slip by and simply fail to execute in a sandbox environment.
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.
Many sandboxes cannot survive a reboot. Some systems try to emulate a reboot by re-logging in the user. This can be detected, however, and not all triggers of a reboot are executed.
By simply overwhelming the target analysis environment, malware can also avoid analysis with this crude but sometimes effective approach. For example,
In order to ensure malware cannot evade analysis by these methods a sandbox analysis environment should:
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.
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.
Some malware sandboxes, 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 technology 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.