Breaking the Sandbox
Author: Sudeep Singh
Introduction

In this paper, I would like to discuss various existing and interesting techniques which are used
to evade the detection of a virus in Sandbox. We will also look at ways a sandbox can be
hardened to prevent such evasion techniques.
This paper is targeted towards those who have an experience with Windows OS internals,
reverse engineering viruses as well as those who are interested in developing detection
mechanisms for viruses in a Sandboxed environment.
A deep understanding of the evasion techniques used by viruses in the wild helps us in
implementing better detection mechanisms.
Purpose
New offensive techniques give rise to innovative detection mechanisms, as has always been the
case in cyber security.
Nowadays, it is becoming increasingly common for malware analysts to leverage sandboxes for
automation of malware analysis. However, most techniques used in viruses to evade such
sandboxes are targeted towards commercial and well-known VMs like VMWare Workstation,
VMWare Fusion, Virtual Box, Virtual PC, Qemu and some sandboxes like CWSandbox, Anubis
and so on. These techniques can prevent analysis in a sandbox based only on known
information.
However, there is a lot of scope for improvement in the techniques used by viruses to detect
and evade a Virtualized Environment. This encourages the development of more hardened
sandboxes which are as close to VMM transparency as possible.
Anti VM techniques
Before we discuss some new ways of preventing analysis in sandboxes, let us discuss some of
the commonly used anti sandbox/anti vm techniques.
Process Names: Till date, viruses rely on looking for known process names running on the
machine to identify the presence of a virtual machine. By enumerating the process names using
Process32First()/Process32Next(), they look for running process such as vmsrvc.exe,
vmusrvc.exe, vboxtray.exe, vmtoolsd.exe, df5serv.exe, vboxservice.exe and so on. These are
known values of process names that may be running in a sandbox used by malware analysts.
Registry Artifacts: It is also common for viruses to access specific registry entries to check for
presence of sandboxes. One of the most common registry entry accessed for this purpose is:
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Disk\Enum
Subkey: “0”
Then the value of above subkey is parsed for the presence of substrings like vmware, qemu, xen
and so on.
This is again based on known values.
Module Names: Sandboxes inject modules in a process to log the activities performed by it.
Since some of the module names used by security sandboxes are known publicly, they are used
by the virus to detect the presence of sandbox the following way:
Call GetModuleHandleA() on the module name. If the handle returned is Non Null, this
indicates the module is loaded. It is unloaded by calling FreeLibrary(). Once this is done, the
sandbox will not log any activity performed by the malware. Common module names often
searched by the viruses are dbghelp.dll, sbiedll.dll and so on.
Backdoor Detection: In most virtual machine softwares like VMWare Workstation, VMWare
Fusion, Virtual PC, Parallels and so on, Hypervisor uses a backdoor to communicate with the
guest operating system.
We can detect the presence of virtualization software and also identify its type using this
backdoor technique.
For instance, to detect the presence of VMWare there is a known documented technique which
checks for the presence of VMX backdoor used by Hypervisor to communicate with the guest
operating system:
mov eax,0x564d5868
mov ecx, 0xa
mov dx, 0x5658
in eax, dx
cmp ebx, 0x564d5868
While these techniques are good, they are again directed towards specific virtualization
softwares.
Long Opcode Instructions: This technique was documented by jaelanicu in 2009. It is not used
so often in viruses, however it is a unique technique. It is based on the fact that virtualized CPU
does not have a limitation on the length of an instruction unlike a real x86 CPU. When an
instruction of length greater than 0x15 bytes is executed on a real CPU, it will trigger an
exception however in a virtual CPU it will not trigger an exception. This difference in the result
is used to detect the presence of virtualization.
It was observed that Qakbot uses this technique as shown in the screenshot below:
Please note that this technique may not work reliably on recent versions of Virtualization
Softwares.
Number of Cores: It is common for malware analysts to allocate a single processer core to the
sandbox. However, in a real world case today, most processors will have multiple cores.
Malwares can use several techniques to find the number of CPU cores and then decide if they
are running inside a virtual machine on the basis of the result. One of the easiest ways of doing
this is by checking the Process Environment Block:
Mov eax, dword ptr fs:[0x30]
Mov eax, dword ptr ds:[eax+0x64]
Cmp eax, 0x1
Je vm_detected
This technique may appear to be trivial

www.at4re.net