The Hacker Diary

TDL3 The Worst Best Rookit Ever

Occasionally, I do computer repair.

I fixed that computer in 5 seconds flat.

At one point it was my primary source of income after I quit a job where I wasn't valued as an employee. (I am sure we've all been there once.) In my many years of doing computer repairs, I occasionally would run into that one piece of malware that would throw a wrench in the spokes and just make me stop dead in my tracks. Whether it was in awe of innovation or frustration in removal, there have been those few moments where I just had to step back and re-evaluate my troubleshooting methodology, adjust my dropped jaw or walk away before I made smash smash like bam-bam.  The last time I had a moment like that happened when I had my first rootkit run-in 2 to 3 years ago. If you don't know what a rootkit is ( are you living under a rock???) read here. It was after a few years elapsed from Greg Hoglund's NT based rootkit. It's cited as the first rootkit for NT systems but I believe otherwise as there is always someone who beat you to innovation- if you want to call it that. You know, kind of like how Alexander Graham Bell and Tesla were gamed on for credit by Thomas Edison for various inventions- but I digress. The community evolved over night and some of the more elitist computer repair community saw the rootkit as a mythical creature that just couldn't exist (whether by cognitive dissonance or otherwise) and went the route of the ostrich with it's head in the sand until it couldn't be ignored anymore.

Then it happened. An arrogrant Sony/BMG wrote some DRM software that caused quite a ruckus and shook things up while propelling the term "rootkit" into the media spotlight like so many Britney Spear's head shaving incidents: Sony included a rootkit on music cds as a means to combat piracy with much fail. The rootkit served to enable malware writers to cloak objects from windows with little effort and thus the class action lawsuits started rolling in like seaweed after a hurricane as a new era of malicious code got some traction.

Yesterday  (♫ Virus removal was such an easy game to play ♫)

Yesterday (well this post has been drafted for a week or so- not quite yesterday anymore), I had the moment I spoke of above where I had to re-evaluate my methodology. I have seen some pretty ridiculous infections in my time but this one takes the cake as of December 14, 2010- the worst piece of malware I have ever had the displeasure of removing but credit for innovation. The customer dropped the PC off on a Friday. Generally, with my experience I can fix almost any issue inside of 20mins to an hour depending  on the pc's specs and infection severity. Mostly, the issues I see are of the spyware/malware/trojan series and are easy to remedy. This include your occasional rootkit.

Troubleshooting

Generally when I am fixing computers I ask a line of questions to deduce how much the customer is computer savy, if they know enough to get themselves in trouble, then ask about the symptoms. Based on their responses you can usually make an educated guess of what you are dealing with and what tools you will be focusing on using to fix the pc. When I troubleshoot a system, the very first thing I do is boot the machine up and see how it behaves. Can I replicate the symptoms that the customer described? If I can then I am on the right track. If not, then perhaps the problem is intermittent, customer gave bad information, problem is different than as described or a combination of all of the above.

As a rule of thumb, I NEVER EVER, I really mean NEVER EVER using any removable writable media when working on a system. It is amateur, irresponsible and common place for many shoddy computer repairmen/repairwomen. Rather, I will burn CD's with my toolkit and the most up-to-date revisions. (Thanks be to scripting and wget.)

The troubleshooting work-flow is generally as follows (AND I DO MEAN VERY GENERAL):

• Boot machine normally. Observe. Replicate symptoms? Disable system restore.(If password protected backup SAM and remediate password in PE environment. restore when finished fixing machine)
• Google symptoms for known issues but don't waste time on anything but exact string matches. (works 20% of the time)
• Run combofix
• Boot machine from PE Environment / Hirens BootCD
• mount registry hive for OS
• Run autoruns to see what is on the startup, it's location, etc.
• Google suspicious entries
• Disable suspicious entries without false positive info.
• Disable all non-microsoft startup items.
• Scan machine for viruses/malware with third party utilities
• Boot machine in safe mode with networking.
• run combofix again
• Run Autoruns - check startup entries, Process Explorer - check hooked dll's and Tcpview - currently active connections --- to monitor for strange activities.
• Restart normally.
• Run Autoruns, Process Explorer and Tcpview to monitor for strange activities. Look for removed startup entries back on startup.
• Cleanup pc, defrag and update all AV and Windows Updates after taking System Restore snapshot.
• Return to customer.

This generally succeeds in fixing 98% of the issues that I run into with computers. When I tried to run procexp.exe it would instantly terminate. Hmmm.

Now, if it had of ran, I would have see that the context switch delta on atapi.sys was awfully high because of TDL3 among other anomalies but I am getting ahead of myself. I thought I might have not double clicked it, so I click again twice and get an error that I don't have permissions to run this executable. Okay, probably a dirty malware dll that has an MD5 on my utility and is blocking it accordingly. I run HxD and hex edit a section of plain-text to alter the MD5 of the executable and rename it. Once again it appears to have started but quit. I attempt to run again and... can you guess the error message? Correct, I do not have permissions to run this executable.

For about 5 seconds I stopped and thought about what I might have missed.

I run cacls and change the permission on the utility to everyone. It runs once then the permission error occurs again.

From this I deduce that my phantom malware is observing what system dll's are getting called by the utility and terminating the utility based on those calls then changing permissions on the executable. This is getting to be a complete pain in the ass whereas I normally would have been home free and now it is apparent that I am dealing with something a little more "advanced" then my run of the mill malware.

It's time to change tactics.

Knowing that there is a low likely hood that I will be able to run some of my more advanced utilities, I try anyway. I theorize that some of this more advanced activity is related to a rootkit and I run GMER and Rootkit Unhooker.

And that is when I discover the name of the rootkit via google. TDL3. After removing the associated driver and restoring order in the operating system there is one last surprise waiting for me.

GRLDR is missing or cannot be found.

Wouldn't you know it, the rootkit create it's own MBR that then bootstraps the OS. Only, it's much more cooler and technical than that.

You can find a full dissection of TDL3 here.

To fix the last part of this rootkit you need to restore the MBR. Run fixboot and fixmbr and you'll be home free.