This article will detail virtualization-based malware and explore: the differences between virtualized and emulated malware, virtualization-based sandbox malware generally and the three different techniques that malware use to evade virtualization-based malware. We’ll give a rundown of some of the different malware and malware families that take advantage of virtualization-based sandbox vulnerabilities.

Virtualization-based versus emulated sandboxing

Sandboxes are typically used to detect malware and the relative safety of code. However, advanced malware and malware families can evade both mainline consumers and next-generation sandboxes. This applies to virtualization-based sandboxes, or sandboxes running on virtual machines. Emulated sandboxes are where the entire system is emulated — from memory to CPU to I/O devices. It offers the greatest stealth visibility of what occurs within programs and applications. Virtualization-based sandboxing offers less stealth (as malware can easily detect the hypervisor and then hide their malicious actions) and offers less visibility within programs and applications. This is a major shortcoming for virtualization-based sandboxing.

Virtualization-based sandbox malware

Advanced malware can detect whether it is executed or running within a sandbox. When it detects a sandbox, it will simply avoid taking malicious action and will successfully evade detection. The sandbox will then erroneously label the file as benign and will be allowed onto the network.  Without detecting that it is in a sandbox, the malware will just proceed as normally and perform malicious actions. The key here is to not allow detection so if it is malware, you can see it for what it actually is. Virtualization-based sandboxes cannot evade detection because the malware can detect virtual machine environments such as VMware, Xen and KVM. When this “guest” operating system (OS) is running on top of a “host” OS, it inserts artifacts onto the host system. Some of these artifacts include OS system files, processes, additional CPU features and other elements required for virtualization. These artifacts are the tell-tale signs advanced malware looks for when detecting sandbox or VM presence and is one of the techniques explored. 

Techniques to avoid virtualization-based sandboxes

There are three techniques that advanced malware uses to avoid virtualization-based sandboxes.

Virtual machine artifacts discovery

As mentioned earlier, VMs often include artifacts that leave clues about their presence on a system. You can think of them as a trail of breadcrumbs that malware can use to spot a virtualization-based sandbox. There are a number of different breadcrumb trails attackers can use, including:

The presence of VM tools: For example, if you are using VMware, your system may have over 50 references to VMware in its system files Specific hardware parameters unique to either VM or real physical environments: These can be found querying serial numbers or values attributed to processors, motherboards and so on Registry keys can contain large volumes of values that only virtual systems use: VMware can store over 300 references to VMware Specific system memory structures may be located in different areas for VM environments, including Interrupt Descriptor Table (IDT) Identifying the virtual network adapter’s MAC address or BIOS serial number: VMware is associated with MAD addresses beginning with 00-05-69, 00-0c-29, 00-1c-14 or 00-50-56

User activity discovery

User activity on the host, including browser bookmarks, history, cache and so on, may be indicative of an authentic environment.  Malware can also detect user activity by referring to user interaction and digital signatures. User activity can be determined by using the frequency and speed of mouse clicks — sandboxed environments will have as many. Other evidence can be gleaned from specific user interaction such as interaction with the system that precedes malicious code activation. An example of this is the time it takes for a user to activate malicious code by double-clicking on an embedded image. 

Virtual hardware fingerprinting discovery

Attackers can check the system temperature and the fan to determine whether the environment is physical. A CPU check of a system fan can be performed with a WMI query of $q = “Select * from Win32_Fan” Get-WmiObject -Query $q. If the results return zero elements, the machine is likely virtual.

Examples of virtualization-based sandbox malware

There are many different examples of malware that can evade virtualization-based sandboxes. The following examples of malware use the techniques listed above.

BadPatch CHOPSTICK CozyCar Dyre EvilBunny FIN7 FinFisher GravityRAT HAWKBALL OopsIE OSX_OCEANLOTUS.D PlugX Pupy Remcos RogueRobin ROKRAT Smoke Loader SynAck UBoatRAT Ursnif yty

Mitigation and detection

Virtualization-based sandbox malware cannot be mitigated easily because it uses abuses of system features. To remove this ability from malware would essentially require turning off the system’s ability to use virtual environments. You also cannot easily detect this type of malware but monitoring your system for suspicious processes that gather system information for discovery in a short time period may help. 

Conclusion

Sandboxes are normally used in part to verify whether an application, program, executable or just a piece of code is malicious. Attackers know this and can effectively evade virtualization-based sandboxes, making it easier to gain entry to a target system. By using emulated sandboxes, you can bypass this vulnerability and better avoid the malware listed above.  

Sources

Virtualization-Based Sandboxes are Vulnerable to Advanced Malware, Lastline Virtualization/Sandbox Evasion, MITRE ATT&CK Sandbox Architectures — Which One is Best at Detecting Malware?, Lastline