Blog

Kernel Driver Backdooring

05.04.2007 - 2:17 PM
One interesting piece of code we found this week was actually "backdooring" an existing Windows kernel driver. In the past, we have seen malwares patching Windows drivers to increase their performance (by removing the connection limit), but this time, the driver is modified to execute code and appended to the driver, using parasitic techniques. The Windows file protection won't trigger when the driver is patched, but the protection isn’t disabled either, so if you try to modify the driver once it has been patched, Windows complains.

The backdoored driver is TCPIP.SYS.

The malicious code actually uses a basic EPO (Entry Point Obscuring) technique. Below, you can see the original entry point of TCPIP.SYS:

This is the patched entry point:

The start of the malicious stub is in the reloc section of the driver, as you can see below:

Now, let's reverse engineer the injected stub by looking at the first subfunction:

As you can see in the above screen shot, the code first uses call/pop to get the actual address (as a virus or packer would do), and then starts a big loop. If the current Word XOR 0x8F matches 0x5AC2, we have found the driver imagebase. ("ZM" XOR 0x8F = 0x5AC2), and this matches the two letters found at the imagebase of any PE file.

The malicious code then adds the entry point RVA of the original TCPIP.SYS file saved during infection to the imagebase of the driver, to get the Real Entry Point Virtual Address.

Once this is done, the driver fixes the original entry point of TCPIP.SYS, by overwriting the bytes patched during infection, to jump to its malicious stub:

After this, the malicious code applies the relocations itself. (The relocation entry in the data directory has been nulled):

The function has 3 parameters: Current Loaded Base, the Original Driver Base, and the RVA of the Relocation Directory.

Here is a little piece of code from the relocation fixing routine:

You can see that the malicious code checks whether the loaded imagebase is different from the original one. If it's not different, the driver is using the original imagebase and thus, doesn't need any relocation; and the routine exits. Otherwise, relocations are applied.

After this, an interesting routine is called. The routine is used to dynamically load another driver without touching the registry. This technique has been described by Greg Hoglund and was published on rootkit.com a long time ago. It basically uses the ZwSetSystemInformation function:

Interestingly, some assumptions are made, and the driver can make a BSOD in certain conditions, which won't be explained here; we don't want to fix malicious code bugs.

Speaking of bugs, the loaded driver is even more unstable, and the infected machine displays a BSOD every few minutes after it has been loaded, resulting in a completely unusable machine. The malicious codehas been tested on Windows XP SP0 to SP2 none of the computers worked correctly; they kept displaying the BSOD.

Once the rootkit has been loaded, the original entry point of TCPIP.SYS is called:

The additional rootkit file hides files and processes for a short time, before the computer actually reboots with a BSOD. The rootkit also locks TCPIP.SYS to protect it against scanning.

Researcher: Nicolas Brulez, Websense Security Labs

Special thanks to Kimberly for research assistance.

Bookmark This Post:

Post a Comment: