TDL3 and ZeroAccess: More of the Same?

http://blog.webroot.com/2011/08/08/tdl3-and-zeroaccess-more-of-the-same/

By Marco Giuliani

In our previous technical analysis of the ZeroAccess rootkit, we highlighted how it acts as a framework by infecting the machine — setting up its own private space in the disk, first through a dedicated file system on the disk, and more recently by using a hidden and locked directory. This is where the rootkit stores the modules it downloads from the command and control servers. Until now, the plugins we’ve monitored have been ad-clickers and search engine hijackers.

We have also noted how the ZeroAccess rootkit acts very similar to the TDL3 rootkit, either by infecting a random system driver, using its own file system to store its plugins or by filtering the disk I/O by analysing the SCSI packets – though in a pretty different way. It’s more effective in the TDL3 rootkit and less effective in the ZeroAccess rootkit, however ZeroAccess has many more self-protection mechanisms in place.

While analyzing the ZeroAccess rootkit, I’ve always had the feeling it was inspired by the TDL3 rootkit. But while looking at the latest updates of it I’ve found something pretty interesting: The ZeroAccess team is looking at TDL rootkit as an enemy that needs to be defeated. The questions remains, is there a link between the two rootkits? We suspect the answer is yes.

One of the downloaded plugins, called desktop.ini,  dropped by the module driver called @800000c0, has an embedded anti-TDL specific routine, able to detect if the system is already infected by the TDL rootkit and, if it’s the case, the routine is going to disable it.

As malware analysts may recall, the TDL rootkit is comprised of two parts — the kernel mode driver which hides the rootkit on the disk, and the cmd.dll plugin. The latter part is the user mode part that is being injected inside the user mode processes. It acts as an ad-clicker and a fundamental bridge to the command and control server listed in the cfg.ini rootkit file.

Now, ZeroAccess’s search engine hijacker plugin is able to scan the virtual memory of the process where it resides, looking for TDL’s cmd.dll traces and, if found, automatically recovering the hidden disk path to it and overwriting its code with trash bytes along with the cfg.ini’s TDL configuration file. At the next start-up, the TDL rootkit is still active in kernel mode. However, its payload has been totally disabled, rendering it useless.

This is a really interesting feature because it looks like the ZeroAccess authors want to specifically target the TDL rootkit, this reminds me of the war between the two biggest infostealing trojans ZeuS and SpyEye.

It looks like there is a link between the two rootkits that would explain why they look so conceptually similar. And here is the next finding: another plugin downloaded by ZeroAccess and called clickbot – readers may recall that this is the ad-clicker. It registers a class called Z00clicker2. Does this ring a bell?

Let us rewind to January 2010 when the TDL3 rootkit was actively spreading in the wild. At that time we discovered another variant of the TDL3 rootkit which was looking pretty different from the one in the wild. In fact, it looked like one of the  first versions of TDL3 rootkit spotted in late 2009, effectively an older version of TDL3.

When TDL3 was discovered in Q3/Q4 2009, it was using a specific disk hooking technique that then changed on the way, by becoming much more advanced and technically smarter.

So, in January 2010, we found two variants of TDL3 rootkit spreading in the wild: the original one and another one that was using the original disk hooking technique. As far as we know, the original source code of the TDL3 rootkit may have been sold but the development of the original TDL3 rootkit never stopped. So, who bought the original TDL3 source code developed their own plugins on top of the old TDL3 rootkit?

The user mode plugin embedded in this variant of the TDL3 rootkit was different from the usual cmd.dll plugin, and it was named Z00clicker.dll.

The questions raised right now are:

1. Why is ZeroAccess’s ad-clicker using the same name of the plugin dropped by the TDL3 rootkit variant?
2. Why is ZeroAccess implementing specific anti-TDL3 routine to kill the TDL rootkit?
3. Why is the ZeroAccess rootkit is so similar – conceptually speaking – to the TDL3 rootkit?

We could draw a few conclusions here, and any one of them is possible:

• The team behind the variant of the TDL3 rootkit is the same as the one behind ZeroAccess rootkit.

• The ZeroAccess rootkit’s source code has been sold on the blackmarket and the same team that bought the TDL3 sources then bought the ZeroAccess ones as well.

We’ll keep monitoring the evolution of this rootkit and keep you updated. In the meanwhile you can download and check if your system is already infected by the ZeroAccess rootkit. Our free removal tool will be able to detect whether the system is infected and, if so, it’ll clean the system for you.

All the technical details about the anti-TDL3 routine will be added to our ZeroAccess whitepaper very soon.

0.000000 0.000000