MBR rootkit changes itself and strikes again

When MBR rootkit came out on late 2007 - early 2008, it was immediately clear that it was a breakthrough infection, different from every other kind of rootkit infection seen in the wild. The proof of concept was known since 2005 but no one was expecting to see a malware using this technology in the wild. It took only few months to quickly become one of the worst threats of the last year, with ten of thousands of infected PC.

Even if the first MBR rootkit variant is still undetected by some antivirus vendors, its creators decided to develop a new version of it, virtually able to bypass almost all security products, even the ones able to detect the first version. Our research lab started to receive new reports of this infection since the first days of April.

If the first MBR rootkit was not trivial at all, the new variant is yet more tricky to be detected. Master Boot Record is still the main target, but the way how it hides itself from security products is somehow impressive. Later this week, we're going to release a new product, Prevx 3.0, which will detect and clean this infection for free.

First MBR rootkit variant was using IRP hooks to filter out every attempt to read and write the MBR. Disk.sys Windows driver, disk class driver used for managing disk devices, was hooked and the original Windows functions pointed by the driver and used to handle disk packet requests were replaced by the rootkit ones. Of course every reference to the original address was overwritten by the rootkit, so that it was more difficult for a security product to discover the original function address and restore the legal function.

Hooking disk.sys would mean working really in-depth, bypassing most of security solutions which claim to be able to read drives at low level.

However, when MBR rootkit infected the system, it was easy to understand that something in the system was wrong because of orphan system threads and IRP hooks pointing to an unknown kernel memory region.

The new version of MBR rootkit is smarter enough to give researchers some bad days, due to improved hooking techniques and spaghetti code. As written in my previous blog post, the rootkit is still using IRP hooks but in a smarter way.

It doesn't hook anymore disk.sys driver, it goes deeper. It checks which is the lower device to which the device \Device\Harddisk0\DR0 - belonging to disk.sys driver - is attached to. The relative driver is then hooked. More exactly, its IRP_MJ_INTERNAL_DEVICE_CONTROL function is redirected.

If the lower driver to which the device is attached is atapi.sys, then atapi.sys will be hooked. If the lower driver is acpi.sys, then that driver will be attacked. If the lower driver is vmscsi.sys, then that one will be alterated. This is why you can get different results from pc to pc, and from a pc and a virtual machine like VMWare.

This is really cool, but impressive things are still to come. This hook, used to hide the MBR, is set on the fly everytime the rootkit catches an attempt to read the Master Boot Record by opening an handle to the disk. Then, when the handle is closed, the hook is removed. Everything will look clean, because of no visible hooks.

Here the impressive stuff: to understand when someone is opening handle to the disk the rootkit uses a technique called Direct Kernel Object Hooking. This technique, already known since some time but used only by few rootkits because of it's complexity, attacks Windows Kernel Objects's methods. By doing so, attackers can control and alterate the OS from one of the best places. We have seen this technique used in some Rustock variants.

Anyway, even this attack technique can be detected. Indeed, if you scan the system after a MBR rootkit infection, you will not find any attack caused by DKOH at first glance. MBR rootkit creators knew that they could go still deeper than simple DKOH, and they did it.

Before explaining what did they do, I would underline that a similar attack technique has been lately used to hide SSDT hooks.

Detecting SSDT hooks is trivial, because you can scan the System Service Descriptor Table and check for discrepancies, redirects, inline hooks, or even a mix of all these techniques. What would happen if someone forces some applications to use another System Service Descriptor Table which would be a copy of the original one but with malicious hooks set? An attacker is able to arbitrary redirect applications to use a faked SSDT and leave security products to scan the original untouched SSDT table. A non-aware antirootkit will not find anything wrong in the system, no hooks in the SSDT, because it's scanning the original untouched table.

If you understand this, then you can understand how does the new MBR rootkit work. It's just a bit more complicated and done more in-depth, but the concept is almost the same.

Explained as simple as possible, every object like a device object in Windows has an object header structure before it. The object header defines the object, assigning it to the relative kernel object. For example, the device object \Device\Harddisk0\DR0 is defined as kernel object type "Device".

Now, if you would hook the kernel object type "Device", you could do it by replacing its methods. Anyway it would be easily detected by every object type scan. This is still not what MBR rootkit writers would, the infection is not hidden enough.

Then what did they decide to do? They created a custom kernel object type, a copy of the original "Device" kernel object. This kernel object is hooked, its ParseProcedure is replaced by the rootkit one. Then, the \Device\Harddisk0\DR0 device type has been replaced in the OBJECT_HEADER struct, changed to the custom object type just created.

By doing so, the hook will be totally invisible to a plain DKOH scan because original Windows kernel objects are not hooked.

When an handle to the device is opened, the rootkit sets up its IRP hook to the already choosed driver and sets a global DKOH hook on the kernel object type "File", replacing the CloseProcedure method. By doing so, it is now able to understand when the handle will be closed and it can immediately remove its hooks.

This is really impressive stuff. This is another reason why we shouldn't actually be worried about SMM rootkits or CPU attacks more than what we should be because of current attacks. Neprodoor, new MBR rootkit and many other ones are all real in the wild attacks that are showing the difficulties of security industry to fight against these threats.

We have already detected many infections caused by the new MBR rootkit and we expect to see this number to quickly increase, like the old MBR rootkit did last year.

We have already written detection and cleanup routine for this nasty infection. The major update we're going to release in some days to our Prevx products will include this feature. Cleanup of this infection will be released for free.