As promised in my last post, we will discuss some interesting techniques used by StealthMBR and possible motives behind them. This new variant has implemented extensive protection technology at the kernel level, and looking at its layers of defenses it appears to be the job of organized and technical kernel code developer(s) who is/are probably making decent-albeit illegal-income from this. Although StealthMBR is inspired by techniques from prior projects like BootRoot, it is continuously evolving its defenses.

This variant of StealthMBR is unique among other kernel mode rootkits that we have seen to date; not only because it overwrites the MBR but also because of the number of self protection measures it is employing to prevent itself from being detected and removed once it gains the control of the system.

Self protection measures and motives:

1. Hooks IRP dispatch table of \\driver\Disk
Motive: This is one of the lowest level hooks in the kernel, created for IRP_MJ_READ and IRP_MJ_WRITE. These are created to deny read/write permission to any application that is trying to access the MBR.

2. Dummy hooks in IRP dispatch table of \\driver\Disk.
Motive: Other dummy hooks are created, probably to keep all the hooks in the same range, which may dupe some of the anti-rootkit tools that check if all the valid hooks are in the same device object range
.
3. Hooks IRP dispatch table of \\driver\CDRom
Motive: The IRP dispatch table pointers of both disk and cdrom point to same location, so this rootkit hooks the IRP table of CDRom and changes the pointers to the same location as that of the corresponding hooked dispatch routines of disk. If this table is not patched, some AV tools can compare the two pointers and raise a flag if a discrepancy is found. Also, it can be used to restore the original pointers in the IRP dispatch table of disk.

4. Patches classpnp.sys!ClassInitialize function
Motive: The ClassInitialize function is an exported function of the ClassPNP.sys driver, which has references to various pointer locations of the original IRP dispatch table [Figure 1]. An AV tool having the knowledge of this can compare the two pointers and raise a flag if a discrepancy is found. Also, it can be used to restore the original pointers in the IRP dispatch table of disk.

The addresses highlighted ( in red) in Figure 1 are the original addresses which will be patched by the rootkit.

Figure 1

5. Creates a “Watcher” thread
Motive: This is the plan ‘B’ of this malware or a failsafe method to prevent itself from being removed, even if the original pointers are known and somebody(AV) tries to restore its hooks (which is the necessary first step to write back the MBR). This thread continuously watches any attempt to restore the original IRP_MJ_READ/WRITE hooks. As soon as these hooks are modified, the thread does following four things in this order:

• Restores the IRP_MJ_READ and IRP_MJ_WRITE dispatch routines to point to its own routine
• Rewrites the MBR at sector 0
• Rewrites the rootkit loader code and original MBR code at sector 60,  sector 61 and sector 62
• Rewrites the whole rootkit module in the later sectors of disk

6. Direct disk sector write access
Motive: In almost a month, StealthMBR has improved its routine to write to the MBR. Instead of using User mode APIs to write into the MBR, it now uses a call to the IoBuildSynchronousFsdRequest API to write directly in various sectors of disk by using IRP_MJ_WRITE of \\driver\disk.The possible motive of this improvement is again to evade detection by various Intrusion detection tools. 

The following code [Figure 2] is the part of watcher thread, which checks if the value of IRP_MJ_READ/WRITE is the same as the value in the EDI register. If the value has changed it will perform steps a,b,c,d as explained in point 5 above. The following code is annotated to highlight the interesting information and is self-explanatory. It can be noted that there are three calls to the rootkit’s WriteToDisk function to restore various infections.

Figure 2. Annotated code of “watcher” thread of StealhMBR rootkit

What this means for McAfee’s customers
McAfee is detecting this threat generically with the 5256 DAT files as Generic Packed.g and StealthMBR. The in-memory hooks are also detected as StealthMBR!rootkit* in the latest beta dats and will be included in the 5258 DAT files. So make sure to update your DATs to remain protected from this ever stealthy rootkit. 

Conclusion:

Since the last variant we have seen quite a few improvements in this malware, and it looks like the malware authors will keep on modifying this code to challenge AV vendors in this arms race. We will keep monitoring these threats and keep you updated of their progress.

*Note: The memory rootkit detection and repair is only available with the following VirusScan products. Please upgrade to these products to be better protected against such stealth malware.

• VirusScan Enterprise (Ver 8.5)
• VirusScan Online (Ver 11.2 and above)