A forum for reverse engineering, OS internals and malware analysis 

Forum for analysis and discussion about malware.
 #2426  by CloneRanger
 Sat Aug 28, 2010 7:56 am
@ EP_X0FF

Thanks for the explanation about how TDL sneaks in the unsigned drivers etc. Sure is a problemmo for people who are click happy, and unfortunately a LOT are :P

What about MBRguard in general though, apart from it not being able to block TDL type stuff, as you intimated i presume ?
 #2427  by Fabian Wosar
 Sat Aug 28, 2010 8:00 am
CloneRanger wrote:If they do show up can they be disabled on the fly ?
Technically you could unload it. But it simply is not practical.
CloneRanger wrote:Also could they have their name changed to for eg, from whatever.sys to whatever.sysz then a fake whatever.sys dropped into the drivers folder to prevent it from running again ? See my Zip - PW = whatever
Not possible. Because it is not stored on the regular disk as EP_X0FF already explained.
CloneRanger wrote:This could be a temporary solution whilst a better fix arrives, or ?
There already is a fix: Boot from your Windows DVD, run a repair console from there and run fixmbr or bootrec /fixmbr. That's it. Detecting TDL-3 is quite easy as well, because there are so many artifacts. It is even possible from user mode.
 #2428  by Every1is=
 Sat Aug 28, 2010 8:09 am
EP_X0FF wrote:PatchGuard actually is doing what how it is named: guarding from modifying SSDT/SSSDT, IDT's, GDT's, using kernel stacks not allocated by the kernel, modifying or patching code contained within the kernel itself or the HAL or NDIS dll. As in fact TDL3 is much more PatchGuard friendly than most of security software. If assumptions are correct TDL can use bootkit technique to load itself while operation system initialization, so no digital signatures required at all. This is conceptual bypassing of built-in security. The more interesting thing here - how it installs on x64.
This is why intel bought mcafee... I can't think of a better way (?) to protect against this sort of stuff than from a hardware level. And am amazed that it hasn't been done before. Well, not yet even now.

In some bioses you can "protect against viruses". I assume that those machines just won't allow the bootsector to be overwritten without changing that bios setting, correct?

BTW, will drvmon.exe work on x64 systems fully?

And http://www.net-security.org/malware_news.php?id=1446 "The rootkit needs administrative privileges to infect the Master Boot Record. Even then, it still cannot load its own 64 bit compatible driver because of Windows's kernel security. So, the dropper forces Windows to immediately restart. This way, the patched MBR can do the dirty work," says Giuliani.

System with user running without admin privs won't get infected by this one?
 #2429  by Fabian Wosar
 Sat Aug 28, 2010 8:30 am
Every1is= wrote:This is why intel bought mcafee... I can't think of a better way (?) to protect against this sort of stuff than from a hardware level. And am amazed that it hasn't been done before. Well, not yet even now.
"Antivirus hardware" is nothing new and failed miserably in the past.
Every1is= wrote:In some bioses you can "protect against viruses". I assume that those machines just won't allow the bootsector to be overwritten without changing that bios setting, correct?
That is at least the idea. The reality though is that it never worked because only access through the BIOS is actually monitored. Since Windows NT and it's successors talk to the disk directly using their native disk drivers the BIOS is never involved except during the boot phase.

Some BIOSes will display a warning though when the MBR was changed on the next boot.
Every1is= wrote:System with user running without admin privs won't get infected by this one?
No, they won't.
 #2430  by EP_X0FF
 Sat Aug 28, 2010 8:46 am
Every1is= wrote:In some bioses you can "protect against viruses". I assume that those machines just won't allow the bootsector to be overwritten without changing that bios setting, correct?
Forget about this legacy stuff in BIOS. It will protect you only from Windows 98 installation.
BTW, will drvmon.exe work on x64 systems fully?
It's not signed, so no.
 #2435  by Blur
 Sat Aug 28, 2010 10:38 am
I've read, that doesn't clear me how does it manage to patch compressed PE within the bootmgr to disable drivers signing on vista and windows7 :(
 #2437  by Blur
 Sat Aug 28, 2010 10:53 am
On my way mate :) Though still can't find the code which does the patch stuff... Will try harder :)

P.S. Well may be it's easier to wait for any article hehe :)
  • 1
  • 6
  • 7
  • 8
  • 9
  • 10
  • 60