Part of the process of malware analysis and investigation is dynamic analysis – simply put, in this type of analysis, malware (or suspected malware) samples are allowed to execute in a contained, virtualized environment. Its actions, flow, communications and other factors are all observed, documented, analyzed and compared against other known malicious or suspicious behaviors and indicators.
Naturally, when a new variant of an existing malware, or even an entirely new strain of malware is detected in such a manner, it doesn’t take long until the malware’s in-the-wild effectiveness sharply declines, as more and more security vendors and solutions will recognize and block it.
Acknowledging this fact, and in an effort to stay under the radar and extend the life expectancy of their malware as much as possible, malware developers often incorporate various mechanisms intended to hinder dynamic analysis.
This blog, part of our series on different malware evasion techniques, will focus on common VM detection techniques employed by malware developers in order to detect virtualized execution of their malware and is intended to provide an introduction to the topic.
There are 2 main approaches employed by malware developers to hinder the execution of their malware in an analysis or research environment, and most malware employs various combinations of these approaches:
CPUID is an instruction present in almost all modern CPU architectures. It is intended to allow the software to discover various details about the processor of the machine it is being executed on.
Calling this instruction with EAX=0 as input will return the CPU manufacturer-ID string, a 12-character ASCII string that will be stored in EBX, EDX and ECX (in that order).
On machines running on a physical Intel or AMD CPU this string will be “GenuineIntel” or “AuthenticAMD”, respectively.
On machines running off of Microsoft’s Hyper-V or VMware this string will be “Microsoft HV” or “VMwareVMware”.
Calling CPUID with EAX=1 as input will return Processor Info and Feature Bits, essentially a rundown of various details about the CPU.
On a physical machine, the 31st bit of the returned ECX register will be 0, while on a virtual machine it will be 1.
MAC address checks
A MAC address is a unique identifier assigned to Network Interface Controllers on a machine. By checking MAC address prefixes, it is possible to identify the manufacturer of the network adapter. This can easily be done using the “ipconfig /all” or “wmic nic list” command.
For example, network adapters from Broadcom, a common supplier of networking hardware to many PC manufacturers, will start with one of the following prefixes: (partial list)
While VMware network adapters will start with one of the following:
VirtualBox network adapters will start with 08:00:27, Hyper-V with 00:03:FF.
Virtualized Windows environments will often contain various registry entries not commonly found on physical machines, the presence of which can be a tip-off to the fact the malware is running on a VM.
\HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\Scsi\Scsi Port 0\Scsi Bus 0\Target Id 0\Logical Unit Id 0\”Identifier”; ”<value>”
\HKEY_LOCAL_MACHINE\SOFTWARE\Oracle\VirtualBox Guest Additions\*
In order to facilitate their operation, many virtualized Windows environments will have certain processes running that aren’t usually found on physical machines. This can be easily done using “wmic process” or “tasklist” commands.
Virtualized Windows environments will often have certain services present on them that are not present on physical machines. This can be easily accomplished with “sc query” or “wmic service list” commands.
VMware Physical Disk Helper Service
In addition to what has been described above, virtualized Windows environments will also often contain certain files (usually drivers), the presence of which can be indicative of a VM.
Using the techniques described above, malware can often detect if it is being executed in a virtualized environment and avoid or adjust its execution. We recommend addressing these artifacts in your own analysis environments in order to maximize the chance of malware successfully executing itself there.
In our next blog, we explore how over time malware developers have also added methods to avoid sandboxes and analysis environments by performing various checks to see if there is an actual user operating the machine the malware is being executed on.