We have already written in a previous blog post about the new TDL3 rootkit able to hit 64 bit Windows operating systems. We will try to check more in depth how it is actually working.

The dropper is being dropped by usual crack and porn websites, but we soon expect to see it dropped by exploit kits too, as happened to current TDL3 infections.

As already written in the first blog post, the dropper uses two different infection techniques. If the system is a 32 bit build of Windows, the dropper will use the common technique already used by old TDL3 rootkit, by loading its driver through AddPrintProvidor API trick. After the driver is loaded, the rootkit will overwrite the master boot record with its own code.

If the system is a 64 bit build of Windows, the dropper is not able to load its own unsigned driver because of Windows security checks. The dropper needs to get its driver loaded by using the MBR trick. As said in the previous blog post, the dropper infects the drive's MBR and immediately reboot the system to get its code loaded at the following system startup.

The dropper is using a non conventional - though well known - way to patch the drive's master boot record. It opens an handle to PhysicalDrive0 and then overwrites the MBR by using SCSI commands. It make uses of IOCTL_SCSI_PASS_THROUGH_DIRECT command, well documented by Microsoft in its MSDN.

After the MBR has been overwritten, the rootkit needs to immediately restart the system. To do so, it needs SeShutdownPrivilege privilege before calling ExitWindowsEx API. So it sets up the specified privilege by calling RtlAdjustPrivilege API exported by ntdll.dll and then calls ExitWindowsEx API using EWX_REBOOT | EWX_FORCEIFHUNG parameters to immediately reboot the system.

On both 32 and 64 bit builds the dropper stores all the other components of the infection inside last unused sections of the hard drive. These components will be then called at next system restart.

After the system is restarted, the new MBR installed by the rootkit is executed. Before it could start its own payload, it decrypts itself with a simple ROR loop. After the MBR has been decrypted, the code flow is passed to one of the infection components that is named ldr16.

Ldr16 is a small 16bit loader used by the rootkit to intercept Windows startup routine and patch configuration data so that it can disable driver signing and load the rootkit driver loader in the system. To intercept disk I/O ldr16 hooks int 13h handler by alterating the Interrupt Vector Table. The old handler is stored in a variable for later use and the new hook function is stored in the IVT.

Ldr16 is then responsible to run the right rootkit driver loader by looking at what operating system build is being loaded. In fact the rootkit stores both ldr32 and ldr64 loaders at the end of the hard drive. Ldr16 choices then ldr32 or ldr64 by looking at what Windows build is being loaded.

To detect whether 32 or 64 bit build of Windows is installed, the ldr16 code checks PE files header, looking at the NT header OptionalHeader's Magic value. If it is IMAGE_NT_OPTIONAL_HDR32_MAGIC, then ldr32 loader will be loaded, otherwise it will load ldr64 loader.

Both loaders are responsible to load the real rootkit driver - drv32 or drv64, stored at the end of the hard drive - in the system by using an unconventional way. They manually allocate kernel memory needed to store the specific driver code and set up all the stuff before calling IoCreateDriver kernel API.

The driver is now loaded, bypassing signature check and bypassing by design Microsoft PatchGuard (KPP). The main rootkit driver code itself is not changed too much from the last 3.273 build we saw months ago. It alterates disk I/O by injecting itself in the disk drivers's chain. We already explained the technique used by the rootkit in a blog post we published last year. Since that blog post, we didn't see any major change, just minor code changes. It is possible to spot the infection by analyzing disk drivers's stack. This technique always detected TDL3 infection in the system.

MBR code is filtered by the advanced rootkit disk I/O filtering engine. This is the only real MBR code self-defense at the moment.

Besides this, the rootkit has a user mode component too, injected inside user mode processes by the kernel mode driver. The driver sets up a load image notify routine to intercept every process which loads kernel32.dll module. If so, the driver injects the user mode infection component inside that process. The infection component is called cmd.dll.

The same applies to 64 bit builds of Windows. The rootkit driver sets up the same load image notify routine and inject its 64 bit compatible user mode dll component.

The user mode component analyze the process, by looking if any hook is found in one of following libraries: kernel32, mswsock, ws2_32, wsock32, dnsapi, wininet. Every hook found is deleted and original code is restored. Then, the tdl3 module hooks ZwProtectVirtualMemory, ZwWriteVirtualMemory and KiUserExceptionDispatcher native API from ntdll.dll.

As already written in previous blog posts, this user mode component is able to poison search requests inside browser processes, redirect websites and communicate to remote C&C server.

If this release of TDL3 rootkit x64-compatible will spread as the older TDL3 rootkit, there are no doubts it will quickly become a serious threat. The doors to the heart of 64 bit are officially opened. If MBR patching technique was only one among many infection techniques used by rootkits to infect 32 bit builds of Windows operating systems, it will probably become the most used way to hit 64 bit builds of Windows.

Transition period from 32 bit to 64 bit operating systems is started years ago. Malware development is tightly following it. They of course don't wanna get caught unprepared.

On a side note: the dropper won't infect the system if it runs in a limited account or in an account with UAC activated. Does social engineering ring a bell?