Skip to content

Primitive Matrix

Exploitation techniques do not exist in a vacuum. Each one operates within a window defined by the Windows version that introduced the kernel structure it depends on and the mitigation that eventually blocked or constrained it. GDI bitmap abuse worked from Windows 7 through RS3. WNF state data exploitation emerged in RS5 and was largely superseded by I/O Ring on Windows 11. Token swapping has worked since Windows NT and still works today. Understanding these windows is critical for exploit development, for defense prioritization, and for assessing the real-world impact of a vulnerability on a specific target environment.

This matrix tracks the availability of each major exploitation primitive across Windows builds, identifies which mitigations block them, and maps the recommended exploitation chains for current systems. The goal is not to provide a step-by-step exploitation guide, but to give defenders and researchers a clear picture of what works where, and what has been effectively mitigated.

Version Compatibility Matrix

Primitive Technique Min Build Max Build Blocked By Replacement
Pool Spray (Palette/Bitmap) Spray pool with GDI objects to control allocation layout pre-RS1 RS3 (10.0.16299) Type Isolation prep, pool layout changes Named Pipe Attributes spray
GDI Palette/Bitmap R/W Abuse GDI object headers for kernel read/write pre-RS1 RS4 (10.0.17134) GDI object type isolation WNF State Data, Pipe Attributes
WNF State Data Corrupt _WNF_STATE_DATA for relative R/W RS5 (10.0.17763) 21H2 (10.0.22000) Pool hardening improvements I/O Ring
Named Pipe Attributes Spray pipe attributes in paged/nonpaged pool RS5 (10.0.17763) Current (still works) Partially mitigated by pool hardening Still primary for pool spray
I/O Ring R/W Abuse I/O Ring structures for arbitrary kernel R/W 21H2 (10.0.22000) Current No full block yet Primary kernel R/W on 22H2+
PTE Manipulation Modify page table entries to remap physical memory All versions Current Requires existing ARW primitive Still works
Token Swapping Overwrite process token pointer for privilege escalation All versions Current No direct mitigation Still works (offsets change per build)
KUSER_SHARED_DATA Abuse shared kernel/user page for code exec or data All versions Current SMEP blocks code execution variant Data-only variant still works
Previous Mode Manipulation Flip thread PreviousMode to bypass access checks All versions Current HVCI makes harder Still works on non-VBS systems
ACL/SD Manipulation Overwrite security descriptors for privilege escalation All versions Current No direct block Still works
Bit-Manipulation Primitives Use RtlSetBit/RtlClearAllBits through hijacked callbacks All versions Current kCET constrains delivery, not function Still works through valid kCFG targets

The most striking pattern in this matrix is the durability of data-only primitives. Token swapping, PreviousMode manipulation, ACL/SD corruption, and PTE manipulation have all survived every mitigation cycle because they target data structures, not code paths. Microsoft's mitigations have been highly effective at blocking code execution primitives (function pointer hijacking, ROP chains, shellcode staging), but the data plane remains largely unprotected. The only mitigation that can protect kernel data structures is Kernel Data Protection (KDP) through VBS, and its deployment remains limited.

Mitigation Impact Summary

The table below maps each major kernel mitigation to the primitives it blocks and, equally important, the primitives it leaves unaffected. This dual view reveals the gaps that modern exploits navigate.

Mitigation Introduced Primitives Blocked Primitives Unaffected
SMEP Windows 8+ (hardware) KUSER_SHARED_DATA code exec Token Swap, PTE, I/O Ring, Named Pipe, ACL
SMAP Windows 10 RS1+ (hardware) Direct user-page access from kernel I/O Ring, Token Swap, PTE, ACL
kCFG Windows 10 RS2+ Indirect call hijacking Data-only primitives (Token, ACL, PTE)
kCET Windows 11 22H2+ (hardware) ROP/JOP chains, shadow stack bypass Data-only primitives
HVCI Windows 10+ (opt-in), 11 default on RWX kernel pages, Previous Mode (harder) Token Swap, ACL, data-only attacks
Pool Hardening Windows 10 21H1+ Pool overflow adjacent corruption (harder) I/O Ring, PTE, Token (via other primitives)
Type Isolation Windows 10 RS3+ GDI Palette/Bitmap pool spray Named Pipe spray, I/O Ring
Secure Pool Windows 11 22H2+ Pool metadata corruption I/O Ring, data-only attacks

The "Primitives Unaffected" column tells the real story. Every mitigation leaves token swapping and ACL manipulation untouched. HVCI, which is often cited as the strongest kernel protection, blocks code execution but has no effect on data-only attacks. Pool hardening makes the initial corruption step harder but does not protect the exploitation endgame. The result is that modern exploit chains simply route around mitigations: they use data-only corruption primitives (I/O Ring, pipe attributes) to reach data-only exploitation targets (tokens, security descriptors).

The following chains represent the state of the art for kernel exploitation on current Windows builds. They are organized by the mitigation environment, since the available mitigations determine which primitives are viable.

Non-VBS Systems

On systems without Virtualization-Based Security, the full range of data-only primitives is available without additional constraints. I/O Ring provides the standard kernel R/W primitive on Windows 11. Token swapping is the simplest privilege escalation path once R/W is established. PTE manipulation remains an option for scenarios requiring code execution (such as loading unsigned kernel code).

The typical chain flows from vulnerability trigger, through pool corruption, to I/O Ring R/W, to token swap. The pool corruption step uses named pipe objects or pipe attributes for spray, depending on the pool type. The information leak for KASLR bypass comes from a relative read through the corrupted spray object.

VBS/HVCI-Enabled Systems

HVCI blocks unsigned code execution in the kernel, which means function pointer corruption cannot be used as an intermediate step, and PTE manipulation for code execution is constrained by hypervisor-enforced W^X. The exploitation chain must be entirely data-only from start to finish.

I/O Ring exploitation is fully HVCI-compatible because it uses only data corruption and standard kernel code paths. Token swapping and ACL manipulation are similarly unaffected. The chain remains: vulnerability trigger to pool corruption to I/O Ring R/W to data-only escalation (token swap or ACL manipulation). The only difference from non-VBS systems is that certain initial corruption paths (those that go through function pointer hijacking) are blocked, narrowing the set of vulnerabilities that can reach the I/O Ring corruption step.

Bit-manipulation primitives deserve special mention here. Functions like RtlSetBit and RtlClearAllBits are valid kCFG targets, meaning they can be called through corrupted indirect call sites even on HVCI-enabled systems. This provides a data-only path from UAF callback hijacking to privilege escalation without requiring traditional shellcode or ROP chains.

Legacy Systems (pre-21H2)

Older Windows 10 builds without I/O Ring availability and without Segment Heap pool hardening allow WNF state data or Named Pipe Attributes as corruption targets. These systems are increasingly rare in enterprise environments but remain common in IoT, embedded, and industrial contexts running Windows 10 LTSB/LTSC.

The chain on these systems typically uses WNF state data or pipe attribute corruption for an initial R/W primitive, followed by token manipulation or PTE modification for escalation. The absence of pool hardening makes spray more reliable, and the absence of I/O Ring means the exploit must use older R/W techniques that may be less stable.

Cross-References