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.
Going Under the Radar
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:
- Virtualization detection and avoidance – this approach focuses on detecting artifacts of the virtualization infrastructure (Hyper-V, VMWare, VirtualBox, QEmu, etc.) employed by analysis systems, from large-scale sandboxing systems hosting any number of virtual machines to small-scale systems, such as individual analysis or research machines maintained by researches and analysts.
- Analysis environment/Sandbox detection and avoidance – this approach focuses not on detecting infrastructure used in analysis systems, but on other artifacts that are usually present in such systems, such as the presence of analysis tools like debuggers or other tools commonly used in malware analysis such as the SysInternals suite, or other artifacts that may be a tip-off to the fact that the malware is being executed in an analysis environment or sandbox. This topic will be covered in our next blog post.
To thwart attempts at having their malware analyzed and then detected, malware authors will use anti-virtual machine (ant-VM) techniques. By adopting the technique the malware is designed to detect whether it is running inside a virtual machine, if a virtual machine is detected the malware will then act differently or just not run at all. Not surprisingly, this causes huge headaches for the security analyst. Anti-virtual machine techniques are commonly found in more prolific types of malware such as spyware and bots. The attractive "honeypots" of large organizations often have virtual machines as part of their security infrastructure, therefore the malware typically targets the average user's machine, which is less likely to have a virtual machine operating.
Virtualization detection and avoidance
CPUID checks
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.
- Example 1:
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”.
- Example 2:
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)
- E0:3E:44
- 00:10:18
- D4:01:29
- 00:0D:E6
While VMware network adapters will start with one of the following:
- 00:1C:14
- 00:50:56
- 00:05:69
- 00:0C:29
VirtualBox network adapters will start with 08:00:27, Hyper-V with 00:03:FF.
Registry checks
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.
Examples:
- Generic:
\HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\Scsi\Scsi Port 0\Scsi Bus 0\Target Id 0\Logical Unit Id 0\”Identifier”; ”<value>”
\HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\SystemBiosVersion\"SystemBiosVersion";”<value>”
- VMware:
\HKEY_CURRENT_USER\Software\VMware, Inc.\*
\HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\*
\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\SCSI\*VMware*\*
\HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\*VMware*\*
- VirtualBox:
\HKEY_LOCAL_MACHINE\HARDWARE\ACPI\DSDT\VBOX__
\HKEY_LOCAL_MACHINE\HARDWARE\ACPI\FADT\VBOX__
\HKEY_LOCAL_MACHINE\HARDWARE\ACPI\RSDT\VBOX__
\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VBox*
\HKEY_LOCAL_MACHINE\SOFTWARE\Oracle\VirtualBox Guest Additions\*
Process checks
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.
Examples:
- VMware:
VGAuthService.exe
vmacthlp.exe
vmtoolsd.exe
- VirtualBox:
VBoxService.exe
VBoxTray.exe
Service checks
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.
Examples:
- VMware:
VMTools
vmvss
VGAuthService
VMware Physical Disk Helper Service
- VirtualBox:
VBoxService
File checks
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.
Examples:
- VMware:
C:\Windows\System32\drivers\vmhgfs.sys
C:\Windows\System32\drivers\vmmemctl.sys
C:\Windows\System32\drivers\vmmouse.sys
C:\Windows\System32\drivers\vmrawdsk.sys
- VirtualBox:
C:\Windows\System32\drivers\VBoxMouse.sys
C:\Windows\System32\drivers\VBoxGuest.sys
C:\Windows\System32\drivers\VBoxSF.sys
C:\Windows\System32\drivers\VBoxVideo.sys
Caught in the Act
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.