Guntior - the story of an advanced bootkit that doesn't rely on Windows disk drivers

At this time, most systems were x86, and thus didn't benefit from Kernel Patch Protection (KPP) or Driver Signing Enforcement. As a result, there was a lot of sophisticated malware loading unsigned drivers that used kernel mode hooks and direct disk access to hide malicious activity. Bootkits typically store their components in the disk sectors outside the normal file system and conceal their data from the rest of the operating system by returning zeroes or spoofed data in response to any requests for it 

The analysis of any bootkit involves not only reverse engineering skills, but also forensic skills in order to extract the infected boot sector, MBR and malware modules from disk sectors. 

• The dropper
• HIPS evasion
• Disabling security software
• Driver installation
• Payload DLL
• A few words about the Windows disk I/O subsystem
• Low-level disk access via ATA PIO mode
• Disk infection
• Bootloader
• Key takeaways
• Appendix

• The malware copies its executable to the temp directory as a DLL.
• Registers a new keyboard layout in the registry.
• Intercepts ZwQueryValueKey in its own process to supply "Ime File" registry value with the malware DLL path to the OS.
• Gets a handle to the Explorer window with FindWindow.
• Send the WM_INPUTLANGCHANGEREQUEST message to that window.
• The OS calls the ZwQueryValueKey hook to query the "Ime File" value of the newly registered keyboard layout and gets the DLL path.
• Windows caches information about this keyboard layout.
• Send the WM_INPUTLANGCHANGEREQUEST message again.
• ImmLoadLayout loads the DLL into the Explorer process using the cached data.

Created keyboard layout data.

The following diagram explains this trick.

Disabling security software

Upon its successful execution, the DLL code sets an event to signal the dropper. This injected DLL is responsible for loading the bootkit driver, but before doing this, it tries to disable the following tools by sending the appropriate IOCTLs to their drivers or killing their processes.

• 360tray.exe, 360 Total Security by Qihoo 360
• HintClient.exe by Shanghai Hintsoft Co., LTD, IOCTL code 0x00403A3B.
• DrvMon tool by Fyyre and EP_X0FF, IOCTL code 0x00403B0A.
• HardwareInfo.exe, part of the NetTools, IOCTL code 0x00220008.
• CfgClt.exe
• AVP.exe, Kaspersky security products
• KSafeTray.exe, PC Doctor Flow Monitor (PC Doctor) by Kingsoft
• RavMonD.exe, Rising AntiVirus by Beijing Rising Information Technology

For example, below you can see the code to disable DrvMon.

The bootkit is particularly interested in disabling ESET security products. It creates a separate thread in which it tries to terminate nod32krn.exe service in an infinite loop with a timeout of two seconds. To ensure that the process is killed, the driver is used.

Driver installation

Another interesting characteristic of this malware is how it installs and loads its driver. This tricky method is based on hijacking the Microsoft Trusted Audio Drivers service named drmkaud (drmkaud.sys) and utilizing PnP Manager to load it. To install the driver, the malware performs the following actions.

1. Selects a random name for its driver to be dropped into C:\Windows\System32.
2. Opens the registry key of Trusted Audio Drivers in HKLM\SYSTEM\CurrentControlSet\Enum\SW belonging to Device Manager with the full path HKLM\SYSTEM\CurrentControlSet\Enum\SW\GUID\GUID\{eec12db6-ad9c-4168-8658-b03daef417fe}\{ABD61E00-9350-47e2-A632-4438B90C6641}. These GUIDs are stored in encrypted form.
3. Modifies the security descriptor allowing Everyone all access to those keys.
4. Sets ConfigFlags value to zero, replaces the original name of the service drmkaud with the malware's.
5. Creates the driver service key in HKLM\SYSTEM\CurrentControlSet\Services.
6. Extracts the driver from the resources section, decrypts it and drops it onto disk.

The Trusted Auto Driver Service in the Enum key is hijacked so that its GUID can be used to load the malicious driver via the PnP Manager. The malware repeatedly tries to open any device named \Device\000000NN, each time incrementing the N values until it succeeds. For each device the code sends a special IOCTL code supplying the aforementioned GUID, which is stored in encrypted form.

If this trick fails, the malware loads the driver as usual, manually creating its service. Once it's loaded, the malware starts infecting the disk.

Payload DLL

The dropper uses a similar trick to register the payload DLL in the system. Instead of simply dropping the DLL and registering it in autorun, it hijacks one of Windows standard services by rewriting its executable with the malware DLL. To defend against malware analysis, the malware stores a list of these DLL names in encrypted form and decrypts them only briefly to the stack, making it unlikely that an analyst will find these names in a memory dump.

Trying to hijack at least one of them, the malware targets the following Windows services:

• AppMgmt - Software Installation Service
• BITS - Background Intelligent Transfer Service
• FastUserSwitchingCompatibility - Fast User Switching Compatibility service
• WmdmPmSN - Portable Media Serial Number Service
• xmlprov - Network Provisioning Service
• EventSystem - Event System service
• Ntmssvc - Removable Storage Service
• upnphost - Universal Plug and Play Device Host Service
• SSDPSRV - Simple Service Discovery Protocol service
• Netman - Network Connections service
• Nla - Network Location Awareness Service
• Tapisrv - Telephony service
• Browser - Browser service
• CryptSvc - Cryptographic Services
• helpsvc - Help Center Service
• RemoteRegistry - Remote Registry service
• Schedule - Schedule service

Below you can see the steps of this process. Before rewriting the system executable, the malware gets the address of SfcFileException export function in sfc_os.dll. Sounds familiar, right? This DLL implements the Windows System File Checker (SFC) API that can be used to scan or restore corrupted system files. The malware authors abuse one of these API functions to prevent SFC from automatically restoring the target system file after its modification.

The hijacked service DLL is responsible for communication with the driver, supplying it with pointers to undocumented ntoskrnl functions and kernel structure offsets, saving the driver from having to do it in kernel mode. The first IOCTL to be sent to the driver is 0x222440, which initializes it for further operation. The following data is to be sent.

• Addresses of the following functions: MmGetSystemRoutineAddress, PspTerminateThreadByPointer, KeInsertQueueApc, KiInsertQueueApc;
• First 12 bytes of each of those functions (their prologs); PspTerminateThreadByPointer;
• The offsets of the following kernel structures are EPROCESS->ThreadListHead, ETHREAD->ThreadListEntry.

When the malware needs to terminate a specific process, it sends a special IOCTL containing the PID. The driver gets a EPROCESS pointer to this PID and enumerates all threads belonging to this processes using the supplied offsets of EPROCESS->ThreadListHead and ETHREAD->ThreadListEntry and for each of them calls PspTerminateThreadByPointer.

The DLL contains an impressive list of processes to be terminated. Some of them belong to well-known security companies.

• ESET - nod32krn.exe, egui.exe, ekrn.exe;
• Qihoo 360 - 360tray.exe, 360leakfixer.exe, 360Safe.exe, safeboxTray.exe, 360safebox.exe, 360sd.exe, ZhuDongFangYu.exe, 360rp.exe, 360sdupd.exe;
• Kingsoft WebShield - KSWebShield.exe, kxesapp.exe, kxeserv.exe, kwstray.exe, kxedefend.exe, upsvc.exe, kxescore.exe, KVExpert.exe, kxetray.exe, KSafeSvc.exe, KSafeTray.exe;
• Rising AntiVirus - RavMonD.exe, RsTray.exe, RsAgent.exe, RegGuide.exe, RsMain.exe, RsCopy.exe, Rav.exe;
• Jiangmin Antivirus - KVSrvXP.exe, KVExpert.exe, KVMonXp.exe
• Kaspersky - AVP;
• Rising PC Doctor - ras.exe, knownsvr.exe, rstray.exe;
• Tencent QQPCMgr - QQPCLeakScan.exe, QQPCWebShield.exe, QQPCTAVSrv.exe, QQPCRTP.exe, QQPCMgr.exe, QQPCUpdateAVLib.exe, QQPCTray.exe, QQRepair.exe, QQPCPatch.exe;
• Other - Calc.exe (:D), guiyingfix.exe, knsdtray.exe, knsd.exe, knsdsvc.exe, knsdsve.exe.

Another interesting observation is that, before calling the undocumented function pointers passed from user mode, the driver first tries to restore the first 12 bytes of each function. The authors probably assumed that the drivers of some security products set hooks on these functions by patching their first bytes at runtime. The DLL provides the driver with these first 12 bytes, but before that, it copies them from ntoskrnl on disk, loading it into the process and finding those undocumented functions, i e PspTerminateThreadByPointer and KeInsertQueueApc. The screenshot below demonstrates this technique.

The code above walks through the list of all processes' threads as follows.

Now we can take a look at the entire malware installation routine.

The DLL is a core part of the malware, which acts as a bot and communicates with its control servers. The address is hard coded in the DLL. After connecting to 183[.]60[.]132[.]220, it tries to download one of the executable files with the names 1.exe, 2.exe, 3.exe, ..., 32.exe and run it in the system with the Explorer access token. Unlike TDL4, this bootkit isn't interested in protecting downloaded executables on disk. They are stored as regular files on volume and the bootkit doesn't restrict access to them.

Being the OS that is based on the hybrid kernel architecture satisfying the highest standards, Windows has the multi-layered disk I/O architecture. It's based on the device stack model, where each layer is represented by a separate kernel mode driver. One of the main advantages of this approach is that each of these layers is isolated from others and can use the unified Windows I/O subsystem's interfaces to communicate with other drivers on the stack. For example, the File System Driver (FSD) can dynamically attach its device to the existing disk device stack to dispatch file operations.

At the top of this device stack is the FSD (ntfs.sys), which handles file operations and attaches its device to the lower one belonging to the volume manager (volmgrx.sys). In order to operate files data, the FSD converts file offsets to the volume ones and addresses volmgrx.sys. The latter converts its offsets to the disk ones and calls the disk driver disk.sys or it can reach out to the partition manager (partmgr.sys) that is also located down the device stack. Unlike the device belonging to the volume manager, the partition manager's one represents a raw disk partition without a file system. Upon receiving a request, disk.sys calls the disk port driver atapi.sys, clarifying exactly which device on the ATA bus it needs to reach. The disk port driver completes this request by communicating directly with the disk controller. The major difference between the FSD and other drivers on the stack is that the first should keep the context for any open file (FILE_OBJECT and its FsContext) while others simply operate with disk or volume offsets.

The driver objects of the aforementioned drivers were an attractive target for rootkits and bootkits in the x86 era. The malicious Ring 0 code aimed at modifying the function pointers in the drivers' dispatch table to intercept the I/O operations of interest. IRP_MJ_READ, WRITE, DEVICE_CONTROL were the primary targets. Thus, rootkit detectors had to go as low as possible to safely read disk sectors, skipping potentially infected drivers located higher on the stack.

Low-level disk access via ATA PIO mode

The rootkit includes a unique feature we haven't seen in other notorious bootkits such as TDL4, Rovnix or Mebroot. It's capable of communicating with the hard drive at the lowest level without calling any Windows disk or disk port drivers (disk.sys, atapi.sys).

In a nutshell, instead of sending the IOCTL_SCSI_PASS_THROUGH_DIRECT request to atapi, the rootkit works directly with the ATA bus via IO ports 0x170-0x177 and a device control register port such as 0x376. Once all the preparations are done, the rootkit calls hal!READ_PORT_BUFFER_USHORT to read data from disk or hal!WRITE_PORT_BUFFER_USHORT to write to it. At the beginning of this routine, the rootkit queries the information about the IDE controller using hal!HalGetBusData for PCIConfiguration.

In spite of the presence of this interesting feature, the malware uses it in very limited cases. These cases don't even require calculating disk offsets using the partition table.

• To overwrite the MBR and drop the malware components onto the end of the disk during the disk infection process.
• The disk infection watchdog thread reads the MBR every 5 seconds in an infinite loop.

The disk infection routine is located in the main dropper and called in the context of Windows Explorer process after code injection is done as described above. If the injection fails, the dropper calls this function in the context of its process.

The rootkit provides the malware with two disk communication IOCTLs. The first is used to select the drive on which the malware wants to perform the RW operation and another describes this request.

• 0x30 and 0x34 to write sectors in 28/48 bit PIO mode;
• 0x20 and 0x24 to read sectors;
• 0xEC - IDENTIFY command.

• IOCTL_ROOTKIT_KILL_PROCESS 0x222444 to kill the specified process, as input accepts a Process ID (PID).
• IOCTL_ROOTKIT_INIT_DATA 0x222440 to initialize the rootkit structure containing undocumented offsets and functions, as input accepts initialized ROOTKIT_INIT_STRUCT (see below).
• IOCTL_ROOTKIT_READ_WRITE_DISK 0x22243D to read/write disk data.
• IOCTL_ROOTKIT_SEND_MBR_SIGNATURE to specify a disk to the rootkit for the following I/O operations.

• Send the signature of the disk to be infected to the rootkit (IOCTL_ROOTKIT_SEND_MBR_SIGNATURE).
• Read the first 16 sectors of the disk with IOCTL_ROOTKIT_READ_WRITE_DISK or with CreateFile/ReadFile on \\.\PhysicalDrive0 if the rootkit driver failed to load. Frankly, I didn't get why the malware reads as many as 16 sectors as it uses only first one that represents the MBR to infect it.
• Infect the MBR with the code from the 112 resource with 16-bit bootloader code.
• Allocate a virtual memory region with the size of 0x7E00 (63 sectors) and copy there infected MBR, original MBR, the 16-bit bootcode and the payload DLL.
• Overwrite the original MBR with the infected one.
• Calculate the offset from the end of the disk to drop the bootkit data (DiskSize - 0x41 sectors).
• Write the bootkit data to the end of the disk.