Author Topic: Rootkits and MBR  (Read 2971 times)

0 Members and 1 Guest are viewing this topic.

January 03, 2008, 01:01:10 am
Read 2971 times

sowhat-x

  • Guest
2008 just came in,along with newer malware tricks to handle...

At first,check this nice article,which is dating back in February 2006.
For the sake of simplicity,and in case the original blog disappears for some reason,
I copy/paste most of the article's contents here...the original page can be found at:
http://morph3us.org/blog/index.php?/archives/29-Finding-hidden-drivers-in-Windoze-NT.html

Quote
You have to reboot your box and start the system with enabled boot logging:
hit F8 before Windoze boot screen and select the entry "Enable Boot Logging".
Another possibilty to boot with enabled logging is to hand the /BOOTLOG option to the Windoze kernel,
as a parameter by editing the `boot.ini' file.
If the Windoze kernel detects the above mentioned option,
the I/O manager calls IopBootLog() to record all loaded drivers.Even disabled drivers are logged.
IopBootLog() cannot simply write the data into a log file,
because the Session Manager Subsystem (Smss.exe) is going to execute `chkdsk',
to ensure the system drives consistency, later in the boot process.
Therefore IopBootLog() has to save all messages in the HKLM\SYSTEM\CurrentControlSet\BootLog registry value.
Later on the kernel invokes the IopCopyBootLogRegistryToFile() method,
which creates the file `%SYSTEMROOT%\Ntbtlog.txt',
and copies the contents of the BootLog registry value to the file.

Now we have a complete list with all loaded drivers,
because the rootkit which would hide drivers after its initialization is loaded and executed after the boot logging.
Then we can compare the "clean" list with another list,
retrieved by querying the standard APIs for enumerating drivers,for example:
EnumServicesStatusA(),EnumServiceGroupW(),EnumServicesStatusExA() and EnumServicesStatusExW().

The big disadvantage of this method is the necessary reboot.
It would be easy for a rootkit to manipulate the `Ntbtlog.txt' file,or better,the `BootLog' registry value.
We could circumvent this problem by booting from Windoze CD or boot disks and starting the recovery console.
The recovery console is able to list all Windoze installations and to "log into" a selected installation.
It loads the SYSTEM hive `%SYSTEMROOT%\System32\Config\System',
which contains the HKLM\SYSTEM\CurrentControlSet\Services' registry key for the specified installation.
The `Services' key stores all services and drivers.

The recovery console also supports commands to list all services/drivers and to enable/disable them.
So you could easily dump all drivers (and even services) to a file,
reboot the system and compare this file with the data returned by an API.
It's more effort to start the recovery console but you can be sure that the list is not manipulated by any malware.

We are able to beat rootkits which use any kind of hooking technique,
and we are able to detect rootkits which use Direct Kernel Object Manipulation (DKOM) to hide their presence too.
Logically, it's not possible to find rootkits which use the 'Memory Cloaking Concept',
described in Phrack 63-0x08 "Raising The Bar For Windows Rootkit Detection".

And now,have a look at the evolution here,almost two years later...
http://www2.gmer.net/mbr/