[USForce]

Guys, I know that without a low level raw disk reading technique SysInspector can't detect tdl on disk (well, it isn't necessary to get disk access though, TDL3 can be easily detected on memory too, even the infected file - RkU is an example :)) But then, as I said before, there's something strange SysInspector is doing so that it can detect TDL3 casually.

Before infection:


And after TDL infection:


This is really bizzarre :D

[USForce]

before you ask me what TDL3 version I'm using

[main]
quote=I felt like putting a bullet between the eyes of every panda that wouldn't screw to save it's species. I wanted to open the dump valves on oil tankers and smother all those french beaches I'd never see. I wanted to breathe smoke
version=3.273
botid=
affid=
subid=
installdate=2.7.2010 17:54:18
builddate=28.6.2010 17:25:3
rnd=1220945662
knt=1278094212
[injector]
*=tdlcmd.dll
[tdlcmd]
version=3.82
bsh=c2c5138ee909e1800a42c87e05881b0a553eb410
delay=7200
servers=https://19js810300z.com/;https://lj1i16 ... n4cx00.cc/
wspservers=http://rf9akjgh716zzl.com/;http://dsg1t ... 3kjf7.com/
popupservers=http://clkh71yhks66.com/
clkservers=http://z0g7ya1i0.com/

[EP_X0FF]

There is something wrong with your VirtualBox configuration or TDL3 :D
Perhaps something related to hard disk or disk controllers?

Oracle Virtual Box 3.2.6 + Windows XP SP3 + TDL3 + ZeroAccess (default VM settings)
Scanned by SysInspector - rootkit not detected.

[USForce]

There is something wrong with your VirtualBox configuration or TDL3 :D
Perhaps something related to hard disk or disk controllers?

Oracle Virtual Box 3.2.6 + Windows XP SP3 + TDL3 + ZeroAccess (default VM settings)
Scanned by SysInspector - rootkit not detected.

Standard VirtualBox configuration and classic TDL3 dropper. Bah, it'll just remain a mistery, I don't have time about further investigations on such tool :roll:

[notkov]

I think the problem is a bug in TDL3. Sometimes (not 100% reproducible), the file that is infected, if your read it normally (Windows API), the checksum from PE header is wrong! Somehow the stolen part from the file is incorrectly put back. So maybe the image from memory differ with the one read normally from disk.
If you didn't manage to obtain this behaviour, I will attach the files in another post, the clean one and the "clean" one :)

[EP_X0FF]

I think you are right :)
Please attach these files, I will try them with SysInspector.

[notkov]

There are 3 files in archive: infected one, original one, and the file showed by TDL3 as clean. (The checksum is recalculated so you can load the driver).

As you will see, version info of the file showed by TDL3 it's from kbdclass driver :) (because the machine was infected before with TDL3 and it infected kbdclass driver). Disinfection was performed, but the sectors from the end of the harddisk still contain TDL code.
So this could be the problem: The machine you were testing was infected with TDL before, and due to a bug in TDL this is happening.

[EP_X0FF]

Reasonable. Rootkit keeps replaced resource part in it's own file system as file named "rsrc", so such behavior is very likely. TDL3 used wrong resources data, resulting in "killing" VERSION_INFO block, all drivers without this resource automatically become "suspicious" by SysInspector :D

[USForce]

I confirm the bug. If the machine was infected and cleaned before (and mine was actually, I used it for a number of tests before restoring old snapshot) then, if you reinfect the system again, SysInspector will detect the suspicious driver because the Version Info structure is corrupted ;)

mystery solved :D

[Jaxryley]

Not many hitting this one. Koobface sample included.

Code: Select all

hxxp://iglesiabetania1.com/.bte8ce/?getexe=dogma.exe
hxxp://iglesiabetania1.com/.bte8ce/?getexe=p.exe

dogma.exe - Result: 4/41 (9.76%) - MD5...: be29db3571dbc30f726d65b32617a751
http://www.virustotal.com/analisis/084a ... 1278412041

p.exe - Result: 16/41 (39.03%) - MD5...: ea900a6c041468a83f46502a73818e7d
http://www.virustotal.com/analisis/df82 ... 1278412047