Skip to content

Exploit Chain Patterns

The 5 recurring chain shapes that turn a kernel bug into SYSTEM -- from initial corruption through privilege escalation.

No kernel vulnerability is useful in isolation. A heap overflow in clfs.sys does not, by itself, grant SYSTEM privileges. It must be converted into a read/write primitive, combined with a KASLR bypass, and directed at a privilege target like a process token. The steps between "trigger the bug" and "spawn a SYSTEM shell" form a chain, and across the 147 CVEs in the KernelSight corpus, these chains follow a small number of recurring patterns. Understanding the patterns matters because it reveals which mitigations affect which stages, where the hardest engineering problems sit, and why certain vulnerability classes are more valuable to attackers than others.

The Meta-Chain

Every kernel exploit in the corpus follows a variation of the same 7-stage progression. Individual stages may be skipped (BYOVD chains skip stages 1-3 entirely because the driver provides the primitive directly), but the underlying shape holds across decades of Windows kernel exploitation.

FIG -- The 7-Stage Kernel Exploitation Pipeline INITIAL CORRUPTION 1 MEMORY CONTROL 2 PRIMITIVE ACQUISITION 3 KASLR DEFEAT 4 PRIVILEGE TARGET 5 ESCALATION 6 POST- EXPLOITATION 7

Not all stages are always needed. BYOVD chains skip 1-3. Some chains skip stage 4 if the primitive doesn't require leaked addresses.

Stage Action Typical Techniques
1. Initial Corruption Trigger the bug Crafted file, IOCTL with bad length, race condition window
2. Memory Control Shape kernel pool layout Pool spray via named pipes, I/O Ring, WNF state data
3. Primitive Acquisition Convert corruption into R/W Corrupt pipe attributes, palette/bitmap objects, I/O Ring buffers
4. KASLR Defeat Leak kernel base or object addresses NtQuerySystemInformation, security descriptor corruption, prefetch side-channel
5. Privilege Target Locate the escalation object Find current process token, PreviousMode field, or EPROCESS
6. Escalation Modify the target Token swap, PreviousMode flip, privilege bit-set, DACL corruption
7. Post-Exploitation Use gained privileges Spawn SYSTEM shell, inject into protected process, deploy payload

The stages map to mitigations in predictable ways. Pool hardening complicates stage 2. KASLR gates stage 4. kCFG/kCET constrain control flow options at stage 3. HVCI prevents code execution at stage 7. Understanding which stage each mitigation targets reveals why data-only attacks that skip the code execution stages have become dominant.

Chain Archetypes

A. File Format Corruption + Pool Spray + Arbitrary Write + Token Swap

This is the classic CLFS exploitation pattern, and the most frequently observed archetype in the corpus. A crafted on-disk structure embeds corrupted offsets that cause the kernel parser to write outside its allocation. Pool spray places a controlled object adjacent to the parser allocation, and the out-of-bounds write corrupts it into an arbitrary read/write primitive.

Flow: Corrupt BLF metadata → trigger reparse → OOB write into adjacent pool → corrupt pipe attribute / WNF / I/O Ring → stable R/W → token swap → SYSTEM

The pattern works because file system and log drivers parse complex on-disk structures in kernel context. The parser trusts on-disk offsets (anti-pattern 3 from Secure Driver Anatomy), and the pool allocator places parser buffers adjacent to attacker-controlled spray objects. The CLFS base log file (BLF) format is particularly rich in exploitable offsets because it stores dozens of pointer-like fields that are validated inconsistently.

CVEs using this pattern:

The same archetype applies beyond CLFS. ntfs.sys (CVE-2025-24993) and fastfat.sys (CVE-2025-24985) follow identical chains where crafted VHD or FAT images trigger kernel heap corruption during mount. Any driver that parses complex on-disk structures is susceptible.

B. Race Condition + UAF + Pool Spray + Bit Manipulation + Token Escalation

This is the most common afd.sys and win32k exploitation pattern. Two threads race to create a use-after-free: one thread frees an object while another still holds a stale pointer. Pool spray reclaims the freed memory with a controlled object, and the stale pointer dereference corrupts it. The complexity lies in winning the race reliably, which often requires thousands of attempts and careful thread scheduling.

Flow: Race two threads → UAF on socket/window object → spray named pipes or palettes into freed slot → build R/W primitive → bit-manipulation or token swap → SYSTEM

CVEs using this pattern:

The bit-manipulation primitive variant (CVE-2026-21241) is particularly important because RtlSetBit and RtlClearAllBits are kCFG-compliant targets. They pass control flow integrity checks that block traditional function pointer overwrites, making this technique viable even on Windows 11 24H2 with full kCFG enforcement.

C. TOCTOU + Controlled Kernel Write + Token Swap

This pattern skips pool spray entirely. The attacker remaps or modifies a user buffer between the kernel's validation read and its use, producing a write to an attacker-chosen kernel address. The kernel validates the data once, the attacker changes it, and the kernel uses the corrupted value.

Flow: Map user buffer → trigger kernel validation → flip buffer contents from another thread → kernel uses corrupted value → write hits attacker-chosen address → token swap → SYSTEM

CVEs using this pattern:

  • CVE-2024-30088 -- ntoskrnl TOCTOU in AuthzBasepCopyoutInternalSecurityAttributes
  • CVE-2024-38106 -- ntoskrnl missing lock around VslpEnterIumSecureMode

This chain is harder to exploit reliably because the race window is narrow. Attackers typically run thousands of attempts, relying on the kernel to stay stable through failed races (a non-trivial assumption for some vulnerability classes). The fix is conceptually simple: capture user data into a kernel buffer in a single copy (see Patch Patterns, pattern 3).

D. IOCTL Auth Bypass + Direct Kernel R/W + Rootkit Deployment

No memory corruption needed. The driver exposes physical memory mapping, MSR access, or another dangerous primitive through an IOCTL that any user can reach. The attacker opens the device, sends a few IOCTLs, and gets full kernel read/write. This is exploitation without an exploit.

Flow: Open device handle → send IOCTL with target address → read/write kernel memory directly → locate EPROCESS → token swap or callback manipulation → deploy rootkit

CVEs using this pattern:

  • CVE-2024-21338 -- appid.sys IOCTL missing access control, Lazarus FudModule rootkit
  • CVE-2021-21551 -- Dell DBUtil arbitrary R/W
  • CVE-2015-2291 -- Intel iqvw64e.sys arbitrary R/W, most-abused BYOVD driver
  • Capcom.sys -- direct ring-0 code execution via MmGetSystemRoutineAddress callback

This is the BYOVD archetype. The driver is the vulnerability. No exploit development needed beyond a client that sends the right IOCTLs. Ransomware groups and APTs routinely drop signed vulnerable drivers to bypass EDR. See BYOVD for the full landscape and LOLDrivers Deep Analysis for the 1,775-driver risk assessment.

E. Arithmetic Primitive + PreviousMode Flip + Full R/W + Token Swap

Built on the smallest possible primitive: a single controlled increment or decrement. The attacker uses it to flip the PreviousMode field in the current thread's KTHREAD structure, turning kernel address-space access checks from enforced to bypassed. With PreviousMode set to KernelMode, ordinary Nt* system calls can read and write arbitrary kernel memory.

Flow: Trigger decrement-by-one → target KTHREAD.PreviousMode → flip from UserMode (1) to KernelMode (0) → use NtReadVirtualMemory/NtWriteVirtualMemory for full R/W → token swap → SYSTEM

CVEs using this pattern:

  • CVE-2025-3464 -- AsIO3.sys auth bypass + ObfDereferenceObject decrement-by-one
  • CVE-2024-26229 -- csc.sys missing access check, used with PreviousMode flip

This archetype is elegant because the primitive needed is minimal. A single controlled decrement converts into full kernel read/write without any pool spray or heap layout control. The PreviousMode manipulation technique turns the smallest possible corruption into the most powerful possible primitive. See also Arb Increment/Decrement.

Terminal Goals

All five chain archetypes converge on the same small set of escalation targets. The terminal goal determines what the attacker gains and what mitigations remain relevant.

  1. Token swap -- Copy the SYSTEM process token into the current process. The most common terminal goal, used in approximately 70% of the corpus. See Token Swapping.

  2. Privilege bit-set -- Set SE_DEBUG_PRIVILEGE or SE_ASSIGNPRIMARYTOKEN_PRIVILEGE bits directly in the token. Used when the attacker wants to avoid replacing the entire token, perhaps to maintain the identity of the original process while gaining specific elevated capabilities.

  3. PreviousMode flip -- Change KTHREAD.PreviousMode from UserMode to KernelMode. Gives the attacker full kernel read/write through ordinary system calls, which is often more useful than a SYSTEM shell because it provides persistent kernel access without creating suspicious processes. See PreviousMode Manipulation.

  4. DACL corruption -- Null out the security descriptor on a protected process or system object. Used in CVE-2026-21241 via SepMediumDaclSd corruption to unlock KASLR information APIs. See ACL / SD Manipulation.

The convergence on these four targets is not accidental. Each one modifies kernel data without requiring code execution, making them viable under the full set of modern mitigations (SMEP, SMAP, kCFG, kCET, HVCI). This is why data-only protections like KDP and Secure Pool represent the most impactful future hardening: if tokens and security descriptors are protected by the hypervisor, the terminal goals that every exploit chain converges on become unreachable.

Cross-References