By Marco Giuliani

Last Wednesday, Microsoft published a blog post detailing a significant update to a piece of malware named Popureb. The malware adds code to the Master Boot Record, or MBR, a region of the hard disk that’s read by the PC during bootup, long before the operating system has had a chance to get started. Researchers sometimes refer to these kinds of malware as bootkits, or a rootkit which loads at such a low level during the boot process that it is invisible to the operating system, and therefore very difficult to remove.

Microsoft researcher Chun Feng detailed some of the new features of Popureb.E, which includes a very low-level hook into the Windows driver responsible for disk writes and reads. When the driver on an infected system detects an attempt to write changes into the MBR — the kinds of changes a repair tool might try to make — it simply changes the command from write to read, effectively neutering any kind of tool running within Windows that might try to fix the infection.

(Update 2011-07-08: We’ve published a free command line tool that can remove Popureb.E from the master boot record of an infected computer.)

Microsoft’s initial cleanup guidance on Popureb.E was pretty drastic, and more than a little scary: Full removal of the bootkit requires a full reinstall of Windows, wiping out anything currently on the hard drive. We don’t think this is the case, and the Microsoft folks seem to have moderated their advice to include some manual fixes using the recovery console.

While the whole concept behind the Trojan is valid and technically powerful, the practical implementation of the malware is not as valid as the idea behind it. What follows is a fairly technical write-up that describes both the problem, and one  solution we’ve come up with.

Almost five years ago, we saw the first malware that targets the Master Boot Record reappear in the wild after a long absence. MBR virii pretty much disappeared after the DOS virus era, but in late 2007 the Mebroot MBR infector appeared. Bootkit development has advanced significantly in the the intervening years, from advanced kernel-mode rootkits like TDL4, to the Whistler bootkit, to ransomware that encrypts the original Master Boot Record and holds the computer hostage until you pay up.

Choosing to hit the Master Boot Record means moving the battlefield outside the operating system, bypassing every kind of security countermeasure implemented inside the operating system by security software. This is the reason why more and more malware targets the Master Boot Record: the opportunity to start before the operating system permits malware to patch the system as it wants without interference.

Like TDL4, Popureb also targets the Master Boot Record, preventing applications running within Windows from overwriting — or even touching — the infection. The Trojan makes no attempt to hide its code in the Master Boot Record; Instead, it just prevents every kind of security software from fixing it, or overwriting it. It’s like a sadistic game, where the security software tries valiantly to fix the Master Boot Record over and over again, but can never succeed.

That said, Popureb isn’t exactly like most contemporary rootkits. For one thing, it doesn’t attempt to hide itself in the system using one of the usual ways implemented by common rootkits. It also doesn’t hide its code on the MBR, but allows everyone to read its MBR code. Maybe the author assumes, with a false sense of security, that no one will be able to fix it. He’s wrong.

Samples of Popureb.E that we’ve seen are not compatible with Windows Vista or Windows 7, so it seems to only affects the Windows XP & Windows 2003 operating systems for now. After the dropper which delivers Popureb is executed, Popureb calculates the sectors on the hard drive where it’ll store its payload. The Trojan gets the right sector address by calling a low-level function that returns the hard drive’s parameters (such as Cylinders, Tracks Per Cylinder, and Bytes Per Sector), which it then uses to calculate the address where it will store its code.

Then the trojan reads the original master boot record, and duplicates the partition table, which it integrates into the infected MBR. Popureb overwrites sector zero with the infected MBR, but it also keeps a copy of the original MBR. However, Popureb renders the original MBR data unusable by using a method so moronically simple to decode that it’s almost an insult to the entire concept of encryption to call Popureb’s technique encryption.

Popureb simply rotates each byte of the original MBR code by 73 characters in one direction. It’s almost akin to the Secret Decoder Ring method of encryption, except that it would have been harder to restore the original MBR had the creator used an actual Secret Decoder Ring. While this modification renders the MBR unreadable by the system, it’s not exactly difficult to, say, rotate that data 73 characters in the opposite direction and restore it, especially if you know what you’re looking for and where to find the data.

After Popureb infects the MBR, the Trojan loads its own kernel mode driver and immediately starts guarding the modified MBR. The disk I/O protection is implemented by walking the disk driver’s stack and hooking the lowest miniport driver, which usually is atapi.sys, though that’s not the only driver it can hook.

The trojan hooks the driver’s StartIo routine and saves the original StartIO pointer for later use. The filtering routine analyzes the incoming Input/Output Request Packets (IRPs), looking for IRP_MJ_INTERNAL_DEVICE_CONTROL packets. When Popureb intercepts a SCSI packet, it checks whether it is a SRB_FUNCTION_EXECUTE_SCSI operation being performed, and swaps the SCSI CDB operation code from write to read, e.g. SCSIOP_WRITE changes to SCSIOP_READ.

The trojan also checks if it’s a CDB10, CDB12 or CDB16 packet, so it can set the right operational code. Then the packet is forwarded to the original StartIo function, which completes the IRP request. This technique will give back the result of successfully written code, while it has instead forced the entire procedure to be a read operation, resulting in a powerful disk protection — or so the author thought.

To get rid of the Trojan’s payload, we recover the disk offset where Popureb stores its code, run through a few operations to find the location of the original (now obfuscated) MBR data, and overwrite the modified MBR with the original MBR data that we restored.

For those following along at home in your debugger, in the infected MBR, at the offset 74h there is the disk sector that we need to multiply by the number of bytes for each sector.

The result will be the desired drive offset. From there, Popureb stores the original MBR at the offset +2400h. It needs to be decoded using an ROR 0x73 loop, the inverse of the ROL 0x73 loop described above.

The Trojan doesn’t implement any kind of watchdog thread to protect its kernel mode hook, which makes the recovery job much easier. Thanks, author of Popureb.

So, in the end, we know where the rootkit stores the original MBR, we know how to disable the rootkit filtering engine, and we know how to recover the original StartIo routine. We are going to release a removal tool for this infection after we have successfully run some internal tests.

What is really a nightmare is that the Trojan looks like it has bugs and sometimes it hangs the system during the reboot stage. This could become a problem that would require you to perform a full system reinstall. Otherwise, even if this malware shows good potential, we’ve found that the current release can be actually defeated without any major issues. The criminals behind the TDL rootkit shouldn’t worry about Popureb: Their TDL creature remains the most advanced, and obnoxious, kernel mode bootkit infections.

About the Author

Blog Staff

The Webroot blog offers expert insights and analysis into the latest cybersecurity trends. Whether you’re a home or business user, we’re dedicated to giving you the awareness and knowledge needed to stay ahead of today’s cyber threats.