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:
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:
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.
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:
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:
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:
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:
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.
In order to evade these types of detection by malware, an 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) is a telltale sign for malware. It is virtually impossible to completely hide the presence of a hook.
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.
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.