A forum for reverse engineering, OS internals and malware analysis 

Forum for analysis and discussion about malware.
 #5984  by kmd
 Tue Apr 19, 2011 1:53 am
Eset comparing tdl4 with new bootkit from China is absolutely incorrect
There are other ways of penetrating into kernel-mode address space on x64 operating systems, for instance, as in the case of the Chinese bootkit which is detected as NSIS/TrojanClicker.Agent.BJ (VirusTotal). This uses quite a different approach to load its unsigned driver.
first of all this bootkit is nothing special (it had zero stealth level)
secondary - it's x86
third - new China bootkit intercepts ExVerifySuite function and replaces legitimate fips.sys with very primitive rootkit driver used for dll injection.

both tdl4/fips using bootkit techiniques/driver replacements so
the same words but totaly different meaning.
 #6095  by InsaneKaos
 Sat Apr 30, 2011 12:11 am
Looks like there is a new one

Infects still the mbr. Rootkit unhooker shows infected atapi.sys, Gmer didn't recognize it. TDSSKiller was not able to load completely, it was intercepted at 80%
Fixing the MBR with tools like aswMBR didn't work. No access.
Replacing the atapi.sys did not clean up the system, but after fixing the mbr via RC, TDL infection was gone.

VT was not working at this time. I'll post a link later, if it works for me.
Attachments
pw: infected
(114.91 KiB) Downloaded 124 times
 #6097  by USForce
 Sat Apr 30, 2011 3:26 am
Yes, they actually improved it :)

1) Bypassed Microsoft patch (STATUS_INVALID_IMAGE_HASH error overwritten) to be able again to infect x64 OS
2) Bypasssed Microsoft patch to kdcom.dll (now TDL4 checks kdcom resource directory size on the x64 version of it, whether it is == 0x110 || 0xFA)
2) Slightly modified disk miniport hook
 #6102  by nullptr
 Sat Apr 30, 2011 8:37 am
For anyone that maybe interested, Esage Bootkit Remover will detect it, but not remove it without a little help.
For Win 32, suspend the system watchdog thread, then run Bootkit Remover. I've not tested on 64-bit as yet.
 #6120  by erikloman
 Sun May 01, 2011 7:01 am
I've tried eSage Bootkit Remover using the new variant from InsaneKaos. The below log shows that it did not detect the infected MBR:
Program version: 1.2.0.0
OS Version: Microsoft Windows XP Home Edition Service Pack 3 (build 2600)

System volume is \\.\C:
\\.\C: -> \\.\PhysicalDrive0 at offset 0x00000000`00007e00
ATA_Read(): DeviceIoControl() ERROR 1
Boot sector MD5 is: 6def5ffcbcdbdb4082f1015625e597bd

Size Device Name MBR Status
--------------------------------------------
4 GB \\.\PhysicalDrive0 OK (DOS/Win32 Boot code found)


Done;
Press any key to quit...
I also tried aswMBR which looks like is not able to fix the MBR:
aswMBR version 0.9.5 Copyright(c) 2011 AVAST Software
Run date: 2011-05-01 08:46:00
-----------------------------
08:46:00.624 OS Version: Windows 5.1.2600 Service Pack 3
08:46:00.624 Number of processors: 1 586 0x2502
08:46:00.624 ComputerName: DESKTOP UserName: John
08:46:02.311 Initialize success
08:46:08.999 Disk 0 (boot) \Device\Harddisk0\DR0 -> \Device\Scsi\vmscsi1Port2Path0Target0Lun0
08:46:08.999 Disk 0 Vendor: VMware,_ 1.0_ Size: 4096MB BusType: 1
08:46:08.999 Device \Driver\vmscsi -> DriverStartIo ff39557b
08:46:08.999 Disk 0 MBR read error 0
08:46:08.999 Disk 0 MBR scan
08:46:08.999 MBR BIOS signature not found 0
08:46:09.030 Disk 0 scanning sectors +8369865
08:46:09.030 Disk 0 scanning C:\WINDOWS\system32\drivers
08:46:09.889 Service scanning
08:46:10.624 Disk 0 trace - called modules:
08:46:10.624 ntoskrnl.exe CLASSPNP.SYS disk.sys >>UNKNOWN [0xff395730]<<
08:46:10.639 1 nt!IofCallDriver -> \Device\Harddisk0\DR0[0x81194040]
08:46:10.639 3 CLASSPNP.SYS[fab9bfd7] -> nt!IofCallDriver -> [0x812032d0]
08:46:10.639 \Driver\vmscsi[0x81151a18] -> IRP_MJ_CREATE -> 0xff395730
08:46:10.639 Scan finished successfully
08:47:02.499 Disk 0 MBR fix error
Am I doing something wrong or are these tools only capable working with some versions of atapi.sys and not with other miniport drivers (like the vmscsi, storport, ataport, etc.)?
 #6122  by USForce
 Sun May 01, 2011 8:14 am
erikloman wrote:@InsaneKaos: Nice find!

Improved disk minport filtering hook confirmed (affects detection on both 32-bit and 64-bit systems).

Question is, what did TDL4 authors change in the filtering hook ...
Nothing too relevant, just changed the disposition of the hook devices. Anyway looks like there's a bug in this variant of TDL dropper when infecting x64 versions of Windows. Here it goes in a infinite loop when trying to call ZwDeviceIoControlFile with IOCTL_SCSI_PASS_THROUGH_DIRECT
  • 1
  • 40
  • 41
  • 42
  • 43
  • 44
  • 60