TDL4 Rootkit and Imaging Apps

TDL4 Rootkit is notorious to trash the sytem and is able to bypass most of the ISR software.

I recently got curious to test it against an image restore by imaging apps. This bootkit has two variants, one that infects MBR and writes its file sytem on an area at the end of the disk and becomes activates from the very boot up of OS.

2nd variants infects VBR of the partition and makes a special hidden partition of its own at the end of the disk to write its file system there.

I tried the first variant of the rootkit( MBR infector).

I made a clean image on my system disk with macrium reflect free and paragon free. Infected the system, confirmed infection with gmer and kaspersky tdsskiller tool and then tried to restore system drive. Both software were able to restore the system thus removing the bootkit but there was a glitch. None of these were able to delete the file system written by the Rootkit on the hard disk. So infection was not there after restore but some files related to Rootkit wre left on the disk. Though they were harmless but I was not comfortable.

I tried another way, first format the disk offline by gparted and then restore a clean image, same result. Then I deleted the disk with gparted live CD, recreated the volume and did a restore, this time I was able to clean rootkits file system. I never knew that a clean restore and format wil fail to remove all traces of this Rootkit. Very interesting experience.

 

Image for Windows/Image for DOS/Image for Linux have an option called 'Wipe Unused Sectors' when doing a Image Restore. I would 'guess' that this option would take care of that problem.

See Pages 54 & 55 of the Image for Linux Manual:

http://www.terabyteunlimited.com/downloads/ifl_en_manual.pdf

 

Interesting indeed... one question, have you created a image of the C:\ partition only, or a full clone of the hard drive?

If it was an image of the C:\ drive only, its understandable that the partition created by TDSS would remain, i think.

 

Settings for tdsskiller.

 

I used default settings but I did try an option in macrium or paragon to adjust partitions acc to image( something like this if not exactly same option) but I think it did not matter as restore was on same drive of same size.

 

I think that in the Future I may have only one partition on the hard drive containing the Windows OS and always use the option to "Wipe Unused Sectors" when doing an Image Restore.

 

It was a win 7 32 bit VM in Ubuntu host in VBox. System had two disks, C for OS and disk D to save images. Win 7 default install. I made an image of entire C drive and then restored it.

 

Please read my post again. TDL4 variant I used doesn,t create a partition of its own.

 

I might try this option but I don,t have a license for this software while macrium and paragon have free versions. Same for acronis.

 

This Rootkit completely bypasses comodo time machine.

 

I might be wrong, but i think this necessarily implies the existence of a different partition

Anyway this shows that a simple image restore may not be enough.

It would be interesting to test restoring a clone of the entire Hard Drive, and check if there are any traces of the infection left.

 

You should try the AX64 beta app against this variant. The developer is very actively improving it and may be able to defend against these remnants.

 

AXTM (AX64 Time Machine) backs up both the MBR and the VBR at this point in its BETA testing phase. Sounds like a restore would take care of both these variants, albeit leaving any homemade partition/FileSystem in place... probably neuter any active portion of the rootkit.

 

aigle was kind enough to test AX64 with this rootkit, and provided a sample to me for tests. Basically as soon as TDL is installed it breaks the file system and AX64 cannot even read the list of volumes. So online restore doesn't work.
Restore with recovery media works, and kills TDL as expected. However the hidden file system of TDL remains, because AX64 doesn't touch unused disk space. Which is fine in my opinion. None of the imaging apps normally restore the unused space and I see no harm in part of the rootkit staying there.

Isso

 

Yes, This should be the way to go. I learned it after this testing.

 

Yes, exactly same behavior by imaging apps like Macrium, Paragon etc. My testing was basically to see if these`apps are any different than AX64. But all work the same.

 

Restoring the MBR while restoring should be enough ;-)
Every serious image app has that option.

 

Should these apps have an option to delete the partition and restore the filesystem via image as Peter2150 does? While remnants of a non-active/present rootkit would be benign; I would be more comfortable having it completely gone. I could understand not doing this for a free imaging app but if I pay for one I would want complete eradication.

 

AFAIK, imaging programs always do this. It´s the normal operation, no need to select any option.

 

Robin,

I don't believe that's the default 'modus operandi' of the disk-imaging programs I've used (DS & IFW-IFD).

TS

 

It removes the rootkit but not the created file system.

 

1000db,

That operation (delete the partition and restore the filesystem) won't clear the TDL traces. The reason is that TDL creates its file system outside of any real partitions. It writes to the unused disk space, that is normally not processed by the imaging apps.

However some of the imaging programs allow to wipe the unused space on restore - this will clear all the TDL traces. It's easy to do, but may take lot of time, that's why that option is never on by default. Again, there is no need to do that - it doesn't matter what kind of information is written in the unused space, unless there is a rootkit sitting in the MBR and using it. And MBR is restored by any imaging app, effectively killing the rootkit.

Isso

 

I was referring to the restore of a single partition in a sector (not file) mode. The existing partition is deleted and recreated from the image.

From the Paragon HDM manual: "All contents on the partition selected for restoring purposes will be deleted during the operation."