A common approach to analyse potentially malicious software is dynamic analysis in a virtual machine. Therefore, malware authors use techniques to alter the malware's behavior when being run in a VM. But how do they actually do it?
A common approach to analyse potentially malicious software is dynamic analysis. The binary is executed in an analysis environment, usually a Virtual Machine (VM), and its behaviour in the system is inspected.
Malware developers are aware of this and try to impede this by hiding their malicious intent when being analysed. To be able to do so, the malware needs to detect that it is running inside a VM. For this, various detection methods exist that we will discuss further in this blog post. With these in mind, we also performed an analysis of 50,000 malware samples on the usage of VM detection methods.
VM Detection Methods
An easy approach is to use the instruction CPUID. When used with input value 0x0, this returns the CPU’s manufacturer ID string. In case of a Xen virtual machine, this is “XenVMMXenVMM”. Similarly, when used with the input values 0x80000002, 0x80000003 and 0x80000004, this returns the CPU’s brand string, which usually is something like “Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz”. But for example in case of the emulator Qemu, this returns “QEMU Virtual CPU”. In addition, the input value 0x40000000 can be used in the same manner. Interestingly this specific input value is not implemented on physical CPUs but on virtual ones. Here it also returns the CPU’s brand string that can then easily be checked.
Besides this and many more low-level methods, high-level methods utilising the Windows API can be used. For example, obvious registry keys like HKEY_LOCAL_MACHINE\HARDWARE\ACPI\DSDT\VBOX__ can be searched for using the function RegOpenKey(), which would indicate the presence of a VirtualBox VM as can be seen in the following code example. If the key exists in the system, the VM would be detected.
if (RegOpenKeyEx(HKEY_LOCAL_MACHINE, "HARDWARE\\ACPI\\DSDT\\VBOX__", NULL, KEY_READ, &resultKey) == ERROR_SUCCESS)
{
IsVM = true;
}
Another trend is to use Windows Management Instrumentation (WMI) classes to retrieve information about the system. The query SELECT * FROM MSAcpi_ThermalZoneTemperature with the property CurrentTemperature can be used to identify a VM. On a physical system this returns information about the temperature of its hardware components. If this property is not supported, the check was probably executed on a virtual machine, because a VM does not have any hardware of which the temperature could be measured. Fortuna recently observed the Remote Access Trojan GravityRAT to use this method [1]. Many more queries can also be used to check for system artefacts indicating the presence of a hypervisor.
Current Prevalence of VM Detection
With this in mind, we tried to analyse the prevalence of VM detection in current malware. We utilised a technique called Virtual Machine Introspection (VMI). It allows tracing of the use of Windows API calls and system calls. With this method, we also looked for certain instructions that cause VM exits. A VM exit is the traversal from the VM to the hypervisor. This occurs if the VM tries to execute an instruction that needs elevated privileges. An example for this is CPUID. It needs information about the CPU that only the hypervisor can retrieve, therefore only the latter can handle this instruction. As our analysis is performed on the hypervisor, these instructions can then be analysed.
We inspected 50,000 random samples in the beginning of July 2019. We found that at least 2.77 % of analysed binaries were using at least one method strongly indicating the use of VM detection. The most used method was utilising the instruction CPUID with the input 0x40000000.
At the first glance this does not seem much, but it should be noted that we could only detect the use of certain functions with their respective input values, but not if this was the malware’s actual intention. For example, we found that almost every sample was using the CPUID instruction with input values 0x0 and 0x1. Both variants retrieve general information about the CPU and are valid methods for VM detection. However, because a compiler probably uses them for compatibility checks, it is hard to detect if it was actually used to detect a VM if every other benign program also uses it. Therefore, it is highly plausible that a much higher amount of samples was actually using virtual machine detection.
With this in mind, seeing that a minimum of 2.77% of samples are blatantly using VM detection methods, there is a good chance that VM detection is still quite common to be used by current malware. Many checks could slip under the radar of typical analysis systems. Often these checks are similar to those of a benign software installer like simply checking the systems hardware capabilities. How many CPU cores are available? How much system memory is installed? What size is the main hard drive? If those checks return values lower than typical for a physical system, the chance of being executed on a VM is high. With methods like these, it is hard to detect the malware before it detects the analysis and hides itself from dynamic analysis.
Possible Countermeasures and Future Work
One method to counter VM detection is to develop an analysis system that cannot be distinguished from a non-virtual system. To achieve this a virtual system would have to alter the return values to checks that would otherwise reveal its true nature. This could for example be done using VMI because it can intercept all returning functions. It can also distinguish between the processes using the methods that need to be changed. Therefore, only the analysed sample would be affected and no problems with the operating system due to false information about the system would occur. For example the analysis system could return, that a 2TB hard drive is installed, even though it actually only has 20GB available.
A good approach for further studies would be to analyse if a hardened system increases the amount of detected malware. Comparing the results of a test-set of samples of this system with the results of a non-hardened system could give more insight in the actual prevalence of VM detection. Ideally, one could use an actually physical system instead of a hardened system to gather results that are even more reliable. Lindorfer et al. [2] tested a similar approach in 2011.
The potential of VMI to harden VMs against detection should be further looked into as well. Some checks might always be impossible to fake like timing differences between a virtual and a non-virtual system. Nonetheless, we found that simple checks for example using the CPUID instruction are popular and could effectively be countered. VMI is a technique that could be a great advantage in the fight against environment aware malware.
All in all, we found that there are various techniques to detect a virtual environment. Those that are more noticeable are currently in use to some extent. The more inconspicuous ones could be used even more. The impact of this remains unclear. This leaves room for a lot further research. This is especially interesting concerning the growing market of cloud computing. More and more systems are virtualised, even workstations. Will the use of VM detection in malware decline to not lose possible victims?
Phillip can also be reached via his personal Twitter account.
References
[1] Andrea Fortuna. “Malware VM detection techniques evolving: an analysis of GravityRAT”. 2018.
[2] Martina Lindorfer, Clemens Kolbitsch, and Paolo Milani Comparetti. „Detecting Environment-Sensitive Malware“. In: International Workshop on Recent Advances in Intrusion Detection. Springer. 2011, pp. 338-357.
Phillip Kemkes
R&D Engineer