Prevx Blog
It took some time but now x64 Windows operating systems are officially the new target of rootkits.
We talked about TDL3 rootkit some months ago as the most advanced rootkit ever seen in the wild. Well, the last version of TDL3 was released months ago and documented as build 3.273. After that, no updates have been released to the rootkit driver. This was pretty suspicious, more so if you've been used to seeing rebuild versions of TDL3 rootkit every few days to defeat security software.
Obviously, the rootkit was stable and it is currently running without any major bug on every 32 bit Windows operating system. Still though, the dropper needed administrator rights to install the infection in the system. Anyway, the team behind TDL3 rootkit was just too quiet to not expect something new.
They actually built a nice gift for every security vendor, because TDL3 has been updated and this time this is a major update; the rootkit is now able to infect 64 bit versions of Microsoft Windows operating system.
Why this is a worrying and important news? x64 versions of Windows are considered much more secure than their respective 32 bit versions because of some advanced security features which are intended to make it more difficult getting into kernel mode and hooking the Windows's kernel.
Windows Vista 64 bit and Windows 7 64 don't allow every driver to get into kernel memory region due to a very strict digital signature check. If the driver has not been digitally signed, Windows won't allow it to be loaded. This first technique allowed Windows to block every kernel mode rootkit from being loaded, because malwares aren't usually signed - at least, they shouldn't be.
The second technique used by Microsoft Windows to prevent kernel mode drivers from alterating Windows kernel behavior is the infamous Kernel Patch Protection, also known as PatchGuard. This security routine blocks every kernel mode driver from alterating sensitive areas of the Windows kernel - e.g. SSDT, IDT, kernel code.
These two techniques combined together allowed x64 versions of Microsoft Windows to be much better protected against kernel mode rootkits.
The first attempts of breaking this Windows security had been run by Whistler bootkit, a framework bootkit sold in the underground and able to infect both x86 and x64 versions of Microsoft Windows.
But this TDL3 release can be considered as the first x64 compatible kernel mode rootkit infection in the wild. Our Prevx community spotted the infecting dropper more than 9 days ago and we are now seeing new samples reported every day. This means the infection is spreading on the web, by using both porn websites and exploit kits.
Speaking about the infection itself, we are still analyzing the infection. Though at first glance we don't feel it could be considered as a brand new TDL3.
It looks like someone got TDL3 sources and added bootkit infection to it. This is because the TDL3 rootkit is now targetting the Master Boot Record, as MBR rootkit did years ago and as Whistler Bootkit is currently doing.
To bypass both Kernel Patch Protection and Driver Signature verification, the rootkit is patching the hard drive's master boot record so that it can intercept Windows startup routines, owns it, and load its driver. Both Windows security mechanisms are bypassed.
While on x86 versions of Windows it doesn't need to immediately restart the system because it can load the driver as it wants, on x64 versions the infection steps are different.
The rootkit needs administrative privileges to infect the Master Boot Record. Even then, it still cannot load its own 64 bit compatible driver because of Windows's kernel security. So, the dropper forces Windows to immediately restart. This way, the patched MBR can do the dirty work. The infected MBR code itself is encrypted by using a simple ROR loop.
Even the rootkit build version changed from 3.273 to 0.02. It looks like a beta build. We say this because from our first internal tests, the rootkit didn't always fully work.
Our current idea is that TDL3 sources could have been sold and the new team who owns them has started adapting the rootkit to x64 platform by adding to it a bootkit infection technique already showed by Whistler bootkit and Stoned v2 bootkit.
What is more important is that with this new TDL3 release a new era is officially dawned; the era of x64 rootkits. How this develops, we're not sure.
We will keep you updated as soon as we have more informations. In-depth analysis is undergoing.
8 comments so far
- TommyMacAngel on Aug 26 17:42, 2010
- backfolder on Aug 27 16:39, 2010
- GTS on Aug 28 5:28, 2010
- Olipro on Aug 28 12:38, 2010
- Aelthegrin on Aug 30 21:09, 2010
- eikelein on Aug 31 13:34, 2010
- ceasar on Sep 5 7:57, 2010
Thx very much for info...
A sad day today... A sad summer for MS (lnk, dll and now that...)
:(
Thanks Marco for the info.
Let´s see what´s going next... =|
New reader to your blog... glad I found you, you've got some great info that will be most helpful.
As far as I'm concerned, however, this era started long ago, as I've been investigating an advanced persistent threat on XP x64 on and off for at least the last 6 months...
Not interesting, this is a cat and mouse game.
Now that these guys have figured out how to break the current PatchGuard, I have absolutely no doubt in my mind that Microsoft will be producing a new iteration of it that will break this rootkit.
At the end of the day, Microsoft will always be able to update PatchGuard to break an existing rootkit, so the best the rootkit developers can do is block things like Windows Update at the cost of making the rootkit more conspicuous.
Then of course there is the option of taking steps to prevent writing of the MBR - additionally the kernel could quite trivially snapshot the MBR at boot and perform integrity checks to make sure it's not being modified - if it finds it has been modified it can either silently restore it or prompt the user on the secure desktop as to whether they really want the overwrite to go ahead.
@Olipro - If MBR is infected, then the code in MBR can easily modify integrity checks during the boot. You need additional realm of operation that cannot be reached by the MBR code (firmware for example).
Yet another round on the good old cat and mouse carousel. The mice are getting ever more crafty.
I'd truly like to know if there is a utility around to save a known good MBR externally and if required to write it back?
Just a thought.
These guys (who develops malware) are stunningly good with their stuffs. I just can't understand why they have to do all these when with their skills alone they can get a hell of a living in a clean way.
Great article!

Thanks Marco for your great info!
Regards,
TH