Virtualization Detection Techniques Used By Malware

The WannaCry malware outbreak isn’t even over yet, but another new malware, Petya, has surfaced. Both of these malwares make use of vulnerabilities in the Microsoft (News - Alert) Windows operating system. The vulnerabilities, namely ETERNAL BLUE and DOUBLE PULSAR, are believed to have originated from the NSA and were released by the group The Shadow Brokers earlier this year.

While Microsoft managed to thwart a considerable amount of damage by issuing patches promptly, several systems around the world still got infected, particularly those of healthcare providers. Businesses that could not apply the updates in time were hit the most, with many of them losing access to their important data permanently. It is advisable to periodically backup such data using a virtual data room provider.

Like all other sophisticated malwares, WannaCry also tried to derail investigations from security researchers. It is a common practice to use a virtual machine to isolate the malware from the host system for investigation. This is done to protect the actual machine from the malware with the help of the sandboxed environment provided by the VM. But sophisticated malware can lie dormant for a long time if it detects it is being investigated. Most of these detection techniques depend upon detecting if the malware is running in a virtual machine. WannaCry also used a similar trick that depended upon successful DNS resolution of a seemingly random domain name. A considerable number of infected machines were saved because a security researcher found the kill switch domain name and registered it, effectively killing all new infections. New versions of the malware with more sophistication came out in the following weeks but did not reach the same level of penetration because many machines had already been patched by then. Some of the common virtualization detection techniques are examined below:

1. Examining artifacts in the virtualized environment

Usually, virtualization software does not put much effort into cleaning their traces. They often put their identification strings in several places and malware can check those to detect them. The simplest example is of networking interface names. It is fairly straightforward to detect the virtual machine by looking at the name of the network it is connected to, unless the user takes steps to mask that. Other important areas to look for are some registry keys (in case of Windows), hard drive names and some specific drivers installed in the guest system. VMWare guest tools are often used to provide support for additional features like better display scaling and higher resolutions in the guest OS, but make it easier for the malware to detect VM’s presence. An example for VMWare can be seen in the Cuckoobox sandbox source code.

2. Detection based on differences in execution environment

Detection can also be based on the differences in the environment. VMs are often used in automated states in devops. In such cases, the virtualized machine does not have access to hardware devices. The lack of such hardware devices, or lack of software critical to user interfaces, like a desktop manager system, is a strong indication that the malware is running inside a VM. If the machine in which malware is running is disconnected from the Internet but is a part of a local subnet, it is another indication that the machine is part of a cluster as a VM. Absence of a sound card is also a pretty strong indication.

3. Detection based on specific systems

Several techniques are there that are only applicable to specific vendors. For example, VirtualBox can be detected by analyzing the BIOS brand and version, or by checking the registry and presence of specific DLLs. VirtualPC can be detected by analyzing the CPUID. And Hypervisor can be detected by running a specific assembly code in the guest OS.

Finding such vulnerabilities and patching them becomes an arms race between malware writers and vendors. Security researchers often rely on sandboxed analyzers like Cuckoo, but many times this generalized approach does not work well with more complex malwares. Then the researchers have to figure out the detection mechanism by disassembly and fool the malware, or modify the malware by NOP-ing out the detection code to get it running inside the virtual machine.