Bootkit Disk Forensics – Part 2


As I explained in the previous article: DriverStartIo is used by older miniports to actually perform the disk I/O, it takes 2 parameters (a device object and an IRP), exactly the same as IoCallDriver does. The call to DriverStartIo is done with IoStartPacket; however, the device object passed is not that of the miniport, but instead a device associated with the port the target disk is connected to (in my case IdePort1).
IRP_MJ_SCSI points to IdePortDispatch in atapi.sys, by disassembling it we can see exactly how the required device object is retrieved from the DeviceExtension field of the miniport’s device object.
To start with, ebx is the address of the device extension (which is shared between all atapi devices).

The call logic is something like this:

  1. Get the miniport’s device extension from its device object (passed to us in the call).
  2. Get IdePort1’s device extension from offset 0x5C into the miniport’s device extension.
  3. Get IdePort1’s device object from offset 0x0C into its device extension.
  4. Call IoStartPacket with the IRP and IdePort1’s device object.
The relationship between the various objects.
As both the miniport and IdePort devices are created by atapi.sys, the DriverObject field of both devices’ objects point to the same driver object; thus, hooking DriverStartIo is as simple as replacing the address in the driver’s object.  

Detecting DriverStartIo hook with WinDbg

For basic DriverStartIo hook detection we can simply follow the same process as for major function hooks: First, we find the boot disk and list it’s stack.
Device stack for boot device on a clean system
Device stack on a TDL4 infected system.
As I explained in the previous article, modifications made by TDL4 will cause the !drvobj and !devobj commands to think the object is invalid, it’s not. You will probably want to check each driver object in the stack (for the invalid DeviceObject you can again use “dt _DEVICE_OBJECT <address>” to find the DriverObject field).
With most bootkits, the lowest level driver is always the one hooked, so I’ll use this in my example.
DriverStartIo appears not to be hooked.
You can see here that DriverStartIo isn’t hooked because the address resolve to its proper symbol; however, this isn’t actually the real driver object. Earlier i explained that IoStartPacket is always called with the device object of IdePort1, not the disk miniport: This means that when IoStartPacket called DriverStartIo internally, it does so by getting the driver object from the DriverObject field of IdePort1’s device object, then getting the DriverStartIo field from that. Obviously this means that to hook DriverStartIo, one could simply just create a copy of atapi’s driver object, with the DriverStartIo field modified, then set the DriverObject field of IdePort1’s device object to point to the new, malicious driver object (this way on IdePort1 will point to the hooked driver, the rest will point to the original).
As it happens TDL4 actually does the opposite, it hooks the real atapi driver object, then replaces the DriverObject field of the disk miniport’s device object with the address of an identical driver object, without the DriverStartIo field modified.).
If you know what you’re looking for, fake driver objects are easy to detect. All devices created by a driver should point the same driver object, so simply enumerating the devices created by the miniport’s driver then making sure all the DriverObject fields point to the same address is all that’s needed. This can be done a multitude of ways.
Method 1: DrvObj
The fake driver object will have the same name as the real one (in my case “driveratapi”), all you need to do is type “!drvobj driveratapi 2” to get the real driver’s object (this is a downside of TDL4 hooking the real driver object instead of a spoofed one). 
Method 2: NextDevice
Starting with the miniport device, enumerate devices using “dt _DEVICE_OBJECT <address>” and the NextDevice field of each device’s object. We’re looking for any DriverObject field that dosen’t match that of the miniport (this is the real driver object).
All devices should point to the real driver object, except for the miniport.

Method 3: DeviceExtension
This is the least reliable way, as the device extension could change from system to system, but as I mentioned earlier: you can find IdePort1’s device extension at offset 0x5C isn’t the miniport’s device extension, then from IdePort1’s device extension you can find its device object at offset 0x0C (IdePort1’s device object will point to the real driver object). We can actually find the DeviceObject in a single commands using this overly complicated WinDbg-C++ syntax: “dt _DEVICE_OBJECT poi(poi(@@C++(((nt!_DEVICE_OBJECT *)<address>)->DeviceExtension)+0x5C)+0x0C)”, where “<address>” is the miniport device object.


Why Open Source Ransomware is Such a Problem

A while back 2sec4u posted a poll asking if people considered open source ransomware helpful to detection and prevention, with 46% voting yes. Although the poll wasn’t limited to people working in the antimalware industry, 46% is scarily high. Trying to prove a point, help me out Twitter. Is open source ransomware helping …

Mapping Mirai: A Botnet Case Study

Mirai is a piece of malware designed to hijack busybox systems (commonly used on IoT devices) in order to perform DDoS attacks, it’s also the bot used in the 620 Gbps DDoS attack on Brian Kreb’s blog and the 1.1 Tbps attack on OVH a few days later. Although Mirai isn’t even close to …

Dridex Returns to the UK With Updated TTPs

With the exception of a few unconfirmed reports of Dridex targeting Baltic countries (which doesn’t make much sense economically), infection campaigns have ceased since mid August when Dridex briefly resumed spreading to propagate multiple new botnets aimed at Switzerland. This morning a friend of mine, Liam, reported receiving a malicious email which unusually didn’t …