MBR Rootkit: new tricks added

Since the beginning of this year, a new kind of rootkit has been discovered in the wild. The MBR rootkit, the rootkit that affects Master Boot Record to hide itself inside Windows, has enticed the security industry and sparked many conversations on the future of malicious software because of its new approach never used before if not for some proof of concepts.

After three months, the gang behind this infection changed the malware code more and more times, trying to better hide their creature.

Firstly they introduced a driver to overwrite MBR instead of using simple Win32 subsystem APIs. By this way they tried to bypass some poor HIPS protections that would detect low level disk access behavior.

Now that some companies and developers released removal tools for this infections, they tried to change the way how they hide the MBR rootkit.

As explained in a past article we released, the MBR rootkit hooks Disk.sys's IRP_MJ_READ and IRP_MJ_WRITE dispatch routines so that it can obfuscate MBR's original code, showing instead a clean version of the Master Boot Record saved before the infection.

Now the game has become more dirty. First, they patch CLASSPNP.sys driver in memory, then they hook more Disk.sys's IRP_MJ_* dispatch routines and they add same hooks for cdrom.sys's IRP_MJ_* dispatch routines.

To better understand why they did it, let's go a bit more in detail.

Disk.sys's IRP_MJ_READ/WRITE dispatch routines point - in a uninfected machine - to a function called ClassReadWrite, which is a function provided by CLASSPNP.sys driver.

Now, if rootkit hooks Disk.sys's IRP_MJ_READ/WRITE to hide Master Boot Record's code, all that someone could do is getting original pointer to CLASSPNP!ClassReadWrite and, then, read MBR's code without any rootkit's change.

Here the problem arises: ClassReadWrite isn't exported from Classphnp.sys driver, and there are some ways to recover original ClassReadWrite pointer.

The first way would be to do a code analysis of a function called ClassInitialize. This function is exported by CLASSPNP driver and it contains the original pointer to ClassReadWrite function.

Here appears the first countermeasure used by the rootkit: it patches ClassInitialize function so that the original address of ClassReadWrite can't be recovered by there.

Another way would be to analyze cdrom.sys's driver. Cdrom.sys's IRP_MJ_READ/WRITE dispatch routines are pointing to the same ClassReadWrite function. This means that from cdrom.sys it would be possible to recover original address to ClassReadWrite function.

Second countermeasure used by the rootkit: it now hooks cdrom.sys too, instead of only disk.sys.

Then, the third change is the addition of dummy hooks by the rootkit. The first release of MBR rootkit hooked only IRP_MJ_READ/WRITE disaptch routines of Disk.sys. Now they added dummy hooks on:

• IRP_MJ_CREATE
• IRP_MJ_CLOSE
• IRP_MJ_FLUSH_BUFFERS
• IRP_MJ_DEVICE_CONTROL
• IRP_MJ_INTERNAL_DEVICE_CONTROL
• IRP_MJ_SHUTDOWN
• IRP_MJ_POWER
• IRP_MJ_SYSTEM_CONTROL
• IRP_MJ_PNP

maybe to scramble a bit ideas of av companies.

The truth is that, at the moment, security companies are a step behind this new infection and the gang who is developing this rootkit is playing his game and he's winning. Almost all known products developed to detect and remove this rootkit infection have been bypassed by latest releases of this malware. Moreover, looks like the gang is pretty active.

The good news is that Prevx CSI can still detect and clean the MBR rootkit infection. Since we added detection of this rootkit in January to our antirootkit engine, it hasn't required any update and it's still detecting the rootkit component of the infection.

Leave a reply