[Xylitol]

reboot:






Probably a fake defrager like hdd rescue who drop Alureon and a broken dll (for me) who is here for launch the fake defrager (assumption)
a file called InternetExplorerUpdate.exe is also dropped in %temp% and deleted after the infection.
http://www.virustotal.com/file-scan/rep ... 1299204960
https://www.virustotal.com/file-scan/re ... 1299205769
https://www.virustotal.com/file-scan/re ... 1299214973
http://www.threatexpert.com/report.aspx ... 2570d7d163

[EP_X0FF]

Yes, it is PRAGMA TDL modification. A little evolved with anti MBAM feature on board.
Seems to be it blocks loading of MBAM driver by creating watchdog thread that constantly deletes (by directly sending IRP_MJ_SET_INFORMATION/FileDispositionInformation) following file

\\SystemRoot\\System32\\Drivers\\mbam.sys

kinda stupid solution, they also have loadimage notify callback.

Posts moved to TDL Mods thread

[PX5]

Think we hexed ourself saying its dormant, something new out there, as Im in a remote where tdsskiller will not run, nor do many other tools, I know its tdl4 but at present, dont have a current loader. :(

[PX5]

This is same infection I mistake for tdl4, thanks for reversing. :)

[Meriadoc]

Probably a fake defrager like hdd rescue who drop Alureon and a broken dll (for me) who is here for launch the fake defrager (assumption)
a file called InternetExplorerUpdate.exe is also dropped in %temp% and deleted after the infection.

WindowsRecovery drops InternetExplorerUpdate.exe in temp folder and uses same icon,



some reuse, connection (?)

[EP_X0FF]

drops InternetExplorerUpdate.exe

If it look like this http://www.virustotal.com/file-scan/rep ... 1301601811

then it's PRAGMA TDL Mod dropper (infects volsnap.sys in TDL3 way). Can be easily removed by sophisticated user even without using special tools or anti-viruses.

[PX5]

http://www.virustotal.com/file-scan/rep ... 1301784864

[__Genius__]

Interesting topic,
Here
& better discussion from technical aspects

regards.

[Evilcry]

Here the counterpart.

Detecting/Memory Forging Attempt by a Rootkit

http://mnin.blogspot.com/2011/04/detect ... pt-by.html

Regards

[rossetoecioccolato]

The (rootkit) technique is only effective against tools that scan memory using the default mapping for virtual addresses (e.g. antivirus and some rootkit detectors). It is not effective against tools that remap physical pages to an alternate virtual address (e.g. memory forensic acquisition software). Also, the rootkit is not particularly sophisticated in that it sets the debug registers of all the logical processors even when no memory scanning tool is running, thus allowing modification of the debug registers to be detected by memory forensic software. A more sophisticated approach would be to detect the memory scanning software when it loads and only set the debug registers on the memory scanning thread, and then only on context shift to that thread, restoring the debug registers when the context shifts away from the scanning thread.

Leaving this aside, the question that I have for the author of the Volatility plugin (MHL) is how kpcr.Prcb.ProcessorState is getting updated to reflect of the current state of the corresponding register (dr0)? Dr0 is on the logical processor while kpcr.Prcb.ProcessorState.SpecialRegisters.KernelDr0 is in main computer memory. kpcr.Prcb.ProcessorState get's set early in the boot process when the KPCR is initialized. It also get's set on hibernation and when a bugcheck occurs. I am not aware of it being set on context shift. Applications which convert a raw memory dump to MS crashdump format also adjust some context values in kpcr.Prcb.ProcessorState of Processor0 so that Windbg will recognize the processor architecture. This is needed because kpcr.Prcb.ProcessorState typically is not current. Maybe in this case the rootkit is updating kpcr.Prcb.ProcessorState; or else MHL is running some software that updates it as part of the acquisition process?