TLD3 malware, impressive

[Modelworks]

There is a pdf up on the fsecure blog about the tld3 malware and how it works. Someone put a lot of work into this malware. Removal software trying to scan for the malware will see nothing because the malware replaces those locations with clean data before the sector is read since it has full control over what is read by the disk. It enters the system and creates itself as a print requrest that then uses print spooler to execute itself and hooks into the disk driver at the lowest levels intercepting all calls to the drives.

http://www.f-secure.com/weblog/archives/00001976.html

Acting in the lowest level of disk filter driver, TDL3 successfully ‘hooks’ or intercepts accesses to a list of protected sectors. The malware hooks are responsible for two things: allowing direct access to the disk for malware components; and filtering
content access to the disk by other processes thus helping the malware hide its presence on the system.

TDL3 uses two methods to intercept access. In the first method, TDL3 maintains a list of physical addresses for infected sectors, as well as a corresponding fake mapping of the original clean sectors in its memory. When any attempt is made to access the infected sectors, the malware will overwrite the (infected) data read with clean data stored in memory. This listing is primarily used to protect the infected disk filter driver from being accessed, as the malware’s own file system and the malware data stored at the end of the disk are already protected.

The second tactic is simpler, as any read/write access requests to the last disk sectors that do not come from the malware will be presented with filtered content. To filter, the read data in memory to be returned to the calling process is zero-filled thus giving back a clean memory buffer.

Another paper published at the eset page on it, they call it the rootkit of all evil 🙂
http://www.eset.com/resources/white-papers/TDL3-Analysis.pdf

 

[blackangst1]

Wow. Nasty one.

 

[SunnyD]

This isn't particularly new. Filter drivers are one of the common forms of rootkits out there. It's one of the simplest roots out there. Installing it will still take some ingenuity or user intervention on most systems though (it'll require administrator credentials or an exploit).

Of course there is a way around it - you simply install a filter below this one. You can chain as many filter drivers as you want together, the key is getting it inserted into the chain where you want it. Ideally though, the actual physical disk driver (rather than the filter) would protect against this, but then again this sort of behavior is exactly why filter drivers were invented in the first place - to filter data in transit between the physical device driver and the user.

hooks into the disk driver at the lowest levels intercepting all calls to the drives.

Most definitely NOT the lowest level. It sits between the kernel and userland.

 

[Modelworks]

This isn't particularly new. Filter drivers are one of the common forms of rootkits out there. It's one of the simplest roots out there. Installing it will still take some ingenuity or user intervention on most systems though (it'll require administrator credentials or an exploit).

Most definitely NOT the lowest level. It sits between the kernel and userland.

If it were only a filter it might be nothing new but it patches the actual system driver files so that it always has control from the minute the kernel loads the driver and starts to load the OS.

It runs at RING1.

The blog below gives a good run down on how it all works.


http://rootbiez.blogspot.com/2009/11/rootkit-tdl3-why-so-serious-lets-put.html

Some of the good parts

copies itself into the Print Processor directory with a random name determined by the system, then it modifies the characteristics of the newly created file to convert it into a PE Dynamic Linked Library (DLL).

registers the malicious DLL file as an Print Processor which is named “tdl” by calling winspool API AddPrintProcessorA().

Issues an RPC call to the Printing Subsystem hosted by spoolsv.exe process and forces spoolsv.exe to load the Print Processor DLL remotely.

spoolsv.exe will execute the DLL copied inside the Print Processor directory inside the context of spoolsv.exe process
.
after being loaded into spoolsv.exe, the malicious DLL drops a driver and begins its second stage infection in kernel space by calling NtLoadDriver() directly.

dropped driver loaded by spoolsv.exe is actually a loader for another embedded kernel codes. From the its DriverEntry(), the driver allocates kernel pool heap to copy the compressed data to and employs aPlib to unpack the real rootkit driver inside itself.

infector first queries the device object responsible with partition0 on the hard disk device which the “\systemroot” is linked/installed on.
retrieve the last miniport driver object and the name of the driver’s binary file via that device object.

Overwrites the data of “.rsrc” section of victim driver with 824 bytes instead of kidnapping the whole driver like others did (e.g Rustock.C), so that size of the infected file isn’t changed before and after the infection occurs. The original overwritten data is then stored to certain sectors on disk for later file content counterfeiting. The infector also modifies the entry point of infected file to address of the 824 bytes codes.

rootkit no longer uses file system to store its files, it reads and writes directly onto disk’s sectors. The main rootkit’s code is stored at the last sectors of the disk with the sector number is calculated by formula total_number_of_disk – (number_of_rootkit_sector + number_of_overwritten_data_sector).

The next time system reboots, when the 824 bytes in infected driver gets executed, it waits for file system’s setup finishing (by registering itself a filesystem notification routine), then loads and runs the rootkit stored at last sectors of the disk.

In order to protect the real content of the infected hard disk miniport driver, the rootkit hooks the miniport driver object and patches all dispatch routines to the rootkit’s one.

The rootkit will also zero out request buffer if it’s an attempt at retrieving last sectors of hard disk where rootkit’s code (kernel codes, config.ini, DLLs) is stored.


TDL3 also adjusts modified parts of infected image in kernel memory so that any memory forensic attempt will fail in detecting suspectious mismatches between hard disk image and the loaded one.

CodeWalker private version, a_d_13’s RootRepeal, UG North’s RkU, GMER. None of them gave the correct result of TDL3’s dispatcher patches.

rootkitcreates a 11 bytes stub inside the infected driver image space. this 11 bytes stub actually transfers the execution flow to real rootkit IRP hook handler remains on kernel pool heap at 0×817e4e31. Because the detection algorithm of all above antirootkit tools basicallly relies only upon checking whether the dispatcher routines’ addresses fall within the range of driver images without analyzing the actually absolute destination of the handlers, thus definitely they would buy the rootkit’s trap.

the rootkit registers a load image notify routine so that everytime a thread loads “kernel32.dll”, the notify routine will schedule an APC start at LoadLibraryExA to force that thread executing the dropped trojan dlls (tdlcmd.dll and tdlswp.dll) inside user-mode thread’s process. This is the only suspected behaviour that current ARKs are able to detect.

 

[Chiefcrowe]

Impressive indeed.. in fact it's scary. looks like more and more often a complete system wipe will be the only way to really clean up a pc.

 

[ASTOCADDIDS]

Why would putting your nick after the topic title it make any difference? Killerbyte, malware is using under the adware category, try an adware scanner.