SubVirt: implementing malware with virtual machines

Abstract

Attackers and defenders of computer systems both strive to gain complete control over the system. To maximize their control, both attackers and defenders have migrated to low-level, operating system code. In this paper, we assume the perspective of the attacker, who is trying to run malicious software and avoid detection. By assuming this perspective, we hope to help defenders understand and defend against the threat posed by a new class of rootkits.We evaluate a new type of malicious software that gains qualitatively more control over a system. This new type of malware, which we call a virtual-machine based rootkit (VMBR), installs a virtual-machine monitor underneath an existing operating system and hoists the original operating system into a virtual machine. Virtual-machine based rootkits are hard to detect and remove because their state cannot be accessed by software running in the target system. Further, VMBRs support general-purpose malicious services by allowing such services to run in a separate operating system that is protected from the target system. We evaluate this new threat by implementing two proof-of-concept VMBRs. We use our proof-of-concept VMBRs to subvert Windows XP and Linux target systems, and we implement four example malicious services using the VMBR platform. Last, we use what we learn from our proof-of-concept VMBRs to explore ways to defend against this new threat. We discuss possible ways to detect and prevent VMBRs, and we implement a defense strategy suitable for protecting systems against this threat.

Towards Sound Detection of Virtual Machines

“…For example, VMMs mask names and values (i.e., location of the IDT, special processes, communication back doors etc...) or interpose on specific instructions which are used in detection [10]. D2: Detectors search for previously unknown software artifacts.…”

“…Timing the execution of a Benchmark on M necessitates the existence of a reliable timing source. If M is a virtual machine, the VMM may return timing measurements which do not accurately characterize the execution time [10]. To overcome this complexity, we allow the detector to contact an external timing source.…”

“…Thus, we cannot trust a VMM to return valid answers to rdtsc "in the wild" [10]. Figure 7 compares internal (local) versus external timing measurements for the exact same experiment run on two variants of HVM Xen.…”

“…Redpill operates by reading the address of the Interrupt Descriptor Table (IDT) with the SIDT instruction and checking if it has been moved to certain locations known to be used by VMware. This algorithm can be easily fooled since it relies on the VMM to return the correct address of the IDT [10]. Similar to Redpill, VMware's Back 5 is a software-dependent detection attack which uses the existence of a special I/O port, called the VMware backdoor.…”

“…Virtual machine monitor detection has two direct implications for botnet remediation: first, it provides defenders with the ability to detect bots which utilize VMMs for improved stealth (e.g., VM-based rootkits [10,18,27]) and second, exploring VMM detection allows defenders to assess the extent to which intelligent bots can identify and potentially bias virtualized analysis environments such as highinteraction honeypots [9,22,26].…”