The Case of Maximus (Mebroot-based) Bootkit

The next guinea pig is Maximus bootkit based on notorious Mebroot/Sinowal/MaosBoot. This bootkit is dated by 2008. Its dropper waits some time (about a hour) to complete installation. Then it reboots the computer. It refuses to work on our Windows 7 test system, but perfectly works on Windows Server 2003. Let’s start Hypersight Rootkit Detector’s monitoring on the infected system:

We see about 40...60 “stealth code” events. This tells us about a relatively big code base of the rootkit.

There are some typical code pieces of this rootkit shown below.

The code called by patched call of tcpip!IPRcvPacket:

The hooked IRP_MJ_WRITE callback of disk.sys:

The code called from ndis.sys driver:

And finally, the piece of the bootkit’s image in the memory (“MaOS” is a signature typical for Mebroot bootkits):

Mebroot bootkit places its body into nonpaged pool beyond the code of kernel-mode modules. This helps to avoid detection by anti-viruses and software-based rootkit detectors. But it fails to hide from hypervisors.

The Case of AllInOne (Nailuj) Rootkit

We continue writing about detection of various rootkits by Hypersight Rootkit Detector. Today we will test the AllInOne rootkit aka Trojan.Nailuj.A.
This is relatively old rootkit and it does not work properly in Windows Vista and Windows 7 (bugcheck 0x7E SYSTEM_THREAD_EXCEPTION_NOT_HANDLED).

However it installs correctly on Windows Server 2003. It drops the file VideoAti0.sys into %WINDIR%\system32\drivers directory. After rebooting it makes files of the dropper and the driver invisible.
Let’s start monitoring of Hypersight when rootkit has become invisible. We will see “Stealth Code Executed” activity:

The rootkit’s stealth code looks like

As we can see from return address on the stack, this is a IRP hook procedure.
ESI points to the DRIVER_OBJECT and EAX contains the number of IRP major function (IRP handlers are called by the opcode CALL [ESI + EAX * 4 + 0x38] in Windows Server 2003).

Where the stealth code is resided? To determine this, let's look at the list of kernel modules:

As we can see, the code is resided between two modules. We can conclude this is a code of driver, which is hidden by excluding from the list of drivers.

Finally, we can look at the dump of code page for each event to recover the rootkit's image in the memory:

That's all for today. Good luck with discovering new rootkits.