Sandbox Evasion Techniques – Part 2

In our initial post on sandbox evasion we outlined the three main categories of sandbox evasion techniques:

  1. Sandbox Detection: Detecting the presence of a sandbox (and only showing benign behavior patterns on detection)
  2. Exploiting Sandbox Gaps: Exploiting weaknesses or gaps in sandbox technology or in the ecosystem
  3. Context-Aware Malware: Using time/event/environment-based triggers (that are not activated during sandbox analysis)

In this post we’re going to drill down into more detail on sandbox evasion techniques in the first category: when malware specifically detects the presence of a sandbox and switches to benign behavior.

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.

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:

  1. Detect 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 was to detect technical artifacts that existed due to the lack of full hardware support for virtualization (Paravirtualization). 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 type of virtualization detection. In the first, we see an attempt to detect if the malware is running inside VirtualPC:

Sandbox Evasion: malware detecting presence of VirtualPC
Fig. 1: VirtualPC detection by malware

You can see the full analysis report here.

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\HARDWARE\Description\System” to look for values associated with common VM implementations like VMWare:

Malware detecting VM presence by querying registry values

Fig. 2: VM detection by registry value query

You can see the full analysis report here.

  1. Detect 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

  • Using vendor specific knowledge related to:
    • Common VM products. For example, the existence of certain files, processes, drivers, file system structure, Windows ID, username etc.
    • The ecosystem. For example, mechanisms to:
      • Revert the analysis environment back to a clean state after infection: Deepfreeze, Reborn Cards
      • Perform communication with the sandbox controller: additional listening ports, specific network environment (master server, …)
  • 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 communication between processes, drivers and the OS. A hook can be implemented in many ways such as: inline hooks, IAT, EAT, proxy DLL, filter drivers etc. This makes them detectable by:
      • Explicitly inspecting certain instructions or pointers or by
      • Verifying the integrity of the system, e.g. verifying hash signatures of relevant system files
    • Some sandboxes use emulation, which comes with side-effects and small differences compared to a native system e.g. different instruction semantics, cache-based attacks etc. Emulation gaps can be detected, by, for example, 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 is here 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:

Fig. 3: Detecting a sandbox environment – Sandboxie
  1. 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 Fig. 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:


Fig. 4: Malware detecting Wine environment by API query

You can see the full analysis report here.

  1. 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.

An example of a timing-based detection is this sample, that when analyzed checked for rdtsc, the time-stamp counter:

Fig. 5: Malware attempts VM detection by the time-stamp counter

Our colleagues at ForcePoint did a more in-depth write-up on this fairly new approach here.

You can see the full analysis report here.

Sandboxing without detection

In order to evade these types of detection by malware, an 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) 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 sandbox analyzer can run an image copied from actual production endpoints, then the risk of detection falls dramatically. As we wrote earlier, 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 agentless hypervisor-based approach 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.

Next up, read Part 3 in the series: Exploiting gaps in sandbox technology.