Kdrill – Unveiling Rootkit Intrusions In Windows 64-Bit Systems

Kdrill is a tool to analyze the kernel land of Windows 64b systems (tested from Windows 7 to Windows 11). Its main objective is to assess if the kernel is compromised by a rootkit.

The code is compatible with python2/3 without dependencies and can perfom checks without Microsoft symbols or Internet connectivity.

For live memory/kernel analysis, the Winpmem driver is used and Kdrill interfaces itself with the driver, another possibility is to connect to a remote GDB server. KDrill can also analyze Full crash dumps and Kernel crash dumps (mainly stored in C:\Windows\MEMORY.DMP) and a fucked version of AFF4 dumps (zip, but not zipped).

Kdrill accesses the physical memory and decodes/re-builds the OS internals structures to explore them, and to verify their intergrity.

The following checks are performed:

• Loaded modules list
• Drivers in memory code (compared to on-disk version)
• Callbacks of kernel objects and internal ntoskrnl lists
• PlugAndPlay tree and filters
• FltMgr callbacks
• KTimers DPC functions
• IRP driver’s tables
• Driver signing global variables avec callbacks
• NDIS filters and callbacks
• NetIO/FwpkCLNT filtering dispatch
• Devices and their attached device objects
• IDT entries
• PatchGuard initialization and state

Internals

Kdrill retrieves all kernel structures offsets automatically and builds a specific mapping at each execution.

So it doesn’t need symbols or Internet connectivity to resolve them (:wink: disconnected networks).

Most checks verify if the callback or pointed function is in a driver and if the driver is inside a “trust list” I made totally random.

I strongly recommend you to check if those drivers are signed (by a trusted signer)

However, for integrity drivers checks, you will need to have an Internet access to download Microsoft binaries from MS servers in order to diff them. If you already have them in c:\symbols it’s fine too

Rootkits Examples

Some examples of rootkits detections (not all triggers, juste intersting finds).

Winnti

Winnti replaces functions pointers in the NDIS callback of TCPIP. With the cndis command we can identify it:

#>> cndis
 [*] Checking NDIS Firewall layers
  [*] List from fffffa80033d3d70
    Driver      : pacer.sys
    GUID        : {B5F4D659-7DAA-4565-8E41-BE220ED60542}
    Description : QoS Packet Scheduler
    Driver      : wfplwf.sys
    GUID        : {B70D6460-3635-4D42-B866-B8AB1A24454C}
    Description : WFP LightWeight Filter
 [*] Checking NDIS Protocol layers
  [*] List from fffffa8002a71a60
    Name : NDIS6FW
  Callback fffff88003329e50 -> c:\users\toto\appdata\local\temp\tmp1ec3.tmp (not in white list) SUSPICIOUS
  Callback fffff88003329e50 -> c:\users\toto\appdata\local\temp\tmp1ec3.tmp (not in white list) SUSPICIOUS
[...]
    Name : NDISWAN
    Name : WANARPV6
    Name : WANARP
    Name : TCPIP6TUNNEL
    Name : TCPIPTUNNEL
    Name : TCPIP6
    Name : TCPIP
  Callback fffff8800332a660 -> c:\users\toto\appdata\local\temp\tmp1ec3.tmp (not in white list) SUSPICIOUS
  Callback fffff8800332a810 -> c:\users\toto\appdata\local\temp\tmp1ec3.tmp (not in white list) SUSPICIOUS

For more information click here.