Attachments
(118.83 KiB) Downloaded 68 times
A forum for reverse engineering, OS internals and malware analysis
@markusg: I don't think there is any point in posting the same repacked sample over and over. The last 2 files you posted are identical except slightly different (probably polymorphic) packer code.
@freyr
The TDL packer is nothing special. As NOP already said you can retrieve all sensitive data (drv loader, cmd.dll (UPX), cmd64.dll (MPRESS) except cfg.ini because it constructs by cmd.dll in runtime) by simple dumping to disk whole allocated region. However unpacking each TDL sample is quite boring, so automatic tools for TDL data extraction/analysis were developed long time ago (starting from earlier 3.x versions) - all them work (or should) until now and cannot be bypassed by this rootkit due to rootkit own design. You can look for code posted by Fabian Wosar somewhere in the beginning of this thread.
Latest posted sample extracted data in attach.
The TDL packer is nothing special. As NOP already said you can retrieve all sensitive data (drv loader, cmd.dll (UPX), cmd64.dll (MPRESS) except cfg.ini because it constructs by cmd.dll in runtime) by simple dumping to disk whole allocated region. However unpacking each TDL sample is quite boring, so automatic tools for TDL data extraction/analysis were developed long time ago (starting from earlier 3.x versions) - all them work (or should) until now and cannot be bypassed by this rootkit due to rootkit own design. You can look for code posted by Fabian Wosar somewhere in the beginning of this thread.
Latest posted sample extracted data in attach.
[main]
version=0.03
aid=30040
sid=0
builddate=351
rnd=1229272821
[inject]
*=cmd.dll
* (x64)=cmd64.dll
[cmd]
srv=hxxps://lo4undreyk.com/;hxxps://sh01cilewk.com/;hxxps://cap01tchaa.com/;hxxps://kur1k0nona.com/;hxxps://u101mnay2k.com/
wsrv=hxxp://gnarenyawr.com/;hxxp://rinderwayr.com/;hxxp://jukdoout0.com/;hxxp://swltcho0.com/;hxxp://ranmjyuke.com/
psrv=hxxp://crj71ki813ck.com/
version=0.15
Attachments
pass: malware
(67.49 KiB) Downloaded 85 times
(67.49 KiB) Downloaded 85 times
Ring0 - the source of inspiration
Post removed, see thread posting rules, page 1.
3. Please do not post identical samples and links to out-dated information about TDL4If you not sure what sample do you have - please do the small initial analysis (in VM/Sandbox etc) instead of just attaching it here. There is nothing new in TDL4 copy-pasted version for a long time, so there is no sense in samples of the same kind. VT scan results always will be entertainment because everybody knows that signatures and so-called generic detections/heur simple sucks.
Ring0 - the source of inspiration
Goodbye TDL4.03
Microsoft Security Advisory (2506014) Update for the Windows Operating System Loader
Microsoft Security Advisory (2506014) Update for the Windows Operating System Loader
Ring0 - the source of inspiration
I think this probably affects DisableDriverSigning bcd entry, to stop windows cracks from working.
Blur wrote:I think this probably affects DisableDriverSigning bcd entry, to stop windows cracks from working.http://blogs.technet.com/b/srd/archive/ ... dates.aspx
The second advisory, KB 2506014, hardens Windows against kernel-mode rootkits. This specifically breaks the hiding mechanism used by the current Alureon/TDL4 rootkit family. It is an optional update available on WU and WSUS.
Ring0 - the source of inspiration
Blur wrote:I think this probably affects DisableDriverSigning bcd entry, to stop windows cracks from working.I don't think so. WinPE mode must allows unsigned drivers otherwise Microsoft would break many things. I think they fixed how Winload.exe is loading kernel and its dependencies (kdcom.dll, hal.dll, bootvid.dll) by forcing it to load only signed drivers not matter what says the BCD configuration.
I think the situation before this patch was:
BCD -> DriverSigningOption
Winload.exe -> Read BCD and check DriverSigningOption. If Driversigning is enabled, it checks for digital signature on kernel and its dependencies; otherwise it doesn't do any check and just load the kernel
kernel -> will use DriverSigning or not based on the parameters passed by winload.exe (/MININT)
The situation now should be:
BCD -> DriverSigningOption
Winload.exe -> no matter what is the BCD configuration, winload will always check for digital signatures on kernel and its dependencies
kernel -> will uses DriverSigning or not based on the parameters passed by winload.exe (/MININT)
TDL4 was exploiting this situation, by changing the BCD configuration so that Winload could load unsigned drivers as well and restoring the option by changing again the /MININT to IN/MINT
I am Jack's NULL pointer (actual e-mail contact.ntinternals_at_gmail.com)
Theoretically it may now use BcdLibraryBoolean_DisableIntegrityCheck,
and identify kdcom.dll by new export table size. So I think MS make a mistake,
becouse if tdl authors will go by the simple way, infected machine's will be affected to load
unsigned drivers from any "vx-vendors".
and identify kdcom.dll by new export table size. So I think MS make a mistake,
becouse if tdl authors will go by the simple way, infected machine's will be affected to load
unsigned drivers from any "vx-vendors".