Virtual machine introspection (VMI) is a term coined by Garfinkel and Rosenblum in 2003 in their paper “A Virtual Machine Introspection Based Architecture for Intrusion Detection” and they describe VMI as the “approach of inspecting a virtual machine from the outside for the purpose of analyzing the software running inside it”. VMI and its capabilities and techniques have evolved quite a bit since then, but the principle remains the same. However, before we start a discussion on VMI, we will cover some of the basic concepts of virtualization.
Virtualization
Virtualization is a technology that makes it possible for multiple operating systems (OSs) to run concurrently on a single host system without those OSs needing to be aware of the others. The physical machine is multiplexed into several virtual machines (VMs), on top of which unmodified OSs (referred to as guest OSs) can run. Since each VM can have its own OS, this allows multiple guest OSs to run in parallel on a single physical computer. This is how cloud computing providers provide their services, for example. They run multiple customer guest OSs on a single server.
Virtualization is often confused with emulation as they achieve similar results. The difference between virtualization and emulation is that virtualization requires support from the hardware. This leads to a generally faster approach that is more aligned with the actual capabilities of the underlying hardware. Emulation, on the other hand, is generally less performant and will lack any features of the physical hardware unless specifically implemented but does not require any special hardware as it is completely implemented in software. While emulation has its benefits, we will concentrate on virtualization for virtual machine introspection in this blog post.
Hypervisors and VMI
While virtualization does rely on hardware support, there is a software component. This software component is referred to as the hypervisor or the virtual machine monitor (VMM). This software layer sits on top of the hardware and exposes the VM to the guest OS. This is generally accomplished in one of two configurations. A type 1 hypervisor (or bare-metal hypervisor) runs directly on the underlying hardware. The Xen hypervisor is an example of a type 1 hypervisor. On the other hand, a type 2 hypervisor (or hosted hypervisor) runs within an OS. In this case, we refer to the OS within which the VMM runs as the host OS. KVM is an example of this. See figure 1 for a diagram of the two configurations.
The VMM will assist the hardware and gain control when the guest OS performs some operation that the hardware is not designed or instructed to handle. That is, the VMM can program the hardware as to which actions of the guest OS it wants to handle and which actions it wants to let the hardware handle. For example, the VMM may program the hardware to give it control everytime the guest writes to a specific register. Going forward any time the guest OS writes to this register, the hardware hands control to the VMM. We refer to this as a trap to the VMM. This ability of the VMM enables VMI.
The Power of Virtual Machine Introspection
VMI allows us to take advantage of the hardware and the VMM to inspect the guest. As we learned above, the VMM can program the hardware to trap certain events. This is valuable for virtual machine introspection as it allows us to trap specific actions the guest might take and inspect the guest’s state at exactly that moment. This leads us to the next advantage: The VMM has full visibility into the entire guest state. This includes the CPUs, the memory, and any devices (e.g. network cards, hard disks, etc.). Finally, the VMI components benefit from complete isolation from the environment that is being inspected. This makes it difficult to detect or attack the inspecting components and reduces the observer effect on the guest environment. The observer effect describes the intrusive nature of any observer of a system. Even if one tries to be as unobtrusive as possible, there will always be some side effects. This effect is amplified when the observer is located within the system being monitored.
Leveraging VMI
Leveraging these advantages allows us to create powerful tools for the analysis and debugging of software within the guest. For example, one can set breakpoints within the guest and trap to the VMM every time the breakpoint is executed. This is a capability that debuggers and other analysis tools have had for some time. However, by leveraging virtual machine introspection we can set the breakpoint such that it is impossible for the guest to see the breakpoint in memory or detect that a debugger is attached to the process. Occasionally software may change its behavior when it detects it is being inspected. This form of anti-analysis is common in malware or in software that attempts to protect its IP.
This is just a single example of the power of VMI. There is so much more that can be done with this powerful technique. VMI allows us to directly inspect the virtual hardware providing us with a unique view of the system that is not possible by any other means (i.e. the entire physical memory and all CPU registers are always accessible). This allows us to build powerful inspection components. For instance, we can protect memory against modification, inspect each process before it comes into context, or generate an entire control flow graph and we can do all this while remaining completely isolated from the guest and any components that might want to thwart our efforts.
Applications for Virtual Machine Introspection
The applications of virtual machine introspection are vast. The most common use case is perhaps the analysis of potentially harmful software in a sandbox. Using VMI provides isolation from the potentially harmful malware and makes it very difficult for the malware to determine it is being analysed. At the same time, VMI provides access to the entire physical memory of the guest making it very difficult for the malware to hide from the analyst. Such a VMI sandbox may aid a malware analyst by providing a platform for manual analysis or by being part of an automated analysis workflow. In the manual case, the analyst would execute the suspect software and leverage the sandbox to instrument the environment to suit his or her needs. For example, the analyst might set very specific breakpoints for the sample he or she is analysing. On the other hand, VMI lends itself well to automated analysis as well. In this case, a sample would be automatically detonated in the sandbox and VMI instruments the environment to record predetermined actions. For example, an automated run might record all files a sample opens.
VMI also has applications as an intrusion detection system (IDS) for real-time monitoring of critical systems. This can be performed without modifying the guest OS but provides an expansive view into the behavior of a system. It allows a VMI component to record potentially malicious actions and forward them to an IDS or SIEM.
Finally, VMI can be a useful technique for kernel debugging or for debugging the interaction between several processes within an OS. It does not require any special setup or configuration of the guest OS and interactions between multiple components can be debugged from a single instance, rather than having multiple debuggers running simultaneously.
BedRock System’s Products and Offerings
We leverage virtual machine introspection in several of our products and offerings. Our Active Security suite leverages VMI to help you protect and monitor your deployed critical systems in real-time. For more information see our Products page.
In addition to our product offerings, we maintain an open source VMI platform that supports both ARM and x86 architectures called tenjint. tenjint can be leveraged to perform analysis as described above and is available here.
