Sandbox Evasion: Detecting the Presence of a Malware Sandbox

Detecting the Presence of a Sandbox

There are a number of techniques to identify the existence of a sandbox. Once detected, the malware can react in different ways. The simplest step is to immediately terminate. This can raise a red flag since this is not the behavior of a normal, benign program. Another action is to show a bogus error message. For example, the malware may display a message that a certain system module is missing or the executable file has been corrupted. More sophisticated malware may perform some benign operations to conceal the real intention. Let’s take a deeper look into the different techniques used by malware in the wild to detect if it is being executed in a sandbox:

Detecting Virtualization/Hypervisor

This is one of the oldest evasion techniques. However, it is less relevant today as many production environments (workstations and servers) are virtualized anyway and virtual machines (VMs) are no longer only used by researchers and malware analysts. The earliest approach detected technical artifacts that existed due to the lack of full hardware support for virtualization (Paravirtualization). These techniques include:

Detecting artifacts of popular VM hypervisors, e.g. VMWare (“port 0x5658”) or Virtualbox via a backdoor (“invalid opcode”).
Detecting generic hypervisor artifacts: The most famous one is redpill (“IDTR could not be virtualized”)

These techniques are not very effective today. With hardware virtualization support, there are very few visible artifacts (if any) inside the VM since most hardware aspects are now virtualized and handled by the CPU itself. Therefore, they do not have to be simulated by the hypervisor.

Another approach that is still relevant today is detecting the implementation artifacts of the hypervisor
- For example: Reveal vendor from MAC address, device IDs or the CPU ID or from the existence of certain processes, files, drivers, registry keys or strings in memory

We’ve published two analyses demonstrating a couple of types of virtualization detection. In the first, we see an attempt to detect if the malware is running inside VirtualPC:

Another approach is to detect the presence of a VM by looking at registry values. In this example, the malware queried the registry key “HKEY_LOCAL_MACHINE\SOFTWARE\” to look for values associated with common VM implementations like VMWare:

Detecting Sandbox Artifacts

In this approach, it is not the hypervisor that the malware is trying to detect, but the sandbox itself. This can be done either by two of the following techniques:

Using vendor-specific knowledge

Common VM products. For example, the existence of certain files, processes, drivers, file system structure, Windows ID, or username
The ecosystem. For example, mechanisms to revert the analysis environment back to a clean state after infection (Deepfreeze, Reborn Cards). In addition, performing communication with the sandbox controller (additional listening ports and the specific network environment.

Using certain sandboxing technologies for detection

Most sandboxes use hooks (i.e. they inject or modify code and data within the analysis system). The ‘hook’ is essentially a shim layer capturing the communication between processes, drivers, and the OS. A hook can be implemented in many ways such as inline hooks, IAT, EAT, proxy DLL, or filter drivers etc. This makes them detectable by explicitly inspecting certain instructions or pointers or verifying the integrity of the system (verifying hash signatures of relevant system files).
Other malware sandboxes use emulation, which comes with side-effects and small differences compared to a native system. This includes different instruction semantics and cache-based attacks. Emulation gaps can be detected by invoking an obscure CPU instruction that was not included in the emulation. When the call fails, malware will know it is running in an emulated environment.

An example of vendor-specific detection can be seen in Figure 3, where the malware looks for the presence of the module ‘SbieDll.dll” – an indicator that it would be running in under Sandboxie, a common sandboxing environment:

Detecting An Artificial Environment

Sandboxes are usually not production systems but specifically set up for malware analysis. Hence, they are not identical to real computer systems and these differences can be detected by malware. Differences may include:

Hardware properties
- Unusually small screen resolution, no USB 3.0 drivers, lack of 3D rendering capabilities, only one (V)CPU, small hard disk and memory sizes
Software properties
- Atypical software stack, e.g. no IM, no mail client
System properties
- Uptime (“system was restarted 10 seconds ago”), network traffic (“system uptime is days, but only a few MB have been transmitted over the network”), no or only default printers installed
User properties
- Clean desktop, clean filesystem, no cookies, no recent files, no user files

To demonstrate, we’ll go back to the same analysis we looked at in Figure 2. In addition to checking for VM presence, the malware is looking for the presence of Wine, a software emulator (that is, it emulates Windows functions, rather than CPU emulation). We can see here in the VTI Score that the malware is doing a query, GET_PROC_ADDRESS and attempting to determine from the returned result if it what would be expected in a Wine environment:

Timing Based Detection

Monitoring the behavior of an application comes with a timing penalty, which can be measured by malware to detect the presence of a sandbox. Sandboxes try to prevent this by faking the time. However, malware can bypass this by incorporating external time sources such as NTP.

In Figure 5 you can see an example of timing-based detection. The VMRay Analyzer Report shows that the sample checked for rdtsc, the time-stamp counter.

How to Defeat These Sandbox Evasion Techniques

In order to evade these types of detection by malware, an analysis environment should:

Do 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) is a telltale sign for malware. It is virtually impossible to completely hide the presence of a hook.

Either implement full system emulation perfectly or not at all

While a perfectly-implemented emulation environment will be, in theory, difficult to detect, this is a complex undertaking. Just as all software has bugs, it’s a near certainty that any given emulation environment will have flaws that can be detected.

Use a target analysis environment that is ‘real’

If the malware sandbox can run an image copied from actual production endpoints, then the risk of detection falls dramatically. As we wrote earlier in this post, coupling that with randomization of the environment helps to ensure that there are no tell-tale signs for malware to identify the target environment as ‘fake’

VMRay’s technology ensures that there is a minimal attack surface for malware to detect it is running in a sandbox. By not modifying the target environment, not relying on emulation, and allowing real-world images to run as target environments, VMRay gives nothing for malware to flag as a sandbox environment.

References

http://theinvisiblethings.blogspot.de/2006/06/introducing-blue-pill.html

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1009458

https://www.blackhat.com/docs/asia-14/materials/Li/Asia-14-Li-Comprehensive-Virtual-Appliance-Detection.pdf