Module 1: Kernel vs User-Mode Evasion

Why ring 0 access is the ultimate evasion primitive and the cost of getting there.

1. The x86 Privilege Ring Model

Intel and AMD processors implement a hardware privilege system with four rings (0 through 3). Windows uses only two of these:

The transition between ring 3 and ring 0 happens through system calls (the syscall instruction on x64). When a user-mode application calls a Windows API like NtOpenProcess, execution transfers to the kernel through the SSDT (System Service Descriptor Table), runs in ring 0, and returns the result.

2. Why User-Mode Evasion Is a Losing Battle

Most offensive tools (Cobalt Strike, Meterpreter, custom loaders) operate in user mode. They must evade user-mode EDR hooks, API monitoring, ETW tracing, and memory scanning — all from the same privilege level. This creates an inherent disadvantage:

3. What a Kernel Rootkit Can Do

Nidhogg demonstrates the full range of capabilities available to a kernel-mode rootkit. Each capability maps to a specific kernel mechanism:

4. The Kernel Address Space

On 64-bit Windows, the virtual address space is divided cleanly between user mode and kernel mode:

TextVirtual Address Space (x64 Windows)
=============================================
0x0000000000000000 - 0x00007FFFFFFFFFFF   User space   (128 TB)
  - Per-process, isolated
  - Accessible from ring 3
  - Contains: EXE, DLLs, heap, stack, TEB/PEB

0xFFFF800000000000 - 0xFFFFFFFFFFFFFFFF   Kernel space (128 TB)
  - Shared across all processes
  - Accessible ONLY from ring 0
  - Contains: ntoskrnl, HAL, kernel drivers,
    pool allocations, system PTEs, EPROCESS/ETHREAD

Key insight: kernel address space is shared across all processes. When Nidhogg's driver modifies an EPROCESS structure, that change is visible system-wide because every process maps the same kernel memory. There is no per-process isolation in kernel space.

5. Driver Signature Enforcement (DSE)

Microsoft introduced Driver Signature Enforcement to prevent unauthorized kernel code from loading. Starting with Windows Vista x64, all kernel drivers must be signed with a valid certificate:

DSE is enforced by the Code Integrity (CI) module (ci.dll). When NtLoadDriver is called, CI validates the driver's Authenticode signature against the minimum signing level before allowing the image to load into kernel space.

C// Simplified view of what CI checks during driver load
// ci!CiValidateImageHeader is called from ntoskrnl
NTSTATUS CiValidateImageHeader(
    PVOID ImageBase,
    ULONG ImageSize,
    ULONG ImageSigningLevel,  // Minimum required level
    // ... additional parameters
);
// Returns STATUS_INVALID_IMAGE_HASH if signature check fails

6. Bypassing DSE: Attack Paths

Despite DSE, attackers have several paths to load unsigned kernel drivers. These are the realistic vectors that red teams use:

7. HVCI and Kernel Code Integrity

Hypervisor-protected Code Integrity (HVCI), part of Virtualization-Based Security (VBS), adds a second layer of defense beyond DSE:

TextWithout HVCI:
  Ring 0 code can allocate RWX kernel memory and execute arbitrary code

With HVCI:
  The hypervisor (ring -1) enforces W^X in kernel space
  - Pages can be writable OR executable, never both
  - New kernel code pages must be validated by Secure Kernel
  - Even a kernel driver cannot simply allocate and run shellcode

HVCI significantly raises the bar for kernel rootkits. On systems with HVCI enabled, manually mapped drivers (like kdmapper output) may fail because the hypervisor blocks execution of unsigned kernel pages. However, many enterprise environments still lack HVCI, and older Windows 10 builds do not enable it by default.

8. PatchGuard (Kernel Patch Protection)

PatchGuard (KPP) is a kernel integrity monitoring system that periodically checks critical kernel structures for unauthorized modifications:

When PatchGuard detects a modification, it triggers CRITICAL_STRUCTURE_CORRUPTION (bug check 0x109), crashing the system with a blue screen. This means Nidhogg must carefully avoid techniques that PatchGuard monitors. For example, Nidhogg uses DKOM (modifying linked list pointers) rather than SSDT hooking, because SSDT modifications are reliably detected by PatchGuard. However, DKOM is not guaranteed to be PatchGuard-safe: PatchGuard's monitoring scope varies between Windows builds and can include checks on kernel data structures like EPROCESS linked lists. Nidhogg's own documentation acknowledges that PatchGuard can potentially detect DKOM modifications. In practice, DKOM is less likely to be caught than SSDT hooking, but it is not undetectable.

9. Nidhogg Architecture Overview

Nidhogg is structured as two components that communicate via IOCTLs:

The user-mode client sends commands (hide process, protect file, disable ETW, etc.) through DeviceIoControl calls. The kernel driver receives these as I/O Request Packets (IRPs) with IOCTL codes, executes the requested operation using kernel APIs and data structure manipulation, and returns the result. This architecture is covered in detail in Module 2 (driver basics) and Module 8 (full IOCTL table).