Guntior bootkit up to new tricks

Check your help

The resurrection of master boot record (MBR) infection techniques has been common for a while now.

Why? Mainly to bypass security mechanisms such as Windows PatchGuard and kernel driver signing which were introduced in Windows Vista and later.

Families of malware that use this technique are called bootkits. TDL and Sinowal were the first widespread, sophisticated threats to adopt bootkit infection techniques.

Copycats and variations followed, ranging from those that completely overwrite the MBR with a malicious loader to ones that manipulate values to alter loading offsets to hijack the boot process.

One bootkit that has been out for a while now is the Chinese bootkit Guntior.

Droppers have been around since at least 2010 and are still seen in the wild.

Detailed analyses of some versions have already been completed on some online forums and blogs, so we won’t repeat that; instead we will discuss an interesting technique employed by the bootkit’s dropper.

The dropper

The dropper has two execution branches. One is a dynamic link library (DLL) and the other is an executable.

Figure 6

Throughout its execution down the “exe” path it maintains a log file in the %Temp% directory called ‘stinst.log’ to capture information such as the OS version and its randomly generated name when it copies itself to the system32 directory.

It also makes sure that the %Temp% directory is appended to the PATH environment variable.

The dropper relies on the system time as a seed to generate random names for itself and its dropped components.

It also names a copy of itself msimg32.dll in the %Temp% directory, creates a copy of HelpCtr.exe in the %TEMP% directory, and alters the PEFlags in the new copy of msimg32.dll so that they indicate that the file is a dll.

fig7 500

HelpCtr.exe is a clean Windows file that imports calls from msimg32.dll, which is normally found in the system folder.

As you may have guessed from its name, HelpCtr.exe starts the Windows Help and Support Center homepage.

By ensuring that %TEMP% is in the path before the normal system folders, HelpCtr.exe in %TEMP% will load the malicious msimg32.dll from the current directory (%TEMP%) rather than the Microsoft-provided copy in the system folder.

This is similar to the technique used by targeted malware attacks that piggybacked on NVIDIA’s digital signature.

The malware then invokes HelpCtr.exe from the %Temp% directory using a very interesting mechanism. It sends a WM_HOTKEY message to the Shell_TryWnd window in order to run HelpCtr.exe.

By doing so the malware actually runs the “dll” branch of execution before it continues the “exe” branch of execution.

HelpCtr.exe can be started by using the hotkey combination of Win+F1. By passing these specific values to the lParam and wParam arguments, the dropper invokes that hotkey combination.

fig8 500

After doing that, the dropper deletes the copies it created in the %Temp% directory and restores the PATH variable.

check your help 500

Protecting disk sectors

Like other bootkits, Guntior will hook I/O request packet (IRPs) handlers in order to hide the existence of the malicious MBR that it writes to sector 0.

Most bootkits have followed the same architecture discussed in our Popureb white paper.

Guntior is slightly different in that, unlike other bootkits that hijack the I/O path by placing hooks in the miniport driver, it hooks the disk class drivers (disk.sys) IRP_MJ_READ and IRP_MJ_WRITE. This approach is not as deep as placing hooks in the miniport driver.

Normally the I/O path taken for an IRP flows from the storage class driver to the port driver which then interfaces with the miniport driver and back. So the miniport driver resides closer to the hardware than the storage class driver.

Bootkits like TDL4 and Popureb place their hooks in the miniport driver to achieve maximum control. Generally, hooking at such levels is done to subvert the attempts of security software to read and write to disk through storage filter drivers.

Hooked Disk driver IRPs
Hooked Disk driver IRPs

This is to hide the malicious MBR and instead return a clean view of the MBR when read.

Clean MBR view with hooks present
Clean MBR view when hooks are present

The hooks don’t actually reside inside the driver that the rootkit drops but rather in an allocated region of kernel memory.

Inside that region the code relies on a pivot function in order to find its location in memory and passes fixed offsets to the function to access imports and the structures that it requires.

Using this technique it accesses the original IRP table of the disk driver that it keeps intact to serve requests directed at the handlers that it hooks.

Clean IRP table stored
Clean IRP table stored

On unhooking the two IRP hooks we can actually see the malicious MBR.

Malicious MBR view after unhooking IRPs
Malicious MBR view after unhooking IRPs

This technique for hiding the malicious MBR by hooking IRPs has been commonly copied with little variation across different bootkits.


Bootkits share some similar techniques when it comes to hiding their existence and hijacking the boot process to inject malicious code in ring 0.

They differ, though, in how they infect a system and what their payloads actually do. Guntior does not really employ any new techniques when trying to hide itself, but its dropper does use some interesting tricks.

Sophos detects Guntior droppers as Mal/Jadtre-C, the malicious MBR as Troj/JadMbr-A and the kernel memory infection as Troj/JadKmem-A.