Malware Analysts and Security researchers rely on Virtual Machines, debuggers, and sandboxes in their malware analysis due to their pertinent design to analyze malware without risking permanent infection to the host Operating system. This is because if malware infects the guest Operating system during analysis, the analyst can simply load in a fresh image thus avoiding any damage to the actual machine.

Hence threat actors and malware authors have raised their stakes by creating malicious software that can detect the presence of virtual machines, and other controlled environments. This class of malware detects the presence of malware analysis tools such as Virtual Machines, debuggers, and sandboxes and then either terminates execution immediately or simply hides its malicious intent and continues to execute benignly thus evading its own detection. A casual malware analyst may misunderstand it as a genuine application. Analysts are forced to analyze such VM-aware malware by executing them on a physical host, which increases the analysis cost. This category of malware has been vouchsafed numerous nomenclatures such as Analysis-Aware Malware, Environment-Sensitive Malware, VM-aware Malware, and Anti-VM Malware. VM awareness becomes a barrier for malware analysis due to the concealment of malicious behaviors. This post aims at various measures that can be adopted by malware analysts to thwart these techniques of Virtual-aware malware.

Anti-VM Techniques

To evade detection, Malware Authors implement many different techniques to prevent the malware from performing its malicious action in a lab environment, or in some cases from running at all and, by that, preventing the researchers from inspecting any action the malware performs dynamically. The various techniques employed are categorized as follows:

Hardware fingerprinting
Registry enumeration
Process and file system enumeration
Timing analysis check
Memory check
Communication channel lookup

Hardware Fingerprinting

Evasion techniques targeting the Hardware level leverage the fact that virtual machines and emulators often create specific hardware patterns unique to VMs. These devices can either be identified by well-known manufacturer prefixes such as VMWARE VIRTUAL IDE HARD DRIVE and QEMU HARDDISK or by specific drivers that are not present in a real user’s system. Examples of virtual environment artifacts a threat actor might search for include the MAC address of the network interface card, BIOS, graphic card, and specific hardware controllers. Hardware fingerprinting can be carried out using Windows Management Instrumentation (WMI) classes and APIs.

Malware can run the following command to retrieve the model name of the system within which it is running.

wmic computersystem get model

If it is running inside a virtual environment, common outputs that can be retrieved include:

VirtualBox - "VirtualBox".
VMware - "VMware Virtual Platform".
Hyper-V - "Microsoft Virtual Machine".
QEMU/KVM - "KVM".

The following Powershell command gives the BIOS details of a real and virtual machine respectively.

Get-WMIObject -namespace root\cimv2 -class Win32_BIOS

This command returns the BIOS manufacturer, version, and serial number of the machine under inspection. In virtual machines, the following can be observed.

VMware typically returns Phoenix Technologies LTD.
Hyper-V returns Microsoft Corporation.
VirtualBox returns innotek GmbH.

On physical machines, the BIOS manufacturer will reflect the actual hardware vendor such as "American Megatrends" or "Dell Inc.".

Most virtual machine vendors include the feature to virtualize a custom network interface card (NIC) on your host machine. If your lab is running with any VM native NIC, such can be determined using the following command.

wmic nic list

The first three bytes of a MAC address are typically specific to the vendor. It is called the MAC address Organization Unique Identifier (OUI). The following MAC address OUIs are associated with virtual machines.

VMWare

00:05:69
00:0C:29
00:1C:14
00:50:56

VirtualBox

08:00:27

Hyper-V

00:03:FF

To bypass this method, assign a MAC address manually in the adapter settings.

To query details about disk drives, such as the model and serial number, malware can run the following command.

wmic diskdrive get model,serialnumber

In a virtual environment, the following results will be obtained:

VirtualBox - Disk drives may show as VBOV HARDDISK.
VMware - Drives might be listed as VMware Virtual Disk.
Hyper-V - Disk drive may show as Microsoft Virtual Disk.

Physical machines will list actual disk manufacturers like Seagate or Western Digital.

Malware can also query the system for details of the motherboard to ascertain whether it is running in a virtual environment.

wmic baseboard get product,manufacturer,version,serialnumber

In a virtual environment, the manufacturer or product may show a name related to the virtual machine vendor instead of a physical hardware manufacturer, and it will return no output for the serial number and version respectively.

Another technique that can be employed by malware authors is enumerating the system temperature. On a physical system this returns information about the temperature of its hardware components. This technique often works because most hypervisors, including Hyper-V, VMWare Fusion, VirtualBox, KVM, and XENs, do not support the temperature check function. Therefore, the response from the WMI request is an error message that allows the malware to identify it is running in a virtualized environment.

wmic /namespace:\\root\WMI path MsAcpi_ThermalZoneTemperature get CurrentTemperature

In a similar vein, malware can retrieve information about the fans in a computer system by querying the Win32_Fan WMI class.

wmic path Win32_Fan get Name,Status

The above command retrieves the name and status of any fan that is available in the system. In real machines, the current status of the fan might show values like OK, Error, or Unknown depending on the state of the device. Since Virtual Machines do not have direct fan control or sensor information, the result will most likely be empty or non-informative.

A common technique used by malware to detect the environment within which it is being run is via the CPUID. The CPUID instruction is a processor instruction used to retrieve detailed information about the CPU. It provides details such as the Vendor Identification, version, and other information. It takes an input value in the EAX register which specifies the type of information to retrieve. The output of the instruction is then stored in the EAX, EBX, ECX, and EDX registers. A few examples are listed below.

EAX = 0 - Gets the CPU vendor string - A 12-character ASCII string that will be stored in the EBX, EDX, and ECX in that order.
EAX = 1 - Retrieves processor version and feature information.
EAX = 2 - Cache and TLB descriptor information.

On leaf 0x40000000, the EBX, ECX, and EDX values combine to create a text string that identifies the CPU vendor. On machines running on a physical Intel or AMD CPU, the Vendor string will be "GenuineIntel" or "AuthenticAMD" respectively. On virtual machines, this string will be as follows:

Hyper-V - "MicrosoftHV"
VMware - "VMwareVMware"
VirtualBox - "VBoxVBoxVBox"
KVM - "KVMKVMKVM"
Xen - "XenVMXenVMM"

Calling the CPUID with EAX = 1 as input will return the Processor version and feature bits. On a physical machine, the 31st bit of the returned ECX register will be 0, while on a virtual machine, it will be 1.

Fortunately, all the popular virtual machine vendors allow the host machine to modify CPUID and CPU features. This is because every time your virtual machine fetches a CPUID instruction and wants to execute it, a VM-Exit happens and the hypervisor passes the execution to the Virtual Machine Monitor (VMM), so this is the best time for modifying CPUID results to bypass the above Anti-VM techniques. In VMware, simply modify your .vmx (config file) to override the CPU registers by adding the following lines and restart the VM.

cpuid.1.ecx="0−−−:−−−−:−−−−:−−−−:−−−−:−−−−:−−−−:−−−−"
cpuid.40000000.ebx="0000:0000:0000:0000:0000:0000:0000:0000"
cpuid.40000000.ecx="0000:0000:0000:0000:0000:0000:0000:0000"
cpuid.40000000.edx="0000:0000:0000:0000:0000:0000:0000:0000"

Registry Enumeration

The registry is a centralized, hierarchical database for applications, and it stores system configuration information in the Windows OS. Access to the registry is assured through registry keys, which are analogous to file system directories. A key can contain other keys or key/value pairs, where the key/value pairs are analogous to directory names and file names. Each value under the key has a name, and for each key/value pair, corresponding data can be accessed and modified. Because the registry includes such a big database, it also holds VM-specific key/value pairs. Attackers can therefore check the registry for strings and artifacts that identify an analysis environment.

HKLM\HARDWARE\DEVICEMAP\Scsi\Scsi Port 0\Scsi Bus 0\Target Id 0\Logical Unit Id 0 (Identifier) - VMWARE, QEMU
HKLM\HARDWARE\DEVICEMAP\Scsi\Scsi Port 1\Scsi Bus 0\Target Id 0\Logical Unit Id 0 (Identifier) - VMWARE
HKLM\HARDWARE\DEVICEMAP\Scsi\Scsi Port 2\Scsi Bus 0\Target Id 0\Logical Unit Id 0 (Identifier) - VMware, QEMU
HKLM\HARDWARE\DESCRIPTION\System (SystemBiosVersion)
HKLM\HARDWARE\DESCRIPTION\System (VideoBiosVersion) - VIRTUALBOX
HKLM\SYSTEM\ControlSet001\Control\SystemInformation (SystemManufacturer) - VMWARE
HKLM\SYSTEM\ControlSet001\Control\SystemInformation (SystemProductName) - VMWARE
HKLM\HARDWARE\ACPI\DSDT\VBOX__ (VBOX)
HKLM\HARDWARE\ACPI\FADT\VBOX__ (VBOX)
HKLM\HARDWARE\ACPI\RSDT\VBOX__ (VBOX)
HKLM\SYSTEM\ControlSet001\Services\VBoxGuest (VBOX)
HKLM\SYSTEM\ControlSet001\Services\VBoxMouse (VBOX)
HKLM\SYSTEM\ControlSet001\Services\VBoxService (VBOX)
HKLM\SYSTEM\ControlSet001\Services\VBoxSF (VBOX)
HKLM\SYSTEM\ControlSet001\Services\VBoxVideo (VBOX)
HKLM\SOFTWARE\Oracle\VirtualBox Guest Additions (VBOX)
HKLM\SOFTWARE\VMware,Inc.\VMwareTools (VMWARE)
HKLM\SOFTWARE\Wine (WINE)
HKLM\SOFTWARE\Microsoft\VirtualMachine\Guest\Parameters (HYPER-V)
HKLM\SYSTEM\CurrentControlSet\Services\Disk\Enum
HKLM\SYSTEM\CurrentControlSet\Enum\IDE
HKLM\SYSTEM\CurrentControlSet\Enum\SCSI
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class\{4D36E968 -E325-11CE-BFC1-08002BE10318}\0000\ProviderName

Registry keys like the ones listed above can be searched for using the RegOpenKey() function to indicate the presence of a virtualized environment as seen in the code snippet below.

if(RegOpenKeyEx(HKEY_LOCAL_MACHINE, "HARDWARE\\ACPI\\DSDT\\VBOX__", NULL, KEY_READ, &resultKey) == ERROR_SUCCESS) 
{
	IsVM = true;
}

If the key exists in the system, VM presence would be established.

Process And File System Enumeration

Virtual machines often run unique background processes to support virtualization. Malware can scan for processes associated with popular VM platforms like VMware, VirtualBox, and Hyper-V. Some of these processes include:

vmtoolsd.exe (VMWARE)
vmwaretray.exe (VMWARE
vmwareuser.exe (VMWARE)
VGAuthService.exe (VMWARE)
vmacthlp.exe (VMWARE)
vboxservice.exe (VBOX)
vboxtray.exe (VBOX)
vmsrvc.exe (VirtualPC)
vmusrvc.exe (VirtualPC)
prl_cc.exe (Parallels)
prl_tools.exe (Parallels)
xenservice.exe (Citrix Xen)
qemu-ga.exe (QEMU)

Many VMs rely on specific drivers to manage virtual hardware. Malware can analyze system processes that depend on these drivers to detect virtualization. Some of these drivers include:

system32\drivers\VBoxMouse.sys
system32\drivers\VBoxGuest.sys
system32\drivers\VBoxSF.sys
system32\drivers\VBoxVideo.sys
system32\drivers\vmhgfs.sys
system32\drivers\vmmouse.sys
system32\drivers\vm3dmp.sys
system32\drivers\vmci.sys
system32\drivers\vmmemctl.sys
system32\drivers\vmrawdisk.sys
system32\drivers\vmusbmouse.sys

Malware also looks for certain DLLs associated with virtual machines to detect if it is running in a virtualized environment. Some of the include:

system32\vmGuestLib.dll (VMWARE)
system32\vmtools.dll (VMWARE)
system32\vmmouse.dll (VMWARE)
system32\vmhgfs.dll (VMWARE)
system32\vm3dmod.dll (VMWARE)
system32\vmrawdsk.dll (VMWARE)
system32\vm3dgl.dll (VMWARE)
system32\VBoxDisp.dll (VBOX)
system32\VBoxHook.dll (VBOX)
system32\VBoxMRXNP.dll (VBOX)
system32\vboxogl.dll (VBOX)
system32\vboxoglarrayspu.dll (VBOX)
system32\vboxoglcrutil.dll (VBOX)
system32\vboxoglerrorspu.dll (VBOX)
system32\vboxoglsystem32\vboxoglfeedbackspu.dll (VBOX)
system32\vboxoglpackspu.dll (VBOX)
system32\vboxoglpassthroughspu.dll (VBOX)
system32\VBoxSF.dll (VBOX)
system32\vmicres.dll (HYPER-V)
system32\vmicsvc.dll (HYPER-V)
system32\icsvc.dll (HYPER-V)
system32\prl_vmod.dll (PARALLELS)
system32\prl_umdd.dll (PARALLELS)
system32\prl_hook.dll (PARALLELS)
system32\qemu-ga.dll (QEMU)
system32\qemuwrapper.dll (QEMU)
system32\qga-vss.dll (QEMU)
system32\xenutil.dll (Citrix Xen)
system32\xenevtchn.dll (Citrix Xen)
system32\xennet.dll (Citrix Xen)
system32\xenvbd.dll (Citrix Xen)

The following directory artifacts are also associated with Virtual machines and could be used by malware for VM detection.

%PROGRAM FILES%\Oracle\Virtualbox Guest Additions\
%PROGRAM FILES%\VMware\

Timing Analysis Check

Malware often uses techniques to detect VM_EXIT events, measuring the time cost of these transactions to identify whether it is inside a virtual machine (VM). A known technique is the CPU tick count.

The CPU tick counter is a low-level counter that measures the number of clock cycles (ticks) the CPU has processed since startup. Malware can measure the number of ticks before and after executing specific instructions. If an instruction takes significantly longer than expected to complete, it could indicate that a VM_EXIT has occurred, suggesting that the code is running in a virtualized environment where certain instructions trigger exits. Below is a detailed analysis of how this technique is conducted.

Step 1 - The malware records the CPU tick count before executing a potentially sensitive instruction.
Step 2 - It executes an instruction known to cause VM_EXIT in virtual environments, like cpuid.
Step 3 - It records the CPU tick count after the instruction completes.
Step 4 - The malware calculates the difference in tick counts. If the difference exceeds a certain threshold, it assumes it is running in a VM because of the latency introduced by VM_EXIT.

A C program to demonstrate this technique and the corresponding results in both real and virtual machines are shown below.

#include <stdio.h>
#include <stdint.h>
#include <intrin.h>

//Function prototype
void DetectVMExit(void);


void DetectVMExit(void)
{
    int registers[4] = {0};

    uint64_t cpuid_start_tick = __rdtsc(); //obtain the current tick count
    __cpuid(&registers[0], 0);
    uint64_t cpuid_end_tick = __rdtsc(); //obtain the current tick count

    //Calculate how many ticks it took to execute the CPUID instruction
    uint64_t cpuid_time = cpuid_end_tick - cpuid_start_tick;

    printf("Elapsed ticks = %lld\n", cpuid_time);

    //typically CPUID takes less than 20000 ticks, but takes over 100000 in a VM
    if(cpuid_time > 20000) {
        puts("We're probably in a VM!");
    }
}

Memory Check

This technique involves looking at the values of specific memory locations after the execution of instructions such as store interrupt descriptor table (SIDT), store local descriptor table (SLDT), store global descriptor table (SGDT), or store task register. These sensitive instructions—sidt, sgdt, and sldt—read the location of these tables, and all store the respective register into a memory location. An x86 processor has only three registers to store the locations of these three tables - IDTR, GDTR, and LDTR. Actually, some of the malware with VM detection capability use this technique, which is based on the fact that any machine, whether it is virtual or not, needs its own instance of some register. Systems such as VMware create dedicated registers for each VM. These registers have different addresses than the one used by the host system, and by checking the value of this address, the virtual systems’ existence can be detected. A known technique is the Red Pill technique by Joanna Rutkowska in November, 2004.

Red Pill is an anti-VM technique that executes the sidt instruction to grab the value of the IDTR register. The virtual machine monitor must relocate the guest’s IDTR to avoid conflict with the host’s IDTR. Since the virtual machine monitor is not notified when the virtual machine runs the sidt instruction, the IDTR for the virtual machine is returned. The Red Pill tests for this discrepancy to detect the usage of VM.

int swallow_redpill(void)
{
    unsigned char m[2+4];
    unsigned char rpill[] = "\x0f\x01\x0d\x00\x00\x00\x00\xc3";
    *((unsigned *)&rpill[3]) = (unsigned)m;
    ((void(*)())&rpill)();
    return(m[5]>0xd0)? 1 : 0;
}

Rutowska observed that on VMware, the IDT is typically located at 0xFFXXXXXX, while on VirtualPC, it is located at 0xE8XXXXXX. For host operating systems, the IDT is located far lower in memory. To handle both conditions, the Red Pill checks to see if the IDTR is greater than 0xD0000000. If so, the Red Pill prints a message saying that it is running in a guest operating system. If the returned result is less than or equal to that value, the Red Pill says that it is running on a host machine.

Red Pill succeeds only on a single-processor machine. It will not work consistently against multicore processors because each processor (guest or host) has an IDT assigned to it. There thwart this technique, run on a multicore processor machine or simply NOP-out the sidt instruction.

Tobias Klein wrote the Scoopy suite that looks at the location of the IDT, the GDT, and the LDT, using the IA32 SIDT, SGDT, and SLDT instructions respectively. Klein observed that host operating systems have an IDT located at memory location 0xC0XXXXXX (which is consistent with the Red Pill, in that it is lower than 0xD0XXXXXX). Scoopy checks to see if the IDT is located at an address that starts with 0xC0. If it does, Scoopy prints a message indicating that it is running in a host machine. Otherwise, it prints that it is in a VM. Klein used identical logic to compare the GDT's location with 0xC0XXXXXX to get a second opinion on the matter. Finally, Klein observed that the LDT on a host machine is typically at location 0x0000. On VMs, it has some other value. With these checks for virtual machines, Scoopy has quite accurate results.

Communication Channel Check

Ken Kato discovered the presence of a host-guest communication channel in VMware so-called backdoor Input/Output (I/O) port. VMware uses the I/O port 0x5658 (VX in ASCII) to communicate with the host machine to support functionality like copy and paste between the two systems. Malware can attempt to send specific commands to this port to see if it receives a response, which would indicate it is running in a VM.

mov eax, 564D5868h //VMXh magic number
mov ecx, 0Ah //get VMware version command-specific-parameter
mov dx, 5658h //VX VMware I/O Port
in eax, dx //returns version number in eax

The success of this technique depends on the x86 in instruction, which copies data from the I/O port specified by the source operand to a memory location specified by the destination operand. VMware monitors the use of the in instruction and captures the I/O destined for the communication channel port 0x5668 (VX). Therefore, the second operand needs to be loaded with VX in order to check for VMware, which happens only when the EAX register is loaded with the magic number 0x564D5868 (VMXh). ECX must be loaded with a value corresponding to the action you wish to perform on the port. The value 0xA means “get VMware version type,” and 0x14 means “get the memory size.” Both can be used to detect VMware, but 0xA is more popular because it may determine the VMware version.

Mitigating Anti-VM Techniques

In addition to a few techniques discussed before now for evading VM detection, the most common VMware artifacts can be easily eliminated by uninstalling VMware Tools. There are also a number of undocumented features in VMware that can aid in evading VM detection. Placing the various configuration options shown below in the .vmx file. the VM detection techniques discussed including RedPill and Scoopy are nullified.

isolation.tools.getPtrLocation.disable = "TRUE"
isolation.tools.setPtrLocation.disable = "TRUE"
isolation.tools.setVersion.disable = "TRUE"
isolation.tools.getVersion.disable = "TRUE"
monitor_control.disable_directexec = "TRUE"
monitor_control.disable_chksimd = "TRUE"
monitor_control.disable_ntreloc = "TRUE"
monitor_control.disable_selfmod = "TRUE"
monitor_control.disable_reloc = "TRUE"
monitor_control.disable_btinout = "TRUE"
monitor_control.disable_btmemspace = "TRUE"
monitor_control.disable_btpriv = "TRUE"
monitor_control.disable_btseg = "TRUE"

It should be noted, however, that the above configuration options break the communication channel between the guest and host operating systems. This basically means that all of the ease-of-use features of VMware such as drag-and-drop, shared folders, shared clipboard, and time synchronization will no longer work. Use these settings at your own risk.

Facebook SDK

Top Malware Anti-VM Techniques And Effective Counter-Measures