Endpoint Protection

We’ve been watching new samples of Trojan.Mebroot in recent weeks and something unusual has caught our eyes. While analysing one of these samples I noticed that the installation phase was different from what we have seen in the past—the main executable injected itself into the standard spoolsv.exe process by adding itself as a print processor, then it loaded its driver in the kernel in a two-stage unpacking process.

Wait, haven’t we seen this already? Yes—in Backdoor.Tidserv!

Initially I just thought I was looking at the wrong executable, but after a closer look, the payload definitely looked like Mebroot. It seems that its authors took the installation process from Tidserv, and the similarities are not limited just to that. In the screenshot below, Mebroot is using a typical Tidserv technique in order to inject  a DLL into the spoolsv.exe process by adding itself as  a print processor:

 

The above function gets called twice and the print processor names being used are quite familiar:

 

The print processor names are the strings “TDL4” and “TDL5”, which are typically found in Tidserv samples, in particular the Tidserv installer was creating a print processor named “tdl”. The last version of Tidserv was named TDL3. By using these tags, is Mebroot trying to pretend to be a new Tidserv version? Are they just trying to throw smoke in the eyes of the analysts? Who knows!

After the user mode stage, the main kernel driver is dropped and loaded. The driver is packed, so it will unpack itself and then allocate a chunk of memory in the NonPagedPool region of the kernel. It decrypts a second driver, maps it in the allocated memory, and then the newly allocated driver is executed. This technique is also present in Tidserv; it helps hide the driver from the kernel’s loaded drivers list, since it is loaded manually rather then using the operating system’s appropriate interfaces.

After the computer reboots, the threat is fully running and very few kernel-mode modifications are visible:

 

It looks like the objects handled by the port driver (on my test computer, this driver is atapi.sys) are being hijacked towards some unknown code area. Note that this is not the physical file being modified (like Tidserv does), but the modification is affecting the kernel object associated with such a driver. Further inspection confirms this, as the IOCTL IRP handler for the atapi.sys driver has been redirected to the Mebroot kernel-driver code:

 

Mebroot used to create its own device to hook the disk I/O requests on top of the disk.sys driver, which is the class driver layer used for generic disk functionality. Again, similar to the Tidserv approach, Mebroot stepped deeper in the file system chain by hooking the I/O operations at the port driver layer.

Just to make things more clear, have a look at the following figure. While most rootkits operate at the file-system level, Mebroot and Tidserv go deeper.




Older rootkits used to work at the file system level, by filtering the NTFS I/O in order to hide files from the disk. With the advance of security applications and antirootkit tools, rootkits had to evolve in order to survive, and they had to dig deeper in the operating system to try and operate at a deeper level in respect to the security applications.

Is the race over? No. It is possible for a rootkit to move deeper than Tidserv and Mebroot, but the level of sophistication required becomes higher and higher. Besides, going deeper means getting  closer to the hardware and loosing the abstraction provided by the upper levels, which results in the code becoming more hardware dependent and less compatible. The Mebroot sample I analysed seems to have problems with SCSI systems. In my tests the rootkit initially runs fine, but then the computer hangs and becomes unusable. Increasing the sophistication carries a trade-off in stability and compatibility.

Mebroot and Tidserv are currently the most advanced rootkits in the wild. They developed many new techniques to achieve high levels of invisibility, and it’s interesting to see how some good ideas are replicated by competitors. There is no point arguing who took what, this whole topic shows once again how rapidly threats can evolve, and how rapidly security applications must react not to be left behind.