Wednesday, October 14, 2009

How does malware know the difference between the virtual world and the real world?

It is no secret that the Information Security industry takes advantage of virtualization software in order to research security threats. VMWare, Sandboxie, Virtual PC, Anubis, CWSandbox, JoeBox, VirtualBox, Parallels, QEMU are just just of few of these virtual machines. The cornucopia of virtual environments gives the security professional the opportunity to observe and analyze malicious software in a convenient and easily reproducible manner. This presents an issue for malware writers and because of this, they often include code in their binaries to make it more difficult for computer security professionals to analyze their executables in those virtual environments. Here are some of the most frequent anti-virtualization techniques:

Check for the presence of virtualized hardware:

Virtual environments have virtual network interfaces. Just like any network interface, they are assigned a unique MAC address that usually includes the manufacturer's identification number. For example, a network interface for VMware Workstation will have a MAC address that starts with 00:50:56 or 00:0C:29 (VMware has more than one organizationally unique identifier or OUI). Malware can check for the presence of certain OUIs and choose to behave differently or not to display any malignant behavior whatsoever in a virtual machine.

It is also possible to check for the presence of GUIDs that give away the fact that it's being run in a virtual environment. Eg: MD5: 0151c5afde070a7b194f492d26e9b3ef (Trojan.Agent-124243 by ClamAV):

Any of these can be used by a malware writer to detect the presence of a virtual machine.

Descriptor Table Registers check:

There is only one Interrupt Descriptor Table Register (IDTR), one Global Descriptor Table Register (GDTR) and one Local Descriptor Table Register (LDTR) per processor. Since there are two operating systems running at the same time (the host and the guest), the virtual machine needs to relocate the IDTR, GDTR and LDTR for the guest OS to different locations in order to avoid conflicts. This will cause inconsistencies between the values of these registers in a virtual machine and in the native machine. The instructions SIDT, SGDT and SLDT are assembly instructions that can respectively be used to retreive the values of IDTR, GDTR and LDTR.

Basically, the magic number 0×564D5868 ("VMXh") is copied to EAX and EBX is set to anything but 0x564D5868. A backdoor command is loaded into CX and finally the I/O port number 0x5658 ("VX") is loaded into DX. Then the "in" instruction is used to read from port 0x5658 into EAX. Outside of VMware (on a native host), a privilege error occurs. Under VMware, the magic number 0x564D5868 is returned to EBX (yes, in this case EBX is affected by in EAX, DX) hence the CMP instruction.

Exit if being debugged:

While this is not, per se, a anti-virtualization technique, it remains a a popular check performed by malware to see if a user-land debugger is present on the operating system. That's because more often than not a debugger will be installed in a virtual image used for malware analysis.

For the Windows API function ZwQueryInformationProcess, setting the value of ProcessInformationClass to 7 (ProcessDebugPort) retrieves the port number for the debugger of the process. A value other than 0 indicates that the process is being run through a user-land debugger.

For starters, do not install tools provided by the virtual machine in your guest OS. For example, VMware provides a set of tools called VMware Tools that enhances the overall user experience with the guest OS. The drawback is that installing VMware Tools in a Windows guest OS will leave many clues easily detectable by a piece malware that it is being run in a virtual machine.

The next step is to edit your VMware .vmx file. When you create a new virtual image with VMware, settings about it are stored in a configuration file with the .vmx extension. The file contains information about networking, disk size, devices attached to the virtual machine, etc...and is usually located in the directory where you created your virtual image. With your guest OS stopped, edit the .vmx file and append the following:

Now start your virtual machine. This will allow you to run (with very little effort) more vmware-aware malware than before.

I'll point out that:

monitor_control.disable_directexec = "TRUE" will usually thwart descriptor table registers checks. This setting will make VMware interpret each assembly instruction instead of executing them directly on the processor. Therefore a the result of a sidt instruction will not be an address in the 0xffXXXXXX range as one would get without this setting.

Now, what if after all this, your piece of malware still detects that it is being run in a virtual machine? I would go through the code, find where virtual machine checks are being performed and patch the code with NOPs (0x90).

Finally, if that's too hard or not possible for whatever reason, run your sample on a native system! :-) (you can always use system backup and restore software to quickly revert the machine to its original state without reinstalling the OS)

The idea is not to neutralize the virus at all, the idea is to make it work as if it were on a real machine. The end goal is to reverse engineer the malware to see how it behaves and then provide detection for it.

Malware authors know that virtual machines are used to reverse engineer their work, the vm detection that is present in some samples is there to try and slow the malware researcher down.

maybe my usage of you guys was a bit ambiguous, but I was more referring to the security industry than the researcher. To repeat what I said, why not fake a virtual machine, thus convincing the virus that it's in one, which causes it to hide rather than attack, thus at the very least allowing the victim to use their computer. It's for this reason that I though malware makers wouldn't have tried to identify virtual machines.

What is a little more worrying is if we have malware that can detect it is running on a vm - and then goes into a sort of hibernation state. When a virtualisation exploit is available it gets polled, downloads the payload and attack "the cloud".