Catching Blue Pill

HVT-based rootkits became a new headache for anti-malware vendors since their appearance in 2006. There are no working HVT rootkits yet (only PoC implementations), but who knows what happens later? It is possible (not easy though) to create a HVT rootkit with extra functions such as keylogging, HDD access, network communication or traffic interception. Plenty of helpful source codes are available for a rootkit creator (such as open source hardware drivers, open source operating systems etc). VT-based rootkits are very hard to detect when they are already installed. Moreover, no existing anti-malware product is capable of preventing a VT-based rootkit from installing.

So what is the solution? It is possible to detect HVT rootkits by monitoring indirect results of their activity. The advantages and disadvantages of this approach are well described in Joanna Rutkowska’s articles. The methods described are not generic and can be cheated by a rootkit (e.g. Blue Chicken method). Furthermore, they don't allow unambiguos detection of a rootkit since they don't give any access to the rootkit’s body.

We have found another approach. Here is its brief description.
The idea is to intercept a hypervisor's start by another hypervisor (let’s call the latter a Virtual Intrusion Prevention System, or VIPS). When any hypervisor (malicious or legitimate) starts, it turns VM root mode on. This event can be easily intercepted by a VIPS. So what's next? There are 2 ways to handle this event: blocking a hypervisor completely, or allowing it to work through emulation.

The first way consists in emulating a PC with disabled HVT feature in BIOS. This will block a HVT rootkit from working.

The second way consists in allowing a hypervisor to work through emulated hardware virtualization (or nesting). This should be done for legitimate virtualization software.

In both cases (blocking or emulating), a VIPS intercepts a hypervisor at the moment it tries to start. VIPS can read the hypervisor’s body and analyze it. A notification message can be shown.

At present only the first case is implemented - preventing a hypervisor's start. The second case is currently in development. We hope it to be ready soon.
To check the new feature of the Hypersight Rootkit Detector, we have used the CHKSVMX tool from Invisible Things Lab. When we run CHKSVMX on a PC with installed Hypersight RD, a message from HRD appears that a hypervisor’s start has been blocked. CHKSVMX tool also reports a disabled HVT feature (see images below).

Detecting and blocking hypervisor on Intel VT-x

Detecting and blocking hypervisor on AMD-V

We didn’t test the new HRD feature with the Blue Pill because the Blue Pill is currently implemented on x64 platform only. When we create a x64 version of Hypersight, it will be detecting the Blue Pill as well. The opportunity to catch a Blue Pill does exist and we have proven it.

The approach described can be successfully implemented in anti-malware software to achieve HVT rootkits blocking. It can also be integrated with virtualization software. The real BP stopping aproach can demotivate malware creators from exploring the area of HVT rootkits (mind that the creation of a full-scale HVT rootkit is a big challenge comparable to development of a mini-OS).

Detecting and blocking Shadow Walker

Recently we got a sample of code that conceals itself in the memory by modifying the page table (a technology known as Shadow Walker). Shadow Walker is based on the fact that Intel IA-32 CPUs have 2 address-translation caches: for code pages (ITLB) and for data pages (DTLB). It works like this. A page fault handler (int 0x0e) is intercepted, and then the pages of concealed code in the page table are marked as missing pages. After that, any attempts to access those pages for read, write or execute lead to page faults. The page fault handler checks requested access to page: either execution or access to data. In the case of execution, the handler loads ITLB with a original code page. In the case of access to data, the handler loads DTLB with a fake page. Thus, using desynchronization of ITLB and DTLB, Shadow Walker conceals its presence in the memory.

We tried to run Shadow Walker on a computer with installed Hypersight RD 0.3.543.


Test 1. Detecting

In this test Hypersight RD worked with the default settings. By these settings, modifications of the page table are allowed and recorded. After running Shadow Walker we noticed the window Hypersight RD had started to scroll messages on writing to page table. Hypersight RD window had been looked as follows.



The figure shows that a code that doesn’t belong to any of the kernel modules, writes to the page table. This activity is performed by the page fault handler, marking concealed pages as present or absent when loading them to TLB.


Test 2. Blocking

For this test we have turned on the option "Disable page table modification (unsafe)". This option turns on blocking of the page table modification by untrusted code.



Then Shadow Walker was loaded. Hypersight RD window had taken the following form.



You can see that Hypersight RD blocked Shadow Walker’s attempts to modify the page table. Subsequent work of Shadow Walker became impossible since Shadow Walker was unable to mark pages of code as missing. Thus, the Shadow Walker had been completely blocked.