Malware authors tend to come out with the innovative methods to detect the virtualized / sandboxing territory and cease to execute the moment they discover it. A while back , I blogged about some of the sandbox evasion techniques used by malwares. In this part , I'll walk through some of the most recent and efficient evasions used by malicious code to identify sandboxes.
Today, Advance persistent threats and targeted attacks tend to wait for the human interaction with the system to activate the malicious code. Since automated malware analysis frameworks process millions of samples per day, human interaction is bare minimal and malwares does not replicate and as a result, does not show complete behavior. Underlying hardware used to replicate the malwares also expose several artifacts about the environment which isn't too hard to notice.
Another flavour of DeviceIoControl ( )
In my previous post on this topic , I talked about the technique of using DeviceIoControl ( ) API to fingerprint the hard disk properties. This technique was yet again observerd in Win32/Phorpiex family of malware with the different IO control code. Win32/Phorpiex uses the IoControl Code 0x2D1400 (IOCTL_STORAGE_QUERY_PROPERTY) to check the returned device properties for virtual hard drives.
With this method , notice the output on Vmware and Qemu . It exposes the underlying hard drive properties on both the virtualized environment.
Windows Management Instrumentation
Windows Management Instrumentation is the Microsoft’s implementation of Web-Based Enterprise Management (WBEM) which is the industry initiative to develop standard technology for accessing management information .WMI is the default windows service that can execute the WMI scripts which is typically used to automate the administrative tasks. Above that, it provides common interface and object model to extract the management information about the OS, processor, hardware devices, applications and services.
Malwares can abuse this windows interface in multiple ways. One of the method is using WMI Query Language (WQL) to issue the SQL type queries to extract the hardware information. For instance, following queries can be issued by the malware to retrieve the Hard Drive / Processor information and match the keyword QEMU / VMware / Xen in the values returned.
SELECT *FROM Win32_Processor
SELECT *FROM Win32_BIOS
SELECT *FROM Win32_DiskDrive
SELECT *FROM Win32_SCSIController
SELECT *FROM Win32_ComputerSystem
Checking the time acceleration using GetTickCount ( )
Traditional ways to detect the userland hooks had been to check if the function code does not start with the JMP or CALL instruction. One of the variant of Win32 / Kovter malware family was found to be using slightly different way of checking for the user mode hooks using time acceleration. It calls the API GetTickCount, then sleeps for 500 milliseconds and then calls the GetTickCount again to take the difference of the elapsed time. Sandbox systems historically have been patching sleep ( ) calls to force the stalling code execute faster. This technique performs the difference the time and checks if the code has stalled enough before executing the malicious code. It will terminate the execution if it determines that enough time has not elapsed between these instructions.
No of CPU cores on the virtual machine
Checking the number of CPU cores on the machine executing the malware is yet another elementary way of detecting the sandboxes environment. Analysis machines used by sandboxing environment are customarily configured with the single core while physical machines are predominantly multi core machines. Malwares can get the number of CPU cores by just calling the GetSystemInfo ( ) API taking the pointer to the SYSTEM_INFO structure, which returns the system data.SYSTEM_INFO structure contains the attribute dwNumberOfProcessors field which can be checked to see if the system is a single core machine.
Similar check can also be done by accessing the Process Environment Block of the running process. Offset 0x64 in the PEB defines the NumberOfProcessors on the system.
Foreground Windows check using GetForegroundWindow API ( )
One of the very predictable behavior of sandboxes is that they do not change or switch between the windows when the malware is being executed. Typically, this window would be the one from where the malware is executed and could be most likely desktop window. Recent variant of Win32 / Gataka banking malware was found to be taking the advantage of this behavior by calling GetForegroundWindow () API to get the handle of the current foreground window. Malware ceaselessly calls this API in the loop until the current window handle is changed after which it starts executing the malicious payload, thereby checking if the human is interacting with the execution environment.
Waiting for mouse clicks using SetWindowsHookEx ( ) API
Variants of Win32 / Banechant malwares employs more stealthier mechanism to evade the sandboxes. It installs the hook procedure using SetWindowsHookEx with the hookId 0x0E into the hook chain to monitor low level mouse events. This API defines the HOOKPROC specifying the callback function to execute when the windows receives mouse events. Earlier variants of Win32 / Banechant checked for a single left mouse click in the callback function before the malicious code is executed while the later variants came with the improved technique of checking for the more than three left mouse clicks before the activation of the payload.
As and when sandboxing technology becomes more popular and its adoption grows , malware authors will employ increasing level of sophistication in detecting sandboxes. It is extremely crucial for automated malware analysis systems to keep abreast of all such methods and patch it to keep the environment hidden.
Posts
