alex_aldo - Fotolia
Enterprises are increasingly adopting virtualization technology, according to researchers, who estimate that 70% or more of organizations in 2015 will have implemented virtual servers and other services. Virtual servers and desktops must be protected from malware like other systems, but attackers are coming up with new ways to avoid detection and analysis.
Security researchers have long used virtual machines (VMs) to isolate and analyze malware. This has led to the misconception that malware disappears once it detects a VM. The use of sandbox and virtualization technology is also becoming more prevalent in security tools.
What’s the real story of how malware is adapting to virtual environments?
While it didn’t get much mainstream attention, the W32.Crisis malware Symantec described in 2012 paints a terrifying picture of things to come, as malware authors start using new tactics to infect virtual machines in our environments. The Crisis malware, in addition to a number of other malicious actions, can actively seek out VMware virtual machine files stored on systems it has compromised. Once VMware virtual machine disk files have been discovered, Crisis mounts the disk and then uses a native VMware facility to insert itself into the disk file, thus creating a newly infected VM. This is likely the first time we’ve seen malware authors leverage a virtualization technology’s native file formats to infect systems, but the approach makes a lot of sense: Virtual machines are, after all, just files; and when malware authors realize that file infection can apply to an entire system, it’s only a matter of time before this technique becomes widespread.
Well-known malware in the last five to 10 years has included virtualization detection capabilities. The Conficker worm, prevalent in 2007 and 2008, has virtualization detection capabilities, as does the Storm worm that surfaced in 2008 and 2009. Many other worm and bot variants since then sport various types of VM detection routines. What is the motivation for malware to detect virtualization in the first place?
Virtualization was less common a decade ago than today. Back then, malware that detected virtualization was focused entirely on detection of sandbox environments (specialized or simply virtualized desktops) used by reverse engineers. Malware would often shut down or self-destruct to avoid being pulled apart by security analysts.
Today, however, the opposite is true: Server-oriented malware is actually more likely to infect a virtual system than a physical one in many organizations, and self-destruction would be self-defeating. If the malware detects a VM, it may wait for a short time or certain number of clicks before beginning malicious activities. These behaviors can be harder to catch and patch in automated VM environments.
There’s debate in the reverse engineering and incident response communities as to the motivations of attackers looking to detect virtualization technologies in use, as well as how prevalent the practice of including “anti-VM,” or VM detection, routines in malware really is today. Most security researchers will acknowledge that malware “checks out” the environment it runs in, and may determine that a desktop OS that’s virtualized could be a sandbox. And malware packing tools, such as the Tejon Crypter, feature anti-VM options for VMware, VirtualBox and more.
Learning to adapt
There’s no doubt sandbox and virtualization detection is an area to which attackers are paying attention. Malware can detect whether it’s running inside a VM in fundamentally four ways.
The easiest methods can be used when an attacker has gained access to a system; these involve either examining the MAC address or network adapters or peering into the Windows registry. For starters, VMware has four Organizationally Unique Identifiers (OUIs) registered with the Institute of Electronics and Electronics Engineers. If the network adapters have MAC addresses starting with 00-05-69, 00-0c-29, 00-1c-14 or 00-50-56, all registered to VMware, the attacker knows the malware is inside a VM. The second approach is to look into the Windows registry. Many entries contain simple strings such as VMware, vmx and esx.
A third, more advanced way for attackers and malicious programs to ascertain whether they’re in a “real” machine or a VM is by analyzing the results of specific machine language calls. By attempting to call a particular instruction that moves the value VMXh into a different register, it’s simple to determine whether or not the malware is inside a VM. (This is a VMware-specific option, of course, but many other virtualization platforms have their own simple nuances that could also lead to detection.)
Memory structures is the fourth option that can help malware determine whether a compromised system is virtual or physical. Virtualization technologies have to abstract some components of the operating system. One of these components is the Interrupt Descriptor Table, a data structure on x86 systems, which is used for determining responses to interrupt requests and exceptions. On most non-virtualized hosts, the IDT will reside at a fairly low point in system memory, whereas Guest VMs store it in a higher location. Simply determining where this structure is located can identify VMs. Virtual PC IDTs are typically at memory location 0xe8xxxxxx while the VMware IDT is found at 0xffxxxxxx. Other common memory structures like the Global Descriptor Table and Local Descriptor Table can also indicate the presence of virtualization. Joanna Rutkowska, a well-known security researcher and founder of Invisible Things Labs in Warsaw, Poland, brought this to light in 2006 with her Red Pill tool, which performs this check for the IDT memory location. Since then, many malware variants have used the same techniques.
Not always a quitter
However, some research doesn’t seem to support virtualization detection as a primary area of focus for attackers. Candid Wueest, an analyst on Symantec’s global security response team, wrote a blog last August that breaks down the malware submissions the research team receives from customers every month, by analyzing a subset of the submissions that included anti-VM technology.
Symantec looked at 200,000 of its customers’ submissions from 2012 to 2014 and found on average that one in five, or 20%, of malware per month included virtualization detection, which could abort malware execution.
Some security tools need to evolve to play well in virtual environments. The antivirus industry, for instance, still has to adapt to accommodate VMs and the performance impact of virtualization’s shared resource compute model. Trend Micro’s Deep Security, Intel Security’s MOVE Antivirus (McAfee Management for Optimized Virtual Environment), Kaspersky Security for Virtualization and BitDefender Security for Virtualized Environments are all examples of antimalware tools that have been modified to accommodate for virtualization environments.
In addition, malware reverse engineers have begun looking at products and technology that can help to identify whether their sandbox technology is displaying overt signs of virtualization. Paranoid Fish (pafish) is an open source project that emulates the anti-VM and analysis functions of malware today. It provides a report to analysts describing the anti-analysis actions that are likely to be triggered should malware actually be run in the analyst’s sandbox.
What’s next in the world of malware and virtualization? Expect to see more advancement in antimalware products that leverage virtualization (sandboxes and local agents like those from Bromium), as well as improvements in performance for virtual systems that share resources in virtualized environments.
Malware authors will continue to look for virtualization in use on infected systems, although the techniques will likely shift toward sandbox technology. This could change, however, if new methods of hypervisor compromise become public that allow malware to “break out” of a VM and compromise other systems in the same environment. Whether that happens or not, you’re likely to see more malware using new file infection techniques like those seen in the W32. Crisis malware sooner rather than later.
About the author
Dave Shackleford is the owner and principal consultant of Voodoo Security LLC; lead faculty at IANS; and a SANS analyst, senior instructor and course author. He previously worked as CSO at Configuresoft; as CTO at the Center for Internet Security; and as a security architect, analyst and manager for several Fortune 500 companies. He currently serves on the board of directors at the SANS Technology Institute and helps lead the Atlanta chapter of the Cloud Security Alliance.