[erikloman]

Shall we call this x64 version of TDSS, TDL4?

Seems by that TDSSKiller log, they have gone ahead and named it TDL4.

Also, this is a somewhat new infection routine to directly infect the MBR, instead of an actual system file.

Well the I/O filtering is the same, the watchdog is the same, the device 'layering' is the same, the encrypted file system is the same and TDL3's internal configuration is the same. Just the loading is different. Instead of infecting a system driver it now uses the MBR. Also it is not x64 only, this new variant also infects MBR on x86 (same dropper).

But I agree we should give this a name. Perhaps TDL3mbr? I suggest we let EP_X0FF decide how we should address this variant.

[SecConnex]

Oh I see. I knew the config was the same, but I was not sure. The infection routine has slightly changed.

[erikloman]

Oh I see. I knew the config was the same, but I was not sure. The infection routine has slightly changed.

Kaspersky decided to call it TDL4. Perhaps they know more that us?

[ConanTheLibrarian]

Latest TDSSKiller v2.4.1.3:
\HardDisk0\MBR - will be cured after reboot
Rootkit.Win32.TDSS.tdl4(\HardDisk0\MBR) - User select action: Cure

It worked. They must have updated it.

I downloaded TDSSKiller from here but it failed to fix the MBR on my Windows 7 Professional x64 session.

Agreed - doesn't detect or cure on a VBox x64 Win7

[kakaraka]

Heh, under win7 x64 the user still needs to accept to run the threat as admin.

How about infinite loop with UAC messages, when you have to press "Yes" or reset to get rid of it? :)

Nope, a simple single No prevented the file from running. Even if it was an infinite loop of UAC messages, that would only make it obvious it's malicious.

[sww]

Agreed - doesn't detect or cure on a VBox x64 Win7

x86 right now. x64 version will be ASAP.

[notkov]

Well the I/O filtering is the same, the watchdog is the same, the device 'layering' is the same, the encrypted file system is the same and TDL3's internal configuration is the same. Just the loading is different. Instead of infecting a system driver it now uses the MBR. Also it is not x64 only, this new variant also infects MBR on x86 (same dropper).

The encryption algorithm was changed, right :) ? If I recall correctly, pre-MBR variants used simple XOR encryption. This variant uses a table that is shuffled by a function based on number-of-sectors from the infected hdd.
In my opinion, the biggest step is x64 infection. Anyway, I wouldn't call it TDL4.

[notkov]

Nope, a simple single No prevented the file from running. Even if it was an infinite loop of UAC messages, that would only make it obvious it's malicious.

You could obtain an infinte loop if p1 (that doesn't need admin rights) drops in temp-dir p2 (that needs admin rights) and does a CreateProcess in a loop, until the process is created (let's say, signaled by a mutex). It would make it obvious it's malware? Belive me, most users will hit 'Yes' without even reading the warning.

[USForce]

MBRCheck is blind on SCSI drives (tested on vmware with SCSI disk), of course it couldn't be different.
Hitman Pro x64 crashed (BSOD) on vmware with SCSI disk

[kakaraka]

Nope, a simple single No prevented the file from running. Even if it was an infinite loop of UAC messages, that would only make it obvious it's malicious.

You could obtain an infinte loop if p1 (that doesn't need admin rights) drops in temp-dir p2 (that needs admin rights) and does a CreateProcess in a loop, until the process is created (let's say, signaled by a mutex). It would make it obvious it's malware? Belive me, most users will hit 'Yes' without even reading the warning.

You got it wrong, but you have some imagination... Too bad it did not not help you recognize the RC4 function in the MBR code.