In the past two weeks McAfee Avert Labs is observing activity by a new parasitic worm named W32/Almanahe.a. Apart from its parasitic nature, this worm is particularly interesting because of the rootkit technique implemented by it to hide and protect itself.

Some background:

Rootkit techniques vary from simple “user mode” to complex “kernel mode”. Most of the techniques create some kind of hook to the normal execution path of a call or an API. A more detailed explanation of various techniques can be read in the latest whitepaper by McAfee here.

As explained in the whitepaper, one widely adopted kernel mode hook technique is via SSDT patching as shown in Figure 1. In order to detect such rootkit activity many freely available tools exist along with traditional virus scanners. An easy way to detect such activity is to perform a quick range check on the addresses pointed to by functions listed in SSDT. If the address lies outside Ntoskrnl.exe address range, it implies that the SSDT may be hooked. For example in Figure 1, Rootkit.sys lies outside the address range of Ntoskrnl.exe. A query on address pointed to by hooked NtDeleteKey in SSDT will raise an alarm as it is within address range of Rootkit.sys. 

Figure 1. Common SSDT hook method. Note that Rootkit.sys
is outside the address range of Ntoskrnl.exe. 

W32/Almanahe approach to SSDT hooking

An easy yet efficient way to bypass a range check technique is to introduce a detour approach while keeping the entry point of detour within Ntoskrnl.exe image. Figure 2 illustrates this scenario.

Figure 2. SSDT hook by W32/Almanahe.sys. Detour is created
within Ntoskrnl.exe body to thwart some analysis tools. 

As shown in Figure 2, the address of NtDeleteKey entry in SSDT is within range of Ntoskrnl.exe. Tools that only check to see if address pointed to by a function in SSDT lies within this range will fail to find the rootkit activity.

W32/Almanahe uses this approach of creating a detour which starts within the Ntoskrnl.exe body. It searches for cavities between section boundaries to introduce its detour code. As an example, Figure 3 shows the memory of Ntoskrnl.exe taken from a clean XPSP1 system. Figure 4 shows the memory of Ntoskrnl.exe on an infected machine, the malicious device driver has successfully patched the cavity space.

Figure 3. Cavity between section boundaries in
Ntoskrnl.exe displayed in Windbg 

Figure 4. Patched cavity by W32/Almanahe.

Performance of various code/hook analyzers on W32/Almanahe infected system

We ran some quick tests on few freely available rootkit analysis tools and looked at their code/hook analysis components only. In the figures 5, 6, and 7 it is evident that hook/code analysis components of these tools fail to pin-point the offending rootkit file by just analyzing the SSDT.

Figure 5 is a snapshot of a range check based tool. It can be noted that it fails to realize that the SSDT is hooked.

Figure 5. SSDT hooks can’t be displayed using just range check methods.

Figure 6. SSDT hooks are visible, however the
hooking entity is displayed as Ntoskrnl.exe.

Other popular rootkit analyzers like IceSword and GMER do a little better where they are able to show that SSDT is hooked. However, they fail to point out the device driver responsible for creating a mismatch in SSDT table and display the hooking module as Ntoskrnl.exe itself. 

Figure 7. SSDT hooks are visible, however the hooking
entity is displayed as Ntoskrnl.exe.

It should be noted that since many of the rootkit analysis tools implement various other techniques to catch rootkits, they may still be able to warn the user of suspicious activity.

Conclusion

The detour approach implemented by W32/Almanahe is neither ground breaking, nor a novel idea, but it is the first instance of use in the wild, observed by McAfee Avert Labs. This is yet another testimony to the fact that rootkits in the wild are adopting new techniques to conceal their nefarious code and seep deeper into the kernel.  In order to correctly find out which device driver is creating the SSDT hooks, rootkit analysis tools will have to dig deeper to perform code analysis by following the control flow of the detour, thus giving them something more to work on in this never ending battle.