Overview

One question

When an attacker holds a kernel read or write primitive on a specific Windows build and CPU, which defenses still hold? Every page on this site answers one half of that question or the other. The halves are called Getting in and What stops them, and the hinge between them is the primitive itself.

FIG_001: The two halves, and the hinge

<!-- MEANS -->
<text class="ks-label" x="30" y="34">GETTING IN &#183; HOW THE ACCESS IS OBTAINED</text>
<rect class="ks-box" x="30" y="48" width="300" height="34"/>
<text class="ks-annotation" x="45" y="69">Driver types &#183; 12 families</text>
<rect class="ks-box" x="30" y="92" width="300" height="34"/>
<text class="ks-annotation" x="45" y="113">Attack surfaces &#183; 9 entry points</text>
<rect class="ks-box" x="30" y="136" width="300" height="34"/>
<text class="ks-annotation" x="45" y="157">Vulnerability classes &#183; 10</text>
<rect class="ks-box" x="30" y="180" width="300" height="34"/>
<text class="ks-annotation" x="45" y="201">Case studies &#183; 157 CVEs, 64 drivers</text>

<!-- feed into the hinge -->
<path class="ks-arrow" d="M330 65 C 372 65 372 150 400 150"/>
<path class="ks-arrow" d="M330 109 C 372 109 372 150 400 150"/>
<path class="ks-arrow" d="M330 153 L400 150"/>
<path class="ks-arrow" d="M330 197 C 372 197 372 150 400 150"/>
<path class="ks-arrow" d="M394 145 L404 150 L394 155 Z" fill="currentColor"/>

<!-- the hinge -->
<rect class="ks-box" x="404" y="118" width="122" height="64" stroke-width="2"/>
<text class="ks-label" x="465" y="142" text-anchor="middle">KERNEL</text>
<text class="ks-label" x="465" y="156" text-anchor="middle">READ / WRITE</text>
<text class="ks-annotation" x="465" y="172" text-anchor="middle">21 primitives</text>

<!-- hinge feeds targets -->
<path class="ks-arrow" d="M526 150 L566 150"/>
<path class="ks-arrow" d="M560 145 L570 150 L560 155 Z" fill="currentColor"/>

<!-- TARGETS -->
<text class="ks-label" x="570" y="34">WHAT STOPS THEM &#183; WHAT IT DEFEATS</text>
<rect class="ks-box" x="570" y="92" width="300" height="52"/>
<text class="ks-annotation" x="585" y="112">Kernel layer &#183; 19 defenses</text>
<text class="ks-annotation" x="585" y="130">DSE, HVCI, kCET, KDP, HLAT, KASLR</text>
<rect class="ks-box" x="570" y="156" width="300" height="52"/>
<text class="ks-annotation" x="585" y="176">User layer &#183; 11 defenses</text>
<text class="ks-annotation" x="585" y="194">PPL, LSA, ETW-Ti, EDR, WDAC, SAC, UAC</text>

<!-- out of reach -->
<rect class="ks-box" x="570" y="230" width="300" height="34" stroke-dasharray="4 3"/>
<text class="ks-annotation" x="585" y="251">VTL1 &#183; Credential Guard, HyperGuard: out of reach</text>
<line class="ks-line" x1="465" y1="182" x2="465" y2="247" stroke-dasharray="3 3"/>
<line class="ks-line" x1="465" y1="247" x2="564" y2="247" stroke-dasharray="3 3"/>
<text class="ks-annotation" x="470" y="240">no path</text>

One real example, start to finish

In 2024 the Lazarus Group did not bring a vulnerable driver with them. They used one that was already on every Windows machine: the kernel driver behind AppLocker, a security feature.

The bug

One control code had no permission check

Any process could open the device and send it. The handler then trusted a pointer the caller supplied, without checking it pointed anywhere sane.

What it gave

Read and write anywhere in kernel memory

No race to win, no memory to groom, no address to leak first. Send the request, choose the address.

What that beat

The antivirus, the credential store, the audit trail

Each of those is guarded by a decision recorded in kernel memory. Once you can edit that memory, you are editing the decision itself rather than defeating it.

What it did not

Credential Guard, on the same machine, untouched

Windows keeps those secrets somewhere the kernel itself cannot reach. Total control of the kernel buys nothing there.

Bug, then capability, then what the capability is worth. That shape repeats across 157 real cases, and learning to read it is what the path teaches. Read this one in full: CVE-2024-21338.

Getting in: the means

How a standard-user foothold becomes a kernel read/write primitive. Read in order, each stage narrows from landscape to capability.

Driver Types
Identify the kernel component, whether file system, network stack, Win32k, core kernel, vendor utility or GPU, then understand its role, IRP patterns and historical vulnerability profile. 12 categories covering 64 unique drivers.
Attack Surfaces
Map how user-mode code reaches the driver: IOCTL handlers, filesystem IRPs, ALPC, shared memory. This determines what an attacker can control.
Vulnerability Classes
Classify the bug as buffer overflow, type confusion, TOCTOU or use-after-free, then understand the corruption it enables. 10 classes with typical primitives gained.
Primitives
Convert the bug into a capability: arbitrary read/write, pool spray, token swap. 21 technique pages split between arb R/W primitives and exploitation building blocks.
Case Studies
Walk the full chain for 157 real CVEs: root cause, exploitation path, patch analysis, detection rules. 58 exploited in the wild. The developer highlights regroup these by developer and chain rather than by bug.

What stops them: the targets

The other half starts where the primitive exists. For every defense on the roster, a maintained inventory of what a kernel primitive does and does not defeat against it.

The defense roster
30 defenses, split by the layer of the asset protected: 19 kernel layer, 11 user layer. 18 have a reviewed bypass inventory today; the rest are tracked as planned, so coverage is a number that moves rather than a claim.
The bypass matrix
Every registered inventory re-evaluated against one platform selector: same Windows version, same HVCI checkbox, different silicon, different answers. Each verdict carries layer, asOf and a basis tier: tested, cited, or inferred.

What still works, as the platform hardens

{% end

How to read the two page types

A case study runs bug, then capability, then what the capability is worth: the root cause with build numbers, the primitive it converts into, the defenses it walked past, the patch, and detection. Start with CVE-2024-21338, the cleanest example in the corpus.

A bypass verdict is never a bare yes or no. It is dated, it names its basis, and it is tied to a build and a CPU feature set. An inferred verdict is a research lead, not a finding. The whole inventory is also published as machine-readable data, JSON regenerated on every deploy.

The corpus

157 CVE case studies · 64 unique drivers · 58 exploited in the wild · 2 remotely exploitable
12 driver type categories · 21 technique pages · 30 defenses on the roster · 49 dated bypass verdicts
1,775 LOLDrivers analyzed · 354 Tier 2 Ghidra confirmed · 80+ AutoPiff detection rules

Where to go next

New here The 7-stage reading path. Each stage ends with a check question, so you can tell whether to move on or reread.

Explore the corpus Interactive dashboard. Search, filter and visualize all 157 CVEs. The heat matrix shows where the bugs cluster.

Researching a specific driver Case studies grouped by driver family, from CLFS through afd.sys to the BYOVD catalogue.

Defending endpoints The bypass matrix answers which controls still bite, per build and per CPU, once an attacker holds a primitive.

Writing or auditing a driver The 6 anti-patterns behind most kernel driver CVEs, with fixes, a checklist, and real CVE citations.

Reference

Tooling for the workflow (static analysis, fuzzing, debugging, patch diffing, AutoPiff), the driver library for BYOVD, LOLDrivers deep analysis and KDU compatibility, and guides for cross-cutting synthesis.

Recent Updates

Date	What's New
2026-09-30	Site-wide redesign around the one-question model: a spine bar on every page names which half you are in, the palette toggle is back, and color in the UI now means status rather than section. Notable Exploits section ships Nightmare-Eclipse and Lazarus/FudModule profiles. The bypass registry is published as machine-readable JSON.
2026-09-04	Every page now shows when it last changed, measured from git rather than asserted. Corpus totals are generated from the data and guarded by a test, after three different figures were live at once.
2026-09-03	Repositioned around the one-question thesis. Navigation regrouped into Getting in and What stops them; new bypass matrix evaluating every inventory against one platform selection; first user-layer defense page, Protected Process Light. Every technique now carries a dated verdict and a basis tier.
2026-03-12	KDU Provider Compatibility and LOLDrivers Deep Analysis updated with full 1,775-driver Tier 2 Ghidra results. 1,404 KDU-compatible (79%), 354 Tier 2 confirmed, 122 confirmed MapDriver candidates with physical + virtual memory primitives reachable from IOCTL handlers. All mitigations, ROP gadgets, and I/O methods scored.
2026-03-01	Backfill: 13 case studies added for 2022--2024 CVEs with published exploit research. CLFS ransomware chain (CVE-2022-24521, CVE-2022-35803, CVE-2023-23376), Project Zero registry audit (CVE-2022-34707, CVE-2023-23420), DEVCORE kernel streaming (CVE-2024-30090, CVE-2024-30084, CVE-2024-38144), activation context bugs (CVE-2022-22047, CVE-2022-41073). Corpus now at 157 CVEs, 58 exploited ITW.
2026-02-28	58 new case studies across afd.sys, clfs.sys, win32k, dwmcore.dll, ntfs.sys, ntoskrnl, plus new deep dives: afd.sys, win32k, ntfs.sys, and new guides: Corpus Analytics, Exploit Chain Patterns, Patch Patterns, Mitigation Timeline.