Sophos reports that the Guntior, malware out of China has resurrected with master boot record (MBR) infection techniques and has been common for a while now.
These new techniques implemented are to bypass security mechanisms such as Windows PatchGuard and kernel driver signing which were introduced in Windows Vista and up.
Many new malware has adopted these techniques ranging from those that entirely overwrite the MBR with a malevolent loader to ones that manipulate values to alter loading offsets to hijack the boot process.
Sophos has also did a analysis of the dropper, you can view the bootkit analysis here.
The dropper
The dropper has two execution branches. One is a dynamic link library (DLL) and the other is an executable.
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.
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.
After doing that, the dropper deletes the copies it created in the %Temp% directory and restores the PATH variable.
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
This is to hide the malicious MBR and instead return a clean view of the MBR when read.
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
On unhooking the two IRP hooks we can actually see the malicious MBR.
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.
Analysis and information belong to nakedsecurity.sophos.com
