Continuing on from the first part of our exploration, in this post I want to explore two questions.

1. How is it that malware can differentiate between being run on real hardware vs being run inside a (system) virtual machine?
2. How exactly do some malware behave differently on real hardware (a bare metal computer system if you will) compared to a virtual machine in order to fight against malware analysis?

How is it that malware can differentiate between being run on real hardware vs being run inside a (system) virtual machine?

The answer to the first question is simple enough. System virtual machine software is designed to mimic the hardware functionality of a bare metal computer well enough, to be able to run the same operating systems and application software you would run on the real hardware. Granted that in reality it is not so clear cut. For example modern CPUs implement special hardware features and instructions, referred to as hardware assisted virtualization features that enable virtual machine software to operate more efficiently and execute code faster on such CPUs compared to relying on strictly software based virtualization techniques.

Many modern virtual machine monitors (VMMs), at the hearts of virtual machine software, do indeed use these hardware assisted virtualization features provided by the CPU they run on (host CPU) to at least some extent by default. Some virtual machine monitors even virtualize these hardware assisted virtualization features well enough these days! Also virtual machine software do have the ability to allow, to varying degrees, direct access to some types of actual hardware on the host system (for example USB peripherals).

But regardless of how sophisticated these virtual machine software tend to be, they are not 100% identical to the real hardware. In fact, one could argue that the goal of virtual machine software is to provide a platform that can facilitate the execution of multiple operating systems concurrently, both efficiently and with an accepted level of isolation (as well as a required amount of sharing capabilities) rather than to provide an environment identical to bare metal systems. As long as the operating systems can run fine and the majority of software running under these virtualized operating systems are running fine, virtual machine software is considered to be doing their job well.

However, some malware on the other hand look for specific differences that can be detected when they are on virtualized operating systems running inside virtual machine software. These differences are of course largely irrelevant when it comes to running operating systems themselves and application software inside the virtual machines. But such differences do give malware the chance to determine if they are running inside a real or a virtual machine. Most such malware which look out for any telltale signs of being run inside popular virtual machine software however, in the absence of such signs, tends to determines that the malware is indeed running on real hardware.

How exactly do some malware behave differently on real hardware compared to a virtual machine in order to fight against malware analysis?

The answer to the second question “how exactly do some malware behave differently on real hardware vs VMs” is that this can vary quite a bit depending on the specific malware. But some of the things that we know malware likes to do from our own experience of analyzing a lot of nasty malware is:

• Malware typically keeps its malicious code encrypted and/or highly obfuscated. Inside a VM the malware may prefer not to decrypt and expose such code to analysis either dynamically by looking at what the code does on the system or statically by disassembling and looking at the CPU instructions to see what it does.

• It is fairly common for malware to inject malicious code into normal applications in a system. For example, malware may inject some “call home” code into major browser processes such as Internet Explorer, Firefox or Chrome. They may inject some code which looks for private or proprietary data into the Windows Explorer process, so when the user browses folders and interacts with files, the injected code can also check if these are files that also contain information that the malware perpetrators might be interested in. In many such cases, this type of code injection is meant to get around host based security technologies that grant the ability to perform specific actions on the system only to a specific set of applications. For example a host based firewall solution might enforce that only the web browser and a limited set of applications that use web based updating are allowed to access web servers on the Internet. By injecting code into these processes the malware masquerades as the processes themselves and bypass the limitations it would have had to operate under because of the enforcement policy of such security technologies. Also behaviour based, malware (or anomaly) detection security technologies do expect the web browser to visit websites and Windows Explorer to open and read files. So by doing injecting code into other processes malware also aims to obscure malicious behaviour from such security technologies. When some malware detects that it is running inside a VM, it simply would refrain from injecting malicious code into system applications and processes as it normally would do to prevent analysts from catching it red handed in the act along with the code it tries to inject.

• Contemporary malware tends to connect to and communicate with C&C servers and/or botnet infrastructure of the malware perpetrators, once a victim machine is infiltrated. Malware analysis within the security industry is known to use VM environments to let the malware run inside VMs and watch the network activity to detect, dissect and analyse these communications so that security technologies such as NIPS systems can be augmented with new detection methods to detect newly analysed malware traffic. So malware authors tend to not expose such communications specifics to analysis by connecting to these C&C or botnet infrastructure when running inside VMs. Some go one step further and try to present decoy information in this situation. For example, some of the later variants of the Citadel malware family, when running in a VM, tries to connect to a set of decoy C&C servers. The most logical conclusion is that the malware authors do this to deceive the malware analysis community into trying to get these decoy servers shut down or if the decoy servers are already non existent, assume that this malware is less of a threat because the C&C infrastructure is no longer operational. Meanwhile on real hardware, the malware will connect to the actual C&C infrastructure.

So now that we know some of the different ways in which some malware behave inside VMs compared to real systems let’s take a closer look what differences between real machines and VMs malware typically look at in order to spot the difference.

1. First, most virtual machine software is much more convenient to work with when specific software from the virtual machine software suite is installed inside the VM. These are referred to as guest additions. They provide the means to share files between the host and the VM or even simple copy and paste operations between applications on the host and those inside the VM. Could even be something that is really essential like proper, non-intrusive management of the mouse interactions between the host system and the VM. These guest additions are usually composed of device drivers, services, system tray components and so on. The presence of such guest additions is by far one of the easiest and most direct things for malware to do in order to detect a VM. And they routinely do. For example, the Citadel malware family mentioned before also uses this method in its arsenal for detecting VMs.
2. Secondly to communicate from inside the VM to the host and vice versa, VMMs use things like shared memory or special instruction sequences etc. If you reverse engineer parts of the guest additions, especially the device drivers, you will see examples of these mechanisms being used. The problem is malware authors have also been known to look at these components closely. Even if the guest additions are not installed, these mechanisms that are there to make guest additions work can be detected and interacted with from inside the VM. In fact to make matters worse, there have been security vulnerabilities from time to time in these mechanisms which allow malware inside the VM to exploit the virtual machine software itself and escape into the host system. While virtual machine software vendors are very vigilant to guard these mechanisms and they generally only represent a small attack surface, in terms of detection of VMs, this is still a big one. Especially if malware inside the VM can go kernel mode inside the VM, then they have a lot of room to play in this area.
3. Third, some malware have been known to look for signs of a system that is used by a normal user doing routine things as opposed to a clean system that is specifically being used to for a particular purpose, like analysing malware. Usually, malware analysis starts with a clean VM because it is easy enough to get a clean VM going for each malware analysis session and also having a clean system does remove a lot of variability which makes the analysis process easier and more consistent. Plus it is highly unlikely for a malware analyst to keep using the VM instance he would use for analysing a particular piece of malware for a period of time doing routine things a typical end user would do.

More sophisticated detection methods

So either by themselves or in combination, the above areas appear to be fruitful for malware authors in detecting if their victim is real or if they are being watched inside a VM. But this is not the end of it. What are some of the even more sophisticated detection methods?

• Modern hardware can be quite complex, as clearly evident by looking at those thick hardware manuals. Even the official device drivers of hardware these days don’t make use of all the features present in the actual hardware. When it comes to emulated hardware inside VMs, the general approach is to emulate the hardware well enough to a point where operating system device drivers work fine with the emulated hardware. So needless to say, emulated hardware can easily lack features present in the real hardware that one can look for to spot if the hardware is real or emulated. From system chipsets to network adapters, there is significant scope here for malware to look at. And some malware with especially with kernel components do indeed do similar things.

• It has been known for quite some time that it is an extremely difficult problem to eliminate or emulate around timing discrepancies that may come about when performing certain operations inside the VM vs on real hardware. Even with the hardware assisted virtualization technologies, some operations are much slower or behave differently inside a VM as opposed to real hardware. While it is a sophisticated task to reliably make a judgement call by detecting such differences, especially when we are dealing with systems under different load, different real hardware and so on, this aspect in general a well worthy challenge when it comes to making VMs look like real machines to any software running inside them. Theoretically it is fair to say this is may be impossible task, but how far it can be done feasibly or exploited feasibly in the real world I think still remains to be seen.

So that brings us to the end of our brief exploration and is by no means exhaustive. For example, even at this level of detail, a few more posts would probably be needed to do justice to what extent malware can interact virtualized networking infrastructure vs real infrastructure to achieve very similar ends.

Hope you’ve enjoyed this brief exploration. Please feel free to explore the site for many other interesting discussions in computer security. It has been a pleasure exploring this topic with you and as always comments are welcomed.