How malware detects virtualized environment (and its countermeasures)

Virtual Machines are usually considered a good way to analyze malware as they can provide an isolated environment for the malware to trigger but their actions can be controlled and intercepted. However, modern age malware detects their environment in which they are running, and if they detect they are running in VM, they sustain their actions. Some of the common side-effects on VM detection by malware are:

• Refrains to inject code inside applications.
• Keep malicious code encrypted.
• Do not connect with C&C servers OR connect with Decoy C&C servers.

This article will focus on how malware detects their environment and how these malware actions can be traced.

Note: This is specific to detection of VMware environment.

Below are the some of the techniques used by malware to detect the virtualized environment?

• Registry Check: Whenever we spawn a new VM using VMware product, In the guest OS there are many entries related to VMware. Malware queries entries like these to confirm the presence of VMware environment. Some examples like below:
  • HKEY_LOCAL_MACHINESYSTEMControlSet001ControlClass{4D36E968-E325-11CE-BFC1-08002BE10318}000DriverDesc
    • VMware SCSI Controller
  • HKEY_LOCAL_MACHINESYSTEMControlSet001ControlClass{4D36E968-E325-11CE-BFC1-08002BE10318}000ProviderName
    • VMware, Inc.
• Memory Check: Location of various memory structures especially IDT varies in VM as compared to a physical machine. Malware checks the usage of various memory structures like:
  • Store Interrupt Descriptor Table (SIDT): In a VM this is typically located at 0xffXXXXXX whereas, in a physical machine, this is located somewhat lower than that typically around 0x80ffffff.
  • Other structures which are often checked by malware are:
    • Store Local Descriptor Table (SLDT)
    • Store Global Descriptor Table (SGDT)
    • Store Task Register (STR)
• Communication Channel Check: Malware often checks any communication with the host. For this Malware executes the IN instruction. IN instruction is a privileged instruction and can only be run from Ring 0. However if it runs from Ring 3, then it will raise an exception. However when this instruction is triggered from malware within VM, no such exception if raised. Instead, the VM raises a connection with the host and if the magic number 'VMxh' is returned to the register EBX, malware is certain that it is currently running under a VM.
• Processes and Files Check: On all the spawned VM there are various VMware processes which keep running in the background like VMwareService.exe, VMwareTray.exe, etc. Also, sometimes VMware also install some tools in the spawned VM. Malware keeps an eye on all such as processes and files to detect VM environment.
• MAC check: Malware also checks for underlying machine MAC address. MAC address starting with 00-05-69, 00-0c-29, 00-1c-14 or 00-50-56 belongs to VMware. The malware also for BIOS serial number. Usually spawned VM's have 'VMware' string appended to their BIOS serial number.
• Other Hardware Check: There are various hardware parameters which are specific to VMware as compared to the physical system. Malware queries various attributes like SerialNo, SocketDesignation, Caption to check the values of Motherboard, Processor, SCSI controller respectively.

Ways to Counter

Malware usually made API calls to get information from the system and made a decision on that. So monitoring these API calls would be informative to counter malware decision system

Countering Registry Check: Monitor malware action by intercepting API calls and add the custom output to deny malware to know about the underlying host. For registry monitor following registry calls:

• RegEnumKey()
• RegEnumValue()
• RegOpenKey()
• RegQueryInfoKeyValue()
• RegQueryMultipleValues()
• RegQueryValue()

Countering Hardware Check: For hardware monitor following APIs:

• SetupDiEnumDeviceInfo()
• SetupDiGetDeviceInstanceId()
• SetupDiGetDeviceRegistryProperty()
• WMI APIs

An important point to note in Hardware check regards information retrieval using MAC address. Analysts must change the MAC address in the VM to other than the VMware range specified above.

Countering Memory Check: To counter Memory Check, monitor instruction like SIDT, SLDT, SGDT, and STR. Also, since malware reads the instructions values from registers, it would be a good idea to change the affected register values.

Countering VM communication Channel: As stated above this is usually carried out with IN instruction. TO counter VM communication Channel, monitor the IN instruction and change the value of magic value(VMXh).

Countering File and Process Check: As you would have guessed by now, file and process check can be countered by monitoring the APIs for Folders, files, processes, etc. In this case, if the malware makes a request to query about VMware files and folders, then that API call should be intercepted, and a custom message should be thrown out as output to Malware so as to deny malware from recognizing any VMware files.

Become a certified reverse engineer!

Get live, hands-on malware analysis training from anywhere, and become a Certified Reverse Engineering Analyst.

Start Learning

So these are techniques from a very high level which can be employed to detect the presence of malware discovering information about the environment.