Parag Mali - tag: project-zero

The Registry Adventure: How One Researcher Read 100,000 Lines of Windows Kernel C and Found 50 Bugs

noreply@paragmali.com (Parag Mali) — Sun, 24 May 2026 00:00:00 GMT

Between May 2022 and December 2023, Mateusz Jurczyk of Google Project Zero manually audited the Windows kernel registry parser and filed 39 bug reports under Project Zero's 90-day disclosure deadline plus 20 low-severity reports without deadline, which Microsoft serviced as 50 CVEs total (44 from the 90-day cohort and 6 more in a March 2024 bulletin). The bugs share a root cause: a thirty-year-old hybrid on-disk-and-in-memory format with a deterministic, unrandomized cell allocator that Microsoft cannot redesign without breaking backward compatibility to Windows NT 4.0. The methodology pivot is the story. Jurczyk started with a coverage-guided fuzzer, found one bug, then put the fuzzer down and read 100,000 lines of kernel C for twenty months. What the audit implies for the rest of the Windows kernel is the open question the article ends on.

1. I Loaded a Registry Hive From a Network Share and the Kernel Crashed

In May 2022, Mateusz Jurczyk pointed a coverage-guided fuzzer at the Windows registry. Within days the fuzzer crashed the kernel and produced CVE-2022-35768. Twenty months later, when he stopped, Jurczyk had filed thirty-nine bug reports against the same subsystem, Microsoft had assigned fifty CVEs to his name, and the fuzzer was sitting unused. Somewhere in those first few days, Jurczyk had realised that the bugs he actually wanted were ones a fuzzer could not see [@pz1-registry-adventure-1].

The threat model is almost too small to fit on a slide. An unprivileged process running at Medium Integrity Level calls RegLoadAppKey with the path of a file the attacker controls. The kernel opens the file, runs its in-house binary parser on the bytes, and exposes the resulting tree of keys back to the caller through a private handle. Microsoft's own documentation describes the surface this way: the hive becomes a private namespace reachable only through that handle, but "the registry will prevent an application from accessing keys in this hive using an absolute path" [@ms-regloadappkey]. The handle is sandboxed. The parser, which is the interesting part, is not. It runs in the kernel with attacker-supplied input, and it has been doing so since Windows Vista.

A file-and-in-memory tree of registry keys and values, encoded in Microsoft's regf binary format and operated on by the Windows kernel's Configuration Manager. Hives live on disk as `*.dat` files (plus `.log` and `.alt` companions) and are loaded into the kernel's address space when an application or the operating system opens them [@ms-registry-hives]. Medium Integrity Level: the integrity label an ordinary logged-in Windows user runs at. Crossing from Medium IL to SYSTEM is what a kernel local privilege escalation does. The class of bug this article is about reliably accomplishes that crossing from an attacker-supplied file.

The fifty CVEs that Jurczyk's audit produced are not a uniform pile. Most of them are kernel local privilege escalations (LPEs); a handful are information disclosures; one is a denial of service [@pz1-registry-adventure-1]. The seventeen that matter for this article are the cohort Jurczyk later catalogued in his Project Zero post on practical exploitation: a tight set of memory-corruption bugs that share a single root cause and a single exploitation primitive, which he named hive-based memory corruption [@pz8-registry-adventure-8].

flowchart TD A["Medium-IL user process"] --> B["RegLoadAppKey API"] B --> C["NtLoadKeyEx system call"] C --> D["Configuration Manager dispatch"] D --> E["Hv* hive parser"] E --> F["Cell allocator and KCB tree"] F --> G["Mapped section pages -- kernel address space"]

Two questions are doing all the work in this article. Why is a thirty-year-old binary parser running in the Windows kernel willing to accept arbitrary input from unprivileged users? And why did it take a single researcher twenty months to map the consequences? The first question is about Microsoft and design. The second is about Jurczyk and method. To take either one seriously, we have to start at the very beginning -- with Windows 3.1.

2. Why There Is a Hive Parser in the Kernel

In 1992 the registry was 64 kilobytes. Windows 3.1 shipped with a single file at C:\WINDOWS\REG.DAT, encoded in a small custom format whose magic bytes spelled SHCC3.10. It held one top-level key, no named values, and existed solely to register OLE objects and shell file-type associations [@pz2-registry-adventure-2]. The first regedit.exe shipped alongside it. There was no security descriptor, no recovery story, and no kernel involvement. You could fit the whole thing in the L2 cache of a 2026 laptop.

Windows NT 3.1, released in July 1993, swept that design away and introduced something different. The new format was called regf, and the design decision that has determined the next thirty-three years of Windows kernel security was made here: the on-disk format and the in-memory format are the same format. Jurczyk's blog post on the regf file format states this plainly: "the regf format aims to bypass the reparsing step -- likely to optimize the memory/disk synchronization process -- and reconcile the two types of data encodings into a single one... This unique approach comes with its own set of challenges, and has been a contributing factor in a number of historical vulnerabilities" [@pz5-registry-adventure-5].

Microsoft's binary registry file format, introduced in Windows NT 3.1 (1993) and stabilized at v1.3 in NT 4.0 (1996). Later versions (v1.4 Whistler beta, v1.5 XP, v1.6 Win10 AU) layer features on top but all remain cross-compatible with the v1.3 baseline. The same format encodes a hive on disk and in kernel memory; there is no separate "loaded" representation [@pz5-registry-adventure-5]. Microsoft has never published an official regf specification [@pz5-registry-adventure-5].

The motivation was reasonable. NT was a multi-user, securable, network-capable operating system targeting servers; its configuration store needed access control, transactional recovery, and the ability to grow well past 64 KiB. Reusing the same byte layout for disk and memory meant a hive could be loaded by mapping or copying its file image, modified in place, and flushed back without a serialization step.

Pre-release builds used regf v1.0; the first shipping NT used v1.1; NT 3.5 and 3.51 used v1.2 [@pz2-registry-adventure-2]. The Win9x consumer line went a different direction entirely, with an incompatible format called CREG that never made it into the NT lineage and quietly died with Windows Me.Windows 95, 98, and Me used a completely incompatible CREG format that did not survive into NT. The modern registry inherits nothing from the Win9x line; every memory corruption bug Jurczyk found descends from the NT 3.1 decision.

The next stabilization happened on July 29, 1996. Windows NT 4.0 (whose pre-RTM development builds had introduced v1.3 in 1995) froze the backward-compatibility baseline at regf v1.3, added a "fast leaves" optimization for subkey lookups, and locked in the binary layout that the modern Windows kernel still reads thirty years later. Later versions layered features on top -- v1.4 (Whistler beta, big values), v1.5 (Windows XP, 2001, hash leaves), and v1.6 (Windows 10 Anniversary Update, 2016, layered keys) -- but every one of them remains cross-compatible with v1.3-aware parsers, and v1.3 itself still encodes a number of Windows 11 hives [@pz5-registry-adventure-5].

Microsoft's own documentation for RegSaveKeyExA describes REG_STANDARD_FORMAT as "the only format supported by Windows 2000," meaning that hives written by Windows 2000 and later, in the default format, are interchangeable with hives produced by Windows NT 4.0 [@ms-regsavekeyex]. A hive file authored on NT 4.0 in 1996 will still mount on Windows 11 in 2026. That backward compatibility is not an accident; it is a load-bearing requirement of system-image management, forensics, and third-party installers.

gantt title Registry format evolution dateFormat YYYY axisFormat %Y section Win 3.x reg.dat (SHCC3.10) :1992, 1993 section NT 3.x regf v1.0 to v1.2 :1992, 1996 section NT 4.0+ regf v1.3 (standard) :1996, 2026 section XP regf v1.5 (hash leaves) :2001, 2026 section Vista RegLoadAppKey + KTM :2006, 2026 section Win 8.1 LOG1 and LOG2 logging :2013, 2026 section Win 10 RS4 Section-backed hives :2018, 2026 section Win 10 AU regf v1.6 (layered keys) :2016, 2026

Ten years later, in November 2006, Windows Vista added the second design decision that completes the threat model. RegLoadAppKey shipped as a public Win32 API, allowing an unprivileged application to load an arbitrary hive file as a private "application hive" reachable only through the returned handle [@ms-regloadappkey]. The motivation was legitimate; per-application configuration sidecars are a reasonable feature.

The consequence was that the kernel-mode regf parser, frozen at v1.3 a decade earlier and unchanged in any of its load-bearing routines, was now reachable from Medium IL with no special privileges. Jurczyk's introduction to the series says it plainly: "arbitrary registry hives can be loaded from disk without any special privileges via the RegLoadAppKey API (since Windows Vista)" [@pz1-registry-adventure-1].

A Win32 API introduced in Windows Vista (2006) that lets an unprivileged process load an arbitrary hive file as a private "app hive," running the full kernel-mode regf parser on attacker-supplied bytes. Microsoft documents the API as one that "loads the specified registry hive as an application hive" reachable only through a private handle; the parser itself is not sandboxed [@ms-regloadappkey].

With the parser reachable from low privilege and the format frozen for thirty years, the only question left was who would notice.

3. Prior Attempts: The "Fuzzed Precisely Once" Misconception

Before we go further, a fact you may have heard in a conference Q&A: the Windows registry is "the most-fuzzed subsystem in Windows," "fuzzed precisely once," by one person. It is not true. The registry has been poked at, in one form or another, since 1996. None of those efforts found the bug class that Jurczyk would eventually name -- but that is a different statement, and the difference is the point of this section.

The first instrument to touch the registry from outside Microsoft was Mark Russinovich and Bryce Cogswell's RegMon, released in 1996 as a Sysinternals utility. RegMon was a kernel driver that intercepted every registry call and surfaced the path, type, process identifier, and result to a user-mode console. It was operational tooling, not a bug-finding tool. Microsoft's own page on the modern successor, Process Monitor, attributes the lineage to Russinovich and notes that Procmon "combines the features of two legacy Sysinternals utilities, Filemon and Regmon" [@ms-procmon]. RegMon made the registry observable from outside the kernel. It could not see corruption inside a hive.

The next wave came from forensics. Microsoft never published a regf specification, so the digital-forensics community reverse-engineered one. Timothy D. Morgan's regfi paper appeared at DFRWS in 2009. Joachim Metz's libregf project published its first format-spec document in July 2009 and has been updated continuously through 2026 [@libregf-spec]. Maxim Suhanov's regf specification covers, among other things, the old single-.log dirty-vector recovery format and the new two-file LOG1/LOG2 layout introduced in Windows 8.1 [@msuhanov-spec]. These were user-space parsers built to mount hive files for evidence extraction. They exercised the format from the outside. They never touched the kernel parser.

A separate research line, in parallel, pursued the layer above the parser. James Forshaw of Project Zero spent years hunting capability and access-control bugs in the registry's name-resolution and permission logic -- registry symbolic links, virtualization quirks, sandbox-escape paths that ride on registry redirection. Jurczyk's PZ #4 covers some of this surface in passing, noting that the registry has at least four distinct ways in which "access to a registry key can be transparently redirected to another path" [@pz4-registry-adventure-4]. These were logic bugs, not memory-corruption bugs. The parser was not the target.

Then, in 2016, Jurczyk and Forshaw collaborated on a black-box bitflipping fuzzing pass against RegLoadKey and RegLoadAppKey. Jurczyk acknowledges the collaboration directly in his retrospective: "I was also somewhat familiar with basic harnessing of the registry, having fuzzed it in 2016 together with James Forshaw" [@pz1-registry-adventure-1]. The cohort produced a handful of registry bug reports filed as Project Zero issues #873, #874, #876, and #993.

It did not find the hive-memory-corruption class. The reason is the same one that would defeat the 2022 fuzzer: random byte flips on a hive file produce a malformed-but-rejected hive far more often than they produce one that passes base-block validation, enters the parser proper, and exercises an interesting bug.Per-issue contents of the 2016 cohort are not anonymously fetchable; the Project Zero tracker now lives at project-zero.issues.chromium.org and redirects unauthenticated requests to a Google sign-in page [@pz-tracker-root]. The cohort's existence is primary-source-confirmed by Jurczyk's reference in PZ #1.

The hive binary format is not very well suited for trivial bitflipping-style fuzzing, because it is structurally simple, and random mutations are much more likely to render (parts of) the hive unusable than to trigger any interesting memory safety violations. -- Mateusz Jurczyk, *The Windows Registry Adventure #1* [@pz1-registry-adventure-1]

In early 2022, Jurczyk made a more serious attempt. He built a coverage-guided Bochs-based kernel fuzzer, the same lineage as his earlier Bochspwn work, and pointed it at the kernel's hive-loading path. Within days the harness produced its first registry kernel bug, filed as Project Zero issue #2299 and assigned CVE-2022-35768 by Microsoft. The fuzzer worked. It just did not scale to the bug class Jurczyk actually wanted, which is the part of the story that matters.

A frequent third-party confusion is worth naming and dispatching here. Bochspwn Reloaded is not the registry-research tool. The repository's own README describes the goal as detecting "the disclosure of uninitialized kernel stack/heap memory," not memory corruption, and reports "over 70 bugs in the Windows kernel" found by the tool in 2017 and early 2018 [@bochspwn-reloaded-repo]. The 2018 white paper makes the same scope clear; the project's technical content is about shadow-memory representation and tainting stack frames and pool allocations to catch infoleaks [@bochspwn-reloaded-paper]. The 2022 Bochs-based registry harness is a separate, unreleased instrument sharing the lineage but not the codebase.

A 2018 Bochs-based Project Zero tool by Mateusz Jurczyk for detecting uninitialized kernel memory disclosures via taint tracking [@bochspwn-reloaded-repo]. *Not* the registry-audit instrument. The 2022 coverage-guided Bochs registry harness is a separate, unreleased tool that shares Bochspwn's general design but is not the public Bochspwn Reloaded repository. flowchart LR A["RegMon (1996)
Operational visibility"] --> B["Forensic parsers
regfi, libregf, msuhanov
2008 to present"] B --> C["Forshaw logic bugs
Sym-links, virtualization
2014 to present"] C --> D["Jurczyk-Forshaw fuzz
Bitflipping RegLoadKey
2016"] D --> E["Bochs coverage fuzz
One good bug
2022"] E --> F["Jurczyk manual audit
50 CVEs
2022 to 2023"]

Every prior attempt had hit the same ceiling. The bug class lived in the code, not in the file. And the code had not yet been read.

4. Six Generations of Hardening Without Redesign

Between 1992 and 2018, Microsoft shipped six generations of registry changes. Not one of them redesigned the parser. Every generation added a feature, hardened a recovery path, lifted a scale limit, or shifted a memory model. Each of those changes also created new surface for the next decade's attackers. The cell allocator at the heart of the format has been substantively the same routine for twenty-five years.

The table below collapses Stage 2's defensive arc into one view. Each row is a generation; the "Surface effect" column captures the bug class that became reachable as a side effect of the improvement.

Gen	Year	What was added	Surface effect
A-1	1992	`reg.dat` / SHCC3.10, 64 KiB OLE database	None in the kernel; user-mode only [@pz2-registry-adventure-2]
A-2	1993	regf v1.0/v1.1, hybrid on-disk and in-memory	Every memory-corruption bug class to follow [@pz5-registry-adventure-5]
A-3	1996	regf v1.3 lock-in, fast-leaves optimization	30-year backward compatibility freezes the parser [@ms-regsavekeyex]
A-3b	2001 / 2016	regf v1.5 (XP, hash leaves), v1.6 (Win10 AU, layered keys)	New features, same v1.3-cross-compatible parser core [@pz5-registry-adventure-5]
A-4	2006	`RegLoadAppKey`, KTM transactions	Parser becomes reachable from Medium IL with no privileges [@ms-regloadappkey]
A-5	2013	LOG1/LOG2 incremental write-ahead logging	New log-replay path becomes attacker-influenceable [@pz5-registry-adventure-5]
A-6	2018	Section-backed hive mapping	Pages become pageable; double-fetch class enabled [@pz5-registry-adventure-5]

Each row deserves a sentence. A-1 is the registry's prehistory; nothing here lives in the kernel, but the hierarchical key/value mental model is established. A-2 is the load-bearing decision: hybrid on-disk and in-memory format, modified in place [@pz5-registry-adventure-5]. A-3 is the moment Microsoft signed a thirty-year contract; the format defined by REG_STANDARD_FORMAT is binary-compatible with NT 4.0 [@ms-regsavekeyex].

A-3b is the format-level feature layering done since: v1.5 (Windows XP, 2001) added hash leaves to speed up large subkey lookups, and v1.6 (Windows 10 Anniversary Update, 2016) added layered keys for differencing hives; both stay cross-compatible with v1.3-aware parsers, and v1.3 still encodes a number of Windows 11 hives [@pz5-registry-adventure-5]. A-4 is the entry-point change: RegLoadAppKey and the Kernel Transaction Manager arrive together in Vista, and both are now attacker-reachable [@ms-regloadappkey].

A-5 introduces the new log format; PZ #5 describes "incremental logging added in Windows 8.1" as one of the two big runtime-recovery overhauls of the modern era [@pz5-registry-adventure-5]. A-6 is the section-backed mapping shipped in Windows 10 RS4 (April 2018), and is the change that makes a hive on an SMB share into a moving target -- hive pages become pageable, and a page that was validated on load can be evicted and re-read with different contents [@pz5-registry-adventure-5].Some Windows 11 system hives, such as UsrClass.dat under HKU\<SID>_Classes, are still written in regf v1.3 -- a format frozen in 1996. The backward-compatibility freeze is not a hypothetical concern [@pz5-registry-adventure-5].

The unit of allocation inside a hive. A length-prefixed chunk of bytes; positive prefix means the cell is free, negative prefix means it is allocated, and the absolute value of the prefix is the size in bytes (multiples of eight). Cells are the building blocks of keys, values, security descriptors, and index nodes [@msuhanov-spec]. Key Control Block: the in-memory kernel object that represents an open registry key. It holds the cell index of the on-disk key node, a parent pointer, a refcount, and a per-key synchronization primitive [@pz6-registry-adventure-6]. The KCB tree is the live representation of every currently-open registry key.

Note: Each generation added new mitigation, new performance, or new functionality. None redesigned the cell allocator, the cell-index-to-virtual-address translation, or the hybrid on-disk-and-in-memory layout. Six generations of mitigation; one unmoved load-bearing routine.

Mapping the result is helpful before we get to the audit. Here is what a hive looks like in the 2025-era kernel from the bytes on disk up to the kernel-object tree that user-mode code touches.

flowchart TD A["Hive file on disk
REGF base block + HBINs"] --> B["Memory-mapped section
pageable pages"] B --> C["_HHIVE structure
0x600 bytes, hive descriptor"] C --> D["_CMHIVE structure
0x12F8 bytes, kernel state"] D --> E["Cell map
cell-index translation"] E --> F["Hv* allocator
HvAllocateCell, HvFreeCell"] F --> G["KCB tree
open keys in kernel memory"] G --> H["User-mode handles via NtCreateKey"]

The diagram is not a model; it is the structure. PZ #6 documents the exact sizes: _CMHIVE is 0x12F8 bytes and contains an embedded _HHIVE of 0x600 bytes at offset zero [@pz6-registry-adventure-6]. None of these objects existed in NT 3.1; what existed was the bottom three layers and a simpler kernel-side wrapper. The architecture grew. The cell allocator did not.

By 2018 the parser had been substantively unchanged for twenty-five years, and nobody had read all of it.

5. The Pivot: Audit, Not Fuzz

Return to May 2022, but now with the full context loaded. Six generations of hardening have created a thirty-year-old attack surface. Forty years of forensic and security research have not penetrated the parser. Jurczyk is sitting at his desk with a working coverage-guided Bochs harness and one good registry bug, and instead of letting the fuzzer run for another six months, he stops.

The detective work that produced the stop is documented in the introduction to the series. Jurczyk noticed two facts that together amount to a methodology critique.

First, the regf format is "structurally simple" in the sense that bitflipping a random byte usually produces an invalid base-block checksum, an out-of-range cell offset, or some other condition that the kernel rejects long before it reaches anything interesting [@pz1-registry-adventure-1]. The base-block validator is doing a lot of work.

Second, the bug class he was chasing -- one that produces kernel memory corruption from an attacker-controlled hive -- requires legal-on-disk hives that exercise particular combinations of features. The interesting bugs live in interactions: transactions plus virtualization plus predefined keys plus log replay, all in the same legal hive image. No byte-level mutator is going to synthesize that.

So Jurczyk did something almost retro. He pulled ntoskrnl.exe with public PDB symbols into the kind of static-and-dynamic analysis toolchain PZ #3 enumerates -- IDA Pro for cross-referencing, WinDbg attached to a kernel target, Ghidra alongside [@pz3-registry-adventure-3] -- and started reading the Configuration Manager. He cross-referenced every entry point against libregf, against Suhanov's spec, and against Windows Internals, Part 2, 7th edition by Allievi, Russinovich, Ionescu, and Solomon [@winint7-part2; @libregf-spec; @msuhanov-spec]. Every attacker-reachable function got traced to every cell read, write, free, and allocation on every path. PZ #3 lists the bibliography he assembled along the way and marks the Russinovich book with the equivalent of a gold star [@pz3-registry-adventure-3]. The methodology is twentieth-century. The yield is not.

The numbers came in twenty months later. Per PZ #1, the audit produced 39 bug reports, which Microsoft serviced as 44 CVEs in the 90-day cohort plus 6 more in a March 2024 low-severity batch, for 50 CVEs total; the average time from report to fix was 81 days [@pz1-registry-adventure-1]. By December 2024, with more Microsoft CVE assignments rolling in, PZ #5 was reporting 52 CVEs [@pz5-registry-adventure-5]. By May 2025, PZ #7 was at 53 [@pz7-registry-adventure-7]. The growth across the publication arc reflects CVE assignment, not new discoveries. "50+" is the safe headline figure.

Inside those 50 CVEs, a tight subset of 17 share a single root cause and a single exploitation primitive [@pz8-registry-adventure-8]. Jurczyk's PZ #8 gives them a name -- hive-based memory corruption -- and divides them into two subclasses. Spatial violations are cell-boundary overflows: writes that cross the boundary of a legitimately-allocated cell into an adjacent cell whose type, owner, or pointer the attacker now controls. Temporal violations are cell-reuse use-after-frees: writes through a cell-index reference whose backing storage has been freed and reallocated to attacker-influenced content. Spatial and temporal together; everything else is detail.

Mateusz Jurczyk's coinage for the bug class that corrupts the in-memory representation of an active hive via the deterministic cell allocator [@pz8-registry-adventure-8]. The spatial subclass is cell-boundary overflows. The temporal subclass is cell-reuse use-after-frees. The class is named in PZ #8 and demonstrated on Windows 11 with all modern kernel mitigations enabled.

The exploitation primitive is the deliberate engineering of the cell allocator, and PZ #8 is unsentimental about it.

The registry cell allocator... completely lacks any safeguards against memory corruption, and... has no element of randomness, making its behavior entirely predictable. -- Mateusz Jurczyk, *The Windows Registry Adventure #8* [@pz8-registry-adventure-8]

A deterministic, unrandomized allocator with no integrity checks on its cell metadata is what you would design if you wanted recovery from a torn write to produce the same byte image every time. It is also, identically, what you would design if you wanted an exploit primitive that places a controlled object at a predictable cell index. The property that makes the parser correct under crash recovery and the property that makes it exploitable are the same property.

Key idea: The bug class was semantic. The fuzzer was syntactic. That mismatch is the audit's entire reason for existing.

How does an attacker-controlled hive actually become a corruption primitive? The sequence is shorter than you might expect.

sequenceDiagram participant U as Medium-IL process participant K as Configuration Manager participant V as Base-block validator participant P as Bin and cell parser participant A as Cell allocator U->>K: RegLoadAppKey(hive_path) K->>V: Validate REGF header V->>P: Walk HBINs, accept legal cells P->>A: Reserve cell indices for keys, values, security A->>P: Hand back deterministic indices P->>K: Build cell map, expose KCB Note over A,P: Attacker-shaped cells now live at predictable kernel addresses K->>U: Return private handle U->>K: Trigger second-stage operation (e.g., transaction abort) K->>A: Spatial or temporal violation fires

The diagram makes the loss of generality clear. The base-block validator does its job; the bin and cell parser accept a legal hive; the cell allocator places attacker-shaped cells at deterministic indices; and then a second-stage operation -- a transaction abort, a log replay, a predefined-key dereference -- reuses a cell index whose backing storage no longer means what the kernel assumes. There is no point in the lifecycle where a fuzzer's mutator could have engineered the legal-on-disk-but-semantically-explosive hive that the audit's reader engineered by hand.

Coverage-guided fuzzing and manual audit are not equivalent tools on this target. The empirical numbers from the same researcher, on the same target, are instructive.

Method	Researcher-months	Good registry kernel bugs	Empirical rate
Bitflipping fuzz of `RegLoadKey` / `RegLoadAppKey` (2016)	~few [@pz1-registry-adventure-1]	4 (PZ #873, #874, #876, #993)	~1 per month or worse
Bochs coverage-guided harness (early 2022)	~1 to 2	1 (CVE-2022-35768)	~0.5 to 1 per month
Manual audit (May 2022 -- December 2023)	20	50 CVEs across 39 reports [@pz1-registry-adventure-1]	~2.5 CVEs per month

To understand why hive-based memory corruption works as a primitive, we have to look at what the parser actually is.

6. Anatomy of the Configuration Manager

If you want to find bugs in the registry, you have to know exactly what a hive is. Here is what one looks like on disk and in memory.

A hive begins with a base block: a 4 KiB header that contains the magic string regf, the format version (v1.3 in modern hives), a sequence-number pair for crash recovery, a checksum, the root cell index, the hive length, the boot type and recovery information [@pz5-registry-adventure-5; @libregf-spec]. The validator that runs at hive load time vets this block first. If the checksum does not match, if the version is unrecognized, if the lengths do not add up, the parser refuses the file and no further code runs. This is the line of defense that ate 99% of the bitflipping fuzzer's effort in 2016 and again in 2022.

After the base block come one or more HBIN blocks. Each HBIN is a 4-KiB-multiple chunk of the hive carved into cells. Microsoft's documentation on registry hives describes the on-disk supporting files alongside the main hive: an .alt backup of the critical HKLM\System hive, a .log transaction log, and a .sav backup [@ms-registry-hives]. The HBIN is the layer the cells live in.

A cell is a length-prefixed chunk of bytes whose first 32-bit field is a signed integer. Positive means free, negative means allocated, and the absolute value is the cell size in bytes (cells are 8-byte aligned). The Suhanov spec documents the convention plainly, alongside the cell types we are about to walk through [@msuhanov-spec]. The signed-size convention is not just a curiosity; it is the load-bearing invariant that the cell allocator must protect, and it is the convention an attacker exploits when they convince the kernel to walk one allocated cell into the next.

{` // Demonstrates the regf signed-size cell convention from Suhanov's spec. // A cell whose first 32-bit field is positive is FREE. // A cell whose first 32-bit field is negative is ALLOCATED; |size| is bytes.

function readCellHeader(buf, offset) { const raw = new DataView(buf).getInt32(offset, true); // little-endian const allocated = raw < 0; const sizeBytes = Math.abs(raw); return { allocated, sizeBytes, raw }; }

// Build a 16-byte buffer: cell #1 allocated, 16 bytes, then a sentinel. const buf = new ArrayBuffer(20); new DataView(buf).setInt32(0, -16, true); // header: -16 -> allocated, 16 B new DataView(buf).setInt32(16, 1234, true); // sentinel "next cell" prefix

console.log("Cell 1:", readCellHeader(buf, 0)); console.log("Cell 2 sentinel:", readCellHeader(buf, 16));

// A trivial validator that only checks "is the size positive after abs()" // will accept a maliciously flipped header that overlaps into the next cell. const tampered = buf.slice(); new DataView(tampered).setInt32(0, -24, true); // size now spans into cell 2 console.log("Tampered cell 1:", readCellHeader(tampered, 0)); `}

A hive holds a small number of cell types. The five that matter for security analysis are catalogued below. Each describes a different on-disk concept, and each can be malformed in ways the parser must catch.

Cell type	Signature	What it stores	Failure mode
Key node	`nk`	A registry key: name, parent index, child-list index, value-list index, security index, timestamp [@libregf-spec]	Dangling indices; malformed name length; recursive parenting
Value	`vk`	A registry value: name, type tag, length, inline data or data-block index [@libregf-spec]	Length-versus-buffer mismatch; type-tag confusion
Security descriptor	`sk`	A security descriptor for one or more keys; reference-counted [@libregf-spec]	Refcount underflow on shared SDs
Index node	`lf` / `lh` / `li` / `ri`	A subkey list: leaves with hash hints, intermediate ri lists [@msuhanov-spec]	Out-of-order entries; phantom subkeys
Big-data block	`db`	A continuation cell for values larger than 16,344 bytes (just under 16 KiB) [@libregf-spec]	Length math overflow; truncated continuation

Between the cells and the parser sits a layer most people do not know about: the cell map. Bins are not guaranteed to be contiguously mapped in kernel virtual address space, so the Configuration Manager maintains a page-table-like indirection that translates a 32-bit cell index into a virtual address. PZ #6 documents this in detail in its discussion of _HHIVE and _CMHIVE, with the latter spanning 0x12F8 bytes and the former 0x600 bytes at offset zero [@pz6-registry-adventure-6].Per PZ #6: _CMHIVE is 0x12F8 bytes and contains an embedded _HHIVE of 0x600 bytes at offset 0. The depth of Jurczyk's reverse-engineering is reflected in these exact offsets, which are not in any Microsoft-published documentation.

A page-table-like indirection layer that translates a 32-bit cell index into a kernel virtual address [@pz6-registry-adventure-6]. The cell map exists because the bins making up a hive are not guaranteed to be contiguously mapped. Most cell-boundary exploitation primitives walk through the cell map. flowchart LR A["32-bit cell index"] --> B["Directory index"] A --> C["Table index"] A --> D["Cell offset within bin"] B --> E["Cell map directory"] E --> F["Cell map table"] C --> F F --> G["Bin base address"] D --> G G --> H["Kernel virtual address of cell"]

The cell allocator itself -- HvAllocateCell, HvReallocateCell, HvFreeCell [@pz8-registry-adventure-8] -- is small, deterministic, and unrandomized. There is no allocator metadata integrity check; freed cells are eagerly reused; cell placement is a function of the bins' free lists, which the attacker can influence by shaping the input hive. Combined with the cell map, the result is that the attacker can place a chosen byte pattern at a chosen cell index with reasonable predictability, and -- because the same allocator services both attacker-influenced and kernel-managed cells -- the attacker can place that pattern adjacent to a kernel-managed object whose corruption hands them an elevation primitive [@pz8-registry-adventure-8].

Since Windows 10 RS4, hive pages are not copied into the paged kernel pool; they are backed by memory-mapped sections that can be paged in from the underlying file [@pz5-registry-adventure-5]. The performance and footprint benefits are real. The security side effect is a new bug class: the kernel can read a hive byte at validation time, then read the same byte again at use time, and the underlying page can have been re-fetched in between. This is the double-fetch pattern, and CVE-2024-43452 -- a double-fetch while loading hives from remote network shares -- is the canonical example Jurczyk cites in PZ #5 [@pz5-registry-adventure-5].

A vulnerability pattern where the kernel reads the same attacker-influenced memory location twice and treats both reads as authoritative. The section-backed registry (Windows 10 RS4) made hive pages pageable, which enables this on hive files served from remote SMB shares: between the kernel's two reads, the attacker swaps the byte under the kernel's feet. CVE-2024-43452 is the canonical example [@pz5-registry-adventure-5].

A small but stubborn misconception about the registry deserves a callout before we move on. The registry is not lock-free. The Configuration Manager uses pushlocks -- a Windows kernel synchronization primitive supporting shared and exclusive modes -- on a per-Key-Control-Block basis, plus a hive-wide pushlock for operations that touch the hive globally [@pz6-registry-adventure-6]. PZ #6's discussion of _CMHIVE and _HHIVE documents the pushlock placements directly. The design is fine-grained pushlock synchronization, not lock-free concurrency, and the difference matters because temporal hive-memory-corruption bugs frequently exploit the gap between unlocking a parent and re-locking it, which exists in pushlock designs and would not exist in a true lock-free one.

A Windows kernel synchronization primitive supporting shared and exclusive modes [@pz6-registry-adventure-6]. The registry uses per-KCB pushlocks and a hive-wide pushlock. The implementation is *not* lock-free; that is a third-party misconception, and several of Jurczyk's temporal hive-memory-corruption bugs exploit the moment a pushlock is released and re-acquired.

Two other runtime subsystems sit on top of the parser. The Kernel Transaction Manager (KTM) lets registry writes be grouped into atomic, rollbackable transactions; KTM rides on the Common Log File System (CLFS).KTM's CLFS backing is interesting in its own right: CLFS has had its own significant CVE history, and a transactional registry write whose KTM log can be tampered with reaches a separate kernel subsystem with its own attack surface. The transactional layer is one of the "semantic combinators" Jurczyk explicitly lists as outside the syntactic-fuzzer reach.

Incremental write-ahead logging via LOG1 and LOG2 provides crash-recoverable durability for individual writes that have not yet been flushed to the main hive [@pz5-registry-adventure-5]. Both layers add features. Both layers add cell-lifetime states the parser must reason about. Both layers contributed bugs to the audit.

The PZ #1 summary breakdown of the 50-CVE cohort is the clearest single statistic in the entire series.

Category	Count
Elevation of privilege	39 [@pz1-registry-adventure-1]
Information disclosure	9 [@pz1-registry-adventure-1]
Memory information disclosure	1 [@pz1-registry-adventure-1]
Denial of service	1 [@pz1-registry-adventure-1]
Total	50

Of those 50, the subset PZ #8 picks out as exploitable via the hive-memory-corruption primitive numbers seventeen: CVE-2022-34707, CVE-2022-34708, CVE-2022-37956, CVE-2022-37988, CVE-2022-38037, CVE-2023-21675, CVE-2023-21748, CVE-2023-23420, CVE-2023-23421, CVE-2023-23422, CVE-2023-23423, CVE-2023-28248, CVE-2023-35382, CVE-2023-38139, CVE-2024-26182, CVE-2024-43641, and CVE-2024-49114 [@pz8-registry-adventure-8]. Seventeen kernel LPEs from one researcher, one subsystem, one bug class, one exploitation primitive.

Microsoft has known about every one of these issues since the day they were reported. Why has the parser not been rewritten?

7. Why Doesn't Microsoft Just Rewrite It?

The first thing anyone asks after seeing the architecture is the obvious question. Why doesn't Microsoft rewrite this thing? The answer is, roughly, "because they cannot."

Backward compatibility is the dominant constraint. A hive file from NT 4.0 in 1996 still mounts on Windows 11 in 2026; that is the published behaviour of REG_STANDARD_FORMAT in RegSaveKeyExA [@ms-regsavekeyex]. Three decades of system images, third-party installers, forensic tooling, configuration-management products, and group-policy templates depend on the regf v1.3 format being readable. A new on-disk format with a hardened in-memory representation would not be a parser change; it would be the kind of compatibility break Microsoft has not made since the move from Win9x to NT.

There are databases inside Windows that look like reasonable alternatives at a glance. None of them is a drop-in replacement, for reasons that have less to do with their internals than with what the registry is asked to do.

System	Implementation	Used for	Why it is not a drop-in
Registry	regf, kernel parser	All Windows configuration, COM, security, policy [@ms-structure-registry]	The thing we are auditing
ESE	`esent.dll`, full ACID DB	Active Directory, Windows Search, Mail, Exchange [@winint7-part2]	Different access model; userland; not designed for boot-path config
LSA Secrets / `SECURITY` hive	regf substrate, restricted access	Cached credentials, Kerberos keys [@winint7-part2]	Same parser, same bug class -- moving the lock does not move the bug
Object Manager Namespace	Kernel object directory	Named kernel objects (events, mutexes, sections)	Different threat model; not a config store
MSIX / AppX state	Per-package JSON/XML in app container	UWP/Store-app configuration	New apps only; cannot host legacy registry consumers

ESE -- the Extensible Storage Engine -- is the closest existing internal candidate. It is a full ACID embedded database, used by Active Directory and Windows Search, and it is much better-engineered as a storage layer than regf is. It is also userland, designed for very different consumers, and not on the kernel boot path. Reusing it would require porting every kernel-mode registry caller across the kernel-user boundary, which has performance implications that nobody has signed off on publicly.

Microsoft's Extensible Storage Engine, an embedded ACID database implemented in `esent.dll`. Active Directory, Windows Search, Exchange, and Windows Mail all use it as their internal data store [@winint7-part2]. It is a much more modern design than the registry's regf, but it is userland, not boot-path, and its access model is different enough that it is not a drop-in replacement for the kernel-mode configuration store.

The LSA Secrets and SECURITY hive are even more instructive. They are regf-format hives with stricter access controls. They inherit the entire hive-memory-corruption bug class verbatim; restricting who can talk to the parser does not change what the parser does with the bytes it receives.

The Windows kernel has another old, hierarchical, semantically-rich subsystem that has not been audited at this scale: the Object Manager Namespace, which exposes named kernel objects (events, sections, mutexes, devices, symbolic links) through a path-like API. It is the same era as the registry, the same kind of in-kernel data structure with a path-resolution layer, the same authorization model that has been hardened incrementally over thirty years. James Forshaw's work has touched it in places; no one has yet read it the way Jurczyk read the Configuration Manager. The Object Manager Namespace is the most plausible next target for a Jurczyk-style audit by anyone who wants to repeat the result on a different subsystem.

The structural argument is the one to remember. The registry's on-disk format and its in-memory format are the same format, and its recovery semantics depend on deterministic cell placement; the attack surface and the recovery semantics are therefore literally the same code [@pz5-registry-adventure-5; @pz8-registry-adventure-8]. You cannot harden one without weakening the other unless you give up the hybrid-format premise entirely -- in which case, you are not hardening the parser; you are rewriting it. And rewriting it is what backward compatibility forbids.

If a wholesale redesign is off the table, can the existing parser be hardened in place?

8. The Theoretical Limits of In-Place Hardening

If Microsoft cannot rewrite the parser, can they at least harden it? Four levers are theoretically available. Each one trades against a different property the existing design depends on.

Lever	What it would achieve	Backward-compat cost	Effectiveness against hive-memory-corruption
Allocator randomization	Break the placement predictability the exploitation primitive relies on	Breaks log-replay recovery semantics that depend on deterministic cell placement [@pz8-registry-adventure-8]	High in principle; incompatible in practice
Cell-metadata integrity checks	Catch naive corruption at allocator boundaries	Modest format change for in-memory layout; on-disk format unaffected	Low; catches accidental corruption, not crafted-input semantic violations
Structured deserialization at load time	Validate the entire hive into a separate in-memory structure	Abandons the hybrid-format premise; effectively rewrites the parser	High but indistinguishable from rewriting
Move the parser to user mode	Reduce blast radius of a parser bug to one process	Performance and correctness implications for boot-path config	Mitigation only; the bug class survives in userland

Allocator randomization is the obvious idea. ASLR-like randomization of cell placement would defeat the "place attacker-controlled bytes at predictable index" half of the primitive, but it would also break recovery semantics: log replay assumes that after a crash, the cells in the recovered hive end up at the same indices the log expected, because the on-disk-equals-in-memory format encodes the cell index in the hive itself. PZ #8's framing of the allocator's lack of randomness as a design property rather than an oversight is precisely about this trade-off [@pz8-registry-adventure-8].

Cell-metadata integrity checks are cheap to add and have an obvious limit. The cell allocator currently has no metadata integrity at all; adding a checksum or a canary would catch a corrupted size header, a stale free-list pointer, or a write that accidentally overran a cell boundary. It would not catch an attacker who shapes a legal hive that exercises the parser's combinatorial logic. The semantic bugs Jurczyk hunted do not write garbage cells; they trick the parser into reusing valid cells for purposes the parser does not realize it is being asked to.

Structured deserialization at hive-load time is the option computer-science textbooks recommend. Validate the entire input file against a formal grammar, deserialize into a separate in-memory representation that is unrelated to the on-disk byte layout, and let the kernel operate on that. This is what the LangSec discipline calls for, and what structure-aware fuzzing surveys treat as the right shape for parser hardening [@manes-fuzz-survey]. It is also identical to "rewrite the parser." The hybrid-format premise that has been load-bearing since 1993 has to die for this option to exist.

Language-theoretic security: a discipline that treats parsers as recognizers for a formal grammar, rejecting inputs outside the grammar instead of recovering from malformed input. The registry parser does the opposite by design: it accepts inputs that the recognizer would call "marginal" (a slightly-malformed log, an off-by-one bin) because recovery from a torn write requires acceptance, not rejection.

Note: LangSec's central recommendation is that a parser should be a recognizer for a formal language: an input either belongs to the language or it is rejected outright, with no recovery and no partial acceptance. The registry's regf parser is not a recognizer in this sense, and cannot be retrofitted into one without abandoning the hybrid on-disk-and-in-memory premise.

Moving the parser to user mode -- running the parser inside an isolated process and exposing only sanitized handles to kernel callers -- is what the academic literature recommends for other kernel parsers. There is no public Microsoft work on doing this for the registry specifically, and the performance cost of a kernel/user boundary on the boot-path configuration store is, charitably, "unstudied." The bug class would still exist; the blast radius would shrink.

Static analysis cannot save us in general. Rice's theorem says, informally, that any non-trivial semantic property of an arbitrary program is undecidable: there is no algorithm that takes a program and tells you whether it has property $P$, for any interesting $P$. Memory safety is interesting. Therefore, any static-analysis approach to "find every memory-safety bug in the Configuration Manager" must be either unsound (it misses bugs) or incomplete (it flags false positives), and in practice usually both. Formal verification of a *specific* parser against a *specific* specification can sidestep this -- the EverParse project at `github.com/project-everest/everparse` does exactly that for TLS and QUIC message parsers in Microsoft research -- but it requires a formal specification of the input language, and the regf format has none.

The honest answer is the one Jurczyk gives in PZ #7 and PZ #8: the parser can be incrementally hardened, and is being, in response to each individual CVE [@pz7-registry-adventure-7; @pz8-registry-adventure-8]. The deeper design choices that make the parser exploitable are the same choices that make it work at all. We have a thirty-year-old parser that cannot be redesigned, cannot easily be replaced, and can only be hardened in ways that trade safety for compatibility. So what does that tell us about the rest of the Windows kernel?

9. Open Problems and What the Audit Implies

Jurczyk read one Windows kernel subsystem for twenty months and produced fifty CVEs. Windows has dozens of kernel subsystems. None of them has been read this way.

That sentence is the article. The rest of this section is bookkeeping.

First, the open business inside the audit itself. Microsoft chose not to fix some of Jurczyk's low-severity reports; PZ tracker issue #2508 is the canonical example of a WontFix close, and the broader "low severity in isolation" category is not "not exploitable in combination" -- modern kernel exploitation is bug-chaining, and a benign-looking primitive plus a benign-looking infoleak often compose into something less benign [@pz7-registry-adventure-7]. PZ #1 also explicitly flags higher-level wrapper logic (path translation in CmpDoOpen, predefined-key abuses, virtualization layers) as parts of the surface that the 20-month audit did not exhaust [@pz1-registry-adventure-1]. There are more registry bugs to find.

Second, the cross-subsystem implication. Microsoft's Windows Insider Preview bounty program pays "from $500 to $100,000 USD" for qualifying critical kernel bugs [@msrc-bounty-windows-insider]. The 50-CVE cohort, valued at the upper bound of the Insider Preview range, is somewhere in the neighbourhood of $5M in latent bounty value, all produced by one person reading code.

Note: At Microsoft's published $100,000 ceiling for critical Windows kernel bugs under the Windows Insider Preview program [@msrc-bounty-windows-insider], the 50-CVE cohort represents roughly $5M in latent bounty value. That is one person, twenty months, one subsystem. The question is not how to fix the registry; it is how many other subsystems would yield similar numbers under similar treatment.

What does that imply for the Object Manager Namespace, the I/O Manager, the print stack, the transactional file system, the Common Log File System, or the WinUSB stack? No public audit of any of those subsystems at the depth of Jurczyk's registry work exists. Some of them have had targeted fuzzing campaigns; none has had a 100,000-line code review by a single expert reader. The expected yield is, charitably, unknown.

flowchart TD A["Windows kernel subsystems"] --> B["Registry / Configuration Manager"] A --> C["Object Manager Namespace"] A --> D["I/O Manager"] A --> E["KTM and CLFS"] A --> F["Print spooler stack"] A --> G["Transactional NTFS"] A --> H["GDI and Win32k"] B --> B1["Jurczyk 2022-2023, 50 CVEs"] C --> C1["Partial Forshaw 2014+, logic bugs"] D --> D1["Episodic fuzzing, no public deep audit"] E --> E1["Episodic CLFS exploitation, no full audit"] F --> F1["PrintNightmare-era patches, no full audit"] G --> G1["No public deep audit"] H --> H1["Years of TYPESAFE_CAST + targeted fuzzing"]

Third, Microsoft's own internal posture. The MSRC SDL pipeline includes OneFuzz-lineage tooling internally, though the public OneFuzz repository was archived in September 2023 [@onefuzz-repo]. No public Microsoft statement confirms or denies whether the registry was systematically fuzzed or audited inside Microsoft before Jurczyk's 2022 audit. The absence of such a statement is itself information: if Microsoft had a parallel internal effort that found these bugs first, they would normally publish that.

Fourth, the methodological question that the article cannot answer because nobody has the data. Does manual code audit scale? One researcher, twenty months, one subsystem, fifty CVEs. Two researchers do not produce twice the bugs because of overlap and coordination cost; the typical second-researcher contribution on the same target is sublinear. There is no obvious path to ten Jurczyks reading ten subsystems in parallel and producing five hundred CVEs.

Key idea: The registry is not interesting because it had bugs. The registry is interesting because someone read it.

Jurczyk did not break new ground by finding a bug. He broke new ground by reading the code -- and the implication for everything else nobody has read is left, as Jurczyk himself might say, as an exercise for the reader.

10. A Practical Guide

Up to here, this article has been about the research. The rest is for practitioners.

For vulnerability researchers

If you want to understand Jurczyk's audit at the level required to repeat it, the Project Zero series is the primary text and the reading order is not the publication order. PZ #4 (hives and the registry layout) and PZ #5 (the regf file format) are the canonical references for the substrate; PZ #6 (kernel-mode objects) is the reverse-engineering of the in-memory structures; PZ #7 (attack surface analysis) is the bug-class taxonomy; PZ #8 (practical exploitation) is the exploitation primitive on Windows 11 with modern mitigations [@pz4-registry-adventure-4; @pz5-registry-adventure-5; @pz6-registry-adventure-6; @pz7-registry-adventure-7; @pz8-registry-adventure-8]. PZ #1 and #2 are the framing and the history; PZ #3 is the bibliography. Read 4 -- 5 -- 6 -- 7 -- 8, in that order, with PZ #1 alongside as a CVE-index lookup.

Audience	Where to start	Why
Researcher learning the surface	PZ #4 then PZ #5 [@pz4-registry-adventure-4; @pz5-registry-adventure-5]	Substrate first; specifics later
Defender / SOC engineer	PZ #7 attack-surface taxonomy [@pz7-registry-adventure-7]	Detection patterns map to bug classes
Kernel engineer (defensive)	PZ #4--6 collectively	Best non-Microsoft technical reference on the Configuration Manager
Patch manager	PZ #8's 17-CVE list + PZ #1 full table [@pz8-registry-adventure-8; @pz1-registry-adventure-1]	Prioritize the hive-memory-corruption cohort

The Jurczyk pattern is reproducible. Pick a closed-source Windows kernel subsystem with a structurally rigid input format. Get the public PDB symbols for `ntoskrnl.exe` (or the relevant driver). Find the equivalent of `RegLoadAppKey` for the surface in question -- the unprivileged user-mode entry point that runs the most kernel code on the most attacker-influenced input. Then read every reachable function. The unglamorous methodology and the long-form Project Zero blog series are the same artifact.Jurczyk's 2022 registry-specific coverage-guided Bochs harness has never been publicly released. The lineage -- Bochspwn (2013), Bochspwn Reloaded (2018) -- is well-documented in Jurczyk's public papers and repositories [@bochspwn-reloaded-paper; @bochspwn-reloaded-repo]. The registry-specific configuration is not.

For defenders

The detection story for hive-memory-corruption attempts is unusual. Most real-world exploitation chains will load an attacker-controlled hive via RegLoadAppKey (or its close relatives RegLoadKey, RegLoadKeyEx, RegRestoreKey) from an unusual path -- typically a temporary directory under the calling user's profile or an SMB share. The hive file itself can be analyzed offline by mounting it with a forensic parser such as libregf [@libregf-repo] or Suhanov's regf tools [@msuhanov-repo].

The kernel exposes the operation via the Microsoft-Windows-Kernel-Registry ETW provider, and Sysmon surfaces registry operations under event IDs 12 (key create/delete), 13 (value set), and 14 (key/value rename) [@ms-sysmon]. A simple detection heuristic is "Medium-IL process performs an unusual rate of hive-load operations on attacker-shaped paths." Detection logic looks like the following.

{` // Toy detection: Medium-IL process loads multiple app hives from // non-standard paths within a short window. Inspired by Sysmon event IDs // 12 (registry create/delete) and 13 (registry value set).

function suspiciousHiveLoad(event, profileWindowMs) { const isLoad = event.operation === 'CreateKey' || event.operation === 'LoadAppKey'; if (!isLoad) return false;

const path = event.targetPath || ''; const fromTempOrShare = path.match(/AppData\\Local\\Temp/i) || path.match(/^\\\\[^\\]+\\/) || path.match(/Users\\Public/i);

const lowIntegrity = event.integrityLabel === 'Medium' || event.integrityLabel === 'Low';

const recentCount = countRecentEventsFromPid(event.pid, profileWindowMs); const burst = recentCount > 5;

return lowIntegrity && fromTempOrShare && burst; }

function alert(event) { if (suspiciousHiveLoad(event, 60000)) { console.log('ALERT: anomalous hive load from PID ' + event.pid + ' path=' + event.targetPath); } } `}

Note: The 17 CVEs in Jurczyk's PZ #8 cohort all share the same exploitation primitive. If you are triaging a backlog of Windows security updates, prioritize fixes for these CVE IDs over the broader 50-CVE list: CVE-2022-34707, -34708, -37956, -37988, -38037; CVE-2023-21675, -21748, -23420, -23421, -23422, -23423, -28248, -35382, -38139; CVE-2024-26182, -43641, -49114 [@pz8-registry-adventure-8].

For engineers maintaining adjacent code

PZ #4, #5, and #6 collectively are the most accessible non-Microsoft technical reference on the Configuration Manager [@pz4-registry-adventure-4; @pz5-registry-adventure-5; @pz6-registry-adventure-6]. If you are doing security review of a subsystem that interacts with the registry -- ETW, KTM, AppX state, group policy -- those three posts plus PZ #7 give you the model of the in-kernel data structures you are talking to.

For everyone else

The 50 CVE IDs spanning CVE-2022-34707 through CVE-2024-49114 are a checklist for "have these been rolled across our fleet?" [@pz1-registry-adventure-1]. The 17-CVE hive-memory-corruption subset is the priority order [@pz8-registry-adventure-8]. The fixes are in Microsoft's monthly servicing channel; there are no out-of-band patches required, but the cohort is large enough that a fleet that fell behind on Patch Tuesday in 2022 -- 2024 may have several of these still outstanding.

The research is published. The detection is uncomplicated. The next twenty months of Windows kernel research will not be about the registry, which makes the question this article ends on -- what about everything else nobody has read -- the only question left.

11. FAQ

A handful of questions worth correcting before they propagate. These are the misconceptions inherited from secondary summaries of the research, including the prompt for this article.

No. **Bochspwn Reloaded** is a separate 2017--2018 Project Zero tool, also by Jurczyk, that detects uninitialized kernel memory disclosures via x86 taint tracking [@bochspwn-reloaded-repo; @bochspwn-reloaded-paper]. The 2022--2023 registry research is **The Windows Registry Adventure**, an eight-part Project Zero blog series [@pz1-registry-adventure-1]. The 2022 coverage-guided Bochs harness Jurczyk briefly used on the registry was a separate, unreleased tool sharing the same general lineage, but it is not the public Bochspwn Reloaded repository. Conflating the two is the most common third-party error about this research. No. At a minimum, Jurczyk and Forshaw fuzzed it in 2016 -- the bug reports filed as Project Zero issues #873, #874, #876, and #993 are the surviving artifacts of that effort [@pz1-registry-adventure-1] -- and Jurczyk built a coverage-guided Bochs harness against it in early 2022 that produced CVE-2022-35768 within days. The 2022--2023 work that produced 50 CVEs was a manual code audit, not a fuzzing campaign. The "fuzzed precisely once" claim mixes up "no published fuzzing campaign at scale" with "no one ever pointed a fuzzer at this," and the latter is just not true. No. The Configuration Manager uses **pushlocks** (shared and exclusive modes) on a per-Key-Control-Block basis, plus a hive-wide pushlock for global hive operations [@pz6-registry-adventure-6]. "Lock-free" is a misconception that appears in some secondary summaries -- including the prompt for this article. The actual design is fine-grained pushlock-synchronized, and several of Jurczyk's temporal hive-memory-corruption bugs exploit the moment a pushlock is released and re-acquired. All of those are correct at different points in the publication arc. PZ #1 (April 2024) counts 44 from the 90-day cohort plus 6 from the March 2024 low-severity batch = 50 [@pz1-registry-adventure-1]. PZ #5 (December 2024) reports 52 [@pz5-registry-adventure-5]. PZ #7 (May 2025) reports 53 [@pz7-registry-adventure-7]. The growth reflects Microsoft assigning more CVE IDs to Jurczyk's existing bug reports over time, not new discoveries. "50+" is the safe shorthand; "50 in the original cohort, 53 by mid-2025" is the precise version. **OffensiveCon 2024**, in Berlin. The talk was "Practical Exploitation of Registry Vulnerabilities in the Windows Kernel"; slides and recording are public [@offcon24-jurczyk-speaker; @offcon24-slides; @offcon24-video]. The earlier **BlueHat Redmond 2023** talk (titled "Exploring the Windows Registry as a powerful LPE attack surface") was the first public disclosure of the research [@bluehat23-slides; @bluehat23-video]. "OffensiveCon 2025" is wrong; that talk has not happened. No. Microsoft has never published a regf specification; PZ #5 states this directly: "Throughout the 30 years of the format's existence, Microsoft has never released its official specification" [@pz5-registry-adventure-5]. Unofficially, two community-maintained specs cover almost all of it: Joachim Metz's libregf, updated continuously since July 2009 [@libregf-spec], and Maxim Suhanov's regf project [@msuhanov-spec]. The Microsoft-blessed reference book is *Windows Internals, Part 2, 7th Edition* by Allievi, Russinovich, Ionescu, and Solomon [@winint7-part2]. Everything else is forensics-community reverse engineering.

The eight Project Zero posts run roughly 120,000 words across April 2024 -- May 2025. Microsoft has serviced 53 CVEs from them so far. The registry's parser remains substantively the same routine it has been since Windows NT 4.0. There is no public roadmap for a redesign. The question that follows -- what is the expected yield of similar audits of every other Windows kernel subsystem that no one has read end-to-end -- is the one a research community could answer in another twenty months, if it chose to.

Adminless: How Windows Finally Made Elevation a Security Boundary

noreply@paragmali.com (Parag Mali) — Sun, 10 May 2026 00:00:00 GMT

**Administrator Protection (informally "Adminless") replaces Windows 11's split-token UAC with a separate, system-managed local user account.** The operating system creates this **System Managed Administrator Account (SMAA)** per local admin, links it to the primary admin via paired SAM attributes, and uses it to host elevated processes in a fresh logon session gated by Windows Hello. The kernel asks LSA to authenticate "a new instance of the shadow administrator" without any SMAA credential because the SMAA has none. The mechanism makes the elevation path a security boundary for the first time, with bulletin-grade fixes when it fails. Microsoft shipped it in KB5067036 on October 28, 2025, then reverted it on December 1, 2025 over an application-compatibility issue, not a security failure. This article walks the twenty-year argument that produced the design, the nine pre-GA bypasses Forshaw found and Microsoft fixed, and exactly where the new boundary still leaks.

1. Two tokens, one user, twenty years

Open an elevated console on a Windows 11 device with the registry value TypeOfAdminApprovalMode = 2 set, and run whoami /all. The user name is no longer yours. It is ADMIN_<sixteen random characters> -- a local account you never created, owned by an operating-system component you never ran, in a logon session that did not exist five seconds ago and will not exist five seconds after the console closes.

For twenty years, an elevated Windows command prompt reported the same user name as the unelevated one. The integrity level changed. The token changed. The user did not. That single architectural fact is the load-bearing premise of every UAC bypass ever published. The Vista User Account Control design from 2006 issued two tokens at logon for a member of the local Administrators group: a filtered standard-user token for everyday work, and a full admin token linked to it via the TokenLinkedToken field [@ms-uac-how-it-works]. When the user clicked Yes on a consent prompt, the Application Information service called CreateProcessAsUser with the linked token. Same user. Same profile. Same HKCU. Same logon session. Different integrity level.

Four resources stayed shared between the filtered and full tokens, and four categories of attack grew out of them. Files dropped in a writable directory the elevated process trusts. Registry values planted under HKEY_CURRENT_USER that an elevated binary reads before it consults HKEY_CLASSES_ROOT. COM elevation monikers that hand the attacker an elevated IFileOperation interface. Path-resolution overrides that redirect %SystemRoot% for a single auto-elevating process. The UACMe project [@uacme] catalogues 81 such methods, each one a load against the shared-resource shape of Vista's split token.

Administrator Protection inverts that shape. The elevated administrator becomes a different account with a different security identifier, a different profile directory, a different NTUSER.DAT hive, a different authentication-ID LUID, and a different DOS device object directory under \Sessions\0\DosDevices\. The operating system manages the account itself. It is created on demand the first time the policy is enabled, linked to the primary admin via paired Security Account Manager attributes, used in a fresh logon session for every elevation, and the elevated token is destroyed when the process exits [@ms-developer-blog-2025, @call4cloud-osint].

The feature ships under four names -- Administrator Protection in Microsoft Learn, Adminless as the community shorthand this article uses, ShadowAdmin in the samsrv.dll engineering symbols, System Managed Administrator Account (SMAA) in the Windows Developer Blog [@ms-admin-protection, @ms-developer-blog-2025, @call4cloud-osint] -- and §6 walks each in turn. The launch arc was short: announced at Ignite 2024 by David Weston on November 19, 2024 [@bleepingcomputer-2024], surfaced earlier that fall in Insider Preview build 27718 on October 2, 2024 [@ms-insider-build-27718], shipped to stable Windows in KB5067036 on October 28, 2025 [@ms-kb5067036], and disabled on December 1, 2025 over a WebView2 application-compatibility regression [@forshaw-pz-jan2026, @ms-admin-protection].

This article walks what changed and what did not. By the end you will know exactly which UAC bypass families are dead, exactly which survive, exactly what the December 2025 revert was about, and exactly where the new boundary still leaks. The path runs through twenty years of design tradeoffs and seven years of binary-level fixes that never converged on a real boundary. It runs through nine Project Zero bypasses Microsoft fixed before shipping. It ends at a question Microsoft's own design documents do not yet answer: when the prompt is a credential gate instead of a click-through, what is left for the attacker to do?

The first thing to understand is what UAC was trying to do, and why Microsoft said for twenty years it was not a security boundary.

2. "Convenience, not boundary": UAC as Microsoft conceived it

Why did Vista ship UAC at all? For most of Windows history, every interactive logon for a member of the local Administrators group produced one full-admin token. The desktop shell ran as a full administrator. Every child process inherited those rights. The worm era of 2003 to 2005 demonstrated, repeatedly, that one process running in user context owned the whole machine. By 2006 the cost of admin-by-default had become impossible to defend [@wikipedia-uac].The pre-Vista Limited User Account (LUA) was Microsoft's first attempt at a fix. The conceptual ancestor of the filtered token failed in practice because roughly half of the third-party application base broke under it, and the documented workaround -- RUNAS.EXE -- was operationally hostile enough that almost no one used it.

The redesign that produced UAC pivoted on a single observation. Forcing administrators to run as standard users had failed because too much software assumed admin rights. So Vista would give each admin user two identities. One would be standard-user enough to run the desktop, the browser, and the day-to-day applications without privilege. The other would carry the admin rights, and the operating system would arrange for the user to opt into it on a per-task basis.

Mark Russinovich's June 2007 article Inside Windows Vista User Account Control in TechNet Magazine [@russinovich-2007-vista] remains the canonical reference for the design. The mechanism is two tokens at logon; the integrity-level taxonomy (Low, Medium, High, System) gating object access; file-system and registry virtualisation rerouting writes by legacy apps; and Mandatory Integrity Control enforcing the no-write-up rule at the kernel-object boundary.

The mechanism by which Vista UAC assigns two distinct access tokens to a single interactive logon for a member of the local Administrators group. The Local Security Authority issues both at logon: a filtered standard-user token with most privileges removed and the Administrators group marked as deny-only, and a linked full administrator token referenced from the filtered token's `TokenLinkedToken` field [@ms-uac-how-it-works].

The disclaimer that follows the design is the single most quoted sentence Russinovich ever published about UAC. The article will lift it verbatim once, because every Administrator Protection design decision falls out of its absence:

It's important to be aware that UAC elevations are conveniences and not security boundaries. -- Mark Russinovich, *Inside Windows Vista User Account Control*, TechNet Magazine, June 2007 [@russinovich-2007-vista]

This is not an accidental disclaimer. It is the canonical Microsoft classification, preserved into the Microsoft Security Servicing Criteria document [@msrc-servicing-criteria]. James Forshaw of Google Project Zero, writing in January 2026, re-states the position verbatim: "due to the way it was designed, it was quickly apparent it didn't represent a hard security boundary, and Microsoft downgraded it to a security feature" [@forshaw-pz-jan2026]. The classification is what determined what Microsoft would and would not pay attention to. A "security boundary" gets a security bulletin when an attacker crosses it. A "security feature" does not. A bypass of a boundary is a vulnerability. A bypass of a feature is a quality bug. For twenty years, UAC bypasses were quality bugs.

The two-tokens-at-logon mechanism is the shape from which the entire bypass canon grows. The twenty years of evolution that follow run along a single timeline.

timeline title Privilege separation in Windows, NT 3.1 to Administrator Protection 1993 : NT 3.1 ships multi-user accounts and DACLs but admin-by-default desktop culture 2006 : Vista UAC introduces the split-token model and Mandatory Integrity Control 2009 : Davidson publishes the first UAC bypass; Windows 7 ships auto-elevation 2014 : hfiref0x's UACMe catalogue collects the bypass canon 2016 : enigma0x3 publishes the registry-hijack family (eventvwr, fodhelper, sdclt) 2019 : CVE-2019-1388 (consent.exe certificate dialog) is the lone UAC LPE bulletin 2024 : Insider Preview build 27718 surfaces Administrator Protection; Ignite 2024 announces it 2025 : KB5067036 ships the SMAA on stable Windows, then reverts on December 1 2026 : Forshaw's nine pre-GA bypasses all fixed; the elevation path is now a security boundary

To see why the entire bypass canon grew out of the split-token shape, the next section walks the mechanic at function-name granularity. It is the load-bearing pre-history of everything that comes after.

3. The Vista UAC split-token in detail

The mechanics at logon. The Local Security Authority Subsystem Service (LSASS) validates credentials. For a user in the local Administrators group, it constructs two tokens. The filtered token has its dangerous privileges removed and the Administrators SID marked deny-only; the full token retains them. The Token Manager wires the filtered token's TokenLinkedToken field to a handle on the full token. LSASS hands the filtered token to winlogon.exe. Winlogon launches userinit.exe. Userinit launches explorer.exe. The shell, holding the filtered token, becomes the parent process from which every user-initiated process inherits [@ms-uac-how-it-works].

The kernel structure that connects the filtered standard-user token to the linked full administrator token in Vista's split-token model. A process holding the filtered token can read the `TokenLinkedToken` field via the `GetTokenInformation` API to discover the handle of the full token, and pass that handle to `CreateProcessAsUser` to launch an elevated child. The same link is the structural premise of token-stealing attacks: any code path that can read or impersonate the linked token bypasses the consent UI entirely [@ms-uac-how-it-works, @forshaw-pz-jan2026].

The shell shares four resources with anything launched under the full token.

The same user security identifier. Both tokens carry the same primary SID. Files, registry keys, and kernel objects that grant access to the user grant identical access to both processes.
The same %USERPROFILE% directory tree. C:\Users\<user>\ is the home of both. The Documents folder, the Downloads folder, the AppData hives, and any application-specific subdirectory belong to one user.
The same HKEY_CURRENT_USER hive. Both tokens map HKCU to the same NTUSER.DAT file. An elevated process that reads a user setting reads the value the unelevated user wrote.
The same logon-session LUID. The Locally Unique Identifier that identifies an interactive logon session is the same on both tokens. The kernel uses that LUID as a key for per-logon-session caching: the DOS device object directory at \Sessions\0\DosDevices\<LUID>, drive-letter mappings, mapped network drives, and the credential cache.

The elevation pipeline. A user clicks Yes on a UAC prompt. The mechanism beneath that click runs through a chain of named function calls.

sequenceDiagram participant User as User shell (filtered token) participant AppInfo as appinfo.dll (Application Information service) participant Consent as consent.exe (secure desktop) participant LSA as LSASS participant New as Elevated child process

User->>AppInfo: ShellExecute / CreateProcess "as admin"
AppInfo->>AppInfo: RAiLaunchAdminProcess RPC
AppInfo->>AppInfo: Read manifest requestedExecutionLevel
AppInfo->>AppInfo: Check ConsentPromptBehaviorAdmin
AppInfo->>Consent: Launch consent.exe on Winlogon desktop
Consent->>User: Show Yes / No prompt
User-->>Consent: Click Yes
Consent-->>AppInfo: Approved
AppInfo->>LSA: Resolve TokenLinkedToken handle
AppInfo->>New: CreateProcessAsUser(linked full token)
Note over New: Same SID and profile and HKCU and logon session
Note over New: Integrity level High

The prompt runs on the secure desktop, the same Winlogon-owned Winsta0\Winlogon desktop where the credential-entry dialog appears at logon, not the user's interactive Winsta0\Default desktop [@ms-uac-how-it-works]. User Interface Privilege Isolation (UIPI) blocks lower-integrity input from reaching higher-integrity windows; the secure-desktop switch is its first defence against synthetic-keystroke attacks against the prompt itself.The secure desktop is not invulnerable. It changes the integrity-isolation context, but a process holding the filtered token can still trigger the switch (that is the whole point of clicking Yes), and code running before the switch can in principle modify the surrounding UI state. CVE-2019-1388 in late 2019 turned out to exploit a different aspect entirely -- a UI-interaction path through the consent.exe certificate-viewer dialog -- and not the secure-desktop switch itself.

Compare this to what comes next. Both tokens share four resources. Each of those resources is a category of attack waiting for a researcher to find it. The next section is the story of what happened when Microsoft tried to make UAC less annoying by silently elevating its own Microsoft-signed binaries -- and what the bypass canon did with the change.

4. Windows 7 auto-elevation and the birth of the bypass canon

A specific moment. December 2009. Leo Davidson publishes Windows 7 UAC whitelist: Code-injection Issue / Anti-Competitive API / Security Theatre on pretentiousname.com [@davidson-2009]. The title is the argument. The page itself is sprawling, contentious, and on a few key technical points exactly right. Microsoft's response, in Davidson's own words: "this is a non-issue, and ignored my offers to give them full details for several months." Microsoft Security Essentials eventually classified the binary (not the technique) as HackTool:Win32/Welevate.A and HackTool:Win64/Welevate.A; in Davidson's pointed observation, "recompiling the binaries in VS2010 means they are no longer detected" [@davidson-2009].Davidson kept writing into his original page over the following decade. A marker buried inside the text reads "As I was typing more words into this page, this appeared in my text editor at the 10,000th word!" In March 2020 he removed the proof-of-concept binaries, noting "I got sick of the page being marked as malware, even by Google (FFS)." The prose remains the canonical first source on UAC bypasses [@davidson-2009].

What Windows 7 added, in October 2009, to fix Vista's prompt-fatigue problem [@russinovich-2009-win7]:

The autoElevate=true manifest attribute, embedded in selected Microsoft-signed Windows binaries.
An internal whitelist of Microsoft-signed binaries living under %SystemRoot%\System32.
The COM Elevation Moniker -- already shipping in Vista (BIND_OPTS3, syntax Elevation:Administrator!new:<CLSID>) -- was the activation primitive. Windows 7 extended implicit auto-elevation to qualifying COM servers whose registrations matched the new whitelist criteria, so callers such as IFileOperation, ICMLuaUtil, and IColorDataProxy could be launched elevated without a consent prompt under the Win7 model [@russinovich-2009-win7, @uacme]. The dedicated registry-curation surface, the COMAutoApprovalList (HKLM\Software\Microsoft\Windows NT\CurrentVersion\UAC\COMAutoApprovalList) that UACMe Method 49 references verbatim, did not ship in Windows 7; it was introduced seven years later in Windows 10 RS1 (build 14393, August 2016) as a Redstone-1 hardening that replaced implicit COM auto-elevation with explicit list curation [@uacme].
The default consent-prompt behaviour ConsentPromptBehaviorAdmin = 5: prompt for consent for non-Windows binaries [@russinovich-2009-win7].

The Windows 7 mechanism by which selected Microsoft-signed binaries elevate without showing the consent prompt to a user who is a member of the local Administrators group. The Application Information service consults a whitelist of signature, path, and manifest attributes; if the binary qualifies, `appinfo.dll` calls `CreateProcessAsUser` with the linked full token and no UI step at all [@russinovich-2009-win7]. A COM activation syntax introduced in Windows Vista that lets an unelevated caller request an elevated instance of a COM server class. The `IBindCtx` is augmented with a `BIND_OPTS3` structure carrying a window handle to attribute the prompt to. The bind moniker `Elevation:Administrator!new:<CLSID>` causes the COM Service Control Manager to launch the server elevated. UACMe methods that target `IFileOperation`, `ICMLuaUtil`, and `IColorDataProxy` all descend from this mechanism [@russinovich-2009-win7, @uacme].

Davidson's technique against the new whitelist is one paragraph of detail. Use the IFileOperation COM elevation moniker, which itself auto-elevates, to write a planted CRYPTBASE.DLL into %SystemRoot%\System32\sysprep\. The path is a writable destination from the limited token because IFileOperation runs elevated. Then launch sysprep.exe, which is auto-elevated as a Microsoft-signed binary in System32. Sysprep loads CRYPTBASE.DLL from its own directory before the system path. The attacker's DLL runs at High integrity in the elevated sysprep process [@davidson-2009, @uacme]. No prompt. The whitelist did the work.

The bypass canon. Davidson's technique was the start, not the totality. The successors walked the same shape across families.

The DLL side-load family. Sysprep was the canonical instance. Subsequent variants targeted cliconfg.exe, mcx2prov.exe, migwiz.exe, and setupsqm.exe -- each an auto-elevating Microsoft binary that loaded a DLL from a writable directory before consulting the system path. Microsoft removed the auto-elevation attribute from many of these binaries over the Windows 10 1709 cycle, but did so one binary at a time [@uacme].
The registry-hijack family. Matt Nelson's August 2016 disclosure of an eventvwr.exe plus HKCU\Software\Classes\mscfile\shell\open\command bypass [@enigma0x3-2016-eventvwr] established the pattern. An auto-elevating binary consults HKEY_CURRENT_USER before HKEY_CLASSES_ROOT for a value the binary trusts to dispatch a child process. The limited user, who owns HKCU, writes whatever they want into the value. The elevated binary executes the attacker's command line. March 2017 produced sdclt.exe plus App Paths [@enigma0x3-2017-app-paths] and sdclt.exe plus IsolatedCommand [@enigma0x3-2017-sdclt]; May 2017 produced the fodhelper.exe plus ms-settings variant [@uacme]. All fileless. All generalising to any auto-elevating binary that walks HKCU before HKCR.
The COM-elevation-moniker abuse family. UACMe's Method 1 (Davidson's original IFileOperation) ages into Methods 41 (ICMLuaUtil, Oddvar Moe, via ucmCMLuaUtilShellExecMethod) and 43 (IColorDataProxy paired with ICMLuaUtil, Oddvar Moe derivative, via ucmDccwCOMMethod), each one a different COM interface that auto-elevates and exposes a method useful for arbitrary file or registry write [@uacme].
The environment-variable and path-poisoning family. Per-process %windir% or %SystemRoot% redirection via registry shims and Image File Execution Options, redirecting auto-elevating binaries to load resources from attacker-controlled directories.

Key idea: The Windows 7 auto-elevation whitelist was the bypass. The day Microsoft shipped a class of binaries that could elevate silently based on signing and path, the entire problem of UAC bypass reduced to "make one of those binaries do something the attacker wants it to do." Every UACMe method that targets a Microsoft-signed binary in System32 descends from this design choice. The 81-method catalogue is not a list of separate vulnerabilities; it is one architectural mistake spreading through the binary inventory.

Enter hfiref0x's UACMe [@uacme]. The project has been on GitHub since 2014. It currently lists 81 named methods. Each entry pairs the method number with the author credit, the target binary, the technique class, and the "Fixed in" build number. The README, taken together, is the institutional memory of UAC's failure as a boundary. Forshaw's January 2026 framing is the operational summary: "A good repository of known bypasses is the UACMe tool which currently lists 81 separate techniques for gaining administrator privileges" [@forshaw-pz-jan2026].

Microsoft chose to fix individual bypasses rather than redesign the model. The next section asks whether seven years of fixes ever caught up.

5. 2017-2024: incremental hardening, no convergence

The middle Windows 10 era was the moment Microsoft treated UAC bypasses as a quality problem and shipped fixes at quality-fix cadence, not security-bulletin cadence. The work was real, but it was always one binary or one interface at a time.

The named milestones, kept short.

Windows 10 1709 (October 2017). Beginning with this build, IFileOperation auto-elevation for callers other than Explorer was restricted [@uacme]. The originating Davidson 2009 family of bypasses, against the sysprep + planted-CRYPTBASE shape, ceased to function for processes other than the shell itself.
Tighter appinfo.dll manifest parsing across multiple Windows 10 builds. Stricter binary-signature checks. Stricter path checks. Stricter manifest checks. Each of these closed individual bypass methods; none of them closed a family.
Per-binary hardening recorded in UACMe's "Fixed in" column. UACMe version 3.5.0 retired roughly eighty percent of the 2014-vintage catalogue as obsolete; the v3.2.x branch retains the full historical record. The project's README warns that "since version 3.5.0, all previously 'fixed' methods are considered obsolete and have been removed. If you need them, use v3.2.x branch" [@uacme].
CVE-2019-1388 (November 2019; reporter: Eduardo Braun Prado via Trend Micro's Zero Day Initiative). The lone departure from the "UAC bypasses get no CVE" rule. A UI-interaction path through consent.exe's certificate-viewer dialog: an unsigned application could trigger consent.exe to display a certificate dialog whose "View Certificate" link launched Internet Explorer running as NT AUTHORITY\SYSTEM, and IE's File menu opened cmd.exe at the same integrity level [@nvd-cve-2019-1388]. Microsoft fixed it on the November 2019 Patch Tuesday and gave it an LPE bulletin.

CVE-2019-1388 was a prompt-UI bug -- specifically, a crash-path that surfaced an IE process at SYSTEM integrity via the certificate viewer -- not a UAC-bypass bug in the categorical sense. The classification distinction matters: Microsoft did not change its position that UAC was not a boundary; the bulletin treated this as a separate UI defect that incidentally crossed the boundary. CISA later added the CVE to the Known Exploited Vulnerabilities Catalog [@nvd-cve-2019-1388].

The accumulating evidence by 2024 was three observations.

UACMe's catalogue has grown from its 2014 origins to 81 methods today [@uacme]. Each family of attack survived the individual fixes. As Davidson predicted in 2009, the auto-elevation whitelist was the structural problem; patching each whitelisted binary as a separate bug was a treadmill, not a convergence.

Microsoft's own Security Servicing Criteria continued to classify UAC as a security feature, not a boundary, throughout the period [@msrc-servicing-criteria, @forshaw-pz-jan2026]. The decision was load-bearing. Fixing the elevation pipeline at quality cadence meant accepting that bypasses would appear quarterly and would not appear in the Patch Tuesday bulletins until the day Microsoft changed its mind about the classification.

The third piece of evidence is what the attackers were doing while the defenders were churning the binary list. Microsoft's own number, quoted by the Windows Developer Blog from the Microsoft Digital Defense Report 2024, is 39,000 token-theft incidents per day [@ms-developer-blog-2025]. A token, once stolen from an elevated process, requires no further bypass: it is a bearer credential good for the lifetime of the logon session. The same logon session is the one the unelevated user and the elevated process share under the split-token model. The "one logon session" property of UAC's design is the structural premise that token theft depends on.

There is one further thread worth naming here. Forshaw's broader 2022 Kerberos work in the user-credential-delegation space is a thread that survives the elevation-redesign question entirely. The May 2022 Exploiting RBCD using a normal user account post [@forshaw-2022-rbcd] is the representative artifact. Network-credential delegation primitives -- Resource-Based Constrained Delegation, User-to-User Kerberos, S4U2Self -- operate at a layer beneath token-level elevation, and survive even a perfect SMAA design because they do not run through the elevation path at all.

Piecewise fixes never converged on a boundary. The question that drove the next five years of Microsoft work was the obvious one: if the issue is the shared-resource model itself, what is the smallest plausible change that fixes it?

6. The breakthrough: the System Managed Administrator Account

The load-bearing design decision is one sentence. Stop trying to make one user account play both roles. The elevated administrator should be a different account with a different SID, a different profile, a different HKCU, a different logon session, and a different DOS device object directory -- and the operating system should manage that account itself.

What is striking about the design is how prosaic the underlying mechanism is. Multi-user accounts have shipped with Windows NT since version 3.1 in 1993. The architecture for running an elevated process under a separate local user has been present in NT for thirty-three years. What changed is that Microsoft finally chose to enforce the multi-user model for privilege separation, by making the operating system itself create and manage the second account, link it to the primary admin via paired Security Account Manager attributes, and use it for every elevation. The sophistication is in linkage, in lifecycle, and in removing auto-elevation, not in any single new primitive.

Note: The thing that changes between UAC and Administrator Protection is not the elevation mechanism (a manifest, a prompt, a CreateProcessAsUser call) but the elevation classification. An elevation bypass used to be a quality bug. It is now a security-bulletin vulnerability. Every Administrator Protection design decision -- separate account, fresh logon session, removed auto-elevation, Hello-gated consent -- is a consequence of the classification change.

The names. Microsoft Learn's term is Administrator Protection [@ms-admin-protection]. Microsoft's announcement material at Ignite 2024 and in the Insider Preview build 27718 post uses the same "Administrator Protection" label [@ms-insider-build-27718]; Adminless is the community shorthand that stuck. The internal engineering term in samsrv.dll (the Security Account Manager service DLL) is ShadowAdmin [@call4cloud-osint]. The Windows Developer Blog's canonical term for the underlying entity is the System Managed Administrator Account (SMAA) [@ms-developer-blog-2025].

The hidden local user account that Windows creates per primary administrator when the `TypeOfAdminApprovalMode` policy is set to 2. The SMAA has its own random user name (typically `ADMIN_`), its own SID, its own profile directory under `C:\Users\ADMIN_\`, its own `NTUSER.DAT` and therefore its own `HKCU`, and its own membership in the local Administrators group. The operating system uses it to host elevated processes; the user never logs into it directly [@ms-developer-blog-2025, @call4cloud-osint].

The SMAA lifecycle. Four beats. Each anchored to a verified source.

Provisioning. When TypeOfAdminApprovalMode = 2 is set under HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System (either by Group Policy or by the Intune Settings Catalog), samsrv.dll's ShadowAdminAccount::CreateShadowAdminAccount runs once per existing local-administrator account. CreateRandomShadowAdminAccountName produces an ADMIN_<random> name. AddAccountToLocalAdministratorsGroup adds the new account to the Administrators group. Accounts managed by Windows LAPS (Local Administrator Password Solution) are skipped; their lifecycle is owned by a different subsystem and Microsoft did not want the SMAA mechanism to fight LAPS rotation [@call4cloud-osint].

Linking. Two paired SAM attributes encode the trust relationship between the two accounts. The primary admin's user record gets a ShadowAccountForwardLinkSid attribute pointing at the SMAA's SID. The SMAA's user record gets a ShadowAccountBackLinkSid attribute pointing back at the primary admin. These two attributes are the only structural relationship between the two accounts; everything else -- profile, HKCU, group memberships -- is independent [@call4cloud-osint].

Two paired SAM-database attributes that encode the trust relationship between a primary admin user and its System Managed Administrator Account. The forward link sits on the primary admin's record and points at the SMAA's SID. The back link sits on the SMAA's record and points back at the primary admin. The Application Information service uses the forward link at elevation time to resolve which SMAA to launch the elevated process under [@call4cloud-osint]. The registry value under `HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System` that selects the elevation policy. Value 0 disables UAC. Value 1 selects classic Admin Approval Mode (the Vista / Win7 / Win10 split-token behaviour). Value 2 selects Admin Approval Mode with Administrator Protection: every elevation routes through the SMAA path. The value is set by Group Policy ("User Account Control: Configure type of Admin Approval Mode") or by an Intune Settings Catalog policy and requires a reboot to take effect [@ms-admin-protection, @call4cloud-osint].

Per-elevation use. appinfo.dll's RAiLaunchAdminProcess RPC endpoint reads TypeOfAdminApprovalMode. When the value is 2, it walks the forward link to find the calling user's SMAA, launches consent.exe on the secure desktop in credential prompt mode (not Yes/No), authenticates the primary user via Windows Hello (PIN, fingerprint, face, or password fallback), asks the kernel to ask LSA for a fresh primary token for the SMAA in a brand-new logon session, and calls CreateProcessAsUser with that token, the user's requested executable, and the SMAA's profile environment [@ms-developer-blog-2025, @ms-admin-protection, @forshaw-pz-jan2026]. The credential-less LSA logon at the heart of step three of this beat is walked in §7.

Teardown. When the elevated process exits, the SMAA's token handle goes out of scope. The logon session is reaped. The elevated profile directory remains on disk at C:\Users\ADMIN_<random>\ -- it has to, to preserve per-elevation user state across reboots -- but the live admin token does not. There is no persistent High-integrity process running between elevations [@ms-developer-blog-2025].

flowchart TD Start[Policy enabled: TypeOfAdminApprovalMode = 2] --> Provision Provision[samsrv.dll: CreateShadowAdminAccount per local admin] --> Naming Naming[CreateRandomShadowAdminAccountName -> ADMIN_random] --> AddGroup AddGroup[AddAccountToLocalAdministratorsGroup] --> Link Link[SAM linkage: ShadowAccountForwardLinkSid /
ShadowAccountBackLinkSid] --> Idle[SMAA exists, no token live] Idle -->|Each elevation| RPC[appinfo.dll: RAiLaunchAdminProcess] RPC --> Prompt[consent.exe: Hello credential prompt] Prompt --> LSA[Kernel asks LSA: credential-less logon for SMAA] LSA --> Run[CreateProcessAsUser with SMAA token] Run -->|Process exits| Teardown[Token handle released;
logon session reaped] Teardown --> Idle Windows creates a temporary isolated admin token to get the job done. This temporary token is immediately destroyed once the task is complete, ensuring that admin privileges do not persist. -- David Weston, Microsoft Ignite 2024 keynote, November 19, 2024 [@bleepingcomputer-2024]

Key idea: The single design decision behind Administrator Protection: the elevated and unelevated halves of an administrator must be different accounts. Different SID, different profile, different HKCU, different logon session, different DOS device object directory. The shared-resource attacks of the UAC bypass canon cannot persist if there are no shared resources.

The mechanism is now described. The next section walks it at function-name granularity for a single elevation, end to end -- and in particular, the credential-less LSA logon at step six that does the load-bearing work of minting the SMAA token without any SMAA credential.

7. The elevation pipeline end to end

Walk a single elevation. Nine steps.

The caller invokes ShellExecute or CreateProcess with an elevation request. For the shell-launched case the user right-clicks an executable and selects "Run as administrator"; the same RPC endpoint serves manifest-declared requestedExecutionLevel = "requireAdministrator" callers and Elevation:Administrator!new:<CLSID> COM moniker requests.
appinfo.dll's RAiLaunchAdminProcess RPC endpoint, hosted inside the Application Information service in svchost.exe, receives the call [@ms-uac-how-it-works].
appinfo reads HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\TypeOfAdminApprovalMode.
If the value is 2 (Admin Approval Mode with Administrator Protection), appinfo reads the calling user's SAM record, locates the ShadowAccountForwardLinkSid attribute, and validates the corresponding ShadowAccountBackLinkSid on the SMAA's SAM record. The linkage check is what binds a given elevated process to a given primary user; without both attributes pointing at each other, the elevation is refused [@call4cloud-osint].
appinfo launches consent.exe on the secure desktop in credential prompt mode rather than the classic Yes/No mode. The prompt asks the primary user to authenticate via Windows Hello (PIN, fingerprint, face, or password fallback), not the SMAA. The SMAA has no human credentials. The Windows Developer Blog states the property explicitly [@ms-developer-blog-2025], and Forshaw's January 2026 post restates it in operational terms: "The user does not need to know the credentials for the shadow administrator as there aren't any. Instead UAC can be configured to prompt for the limited user's credentials, including using biometrics if desired" [@forshaw-pz-jan2026].
On a positive Hello result, appinfo.dll -- running as NT AUTHORITY\SYSTEM inside the Application Information service -- asks the kernel to ask LSA for a fresh primary access token for the SMAA's SID in a brand-new logon session. The LSA logon is credential-less. The kernel asks LSA to authenticate "a new instance of the shadow administrator," and LSA fulfils the request without any SMAA credential because the SMAA has no credential to verify. The trust architecture mirrors the way the Service Control Manager asks LSA for service-account tokens: SCM is trusted to ask for the token; LSA mints it on the strength of the request rather than on the strength of any credential. In Administrator Protection, appinfo.dll is the trusted requester, and its request is gated on the user-side Hello result it received in step 5. The Forshaw verbatim that anchors the mechanism is below this section [@forshaw-pz-jan2026, @ms-developer-blog-2025].
appinfo calls CreateProcessAsUser with the SMAA token, the user's requested executable, and the SMAA's profile environment block (USERPROFILE=C:\Users\ADMIN_<random>, USERNAME=ADMIN_<random>, the SMAA's NTUSER.DAT mapped as HKCU).
The new process loads at High integrity, holding the SMAA's primary token, in a fresh logon session with a freshly minted authentication-ID LUID. The DOS device directory at \Sessions\0\DosDevices\<LUID> does not yet exist; the kernel will create it on first reference.
Subsequent SeAccessCheck calls on system objects evaluate against the SMAA's local Administrators group membership and succeed. The elevated process can write to HKLM, modify program files, install services, load WHQL-signed drivers (subject to App Control for Business and HVCI), and otherwise behave as a member of the Administrators group [@ms-developer-blog-2025].

The mechanism by which the Local Security Authority mints a primary access token for the SMAA without verifying any SMAA credential. `appinfo.dll`, running as `NT AUTHORITY\SYSTEM` inside the Application Information service, requests the logon on the SMAA's behalf after the primary user has succeeded against the Hello credential gate. LSA fulfils the request because the *requester* is trusted; the architecture mirrors the way the Service Control Manager requests service-account tokens. The "credential-less" label is descriptive of the SMAA side of the exchange: the SMAA never has a human credential to verify, so LSA cannot and does not ask for one [@forshaw-pz-jan2026, @ms-developer-blog-2025].

The trust architecture is not new in Administrator Protection. The Service Control Manager has asked LSA for service-account tokens since Windows NT 3.1 in 1993; LSA accepts the request because SCM is the trusted requester, not because the service account presented a credential. Administrator Protection generalises the same pattern to elevation: appinfo.dll is the trusted requester, and the SMAA is its functional analogue of a service account. What is new is the user-side gate -- the trusted requester only makes the request after a positive Hello result on the primary user's credential.

in Administrator Protection the kernel calls into the LSA and authenticates a new instance of the shadow administrator. This results in every token returned from `TokenLinkedToken` having a unique logon session, and thus does not currently have the DOS device object directory created. -- James Forshaw, *Bypassing Windows Administrator Protection*, Google Project Zero, January 26, 2026 [@forshaw-pz-jan2026]

The "unique logon session" property in Forshaw's quote is exactly the structural property the lazy-DOS-device-directory bypass exploits, and §12 walks that exploit in full. For now, the load-bearing observation is the credential-less logon itself: the SMAA token is real, the logon session is real, the integrity level is real, but no SMAA credential ever changes hands. The trust is in the requester, gated by a Hello gesture from the primary user.

sequenceDiagram participant User as User shell (primary admin filtered token) participant AppInfo as appinfo.dll (NT AUTHORITY\SYSTEM) participant SAM as samsrv.dll / SAM database participant Consent as consent.exe (secure desktop) participant Hello as Windows Hello / TPM participant LSA as LSASS participant Elev as Elevated SMAA process

User->>AppInfo: ShellExecute "as admin"
AppInfo->>AppInfo: RAiLaunchAdminProcess RPC
AppInfo->>AppInfo: Read TypeOfAdminApprovalMode = 2
AppInfo->>SAM: Resolve ShadowAccountForwardLinkSid
SAM-->>AppInfo: SMAA SID + backlink check OK
AppInfo->>Consent: Launch consent.exe (credential mode)
Consent->>Hello: Request Hello gesture for primary user
Hello-->>Consent: PIN / biometric / password verified
Consent-->>AppInfo: Approved
AppInfo->>LSA: Credential-less logon for SMAA (trusted-requester pattern)
LSA-->>AppInfo: Fresh SMAA primary token and fresh LUID
AppInfo->>Elev: CreateProcessAsUser with SMAA token and profile
Note over Elev: Different SID and USERPROFILE and HKCU and LUID
Note over Elev: Integrity level High -- DOS device dir not yet created

A practical illustration of the shift, displayed as the diff between the pre-AP and post-AP elevated console session.

{` // Modelled output of 'whoami /all' run from an elevated console. // Before: TypeOfAdminApprovalMode = 1 (classic UAC). // After: TypeOfAdminApprovalMode = 2 (Administrator Protection).

const before = { user: 'CONTOSO\\alice', sid: 'S-1-5-21-123456789-987654321-1122334455-1001', profile: 'C:\\Users\\alice', authId: '0x3e7:0x000abcde', integrity: 'S-1-16-12288 (High)', groups: ['BUILTIN\\Administrators (Enabled)'] };

const after = { user: 'WIN11-PC\\ADMIN_9f2c7e1bdc4a8033', sid: 'S-1-5-21-123456789-987654321-1122334455-1051', profile: 'C:\\Users\\ADMIN_9f2c7e1bdc4a8033', authId: '0x3e7:0x000abf42', integrity: 'S-1-16-12288 (High)', groups: ['BUILTIN\\Administrators (Enabled)'], shadowBacklink: 'CONTOSO\\alice' };

console.log('Different user name:', before.user !== after.user); console.log('Different SID:', before.sid !== after.sid); console.log('Different profile:', before.profile !== after.profile); console.log('Different LUID:', before.authId !== after.authId); console.log('Same integrity:', before.integrity === after.integrity); `}

The pipeline is now a single chain of named function calls. The next section asks what changed about the four shared-resource properties from §3, and which UAC-bypass family each fix forecloses.

8. The four shared-resources fixes, precisely

Each of the four shared resources from §3 maps to a precise Administrator Protection fix, and each fix maps to a named UAC-era attack class it forecloses.

Shared resource (UAC)	Administrator Protection fix	UAC-era attack class foreclosed
Same SID across both tokens	SMAA has its own SID; no shared user identity	Same-user file and registry ACE confusion
Same `%USERPROFILE%`	SMAA has `C:\Users\ADMIN_<random>\`	DLL side-load family (sysprep / CRYPTBASE)
Same `HKCU` hive	SMAA has its own `NTUSER.DAT`	Registry-hijack family (eventvwr, fodhelper, sdclt)
Same logon-session LUID	SMAA gets a fresh LUID per elevation	Token-theft via `TokenLinkedToken`; logon-session DOS device hijack

Profile separation. The SMAA owns its own %USERPROFILE% directory tree under C:\Users\ADMIN_<random>\. Files created by elevated processes land there by default. Library folder divergence is the most visible consequence: an elevated Notepad's File > Save dialog opens at the SMAA's Documents, not the primary user's. The primary user cannot see those files in their own Explorer without explicit cross-profile navigation. The structural property that closes is the writable-shared-directory premise of the Davidson 2009 DLL side-load family. Sysprep + CRYPTBASE was a profile-shared attack; without a shared profile, the elevated binary searches a different directory tree from the one the limited user can write to [@ms-developer-blog-2025].

Registry separation. The SMAA's HKCU maps to the SMAA's NTUSER.DAT, not the primary user's. When eventvwr.exe, running in an SMAA process, queries HKCU\Software\Classes\mscfile\shell\open\command, it reads the SMAA's hive, not the primary user's. The primary user has no write access to the SMAA's NTUSER.DAT. The entire registry-hijack family -- eventvwr / mscfile [@enigma0x3-2016-eventvwr], fodhelper / ms-settings, sdclt / IsolatedCommand [@enigma0x3-2017-sdclt], sdclt / App Paths [@enigma0x3-2017-app-paths] -- forecloses on the same property: the elevated binary's HKCU lookup walks a hive the attacker does not control [@ms-developer-blog-2025].

Logon-session separation. Every SMAA elevation gets a fresh authentication-ID LUID. The Local Security Authority allocates a new logon session for each elevation; when the elevated process exits, the session is reaped. Per-logon-session kernel resource caches, including the DOS device object directory at \Sessions\0\DosDevices\<LUID> and the credential cache, do not flow across the boundary. Token handles cannot be reused. Drive-letter overrides under the limited user's logon session do not appear in the SMAA's session [@forshaw-pz-jan2026].

No auto-elevation. The autoElevate=true manifest attribute is no longer honoured by appinfo.dll under TypeOfAdminApprovalMode = 2. Every elevation that previously went silent now prompts. The Windows Developer Blog states the change directly: "With administrator protection, all auto-elevations in Windows are removed and users need to interactively authorize every admin operation" [@ms-developer-blog-2025]. Forshaw's January 2026 framing of the consequence: "as auto-elevation is no longer permitted they will always show a prompt, therefore these are not considered bypasses" [@forshaw-pz-jan2026]. This is the single most consequential fix in the design. The auto-elevation whitelist was the bypass; removing the whitelist eliminates the class at the source, including the entire silent-elevation primitive class that Forshaw's older RAiProcessRunOnce research relied on.

Multi-user separation is the original UNIX privilege model. The `root` user holds privilege; ordinary users do not; the boundary between them is the file-permission system enforced by the kernel. Windows NT shipped the same primitives in 1993 -- discretionary access control lists on every securable object, per-user profiles, multi-user logon sessions -- but the surrounding culture treated Administrator-as-default as the path of least resistance. The architectural sophistication in Administrator Protection is in *linkage* (the SAM forward / back attributes), *lifecycle* (provisioning on policy enable, teardown on process exit), and *enforcement* (removal of auto-elevation as a mechanism). The primitives themselves are old.

The four fixes share a property. Each one breaks a shared resource that an attacker depends on. But there is one more piece of the redesign that has not yet been described: the prompt itself is no longer a Yes/No click-through. The next section asks what happens when the consent UI becomes a credential.

9. Windows Hello as the consent gate

The classic UAC prompt is a Yes / No on the secure desktop. Administrator Protection turns the prompt into a credential prompt for the primary user's Windows Hello: a PIN, a fingerprint, a face match, or a password fallback. The credential is for the primary user, not the SMAA, because the SMAA has no human credentials; the Hello verification is what authorises the cross-profile elevation [@ms-admin-protection, @ms-developer-blog-2025, @forshaw-pz-jan2026].

To talk precisely about what the gate does, name the primitive it closes. Under classic UAC, the consent prompt treated a click on the secure desktop as sufficient evidence of consent; physical presence was the entire evidence requirement. That primitive shows up in three sub-cases that the UAC literature has documented for two decades.

The primitive by which the legacy UAC consent dialog accepted a click on the secure desktop as sufficient evidence of consent, without verifying *who* clicked. Three operational sub-cases follow. *Unattended-session click-through* -- an attacker (or co-located third party) with brief physical access to an unlocked screen showing a UAC prompt clicks Yes on the presumption that whoever is at the keyboard is the legitimate user. *Habituated-click click-through* -- the legitimate user has clicked Yes on hundreds of UAC prompts and clicks one more without conscious attention. *Pretext click-through* -- a malicious application argues a legitimate-looking case to the user and elicits the Yes click. Administrator Protection's credential gate cost-raises all three sub-cases without fully eliminating any [@forshaw-pz-jan2026, @ms-admin-protection].

Unattended-session click-through. An attacker who walks up to an unlocked screen showing a UAC prompt can click Yes and elevate. The legitimate user has authenticated; the prompt assumes the person at the keyboard is the legitimate user. Post-AP, the click is not sufficient. The Hello biometric or PIN is required, and the attacker (who does not know either) cannot complete the gesture. Microsoft's Ignite 2024 framing addresses this primitive implicitly with "elevation rights only when needed" and "interactively authorize every admin operation" [@bleepingcomputer-2024].

Habituated-click click-through. A user who has clicked Yes on hundreds of UAC prompts over the course of a year clicks Yes on a malicious one as reflex. The classic UAC prompt requires no attentional engagement beyond physical presence and a click. Hello's gesture (a four-digit PIN entry, a fingerprint press, a face-recognition glance) is higher-friction and harder to perform inattentively. The Windows Developer Blog frames the property as "just-in-time administrator privileges, incorporating Windows Hello to enhance both security and user convenience" [@ms-developer-blog-2025].

Pretext click-through. A malicious application that argues its case to the user -- a fake installer, a re-skinned setup utility, a Trojan masquerading as a legitimate update -- can elicit a Yes click pre-AP. Post-AP, the user is also asked for a credential, which is a stronger user-side check. The user is more likely to interrogate "why am I being asked for my PIN again?" than "why is a prompt appearing?" Microsoft Learn captures the intent as "users are aware of potentially harmful actions before they occur, providing an extra layer of defense against threats" [@ms-admin-protection].

None of the three sub-cases is fully eliminated. Forshaw is explicit that visible-prompt bypasses are not classified as security vulnerabilities by Microsoft's design-document position: bypasses that result in a visible prompt are not security bulletins, because the user could equivalently have launched the prompt themselves [@forshaw-pz-jan2026]. What the gate does is cost-raise each sub-case. The unattended-screen attack requires a stolen PIN or coerced biometric. The habituated user must perform a gesture they cannot perform inattentively. The pretext attack must justify the second authentication, not just the first.

What it does not close is worth naming, because three primitives that look like they belong on the credential gate's account sheet were already closed by independent mechanisms, and the article should say so to avoid the common over-attribution mistake.

Synthetic-keystroke SendInput against consent.exe. Already closed by UIPI in Vista 2006, and doubly closed by the secure-desktop switch to Winsta0\Winlogon. Even UI Access processes -- whose purpose is to bypass UIPI for accessibility -- cannot reach into the secure desktop [@forshaw-pz-feb2026].
Headless UI Automation against the prompt. Same UIPI / secure-desktop boundary closes it. Redundant with respect to the credential gate.
CVE-2019-1388-class UI-interaction paths surfaced through the prompt's own UI. Closed by Microsoft's November 2019 HHCtrl patch and the cert-viewer UI redesign, prior to any Administrator Protection development [@nvd-cve-2019-1388].

The credential is hardware-rooted via TPM or Pluton on capable hardware. The PIN is unsealed only under the user's gesture; the biometric flows through Enhanced Sign-in Security (ESS) on capable hardware; the credential itself never leaves the Trusted Platform Module or Pluton enclave when ESS is engaged [@ms-windows-hello-ess]. The detail of the Hello architecture itself -- FIDO2 attestation, the ngc protector, the ESS isolation path through the Secure Kernel -- belongs to the Windows Hello article in this series, and is not re-derived here.

The new risk the gate does not close is the obvious one. Phishing the prompt now phishes a real credential, not just consent. A malicious application that can convince the user to authenticate on its behalf gets the elevation the user would otherwise have given to a legitimate request. The credential remains hardware-rooted and is not exfiltrated to the malware, but the elevation produces a working SMAA token in the attacker's process. This is the surface §15 carries forward to open problems.

Key idea: The credential gate closes one specific primitive: consent-without-identity-verification. It cost-raises three sub-cases (unattended-session, habituated-click, pretext click-through) without eliminating any. The structural boundary is profile separation plus fresh logon session plus auto-elevation removal; the credential gate is the fourth, defence-in-depth, property that ensures the boundary cannot be silently crossed by anyone holding only the limited user's physical access.

The prompt is a credential gate, but it remains a UI element. The next section asks how this elevation model compares to what other operating systems do.

10. Competing approaches: what other operating systems do

Three one-paragraph treatments. The article does not re-derive each system; it positions Administrator Protection against the field.

Linux: sudo plus PolKit pkexec plus PAM modules. The authority model on Linux is file-based. /etc/sudoers (or its LDAP equivalent) is the policy table; the sudoers plugin reads it and decides whether to permit a given user to run a given command [@sudo-ws-sudoers]. PolKit -- polkitd and its authentication-agent helpers -- is the parallel mechanism for GUI privileged-service requests, with actions and mechanisms separated in the polkit configuration files [@polkit-docs]. Biometric integration arrives through the PAM stack: pam_fprintd for fingerprint, pam_u2f for FIDO2 tokens, pam_yubico for Yubikeys. There is no profile separation by default; sudo -i switches HOME to root's home directory but does not separate per-elevation. The model is per-command authorisation, not per-account isolation.

macOS: Authorization Services plus Touch ID via pam_tid. GUI elevation prompts are gated by authorizationdb, a property-list-format policy database whose rules name which credentials (admin password, Touch ID, system-wide entitlements) authorise which actions [@apple-auth-services]. Touch ID is verified by the Secure Enclave Processor; the credential never leaves the SEP, and Authorization Services integrates with pam_tid to allow sudo invocations to use the gesture [@apple-pam-tid]. There is no separate admin profile; Transparency, Consent, and Control (TCC) guards privileged resource access at the per-action level, not the per-profile level. The Mac architecture privileges hardware-rooted consent (Touch ID, Secure Enclave) over account separation.

Microsoft's own sudo.exe (Windows 11 24H2). An inbox terminal transport that triggers the existing UAC or Administrator Protection pipeline; not an alternative to either [@ms-sudo-docs]. The forceNewWindow mode opens an elevated console in a new window. The disableInput mode keeps the elevated console in the current window but blocks keyboard input to it from the unelevated terminal. The normal (inline) mode preserves POSIX-style pipes between the unelevated and elevated processes. Microsoft Learn warns explicitly about the inline mode: "Sudo for Windows can be used as a potential escalation of privilege vector when enabled in certain configurations" [@ms-sudo-docs]. The mechanism is RPC between the unelevated and elevated sudo.exe processes; the elevation itself still goes through appinfo.dll.

Intune Endpoint Privilege Management (EPM). Cloud-policy-driven virtual-account elevation [@ms-epm-overview]. EPM performs elevation via a virtual account that is not a member of the local Administrators group; the elevation rights are conferred only for the duration of the policy-permitted action. Three elevation modes are available: Automatic (no user interaction), User-confirmed (a prompt), and Elevate as Current User (the action runs as the user's elevated identity rather than the virtual account). EPM is architecturally complementary to Administrator Protection: EPM is the enterprise policy story, Administrator Protection is the per-device architecture story. The two can coexist on the same device.

The distinguishing property of Administrator Protection in this comparison is whole-profile separation: the SMAA's own profile, the SMAA's own HKCU, the SMAA's own library folders, plus a fresh logon session per elevation. Neither Linux sudo nor macOS Authorization Services provides that property as a default desktop primitive. EPM provides per-elevation isolation via the virtual account but does not give the elevated process a persistent profile, which is what makes Administrator Protection's compatibility story so different from EPM's.

Administrator Protection is the architecturally tightest desktop elevation model now in production. The next section asks where the boundary still leaks.

11. Theoretical limits: what Administrator Protection cannot fix

Four structural ceilings.

Showing a prompt is not crossing the boundary. Microsoft's design position is explicit: bypasses that result in a visible elevation prompt are not security bulletins, because the user could equivalently have right-clicked "Run as administrator." Forshaw's January 2026 post states the position verbatim: "I expect that malware will still be able to get administrator privileges even if that's just by forcing a user to accept the elevation prompt" [@forshaw-pz-jan2026]. The operational consequence is that social-engineering the consent dialog remains a structural attack surface. The prompt is a UI element. The boundary is the credential gate. The gate is only as strong as the user's resistance to whatever pretext induces them to authenticate.

The MSRC servicing-criteria definition of a security boundary: a logical separation between code or data of different trust levels, intended to be enforced by the operating system and accompanied by a Microsoft commitment to issue a security update when an unauthorised crossing is found. UAC under the classic split-token model is classified as a *security feature*, not a boundary; bypasses receive quality-fix attention but not security-bulletin attention. Administrator Protection is the first elevation mechanism classified as a security boundary, with bulletin-grade fixes when it fails [@msrc-servicing-criteria, @forshaw-pz-jan2026].

Admin equals kernel. Once code is running inside an SMAA elevated process, it has the local Administrators group; it can write to HKLM; it can install services; it can load WHQL-signed drivers; it can call into kernel-mode interfaces gated by SeLoadDriverPrivilege and the App Control for Business policy. The MSRC servicing-criteria position that "admin-to-kernel is not a security boundary" continues to apply inside the SMAA [@msrc-servicing-criteria]. Administrator Protection makes the path to admin into a boundary; it does not change the relationship between admin and kernel. Driver-loading controls remain the domain of WHQL signing, the Microsoft Vulnerable Driver Blocklist (default-on in Windows 11 since the 2022 update), App Control for Business policies, and Hypervisor-protected Code Integrity (HVCI) [@ms-vuln-driver-blocklist]. The App Identity article in this series covers the App Control mechanism in detail.

The SMAA is in the local Administrators group. Discretionary access control list-based exposures of admin-only resources -- CREATOR OWNER ACEs on persistent objects, world-writable DACLs on certain \Sessions\0\DosDevices entries, default-permissive ACLs on a handful of legacy registry trees -- still grant the SMAA full access. The boundary is between standard user and SMAA, not between SMAA and SYSTEM. The SMAA is a high-privilege actor inside the operating system; the relationship between it and the rest of the privileged surface is unchanged.

Out of scope per Microsoft Learn. Remote logon, roaming profiles, backup-admin accounts, Managed Service Accounts and group Managed Service Accounts (MSAs and gMSAs), virtual accounts for services, and domain-admin scenarios are explicitly outside the Administrator Protection model in its current form [@ms-admin-protection]. The feature is local-machine-only, interactive-admin-only. Domain administrators who log into a workstation will not see the SMAA path; service accounts under LOCAL SERVICE, NETWORK SERVICE, or IIS_IUSRS are unaffected.

Key idea: A genuine architectural ceiling on consent-prompt elevation: the prompt is a UI element; the boundary is the credential gate; the gate is only as strong as the user's resistance to social engineering. Closing the gap requires out-of-band consent (smartcard, phone push) or per-action policy without human consent in the loop (EPM's automatic mode). Neither is the default.

Four limits, four sentences. The next section walks the concrete evidence of what actually leaked in the pre-GA Insider Preview builds, and what Microsoft did about it.

12. Forshaw's nine bypasses, classified

Between October 2024, when Administrator Protection first appeared in Insider Preview build 27718, and October 2025, when KB5067036 made the feature available on stable Windows, James Forshaw of Google Project Zero audited the mechanism and found nine separate silent-bypass paths. Microsoft fixed all nine -- either in the KB5067036 ship or in subsequent security bulletins [@forshaw-pz-jan2026]. The fact pattern is the structural confirmation that Administrator Protection is now treated as a security boundary. Under the UAC classification, none of those nine would have received CVEs. Each one would have been a quality bug. The bypass canon ran for twenty years without bulletins. The fact that the first cohort of Administrator Protection bypasses produced nine bulletin-eligible fixes is exactly the change in posture the classification change implies.

All the issues that I reported to Microsoft have been fixed, either prior to the feature being officially released (in optional update KB5067036) or as subsequent security bulletins. -- James Forshaw, *Bypassing Windows Administrator Protection*, Google Project Zero, January 26, 2026 [@forshaw-pz-jan2026]

Walk the nine as three classes.

The lazy DOS device directory hijack

The single most interesting vulnerability in the feature's history; Forshaw's January 26, 2026 deep analysis [@forshaw-pz-jan2026]; Project Zero issue 432313668 [@pz-issue-432313668]. The mechanism turns on a behaviour change Administrator Protection itself introduced. Every SMAA elevation gets a fresh logon session, which means the per-logon-session DOS device object directory at \Sessions\0\DosDevices\<LUID> is not created at SMAA logon time. The kernel routine SeGetTokenDeviceMap creates the directory lazily, on the first reference. The owner of the new directory is the owner of the access token that triggered the creation [@forshaw-pz-jan2026, @theregister-2026].

The impersonation level (`SecurityIdentification`) at which an impersonating thread can read security information about the impersonated token -- the SID set, the privilege set -- but cannot perform privileged operations or open kernel objects as the impersonated user. The kernel allows access checks to consult an identification-level token for *reading* the security information; certain code paths inadvertently use that information for *granting* operations, which is the structural primitive Forshaw's lazy DOS device directory exploit depends on [@forshaw-pz-jan2026].

The SECURITY_IMPERSONATION_LEVEL enumeration in winnt.h defines four levels in ascending order: SecurityAnonymous (value 0), SecurityIdentification (1), SecurityImpersonation (2), SecurityDelegation (3). SecurityIdentification is the second-lowest -- it sits one above SecurityAnonymous -- and is the level Windows uses when it wants to ask the kernel "what would this token be allowed to do?" without actually doing the operation. The trap is when a code path that runs as the caller uses an identification-level impersonation to read a token property -- here, the linked-token field -- and the resulting object inherits the caller's owner SID rather than the impersonated token's.

The exploit chain. An attacker running as the primary user (filtered token, Medium integrity) starts an elevation. Before the SMAA process touches its DOS device directory, the attacker impersonates the SMAA's TokenLinkedToken at identification level and triggers a code path that walks the directory. The kernel creates \Sessions\0\DosDevices\<SMAA_LUID> lazily; in the affected code path, the owner of the new directory becomes the attacker's primary token's owner SID rather than the SMAA's.

The attacker plants a C: symbolic link inside the directory pointing at an attacker-controlled location. When the elevated SMAA process loads its DLLs, the resolution walks \Sessions\0\DosDevices\<SMAA_LUID>\C: first; the symlink redirects the load to the attacker's directory; the attacker's DLL runs in the High-integrity SMAA process [@forshaw-pz-jan2026].

sequenceDiagram participant Att as Attacker (limited user) participant Kern as "Kernel (SeGetTokenDeviceMap)" participant SMAA as SMAA elevated process

Note over SMAA: Fresh logon session -- DOS device dir not yet created
Att->>Att: Impersonate SMAA TokenLinkedToken at Identification level
Att->>Kern: Reference \Sessions\0\DosDevices\<SMAA_LUID>
Kern->>Kern: Lazy-create directory
Note over Kern: Owner SID inherited from impersonating token
Att->>Kern: Create C: symlink under attacker control
SMAA->>Kern: Resolve C: at first DLL load
Kern-->>SMAA: Returns attacker symlink target
SMAA->>SMAA: Load attacker DLL at High integrity

What makes this bypass extraordinary is that it is caused by the feature's design. Pre-Administrator-Protection, the user's primary logon session was created at desktop logon and the DOS device directory existed before any elevation. Lazy directory creation never came up. The SMAA design's "fresh logon session per elevation" property -- the same property Forshaw's January 2026 pull-quote in §7 establishes via the credential-less LSA logon -- is exactly the precondition the lazy-creation path exploits.

Microsoft's pre-GA fix has two parts. First, the manifest-parsing access check uses the SYSTEM-impersonating-the-low-user identity rather than the user's primary token. Second, the DOS device directory is materialised with the correct owner before any user-controlled code path can trigger the lazy-creation path [@forshaw-pz-jan2026]. The Register's coverage of the disclosure noted "the most notable of the nine bugs he reported was a Logon Sessions flaw that relied upon five different Windows behaviors. He added that he likely only found it because he was previously familiar with the OS's 'weird behavior when creating the DOS device object directory'" [@theregister-2026].

The five UI Access bypasses

Forshaw's February 2026 post details the second class, comprising five of the nine bypasses [@forshaw-pz-feb2026]. UI Access is a token flag retrofitted in Vista to let accessibility applications cross UIPI. To qualify, an executable needs three things: a manifest declaring uiAccess="true", a trusted code-signing certificate, and an installation location under an administrator-only directory (typically %ProgramFiles%). The Application Information service's RAiLaunchAdminProcess endpoint launches qualifying UI Access processes without showing the consent prompt, on the theory that the three-criteria check is itself sufficient evidence of administrator approval [@forshaw-pz-feb2026].

The token flag (`TOKEN_UIACCESS`) that allows a process to interact with windows of higher integrity level than its own, bypassing User Interface Privilege Isolation. UI Access is meant for accessibility software (screen readers, on-screen keyboards) that needs to interact with elevated UI. To qualify, an executable must carry a `uiAccess="true"` manifest, a trusted code-signing certificate, and an administrator-only installation directory; qualifying processes run without showing the consent prompt and at integrity level High [@forshaw-pz-feb2026].

Under classic UAC, a UI Access process ran with the filtered standard-user token bumped from Medium to High integrity -- not with the full admin token. Forshaw's February 2026 post states the mechanism verbatim: "the service will take a copy of the caller's access token, enable the UI Access flag and increase the integrity level... If the caller is a limited user of an UAC administrator it will set the integrity level to High" [@forshaw-pz-feb2026].

Under Administrator Protection, the pre-GA design preserved that behaviour unchanged: the UI Access process inherited the limited user's primary token (not the SMAA's), bumped to High integrity. That decision was the structural flaw. A High-integrity process under the limited user can interact with the SMAA's windows whenever a High-integrity SMAA process exists on the same desktop, send messages to them, read clipboard data, and -- through GetProcessHandleFromHwnd -- obtain a process handle on the SMAA process that lets the limited-user process inject code into it.

The five UI Access variants exploit different sub-categories of the same structural property. The Quick Assist binary, a remote assistance application on Windows 10 and 11 that carries the uiAccess flag, is one such variant; R41N3RZUF477 published a public proof-of-concept that exploits the BrowserExecutableFolder group policy to make Quick Assist load WebView2 from an attacker-controlled directory [@quickassist-bypass]. The remaining four exploit, respectively, weaknesses in the secure-application-directory check, the manifest parsing routine, COM marshalling in UI Access contexts, and message-only window handling [@forshaw-pz-feb2026].

Microsoft's pre-GA fix is structural: UI Access processes no longer run as the limited user. They are created with a filtered copy of the SMAA's token (the SMAA's SID, the SMAA's profile, but with SeLoadDriverPrivilege and similar removed). Profile separation is restored at the cost of a more complex token-creation path [@forshaw-pz-feb2026].

The remaining three: implementation flaws

The third class -- three bypasses described by Forshaw only as "implementation flaws and long-standing UAC issues" -- is not detailed publicly [@forshaw-pz-jan2026]. The article does not invent details. Forshaw names the category and cites the framing; the engineering specifics are presumably in Microsoft Security Response Center advisories or are still under disclosure. What can be said is that two of the three appear from Forshaw's framing to be UAC-era bugs that Administrator Protection inherited rather than introduced, and one is an Administrator-Protection-specific implementation flaw.

The bypass canon ran for twenty years without bulletins. The fact that all nine pre-GA Administrator Protection bypasses received fixes -- including a deep one rooted in the feature itself -- is the structural confirmation that the elevation path is now a boundary. The next section asks why Microsoft pulled the feature in December 2025.

13. The compatibility surface and the December 2025 revert

About one month after KB5067036 made Administrator Protection available, Microsoft pulled it. Forshaw, writing in January 2026, gives the canonical attribution: "As of 1st December 2025 the Administrator Protection feature has been disabled by Microsoft while an application compatibility issue is dealt with. The issue is unlikely to be related to anything described in this blog post so the analysis doesn't change" [@forshaw-pz-jan2026]. Microsoft Learn confirms: "The feature previously listed in the October 2025 non-security update (KB5067036) has been reverted and will roll out at a later date" [@ms-admin-protection, @ms-kb5067036].The November 2025 KB5067036 amendment is worth knowing. Microsoft included an unrelated fix for an AutoCAD MSI-repair UAC-prompt regression in the same cumulative; that fix shipped and was not reverted. The WebView2 installer regression is what caused the Administrator Protection revert specifically [@ms-kb5067036].

The structural causes. The Windows Developer Blog (May 2025) [@ms-developer-blog-2025] enumerates the surface where applications break under the SMAA model.

Single sign-on does not cross. Domain and Microsoft Entra credentials cached for the primary user's session are not available inside the SMAA's session. Any elevated process touching Microsoft Graph, Entra ID, or Kerberos-protected resources must re-authenticate. The login dialogs an elevated installer triggers are not failures of the application; they are consequences of the separated logon session.
Network drives do not carry. Drive-mapping in the primary user's session is not inherited by the SMAA. Installers that mount network shares to install per-machine components break. The workaround for affected installers is to use UNC paths directly rather than drive letters.
Library folders diverge. Files saved to Documents, Desktop, Downloads, or Pictures from an elevated app land in C:\Users\ADMIN_<random>\ rather than the primary user's home. A user clicks Save in an elevated text editor and saves to "Documents"; from their own Explorer, the file is invisible.
HKCU diverges. Application settings -- theme, recent-files lists, per-user COM registrations, last-opened paths -- live in the SMAA's HKCU, not the primary user's. The canonical example in Microsoft's documentation is Notepad's dark-mode theme [@ms-developer-blog-2025]: the primary user sets the theme; an elevated Notepad opens in the default theme; the two sessions never agree.
WebView2 installers fail. The error message "Microsoft Edge can't read and write to its data directory" is the recognisable symptom of an installer that assumes one shared profile. The WebView2 runtime stores per-user state in AppData\Local\Microsoft\EdgeWebView\ under whichever profile is active at install time; if the runtime is installed under the SMAA's profile and then used by an unelevated application running as the primary user, the data-directory write fails. This is the regression that triggered the December 2025 revert.
Hyper-V and WSL incompatibilities. Microsoft Learn explicitly tells IT administrators not to enable Administrator Protection on devices that require Hyper-V or WSL [@ms-admin-protection].
Visual Studio. Microsoft's own development environment is "not supported in such a configuration" when run elevated. Extensions don't carry; settings don't carry; project-dialog paths point at the SMAA's profile rather than the developer's actual workspace.

Note: Microsoft Learn explicitly excludes Hyper-V and WSL devices from the recommended enablement set [@ms-admin-protection]. Symptoms of incorrect enablement include WSL distribution startup failures (the WSL service runs under a different account from the launching user, and the SMAA's logon-session-isolation properties interact badly with WSL's named-pipe communication) and Hyper-V Manager connection errors that are difficult to attribute to the elevation model.

I guess app compatibility is ultimately the problem here, Windows isn't designed for such a radical change. I'd have also liked to have seen this as a separate configurable mode rather than replacing admin-approval completely. -- James Forshaw, *Bypassing Windows Administrator Protection*, Google Project Zero, January 26, 2026 [@forshaw-pz-jan2026] Administrator Protection is the right architecture, and the compatibility surface is the bill of materials for twenty years of admin-as-default assumption. Application developers have written installer logic, theme-persistence code, drive-letter assumptions, and HKCU-shared state into shipping software for two decades, on the structural premise that the elevated process and the unelevated user share a profile. The December 2025 revert is the first iteration's learning round, not a structural failure. The same revert pattern accompanied the Windows Vista UAC rollout in 2006-2007, the Windows 7 auto-elevation introduction in 2009 (which itself softened the Vista prompt fatigue at the cost of the bypass canon), and the Smart App Control rollout in Windows 11 22H2. Microsoft will re-enable Administrator Protection when the WebView2 regression and a handful of installer-pattern fixes have shipped.

The architecture survives audit. The deployment is held back by twenty years of accumulated software assumptions. The next section asks what tools defenders now have that they did not have before.

14. The audit and detection surface

Every privileged operation on a device with Administrator Protection enabled now generates an ETW (Event Tracing for Windows) event in the Microsoft-Windows-LUA provider [@ms-admin-protection]. This is the first time the elevation pipeline itself is the source of a stable, operationally useful audit trail.

The basics.

Provider: Microsoft-Windows-LUA, GUID {93c05d69-51a3-485e-877f-1806a8731346}.
Event ID 15031: Elevation Approved.
Event ID 15032: Elevation Denied or Failed.

Each event carries the caller user SID, the application name and path, the elevation outcome, the SMAA used to host the elevation, and the authentication method (Hello PIN, biometric, password) [@ms-admin-protection]. The authentication method field records the primary user's Hello credential, not the SMAA's; the SMAA's authentication in step 6 of §7 is the credential-less LSA logon and has no method field of its own. The Microsoft Learn-documented logman invocation to capture the trace is short:

The Event Tracing for Windows provider that surfaces Administrator Protection elevation events. Provider GUID `{93c05d69-51a3-485e-877f-1806a8731346}`. Event ID 15031 marks an elevation that succeeded; Event ID 15032 marks an elevation that was denied or failed. Each event carries fields for the caller's SID, the application path, the elevation outcome, the SMAA used, and the authentication method [@ms-admin-protection].

{` // Pseudocode for a detection pipeline that reads ETW Event 15031 // (Administrator Protection elevation approved) and flags unusual // application paths per SMAA correlation key.

const allowList = new Set([ 'C:\\Windows\\System32\\mmc.exe', 'C:\\Windows\\System32\\regedit.exe', 'C:\\Windows\\System32\\cmd.exe', 'C:\\Program Files\\Microsoft VS Code\\Code.exe', ]);

function onEtwEvent(event) { if (event.provider !== 'Microsoft-Windows-LUA') return; if (event.id !== 15031) return;

const smaa = event.fields.shadowAccountName; const app = event.fields.applicationPath; const auth = event.fields.authenticationMethod; const user = event.fields.callerUserSid;

if (!allowList.has(app)) { emit({ severity: 'high', title: 'Unexpected elevation under Administrator Protection', smaa, app, auth, user, hint: 'Was the Hello prompt phished?' }); } } `}

Note: For detection engineers, the ADMIN_<random> name is the highest-value correlation key on the device. It is stable per primary admin (the SMAA name is created once and persists across elevations), distinct from the limited-user SID (the SMAA has its own SID, so user-by-SID correlations and SMAA-by-name correlations are independent axes), and present in every ETW 15031 / 15032 event. A detection rule that groups elevations by SMAA name and flags unexpected application paths is the canonical "someone phished a Hello prompt" alert pattern.

Defenders now have the audit trail they did not have under UAC. The next section asks what residual attack surface survives the SMAA architecture, the Hello gate, and the new audit trail.

15. Open problems: what survives

Five residual attack surfaces, each acknowledged in Microsoft's own documentation, Forshaw's Project Zero posts, or the operational literature on Windows privilege escalation.

The user is still the weak link. Every elevation depends on a human accepting the prompt. The Hello credential gate makes that human's decision more costly to fake than the classic Yes/No, but the gate does not change the fact that a successful prompt is a successful elevation. The three sub-cases of consent-without-identity-verification from §9 -- unattended-session, habituated-click, pretext click-through -- are cost-raised, not closed. Phishing-the-prompt remains a live attack surface and Microsoft does not classify it as a vulnerability [@forshaw-pz-jan2026]. Out-of-band consent -- a phone-push approval channel, a smartcard tap, a separate hardware key tap -- would close the gap; none of these is the Administrator Protection default.

Loopback authentication. The structural property that Windows services authenticate to themselves over the local network stack is independent of the SMAA model. SMB to localhost, Kerberos against the local machine account, NTLM challenge-response between processes on the same box -- these protocols predate UAC and are not changed by Administrator Protection. Forshaw's broader 2022 Kerberos research [@forshaw-2022-rbcd] catalogues the class. The NTLMless article in this series covers SMB signing, Extended Protection for Authentication (EPA), and channel binding mitigations that defenders should pair with Administrator Protection to close the loopback path.

Service-account SeImpersonatePrivilege. The Potato lineage of attacks (cataloged in the Access Control article in this series) runs in service accounts (IIS_IUSRS, LOCAL SERVICE, NETWORK SERVICE), not in interactive admin sessions. Administrator Protection scopes itself to interactive admin elevation; the Potato class is structurally out of scope.

Service-account Potato attacks run inside `IIS_IUSRS`, `LOCAL SERVICE`, and `NETWORK SERVICE` rather than in interactive admin sessions. The attacker has compromised a service that holds `SeImpersonatePrivilege`, then uses one of several primitives (the SSPI / NEGOEX dance, the EFS RPC interface, a printer-spooler endpoint) to coerce a higher-privileged service into authenticating against the attacker's local socket, and impersonates the resulting token. Administrator Protection's promise is around the *interactive elevation* path -- the flow from a logged-in user clicking an installer to an elevated process running. Potato is a separate problem class with its own mitigations: removing `SeImpersonatePrivilege` from service accounts that don't need it, applying EPA, and patching the named primitives one by one.

Driver loading once inside an SMAA elevation. Admin equals kernel applies once a process is running inside the SMAA. Vulnerable-driver loading, kernel-mode code execution, and rootkit installation fall under the §11 "admin equals kernel" ceiling -- WHQL signing, the Vulnerable Driver Blocklist, App Control for Business, and HVCI remain the four-mechanism mitigation surface, with the App Identity article in this series covering the App Control mechanism. Administrator Protection does not change the relationship between admin and kernel; it changes the relationship between standard user and admin.

The Hello credential phishing surface. The prompt now phishes a real credential rather than a click-through approval. A malicious application that successfully argues its case to the user gets a Hello gesture against the primary user's PIN or biometric. The credential remains hardware-rooted; ESS-engaged biometrics never leave the TPM or Pluton enclave; the malware does not learn the PIN. But the malware does get the elevation. The Windows Hello article in this series covers FIDO2 / ESS / PIN architecture hardening. Defender-side mitigation is the ETW 15031 / 15032 detection rule set on unexpected application paths [@ms-admin-protection].

The boundary is real, the audit trail is new, and the five-class residual surface is the next decade of work. The next section turns to operator-side practicalities.

16. Practical guide

Six tips, each tied to one Microsoft Learn or Windows Developer Blog primary source. Remember that, as of December 2025, Microsoft has reverted the rollout and the feature is currently disabled on stable Windows; the guidance below applies once Microsoft re-enables it. The Spoiler below contains the verbatim commands.

Enable. Set TypeOfAdminApprovalMode = 2 via Group Policy ("User Account Control: Configure type of Admin Approval Mode" -> "Admin Approval Mode with Administrator Protection") or via the Intune Settings Catalog OMA-URI. A reboot is required for the new policy to take effect [@ms-admin-protection, @ms-kb5067036].
Verify. Run whoami in an elevated console. The profile name shows ADMIN_<random>. Run whoami /priv to confirm the SMAA has the Administrators group enabled [@ms-admin-protection, @call4cloud-osint].
Capture. Start the ETW trace with the documented logman invocation; filter for Event IDs 15031 and 15032 [@ms-admin-protection]. The provider GUID is stable across builds.
Do not enable on devices that require Hyper-V or WSL. Re-evaluate when Microsoft re-enables the broad rollout [@ms-admin-protection, @forshaw-pz-jan2026].
For application developers, follow the Windows Developer Blog (May 19, 2025) guidance [@ms-developer-blog-2025]: install per-user packages unelevated; use %ProgramFiles% (and accept the elevated install path); avoid context switching during install; avoid sharing files between elevated and unelevated profiles; remove auto-elevation dependencies. The auto-elevation manifest attribute is no longer honoured under Administrator Protection, so any installer that relied on silent elevation needs to be reworked.
For IT admins on already-enabled devices broken by an elevated install: disable Administrator Protection temporarily, reinstall the application unelevated, then re-enable [@ms-developer-blog-2025].

Enable via Group Policy registry value (administrator console, persists across reboots):

# Set TypeOfAdminApprovalMode to 2 (Admin Approval Mode with Administrator Protection)
reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System" /v TypeOfAdminApprovalMode /t REG_DWORD /d 2 /f
# Reboot required:
shutdown /r /t 0

Capture the elevation event trace:

logman start AdminProtectionTrace -p {93c05d69-51a3-485e-877f-1806a8731346} -ets
:: After some elevations:
logman stop AdminProtectionTrace -ets
:: Process the .etl with PerfView, Message Analyzer, or:
wevtutil qe Microsoft-Windows-LUA/Operational /q:"*[System[(EventID=15031 or EventID=15032)]]" /f:text

Verify the SMAA presence after enablement:

Get-LocalUser | Where-Object Name -like 'ADMIN_*'
# After an elevation, run from the elevated console:
whoami
# Expect: WIN11-PC\ADMIN_<random16hex>

Note: The single most common mistake in response to an Administrator Protection compatibility problem is to disable UAC globally by setting EnableLUA = 0. This returns the device to the Windows XP single-token model, removes Mandatory Integrity Control enforcement on application processes, and effectively defeats every layer of UAC and Administrator Protection together. It is universally discouraged. The correct fix is per-application, via manifest, or per-device, via the documented Administrator Protection compatibility list.

Six tips, one boundary, one operational checklist. The next section answers the most common misconceptions.

17. Frequently asked questions

No. Administrator Protection runs in `appinfo.dll` inside the Application Information service, which runs in `svchost.exe` in VTL0 (the normal Windows kernel context). The SMAA itself is a normal SAM-database account, not a Virtual Secure Mode trustlet. The cross-process protections of Virtualization-Based Security apply to LSASS Credential Guard and a handful of other VTL1 services; the elevation pipeline is not one of them. The Secure Kernel article in this series treats VTL0 / VTL1 separation in detail. Partially. Administrator Protection replaces Admin Approval Mode UAC when `TypeOfAdminApprovalMode = 2`. The credential-prompt path (the over-the-shoulder elevation that asks a standard user to enter an administrator's credentials) and classic Admin Approval Mode (`TypeOfAdminApprovalMode = 1`) coexist with Administrator Protection across different configurations [@ms-admin-protection]. On a device with Administrator Protection enabled, only the interactive admin's elevation path goes through the SMAA; the standard-user-asking-for-admin-credentials path is unchanged. No. There is absolutely an admin token; it lives in a different account, in a different logon session, for a bounded lifetime. The marketing language describes lifetime and isolation, not nonexistence [@ms-developer-blog-2025, @bleepingcomputer-2024]. The SMAA's token persists for the lifetime of the elevated process; when the process exits, the token handle is released and the logon session is reaped. Between elevations, no SMAA token exists in memory. No. Malware can still elevate if the user accepts the Hello prompt. The boundary Administrator Protection creates is between *silent* elevation and *consented* elevation, not between any elevation and none. Microsoft's design position is explicit: "I expect that malware will still be able to get administrator privileges even if that's just by forcing a user to accept the elevation prompt" [@forshaw-pz-jan2026]. The three sub-cases of consent-without-identity-verification from §9 are cost-raised, not eliminated. What changes is that the elevation must be visible. Defenders gain the ETW 15031 audit trail as a result. No. EPM uses a virtual elevated account on a per-request basis with cloud-side policy, and the virtual account is *not* a member of the local Administrators group [@ms-epm-overview]. Administrator Protection uses a persistent local SMAA per admin user, with on-box `appinfo.dll` policy, and the SMAA *is* a member of the local Administrators group [@call4cloud-osint]. EPM is centrally policy-driven and works on standard-user devices; Administrator Protection is per-device architecture and applies only to interactive admin users. The two can coexist on the same device. No. Per Microsoft Learn, remote logon, roaming profiles, and backup admins are out of scope [@ms-admin-protection]. A domain administrator who logs into a workstation interactively will not see the SMAA path. Microsoft has stated that domain scenarios may be added in future iterations; the current GA-target form is local-machine-only, interactive-admin-only. No. Mimikatz inside the elevated SMAA session still has `SeDebugPrivilege` and can call `OpenProcess` on `lsass.exe` to dump LSASS unless LSA Protection (Run As Protected Process Light) and Credential Guard are also enabled. Administrator Protection protects the *elevation path*; it does not protect the *resulting privileged session*. To protect the privileged session, pair Administrator Protection with LSA Protection (`RunAsPPL=1`), Credential Guard, App Control for Business, and HVCI. The Secure Kernel article in this series covers the LSA Protection mechanism.

The misconceptions are cleared. The next section returns to the opening hook with the new vocabulary the article has built.

18. The user-elevation companion to Credential Guard

Return to the two whoami /all outputs from §1, this time with the vocabulary the article has built.

The first output shows the primary user under classic UAC. One SID, one profile, one HKCU, one logon-session LUID; the elevated console is the same user as the unelevated console, distinguished only by the integrity level on the token.

The second output shows the same login under Administrator Protection. A different user name -- ADMIN_<random> -- with a different SID linked to the primary admin via ShadowAccountForwardLinkSid and ShadowAccountBackLinkSid. A different profile under C:\Users\ADMIN_<random>\. A different NTUSER.DAT mapped as HKCU. A fresh authentication-ID LUID minted by LSASS through the credential-less logon path described in §7, on the strength of appinfo.dll's trusted request and a Hello gesture the primary user just performed. An ETW Event 15031 in the Microsoft-Windows-LUA provider, freshly emitted, recording the elevation as approved, the application path, and the authentication method.

The thesis lands. The elevation path is now itself a security boundary, with bulletin-grade fixes when it fails. Administrator Protection is the user-elevation companion to Credential Guard. Where Credential Guard isolated LSA secrets from admin-equals-kernel inside the machine -- the Secure Kernel article in this series covers the VBS-rooted isolation in detail -- Administrator Protection isolates the elevation path from the standard-user session. The two answer the two halves of the question the foundational Access Control article in this series left open: if admin equals kernel and tokens are bearer credentials, what is left to harden? The answer is the path that gets you there (Administrator Protection) and the data that is there once you arrive (Credential Guard).

The December 2025 revert is the first iteration's learning round. The architecture is the right one. The application base catches up next. Forshaw's framing in February 2026 -- that Microsoft might have shipped this as a configurable mode rather than replacing admin approval completely -- is a reasonable critique, and the re-enablement is likely to address it. Until then, the operational reality on most stable Windows devices is the classic split-token model, with all the bypass canon it implies, and the SMAA design remains an Insider-Preview-and-policy-opted-in posture.

What stays unchanged is the structural insight. The mechanism Microsoft used to make the elevation path a boundary is not novel; multi-user accounts have shipped in Windows NT since 1993. What changed is the classification. Microsoft accepted, after twenty years of evidence, that the elevation pipeline needed to be a security boundary, and accepted with it the engineering cost: separate accounts, separate profiles, separate logon sessions, removal of auto-elevation, a credential gate instead of a click-through, an audit-trail ETW provider, and a willingness to ship bulletin-grade fixes for every Forshaw finding. The classification was the engineering decision. Everything else followed.

This is what it took, in mechanism and in time, to make the elevation path real [@forshaw-pz-jan2026].