Parag Mali - tag: access-control

The Integrity-Level Stack: MIC, UIPI, and Twenty Years of UAC's Quiet Plumbing

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

**UAC has never been the consent prompt.** Two Vista-era primitives, Mandatory Integrity Control (MIC) and User Interface Privilege Isolation (UIPI), add an integrity axis to the access check and a windowing-layer analog that blocks cross-IL message injection. The split-token model gives every administrator a Medium-IL filtered token at logon and holds the full admin token dormant. The yellow dialog is the smallest part of the system. Its architect, Mark Russinovich, publicly disclaimed it as "not a security boundary" in February 2007, and twenty years of bypass research has been the empirical confirmation. In November 2024, Microsoft finally moved the boundary line with Administrator Protection. The MIC + UIPI plumbing outlived UAC itself: it is still the substrate of every browser sandbox, every AppContainer, and the Adminless successor in 2026.

1. Two whoami Outputs, Sixty Seconds Apart

Open an unelevated PowerShell on a Windows 11 administrator account. Run whoami /groups /priv. Click "Yes" on the yellow prompt. Open an elevated PowerShell on the same account. Run the same command. The two outputs are different lists of SIDs. Sixty seconds have passed. The consent prompt did not move a single bit of OS state on its own. The operating system did, because of a stack of primitives that ship with every Windows install and that almost no Windows user has ever heard the names of. This article is a tour of that stack, and of what twenty years of bypass research has taught us about it.

Place the two outputs side by side. The user is the same. The session is the same. The clock has barely moved. Read them carefully.

PS C:\Users\admin> whoami /groups /priv | findstr /i "Mandatory Administrators SeDebug"
BUILTIN\Administrators                Group used for deny only
Mandatory Label\Medium Mandatory Level Label
(SeDebugPrivilege not present)

PS C:\Users\admin> whoami /groups /priv | findstr /i "Mandatory Administrators SeDebug"
BUILTIN\Administrators                Enabled by default, Enabled group, Group owner
Mandatory Label\High Mandatory Level   Label
SeDebugPrivilege                       Disabled

Four facts fall out of those two outputs, and each one of them is a foothold for the rest of this article.

The first fact is that the administrator group SID is present in both tokens. It is not added by the elevation. In the filtered token it carries the flag SE_GROUP_USE_FOR_DENY_ONLY, which means the access-check algorithm consults it only when matching a deny ACE and otherwise pretends it is absent [@uac-how-it-works]. In the elevated token, the same SID is fully enabled. The dialog did not add a SID; it changed which token Windows uses.

The second fact is the integrity level. In the filtered token, the mandatory label reads Mandatory Label\Medium Mandatory Level. In the elevated token, the same label reads Mandatory Label\High Mandatory Level. That label corresponds to a well-known SID under the S-1-16-X family (S-1-16-8192 for Medium and S-1-16-12288 for High) [@well-known-sids]. The integrity level is not a regular group SID. It is a separate field on the token, and as we will see in §4, it drives a separate access-check evaluator that runs before the discretionary access check [@mic-doc].

The third fact is the privilege set. The filtered token holds a small set of user-mode privileges (SeChangeNotifyPrivilege, SeShutdownPrivilege, a handful of others). The elevated token holds the full administrator privilege set, including the named ones the security press writes about: SeDebugPrivilege, SeTakeOwnershipPrivilege, SeLoadDriverPrivilege, SeBackupPrivilege, SeAssignPrimaryTokenPrivilege, and twenty or so others, depending on the Windows build [@russinovich-tnm-2007].

The fourth fact is the most subtle, and the one this whole article exists to make rigorous. The yellow dialog did not create the elevated token. The OS created it at logon, almost half an hour before the prompt ever rendered, and held it dormant in the LSA. The prompt asked the user a single question: may I, the operating system, use the token I already have? It did not ask: may I, the operating system, mint a more privileged token now? That distinction is the difference between how every Windows user talks about UAC and how UAC actually works.

Note: The yellow dialog moves no bits. It asks permission to use authority that was already constructed at logon and held dormant. The integrity primitives, MIC and UIPI, do the bounding work whether or not a prompt ever renders.

The four primitives we are about to tour are the substrate beneath everything in those two whoami outputs. Mandatory Integrity Control (MIC) is the access-check evaluator that decided your Medium-IL PowerShell could not write into %SystemRoot%\System32 before any DACL was consulted. User Interface Privilege Isolation (UIPI) is the windowing-layer analog that prevented your Medium-IL Edge tab from injecting WM_SETTEXT into the High-IL elevated PowerShell next to it. The split-token model is the LSA policy that decided your interactive shell should hold the Medium-IL token instead of the High-IL one. The Application Information service (Appinfo) is the SYSTEM-trusted broker that mediated the token swap when you clicked "Yes."

This article walks every one of those layers, then ends at the empirical proof: twenty years of "UAC bypasses," and Microsoft's own quiet acknowledgement, from week one, that the dialog was never the security boundary [@russinovich-blog-2007]. Why did Microsoft build this stack in the first place? What was wrong with how Windows XP did it?

2. The XP Problem and the Vista Bet

On the overwhelming majority of consumer Windows XP installs in 2003, every process the user launched ran as Administrator, because the first interactive account XP provisioned at setup was an Administrator and the typical user never created a separate Limited User account [@margosis-archive]. Every browser tab. Every embedded Word macro. Every drive-by download. The operational vulnerability surface was the entire OS, because authority on Windows is carried in the access token, and the access token of those XP-era user processes held the full administrator SID set.

Sysinternals co-founder Mark Russinovich, then a Microsoft engineer following the 2006 Winternals acquisition, framed the problem precisely in the June 2007 issue of TechNet Magazine: "Most users of Windows XP run with full administrative rights all the time, allowing all software they run, including malware, to have unrestricted access to the system" [@russinovich-tnm-2007]. The sentence reads like a confession, and it was. The OS shipped with a sound access-control model and an operational policy that defeated it from the first reboot.

Two distinct threat models drove the architectural response Vista shipped four years later.

Threat model one: the runaway admin

The first threat model was the runaway admin. Default-admin consumer installs meant malware silently inherited admin authority because the user was the admin. A drive-by exploit in Internet Explorer ran as the user, the user was an admin, and the malware was an admin. There was no point in the OS where a least-privilege boundary could intervene, because the token never carried a least-privilege bound to begin with. The DACLs were correct; the policy that filled the tokens was the failure.

Threat model two: the shatter-attack class

The second threat model was the shatter-attack class. In August 2002, security researcher Chris Paget published a paper titled "Exploiting design flaws in the Win32 API for privilege escalation" on the Bugtraq mailing list, immediately mirrored on Help Net Security [@helpnet-paget]. The paper coined the term shatter attack and demonstrated that on Windows NT, 2000, and XP, any process running on a user's interactive desktop could send a WM_TIMER message carrying a callback function pointer to any other process's message loop on the same desktop. The receiving process would invoke the callback in its own address space, at its own privilege level [@shatter-wiki].

The shatter-attack term is sometimes attributed to Brett Moore alone. Paget's August 2002 Bugtraq paper actually coined the term; Moore's Black Hat USA 2004 talk Shoot The Messenger: Win32 Shatter Attacks productised the technique class and brought it to a wider conference audience. Both attributions are correct for different artifacts.

This was an architectural defect. The receiving process did not authenticate the message origin. It could not, because the Win32 messaging system was designed in the late 1980s under the assumption that all windows on a desktop belonged to one trust principal. By 2002, that assumption had been false for a decade: services ran on the user's interactive desktop with LocalSystem authority, and the user's browser could send them messages.

Microsoft's December 2002 patch (security bulletin MS02-071) fixed individual services that exposed the most exploitable callbacks. It did not fix the architectural class, because the class was a property of the Win32 messaging design, not of any one service [@shatter-wiki].

The popular history of the shatter-attack class collapses two separate authorship events into one. Chris Paget's August 2002 Bugtraq paper coined the term and produced the original demonstration tool (which Paget called "Shatter") [@helpnet-paget]. Brett Moore's Black Hat USA 2004 talk *Shoot The Messenger: Win32 Shatter Attacks*, eighteen months later, productised the technique into a conference-grade reference talk and contributed additional disclosure work at Security-Assessment.com.

Both attributions are accurate for different artifacts: Paget for the term and the August 2002 paper, Moore for the Black Hat 2004 productisation. The Wikipedia Shatter attack article preserves both authorships verbatim [@shatter-wiki]. The reason the disambiguation matters: any historical account of Vista's UIPI design decision must attribute the threat-model framing correctly, because Microsoft cited Paget's 2002 paper, not Moore's 2004 talk, in the internal architectural discussions Russinovich later summarised [@russinovich-blog-2007].

The Vista bet, stated as four design decisions

Between 2005 and 2006, Microsoft made four decisions about how Vista would respond. The first was to split the administrator's authority by default: an admin user would not hold a single admin token at logon, but a filtered token plus a dormant linked one. The second was to mediate the recombination through an OS-controlled UI surface, so the user could see and consent to the moment authority crossed an integrity boundary. The third was to add a second access-check axis (integrity) that the DACL could not override. The fourth was to add a windowing-layer analog to close the cross-IL variant of the shatter-attack class.

All four shipped together. Vista RTM'd on November 8, 2006 to OEMs and businesses, and Microsoft launched it to consumers on January 30, 2007 [@vista-press-release]. The press release called it "the most significant product launch in Microsoft Corp.'s history."

The architectural canon was published five months later, in the June 2007 issue of TechNet Magazine under the title Security: Inside Windows Vista User Account Control [@russinovich-tnm-2007]. The author was Russinovich, and the article became the single most-cited primary on UAC in the Windows-security literature. Five months earlier, however, in a TechNet Blogs post about PsExec, the same author had quietly written something the entire later debate would rest on, and almost no one read it for what it actually said [@russinovich-blog-2007]. We will return to that post in §7. First, the harder question: why couldn't NT's existing access-control model handle any of this on its own?

3. Why the DACL and the Privilege Were Not Enough

Windows NT had the access-control model from day one. It had Security Identifiers (SIDs), access tokens, discretionary access control lists (DACLs), privileges, and an access-check algorithm with a name (SeAccessCheck) that the kernel exposed and documented [@access-control][@windows-internals]. The model was correct in theory and broken in practice. To see why, watch what happens when an XP administrator opens a malicious Word document.

The user double-clicks the document. Word starts. Word loads the document's embedded macro. The macro calls URLDownloadToFile and writes evil.exe into %TEMP%. Then it calls CreateProcess on evil.exe. The new process inherits its parent's primary access token, which is the user's interactive token, which carries the administrator group SID, enabled, with the full administrator privilege set. The DACL on HKLM\SYSTEM\CurrentControlSet\Services grants Full Control to BUILTIN\Administrators. The malware writes a new service entry. The malware now persists across reboots, all without a single elevation prompt, because there was no elevation transition to prompt at. The user was already the administrator [@russinovich-tnm-2007].

The first problem is in the D of DACL. Discretionary access control lists are discretionary by definition: the owning principal of an object decides who has access [@dacls-control]. An attacker running as the user can rewrite any DACL the user owns. That is not a bug; it is the meaning of the word discretionary. Mandatory access-control models (Bell-LaPadula 1973 [@blp-wiki], Biba 1977 [@biba-wiki]) exist precisely because discretionary models cannot defend against principals running with the owner's authority.

The second problem is in the privilege model. A Windows access token carries a list of named privileges such as SeDebugPrivilege, SeTakeOwnershipPrivilege, SeLoadDriverPrivilege. Each privilege is a per-token authorisation to bypass some specific DACL check. An admin token holds them all. There is no way in the NT 4.0 / 2000 / XP design to say "this Word process holds the admin's identity but should not be trusted to use SeDebugPrivilege." Privileges are granted to tokens at logon, and the only way to remove them from a downstream process is to construct a restricted token explicitly, by hand, with CreateRestrictedToken [@createrestrictedtoken].

Generation 1: the seven-year failure to make least-privilege voluntary

Between 1999 and 2006, Microsoft and the Windows security community tried five different ways to make least privilege voluntary. None of them worked at consumer scale.

CreateRestrictedToken is a Win32 API, documented since Windows XP and Server 2003, that produces a copy of an existing access token with selected SIDs marked deny-only, selected privileges removed, and an optional list of restricting SIDs added [@createrestrictedtoken]. It is the kernel primitive every later sandbox (Chromium's renderer sandbox, AppContainer, Office Protected View) is built on. It was a primitive, not a policy. A consumer install with default-admin logons could not use it without an opt-in from every application vendor.

runas.exe, shipped in Windows 2000, let a user explicitly launch a process under a different identity. The user was supposed to log in as a standard user and runas an administrator account when needed. In practice, the user logged in as the administrator and forgot the standard account existed.

Software Restriction Policies (SRP), shipped with Windows XP, let a domain admin define hash, path, certificate, or zone rules that the OS enforced at process creation [@srp-2003]. SRP was a policy mechanism on top of the SAFER substrate [@winsafer]. It worked when configured. On consumer Windows it was off by default; on enterprise Windows it was configured by the few who knew it existed.

Aaron Margosis, then a Microsoft consultant, ran a years-long blog campaign called "Non-Admin" arguing that ordinary users should log in as standard users and only elevate when necessary. His tooling included LUA Buglight (which diagnosed which OS calls a misbehaving application made that required admin privilege), MakeMeAdmin (a runas shim), and PrivBar (a status-bar widget that displayed the IL of the current process) [@margosis-archive]. The blog became required reading inside Microsoft and the Windows-admin community.

Margosis's writing documents the daily friction of being a non-admin on XP. A printer-driver installer fails because it writes a per-user setting to `HKLM`. A game launcher fails because it writes save files to `%ProgramFiles%`. A 1998 line-of-business app fails because it stores its INI file under its install directory. Each failure was the application's fault; in aggregate, the application population rendered non-admin operation untenable for the typical user [@margosis-archive].

Margosis's own pattern, openly discussed on the blog, was to give up on per-application diagnosis and log in as Administrator full-time, while documenting the friction professionally so Microsoft could harvest the data for Vista's compatibility shims. The primitives existed (CreateRestrictedToken, SRP, the SAFER substrate). The third-party software base rendered them unusable. That dataset is the reason Vista shipped file and registry virtualisation as a built-in shim [@russinovich-tnm-2007]: the only alternative was for every application vendor to fix their software, and Margosis's blog had documented for half a decade that this was not happening.

The lesson Microsoft took from the 1999-2006 experience was that voluntary least privilege does not scale. You cannot solve the runaway-admin problem with policy and exhortation. You need an architectural primitive that runs by default, bounds authority by integrity rather than by identity, and absorbs the legacy of applications written for unrestricted admin without breaking them. All four primitives of the Vista bet shipped together in November 2006 [@vista-press-release].

What does an integrity primitive look like, and how is it different from "another ACE"?

4. The Twin Primitives: MIC and UIPI

4.1 Mandatory Integrity Control

An access-check evaluator that compares the integrity level of a subject token to the integrity level of a target object before consulting the object's DACL. MIC denials short-circuit the access check; a Low-IL principal cannot write to a Medium-IL object regardless of what the DACL says.

The load-bearing fact about MIC is in a single sentence on the Microsoft Learn reference page, and the entire architectural difference between MIC and "just another ACE" lives in that sentence. MIC "evaluates access before access checks against an object's discretionary access control list (DACL) are evaluated" [@mic-doc].

Pause on that ordering. Before the DACL. Not together with it. Not after it. The integrity-level check is a separate evaluator that runs first, and its denial is final. If the IL check denies access, the DACL is never consulted, no matter what the DACL says. That is what the word mandatory in Mandatory Integrity Control means.

A well-known SID, carried on every Windows access token and every securable object, that orders subjects and objects on a seven-level integrity lattice (Untrusted, Low, Medium, Medium Plus, High, System, Protected Process).

The seven well-known integrity-level SIDs are defined in the Well-known SIDs reference page on Microsoft Learn [@well-known-sids].

Integrity level	RID (S-1-16-X)	Typical use
Untrusted	`S-1-16-0`	Most-restricted sandboxes; rare on consumer Windows
Low	`S-1-16-4096`	IE Protected Mode, AppContainer, Edge / Chrome renderers
Medium	`S-1-16-8192`	Default for interactive user processes
Medium Plus	`S-1-16-8448`	UI-Access processes (`uiAccess=true` manifest, Windows 7+)
High	`S-1-16-12288`	Elevated administrative processes
System	`S-1-16-16384`	Kernel-mode and `LocalSystem` services
Protected Process	`S-1-16-20480`	PPL-protected processes (LSASS with `RunAsPPL`, antimalware)

The Microsoft Learn MIC reference page describes the operational set as four integrity levels (low, medium, high, system) [@mic-doc]. The Well-known SIDs reference page enumerates seven [@well-known-sids]. Both framings are correct: Untrusted is rare on consumer systems, Medium Plus is a UI-Access-only quirk used by accessibility software, and Protected Process overlaps with Protected Process Light signing-level semantics rather than the canonical IL pipeline. The four-vs-seven discrepancy is a documentation artifact, not an inconsistency in the kernel.

The IL lives on a token in the TokenIntegrityLevel field, retrievable through GetTokenInformation and the TOKEN_MANDATORY_LABEL structure [@mic-doc]. The IL lives on an object in the system access control list (SACL) as a SYSTEM_MANDATORY_LABEL_ACE, a special ACE type that carries the object's IL SID and a mandatory-policy mask [@mandatory-label-ace]. Three policy bits are defined in the winnt.h header [@mandatory-label-ace].

SYSTEM_MANDATORY_LABEL_NO_WRITE_UP (0x1) -- default. A subject at lower IL cannot write to this object.
SYSTEM_MANDATORY_LABEL_NO_READ_UP (0x2) -- opt-in. A subject at lower IL cannot read this object.
SYSTEM_MANDATORY_LABEL_NO_EXECUTE_UP (0x4) -- opt-in. A subject at lower IL cannot execute this object.

Object authors who do not specify a mandatory label inherit the default, which is NO_WRITE_UP only [@mic-doc]. The opt-in policies are exactly that: opt-in. A High-IL process that wants its files invisible to a Medium-IL process must explicitly request NO_READ_UP on the SACL. By default, MIC bounds writes, not reads, and that is one of the structural shapes Forshaw's 2017 "Reading Your Way Around UAC" series exploited [@forshaw-reading-uac].

The "regardless of DACL" property is the part to read slowly. A Low-IL principal cannot write to a Medium-IL object "even if that object's DACL allows write access to the principal," because the IL check runs first and short-circuits the access decision before the DACL evaluator ever sees the request [@mic-doc]. This is the difference between adding "another ACE" for integrity and adding a separate evaluator that runs first. An integrity ACE in the DACL would have been overridable by the object owner, because DACLs are discretionary. A mandatory-label ACE in the SACL is enforced by SeAccessCheck itself, independently of any other ACE in the DACL.

flowchart TD A["Subject requests access
(SID set, IL, desired access)"] --> B["MIC evaluator
compares subject IL to object IL
against NO_WRITE_UP / NO_READ_UP policy"] B --> C{"IL check allows
requested access?"} C -- "No" --> D["ACCESS_DENIED
(DACL not consulted)"] C -- "Yes" --> E["DACL evaluator
walks ACEs in order
(deny first, then allow)"] E --> F{"DACL grants
requested access?"} F -- "Yes" --> G["ACCESS_GRANTED"] F -- "No" --> H["ACCESS_DENIED"]

The architectural payoff is in the pseudocode of the access-check decision itself. Strip the API noise away and the decision reduces to two evaluators in series. The conceptual ordering is exact.

{` // Pseudocode of the Windows access-check ordering (Vista+). // See Microsoft Learn: Mandatory Integrity Control.

function seAccessCheck(subjectToken, object, desiredAccess) { // Step 1: Mandatory Integrity Control. Runs before the DACL. const subjectIL = subjectToken.integrityLevel; // e.g. Medium = 0x2000 const objectIL = object.mandatoryLabel.integrityLevel; // e.g. High = 0x3000 const policy = object.mandatoryLabel.policy; // bitmask

if (subjectIL < objectIL) { if ((policy & NO_WRITE_UP) && (desiredAccess & WRITE_BITS)) return 'ACCESS_DENIED'; if ((policy & NO_READ_UP) && (desiredAccess & READ_BITS)) return 'ACCESS_DENIED'; if ((policy & NO_EXECUTE_UP) && (desiredAccess & EXECUTE_BITS)) return 'ACCESS_DENIED'; }

// Step 2: only if MIC allowed do we consult the DACL. for (const ace of object.dacl.aces) { if (ace.sid in subjectToken.sids) { if (ace.type === 'DENY' && (ace.mask & desiredAccess)) return 'ACCESS_DENIED'; if (ace.type === 'ALLOW') desiredAccess &= ~ace.mask; if (desiredAccess === 0) return 'ACCESS_GRANTED'; } } return 'ACCESS_DENIED'; // implicit deny if no ACE grants } `}

The naive reading of MIC is "they added another ACE for integrity." The correct reading is that they added a separate axis with its own evaluator that the DACL cannot override. The reader who internalises that ordering can re-derive almost every subsequent design decision Vista made about UAC, AppContainer, IE Protected Mode, and Administrator Protection. A MIC denial is final. The DACL is not consulted. That is what mandatory means.

Key idea: MIC adds a second axis to the access check. The first axis is identity (DACL plus token SIDs); the second is integrity (IL). The two axes are evaluated in order: integrity first, identity second. A failure on the integrity axis short-circuits the entire check, regardless of what the identity axis would have said.

MIC bounds file, registry, and most other securable-object writes across IL boundaries. But the XP-era shatter attacks Paget published in 2002 were not about file writes. They were about cross-desktop message injection in the Win32 windowing layer, and MIC cannot help with that, because window messages do not pass through SeAccessCheck. So Vista shipped a second primitive specifically for the windowing layer.

4.2 User Interface Privilege Isolation

The windowing-layer analog of MIC. UIPI blocks a defined subset of window messages and hook APIs sent from a lower-IL process to a window owned by a higher-IL process on the same desktop, terminating the cross-IL variant of the shatter-attack class.

If MIC is mandatory integrity for objects, UIPI is mandatory integrity for windows. Same idea, different layer of the OS. Same principle: a separate evaluator that runs in the window manager and blocks cross-IL operations regardless of the window's own configuration [@uipi-wiki].

The canonical failed-shatter scenario is short and exact. A Medium-IL malware process calls SendMessage(hwnd, WM_SETTEXT, 0, (LPARAM)"some-attacker-controlled-string") against a window handle (hwnd) belonging to a High-IL elevated PowerShell on the same desktop. On Windows XP, the message would arrive and the elevated PowerShell's edit control would update its text, with no authentication check anywhere in the path. On Vista and every subsequent Windows release, the call returns zero. GetLastError returns ERROR_ACCESS_DENIED. The message is silently dropped by win32k.sys before the receiving process's window procedure ever sees it. The window manager noticed that the sender's IL was lower than the receiver's IL and dropped the message [@uipi-wiki][@russinovich-blog-2007].

The "silently dropped" part matters operationally. Legacy applications written before Vista did not check the return value of SendMessage. When Vista shipped UIPI, those applications kept "working" in the sense that they did not crash. They just stopped being effective at any cross-IL interaction they may have previously relied on. This is the same compatibility shape Microsoft used everywhere in Vista: the new bound was real, but the API surface returned plausible failure codes rather than raising new errors that broke legacy callers.

What UIPI blocks, precisely

UIPI does not block every window message. It blocks a specific dangerous subset, and a complete reading of the article requires reading the list slowly.

Operation	UIPI behaviour from lower IL to higher IL
`SendMessage` / `PostMessage` for `WM_SETTEXT`, edit-control mutators, combo-box mutators	Blocked; returns 0 / `ERROR_ACCESS_DENIED`
Posted messages above `WM_USER` (0x0400)	Blocked
`WM_TIMER` with a callback function pointer	Blocked (the original Paget vector)
`SetWindowsHookEx` against a higher-IL thread or process	Blocked
`AttachThreadInput` to a higher-IL thread	Blocked
`SendInput` targeting a higher-IL window	Blocked
Journal record / journal playback hooks	Blocked
Mouse and most keyboard input from the OS itself	Allowed (the user is the principal)
Most paint messages (`WM_PAINT`, `WM_ERASEBKGND`)	Allowed
Read-only window queries (`GetWindowText`, `EnumWindows`)	Allowed (return empty / minimal data rather than failing)

"UIPI blocks all WM_* messages" is one of the most common misconceptions in Windows-security literature. It does not. It blocks the dangerous subset: the messages and hooks that allow a sender to alter the receiving process's state or execute code in it [@russinovich-blog-2007][@uipi-wiki].

sequenceDiagram participant M as Medium-IL malware participant W as win32k.sys participant P as High-IL PowerShell M->>W: SendMessage(hwnd, WM_SETTEXT, ...) W->>W: Compare sender IL (Medium) to target window IL (High) Note over W: Sender IL lower than target IL, WM_SETTEXT in dangerous subset W-->>M: Returns 0, ERROR_ACCESS_DENIED Note over P: Window procedure never invoked, text unchanged

The Microsoft Learn page that opens "Modifies the User Interface Privilege Isolation (UIPI) message filter for a specified window" is the ChangeWindowMessageFilterEx function reference [@changewindowfilter]. It is the closest thing to a first-party UIPI conceptual page on Microsoft Learn. There is no standalone Microsoft Learn page titled "User Interface Privilege Isolation" at the winmsg path: the Wikipedia UIPI article is the standard secondary anchor for the concept itself [@uipi-wiki], and Russinovich's February 2007 TechNet Blogs post introduces UIPI by name in the original architectural canon [@russinovich-blog-2007].

The opt-in exemption: `ChangeWindowMessageFilterEx`

The UIPI block is per-window and per-message. When a higher-IL window has a legitimate reason to accept a specific message from lower-IL senders (for example, a developer tool that needs to receive WM_COPYDATA from a Medium-IL client), the higher-IL process can call ChangeWindowMessageFilterEx to add the specific message to its window's allow-list [@changewindowfilter].

The action constants are documented as MSGFLT_ALLOW (add the message to the allow-list), MSGFLT_RESET (remove explicit policy and inherit defaults), and MSGFLT_DISALLOW (explicitly block the message even if defaults would allow it) [@changewindowfilter]. The function returns BOOL; failure is non-fatal and the caller is expected to validate the result.

A High-IL window that opts WM_SETTEXT into the cross-IL allowed list inherits the responsibility to validate the contents of every message it then receives. The filter is the gate. It is not the validator. A higher-IL process that takes attacker-controlled text and pastes it into a system shell has bypassed UIPI in the same way a service that takes attacker-controlled input and passes it to system() has bypassed least privilege. The mechanism cannot make the higher-IL process safe; it can only make the higher-IL process aware.

The `uiAccess=true` carve-out

The single largest residual exemption from UIPI is the uiAccess=true manifest flag, designed to support accessibility software (screen readers, on-screen keyboards, remote-control tools) that needs to interact with windows above its own IL [@uia-security]. A process that asserts uiAccess=true in its application manifest gets, at process creation, a token flag (TokenUIAccess) that exempts the process from UIPI's cross-IL blocks for the outbound direction. A Medium-IL UI-Access process can post WM_SETTEXT to a High-IL elevated PowerShell window, because the Medium-IL process is acting on behalf of an accessibility client.

The gating conditions for uiAccess=true are tight, by design. Microsoft Learn enumerates three [@uia-security]. The manifest must assert uiAccess="true" in the requestedExecutionLevel element. The binary must carry a valid Authenticode signature. The binary must reside in a directory writable only by administrators, which in practice means %SystemRoot%\System32, %ProgramFiles%, or a similarly admin-only path. The three conditions together are intended to bound uiAccess to vetted, signed, install-time-protected binaries.

We will return to the uiAccess carve-out in §9, because Forshaw's February 2026 Project Zero retrospective documents that five of nine pre-GA Administrator Protection bypasses operated entirely through this surface [@forshaw-adminprot-feb26]. The Vista-era exemption inherited unchanged into 2026 is, nearly twenty years later, the single largest residual cross-IL attack class in the Windows integrity stack.

What UIPI killed, precisely

UIPI killed the cross-IL variant of the Brett-Moore-2002 shatter-attack class. Same-IL shatter attacks (two Medium-IL processes on the user's Default desktop, both belonging to the same user, both running with the user's authority) are not blocked by UIPI, because UIPI is an IL-based filter. Two same-IL processes can still send each other arbitrary window messages, and this is exactly why every modern browser sandbox layers AppContainer and a restricted-token sandbox on top of MIC [@appcontainer-isolation]: the integrity primitives are correct, but they are integrity primitives, not identity primitives, and same-IL same-desktop processes need a different isolation mechanism.

Together, MIC and UIPI provide an integrity bound on access (objects) and on user-interface manipulation (windows). Both are mandatory, default-on, and constant-overhead. They are the load-bearing primitive pair of the entire integrity-level stack. But how does the OS decide which processes get which IL? When you log in as Administrator and open a PowerShell, why is that PowerShell Medium and not High?

5. The Split-Token Breakthrough

The integrity-level pair (MIC plus UIPI) is the access-control primitive. The split-token model is the policy decision that wires those primitives into the administrator's everyday experience. Without the split-token policy, an administrator's interactive shell would hold a High-IL token at logon and UAC would never need to exist. With it, every administrator on Windows 11 today has two tokens. One is in use. The other is dormant. The yellow dialog is the negotiation that toggles between them.

The Vista policy in which an Administrators-group user logging on receives a Medium-IL filtered token plus a dormant High-IL linked token. The filtered token becomes the primary token of the interactive shell; the linked token is used only after consent or auto-elevation, and only when the Application Information service brokers a process creation with it.

What the LSA does at logon

When EnableLUA=1 in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System (the default since Vista), and an Administrators-group user logs on, the Local Security Authority subsystem (LSASS) constructs three things during logon processing [@uac-how-it-works].

The first is the full token: an access token that contains all of the user's administrator group SIDs (enabled, not deny-only), all of the privileges the user is authorised to hold, and an integrity level of High. This is the token that, on XP, would have been the user's primary token from logon onward.

The second is the filtered token: a copy of the full token with all administrator-equivalent group SIDs marked SE_GROUP_USE_FOR_DENY_ONLY, all privileges except a small user-mode subset removed, and the integrity level reduced to Medium. The administrator group SIDs are not removed; they are marked deny-only so they still match deny ACEs but do not satisfy allow ACEs. The privileges are not zeroed; the powerful ones (SeDebug, SeTakeOwnership, SeLoadDriver, SeAssignPrimaryToken, and others) are dropped from the filtered token entirely.

The third is the linked relationship: the LSA stamps each token with a reference to the other via the TokenLinkedToken information class, so that a holder of the filtered token can, with the right privileges, retrieve a handle to the dormant full token by calling NtQueryInformationToken(filteredToken, TokenLinkedToken, &linkedToken, ...) [@uac-how-it-works].

The filtered token then becomes the primary access token of the user's interactive shell (explorer.exe). Every process the user launches by clicking, by Win+R, by typing in a console, inherits the filtered token as its primary token. The dormant full token sits in the LSA, addressable through TokenLinkedToken. The verbatim Microsoft Learn statement is exact: "When an administrator logs on, two separate access tokens are created for the user: a standard user access token and an administrator access token" [@uac-how-it-works].

flowchart TD A["User authenticates
as a member of Administrators"] --> B["LSA logon processing
(LsaLogonUser)"] B --> C["Full token
(admin SIDs enabled, all privileges, IL = High)"] B --> D["Filtered token
(admin SIDs deny-only, privileges stripped, IL = Medium)"] C -.->|"linked via TokenLinkedToken"| D D --> E["Primary token of explorer.exe
and all interactive child processes"] C --> F["Dormant in LSA, used only by Appinfo after consent or auto-elevation"]

The TokenElevationType API surface

Three values of the TOKEN_ELEVATION_TYPE enumeration describe what state the current process is in [@token-elevation-type].

TokenElevationTypeDefault (1) -- no split-token policy is in effect for this token. This is the legacy case (EnableLUA=0) or the case where the user is not a member of any administrators-equivalent group at all. The single token is the only token, and no linked token exists. On a default consumer or enterprise Windows 11 install with an admin account, this value is rare.
TokenElevationTypeFull (2) -- the current process is running with the unfiltered admin token. Admin Approval Mode is in force; this process either was launched via elevation (and holds the linked full token) or was created in a context where the filtered/full distinction is collapsed (some service contexts).
TokenElevationTypeLimited (3) -- the current process is running with the filtered token, Admin Approval Mode is in force, and a dormant full token exists. This is the typical state of an interactive admin shell on Windows 11.

TokenElevationTypeDefault (value 1) is the legacy or domain-controller case in which EnableLUA=0 and the user has no filtered token at all. On a default consumer Windows install, administrators are always TokenElevationTypeLimited or TokenElevationTypeFull, never Default. The Default case is what reverting EnableLUA to 0 produces, and it is the configuration the FAQ in §11 warns against.

What the consent prompt actually does

The behaviour of the consent prompt now resolves to a single operation, and the operation is not "elevate." When the user invokes "Run as administrator" on a binary, the shell calls ShellExecuteEx with the "runas" verb [@shellexecuteexa]. The Application Information service (the topic of §6.2) receives the request via RPC. Appinfo, running as LocalSystem, retrieves the linked full token of the calling user via TokenLinkedToken. Appinfo shows the consent prompt on the Secure Desktop (§6.1). If the user clicks "Yes," Appinfo creates a new process using the full token as the new process's primary token, by calling CreateProcessAsUser with the privileges Appinfo holds because it is LocalSystem [@russinovich-tnm-2007].

The bits that move are the kernel-level handle for the new process and the assignment of the linked token as that process's primary token. The bits the prompt itself moves are zero. The prompt is the consent surface; the token swap is the primitive.

Key idea: The consent prompt does not create authority. It uses authority that was already constructed at logon and held dormant in the linked token. The same primitive can move bits without the prompt -- that is exactly what auto-elevation does.

sequenceDiagram participant U as User participant E as explorer.exe (Medium IL) participant A as Appinfo (LocalSystem) participant C as consent.exe (Secure Desktop) participant P as New process (High IL) U->>E: Right-click, Run as administrator E->>A: RPC: request elevation of target.exe A->>A: Look up TokenLinkedToken of caller's filtered token A->>C: Show consent prompt U->>C: Click Yes C-->>A: Consent granted A->>P: CreateProcessAsUser(linked full token, target.exe) Note over P: New process runs at High IL, full admin SIDs enabled, full privileges Split-token administrator in UAC just means MS get to annoy you with prompts unnecessarily but serves very little, if not zero security benefit. -- James Forshaw, *Reading Your Way Around UAC (Part 1)*, Tyranid's Lair, May 2017

Forshaw's 2017 critique is the load-bearing observation that frames the rest of the article [@forshaw-reading-uac]. Even with the elegant split-token policy in place, there is a structural problem the design did not solve. The filtered token and the linked token share the same user SID. They write to the same %USERPROFILE%. They consult the same HKCU registry hive. They live in the same logon-session LUID. From an integrity-isolation point of view, the two tokens are bounded against each other; from an identity-isolation point of view, they are the same user.

That shared-identity property is what made the bypass-research industry possible, and what Administrator Protection finally attacks in 2024 (§9). We will return to it. First, let us tour the rest of the stack the consent prompt sits on. If Appinfo is the SYSTEM-trusted broker that does the token swap, where does it live? And what stops malware from spoofing the consent prompt itself?

6. The Full UAC Stack on a Modern Windows Box

The reader now knows the four load-bearing primitives. This section walks every supporting piece that surrounds them on a 2026 Windows install, in the order needed to follow an elevation event end-to-end. There are four pieces: the Secure Desktop the prompt renders on, the Appinfo service that brokers the token swap, the two distinct activation surfaces that trigger an elevation, and the auto-elevation allowlist that shaped fifteen years of bypass research.

6.1 The Secure Desktop, not Session 0

A separate desktop object at the Object-Manager path `\Sessions\\Windows\WindowStations\WinSta0\Winlogon`, within the user's interactive session, on which `consent.exe` runs the UAC prompt. Isolated from the user's `Default` desktop by Object-Manager DACL and the `SwitchDesktop` API.

When you click "Run as administrator" and the screen dims and the prompt appears, the screen dims because you have just been switched to a different desktop. Not a different session, not Session 0, not a different window station. A different desktop within the same window station, accessed through the SwitchDesktop API [@russinovich-tnm-2007].

The Object-Manager path is exact. Inside the user's interactive session (Session 1 if the user is the first interactive logon, higher numbers for subsequent users), there is a window station named WinSta0. Inside WinSta0 there are several desktop objects: Default (where the user's normal interactive processes paint), Winlogon (where consent.exe runs the prompt), and Disconnect and Screen-saver for related uses. The full path of the Secure Desktop is \Sessions\<n>\Windows\WindowStations\WinSta0\Winlogon.

The Winlogon desktop is protected by an Object-Manager DACL that the user's normal interactive processes (running on Default) cannot open for DESKTOP_CREATEWINDOW or DESKTOP_HOOKCONTROL. A Medium-IL malware process on Default cannot draw into the Winlogon desktop, cannot enumerate its windows, and cannot send messages to them. The OS performs the desktop switch in win32k.sys and renders consent.exe's window on the new desktop with a snapshot of the previous desktop as a dimmed background, so the user has visual continuity but consent.exe is the only process accepting input [@russinovich-tnm-2007].

Note: The Secure Desktop is not in Session 0. Session 0 Isolation is a different Vista feature that moved all Windows services off the interactive desktop into a non-interactive session (Session 0), separately from the per-user interactive sessions (Sessions 1, 2, ...). The Secure Desktop is within the user's interactive session: a different desktop object inside the same window station, not a different session. The two features ship together in Vista and are constantly confused, because they are both 2006-era hardening primitives. They are architecturally independent: Session 0 Isolation prevents services from drawing on the user's desktop, and the Secure Desktop prevents the user's processes from drawing on the prompt's desktop. Conflating them mis-describes how either one works. The corpus's Object Manager Namespace article (#46) covers Session 0 Isolation directly; this article treats only the Secure Desktop.

A separate Vista feature, architecturally independent of the Secure Desktop, that moved all Windows services off the interactive desktop and into Session 0. The two features ship together in Vista and are constantly confused, but they live at different layers of the Object Manager hierarchy. flowchart TD A["Session 1
(interactive logon for user 'admin')"] --> B["WinSta0
interactive window station"] A --> C["Service-0x0-3e7$
non-interactive WinSta (services)"] B --> D["Default desktop
explorer.exe, browsers, console windows
(Medium IL processes)"] B --> E["Winlogon desktop
consent.exe renders here
(Secure Desktop)"] B --> F["Disconnect / Screen-saver
desktops"] D -. "blocked by Object-Manager DACL
and SwitchDesktop" .-> E

The Secure Desktop addresses UI spoofing and input injection against the prompt itself. It does not address whether elevation can happen without a Secure Desktop prompt; that is the territory of the auto-elevation allowlist (§6.4) and of the bypass-research class (§7).

6.2 The Application Information service (Appinfo)

The SYSTEM-trusted Windows service (`appinfo.dll`, hosted in `svchost.exe`, runs under `LocalSystem`) that mediates the token swap between filtered and linked tokens at elevation time. Required service: "Run as administrator" fails without it. The modern process-creation entry point is `RAiLaunchAdminProcess`.

Every UAC elevation on Windows goes through one service: Appinfo (display name "Application Information"). Its image is C:\Windows\System32\appinfo.dll, loaded into a shared svchost.exe host process, running as LocalSystem [@russinovich-tnm-2007].

The job is single-purpose: be the SYSTEM-trusted broker that performs the token swap. A Medium-IL caller cannot, by definition, create a process holding a token the caller does not possess. Creating a process under a token with privileges the caller lacks requires two privileges Medium-IL filtered admin tokens do not hold: SeAssignPrimaryTokenPrivilege and SeIncreaseQuotaPrivilege. LocalSystem has both [@russinovich-tnm-2007]. The broker therefore has to run as LocalSystem, and that is what Appinfo is for.

The modern entry point on Appinfo's RPC interface is RAiLaunchAdminProcess, documented verbatim in Forshaw's February 2026 Project Zero post on Administrator Protection [@forshaw-adminprot-feb26]. The Medium-IL caller invokes ShellExecuteEx with "runas"; the shell marshalls the request across to Appinfo; Appinfo retrieves the caller's TokenLinkedToken; if a prompt is needed, Appinfo shows consent.exe on the Secure Desktop; if the user clicks "Yes," Appinfo calls RAiLaunchAdminProcess to create the new process under the linked full token.

Disable Appinfo and "Run as administrator" returns an error. It is the single point of trust in the elevation pipeline, which is exactly why the bypass-research industry pays attention to it: anything that can trick Appinfo into auto-elevating an attacker-influenced binary, without the consent prompt, becomes a fileless UAC bypass (§7.1).

6.3 Two activation surfaces

Note: When you say "elevate a thing," the operating system understands two distinct primitives, not one. ShellExecuteEx "runas" is whole-process elevation: the OS launches a new process and runs the entire process at High IL. The COM Elevation Moniker is per-object elevation: the OS spins up an isolated dllhost.exe that exposes exactly one COM CLSID's methods at High IL while the caller stays at Medium. The bypass-research literature attacks these two surfaces in very different ways. Conflating them mis-describes both the attack surface and the fix surface.

The first activation surface is ShellExecuteEx with the "runas" verb. The OS launches consent.exe, asks the user, and if approved, Appinfo creates a brand-new process under the caller's linked full token. The new process is High-IL for its entire lifetime, with the entire administrator privilege set and all the admin group SIDs enabled. The Windows Explorer "Run as administrator" context menu uses this verb. So does the runas /trustlevel: command. So does any program that calls ShellExecuteEx and sets the lpVerb member of SHELLEXECUTEINFO to the string "runas" [@shellexecuteexa].

A COM activation surface (`Elevation:Administrator!new:{CLSID}`) that asks the OS to instantiate a single COM out-of-process server in a new elevated `dllhost.exe`, exposing only that one CLSID's methods at High IL. Per-object elevation, distinct from `ShellExecuteEx "runas"` whole-process elevation.

The second activation surface is the COM Elevation Moniker. A Medium-IL caller invokes CoGetObject (or CoCreateInstance via a moniker) with the display name "Elevation:Administrator!new:{CLSID}" (or "Elevation:Highest!new:{CLSID}"). This asks the OS to instantiate a single COM out-of-process server in a new elevated dllhost.exe host process, exposing only that one CLSID's methods at High IL. The caller stays at Medium. Only the COM object's host process is elevated, and only for the lifetime of the object [@com-elevation-moniker].

The semantics are deliberately narrow. The COM Elevation Moniker requires the target CLSID to opt in via two registry values under HKCR\CLSID\{CLSID}: Elevation\Enabled = 1 and an LocalizedString value that names the elevation prompt's display string. Not every COM class is moniker-eligible; the registry enables elevation per CLSID.

Property	`ShellExecuteEx "runas"`	COM Elevation Moniker
Granularity	Whole process	One COM object
Lifetime	Entire process lifetime	Object lifetime only
Caller IL after	Caller stays Medium; new process High	Caller stays Medium
New process	Target executable	`dllhost.exe` host
Authority surface	All admin SIDs and privileges, broad	Methods of one CLSID, narrow
Typical use	"Run as administrator" context menu, MSI installers	Programmatic file copy, Wmi management, registry edits
Primary canonical bypass class	DLL-search-order against the new process	Auto-elevated COM behaviour abuse

The distinction matters because most of the canonical UAC bypasses do not touch ShellExecuteEx "runas" at all. Leo Davidson's December 2009 essay attacked the COM Elevation Moniker by invoking the IFileOperation COM class (auto-elevation-eligible, registered under the right CLSID) from a Medium-IL caller, and using its CopyItem method to overwrite a system file at High IL [@davidson-2009][@ifileoperation]. The ICMLuaUtil and IColorDataProxy interfaces follow the same shape: a Medium-IL caller instantiates an auto-elevatable COM class via the moniker, and then calls a method on the High-IL object that performs an attacker-chosen action [@uacme].

Both surfaces share the same backend: Appinfo brokers the token swap, and RAiLaunchAdminProcess (or its COM equivalent) creates the new process. The difference is whether the elevated child is a whole new process (broad authority for a long time) or a COM object's host (narrow authority for a single activation). The bypass-research literature exploits the second class far more than the first, because the second class exposes a narrower, more abusable behavioural surface: the CLSID's methods.

6.4 The auto-elevation allowlist

Vista's prompt fatigue was a usability disaster. Beta reviewers described users clicking through three or four prompts per common task. Windows 7, shipped in October 2009, tried to cut the noise by quietly elevating a curated set of Microsoft-signed binaries with no prompt at all. That single decision shaped the next fifteen years of UAC bypass research, because every "bypass" you have ever read about lives inside the gap between which binary gets elevated and what the binary does after elevation.

The set of Microsoft-signed binaries in trusted system directories on Appinfo's internal allowlist that elevate without a consent prompt. Four gating conditions: `autoElevate=true` manifest element, Microsoft Authenticode signature, trusted directory path, and an internal Appinfo allowlist entry enforced inside `appinfo.dll`.

The manifest element is a single string. Inside the application's side-by-side manifest, under the <trustInfo> / <security> / <requestedPrivileges> element, the binary asserts <autoElevate>true</autoElevate> [@app-manifests]. That assertion was discovered and publicly documented by independent UK developer Leo Davidson in December 2009 [@davidson-2009].

The autoElevate=true manifest assertion is necessary but not sufficient. Appinfo enforces three additional gating conditions before honouring an auto-elevation request [@davidson-2009].

The binary must carry a valid Authenticode signature chained to a Microsoft root certificate.
The binary's path must reside under a trusted system directory, in practice %SystemRoot%\System32 or %SystemRoot%\SysWOW64 (or the localized variants for non-English locales).
The binary's name must appear on an internal allowlist enforced in code in appinfo.dll, not in any user-visible policy file.

The fourth gate (the internal allowlist) is the one that surprises practitioners. A binary can be Microsoft-signed, located in System32, and carry autoElevate=true in its manifest, and Appinfo can still refuse to auto-elevate it, because the binary's name is not on the hard-coded allowlist inside appinfo.dll. There is no public Microsoft-published file enumerating the allowlist; the only way to enumerate it operationally is to scan the manifests of every binary in System32 and cross-check which ones actually auto-elevate.

The community-standard way to enumerate the manifest-asserting subset of the allowlist is to run Sysinternals `sigcheck -m C:\Windows\System32\*.exe` and pipe the output to `findstr /i autoelevate`. That gives you every binary in `System32` whose embedded manifest asserts `autoElevate=true`. On a Windows 11 25H2 install, the list runs to thirty to forty binaries: `mmc.exe`, `eventvwr.exe`, `fodhelper.exe`, `ComputerDefaults.exe`, `sdclt.exe`, `slui.exe`, and others.

The list of names in the manifest is not the same as the set Appinfo actually auto-elevates. UACMe's research README enumerates the operational subset: which manifest-asserting binaries Appinfo actually honours, by Windows build, with the technique class and the catalogued bypass method [@uacme]. The canonical observation is that of the manifest-asserting list, only the operationally-allowlisted subset is exploitable, and the operational subset changes silently across feature updates without any security bulletin because none of the resulting bypasses are classified as security vulnerabilities.

{` // Pseudocode of Appinfo's auto-elevation decision (Win7+). // All four gates must pass for auto-elevation without a consent prompt.

function shouldAutoElevate(binaryPath) { // Gate 1: the application manifest must assert autoElevate=true. const manifest = readEmbeddedManifest(binaryPath); if (manifest?.requestedPrivileges?.autoElevate !== true) return false;

// Gate 2: the binary must carry a valid Microsoft Authenticode signature. const sig = verifyAuthenticodeSignature(binaryPath); if (sig.status !== 'valid' || sig.rootCA !== 'Microsoft') return false;

// Gate 3: the binary must reside under a trusted system directory. const trustedDirs = ['C:\\Windows\\System32\\', 'C:\\Windows\\SysWOW64\\']; if (!trustedDirs.some(d => binaryPath.toLowerCase().startsWith(d.toLowerCase()))) return false;

// Gate 4: the binary name must appear on Appinfo's internal allowlist. // This is the one enforced in code in appinfo.dll, not exposed as policy. if (!APPINFO_INTERNAL_ALLOWLIST.includes(baseName(binaryPath).toLowerCase())) return false;

return true; } `}

Four gating conditions. Three of them constrain which binary gets elevated. None of them constrain what the binary does after elevation. The fourth gap, the behavioural one, is the space the bypass-research industry has occupied for fifteen years. That is §7.

7. Twenty Years of Bypass Research as Empirical Test

In February 2007, eleven days after Vista's consumer launch, Mark Russinovich published a TechNet Blogs post titled PsExec, User Account Control and Security Boundaries. The post walked through a quirk of how PsExec's -l switch interacted with restricted tokens on Windows XP, used the walkthrough to introduce Vista's integrity-level model, and then dropped a single sentence the entire later debate would rest on [@russinovich-blog-2007].

Neither UAC elevations nor Protected Mode IE define new Windows security boundaries... potential avenues of attack, regardless of ease or scope, are not security bugs. -- Mark Russinovich, *PsExec, User Account Control and Security Boundaries*, TechNet Blogs, February 12, 2007

That sentence, in the public record from week one, is the architectural reason every "UAC bypass" published from 2009 onward was classified by Microsoft as a non-vulnerability. The bypass-research literature is the empirical proof of the disclaimer, not a counterargument to it. Three durable bypass classes carry the empirical weight.

7.1 The `ms-settings` / `DelegateExecute` registry-hijack class

The first durable class is the registry-hijack bypass of auto-elevated binaries. Mechanism: an auto-elevated binary (eventvwr.exe, fodhelper.exe, ComputerDefaults.exe, certain sdclt.exe variants) executes a handler for a custom file extension or URL protocol on launch. The relevant handler mapping is in HKCR, but Windows resolves HKCR by first consulting HKCU\Software\Classes and only falling back to HKLM\Software\Classes if no per-user mapping exists. A Medium-IL user can write to HKCU without elevation. So the user writes a HKCU\Software\Classes\<scheme>\shell\open\command key whose default value is an arbitrary command line and whose DelegateExecute value is the empty string. Then the user launches the auto-elevated binary. The binary loads, Appinfo elevates it to High IL, the binary resolves its registered handler, walks HKCU\Software\Classes first, finds the attacker-controlled command line, and executes it. The attacker's command runs at High IL [@enigma-eventvwr][@mitre-t1548002].

The first public canonical demonstration was Matt Nelson's August 15, 2016 post Fileless UAC Bypass Using eventvwr.exe and Registry Hijacking, published on his blog under the handle enigma0x3. Nelson hijacked the mscfile association by writing HKCU\Software\Classes\mscfile\shell\open\command with cmd.exe as the default value, then launched eventvwr.exe. The Event Viewer auto-elevates because of its manifest, resolves the mscfile association to load eventvwr.msc, walks the HKCU mapping first, finds cmd.exe instead of mmc.exe, and launches an attacker-controlled cmd.exe at High IL [@enigma-eventvwr]. The technique required no file on disk except the registry value itself; this is what fileless means in this context.

Nelson productised the class through 2017. The March 14, 2017 Bypassing UAC Using App Paths post generalised to HKCU:\Software\Microsoft\Windows\CurrentVersion\App Paths\control.exe, exploited by sdclt.exe [@enigma-apppaths]. The March 17, 2017 'Fileless' UAC Bypass Using sdclt.exe post showed a fileless variant of the same attack using the IsolatedCommand REG_SZ value on HKCU:\Software\Classes\Folder\shell\open\command, with sdclt.exe /KickOffElev as the trigger [@enigma-sdclt]. The same post referenced WikiLeaks's March 2017 Vault7 disclosures, in which the CIA's "Vault7" cache contained operationalised versions of the technique, confirming nation-state adoption of the bypass class [@enigma-sdclt].

The fodhelper variant was published on May 12, 2017 under the title Bypassing UAC Using fodhelper.exe. The canonical URL enigma0x3.net/2017/05/12/bypassing-uac-using-fodhelper-exe/ currently returns HTTP 404; the technique is anchored by UACMe Method 33 and MITRE ATT&CK T1548.002, both of which preserve the date, author, and registry path verbatim [@uacme][@mitre-t1548002].

sequenceDiagram participant U as User (Medium IL) participant R as HKCU registry participant F as fodhelper.exe (auto-elevated) participant A as Appinfo (LocalSystem) participant C as Attacker payload (High IL) U->>R: Write HKCU Software Classes ms-settings shell open command with attacker cmd U->>F: ShellExecute("fodhelper.exe") F->>A: Request elevation (autoElevate gate passes) A->>F: New process at High IL, no consent prompt F->>R: Resolve ms-settings handler via HKCU first R-->>F: Returns attacker command F->>C: Spawn attacker payload at High IL

Microsoft's response to the eventvwr bypass was to ship a fix in the Windows 10 Creators Update (1703) that made eventvwr.exe not consult the registered association the technique exploited. The fix was technique-specific, not class-specific: the ms-settings (fodhelper), App Paths (sdclt), and IsolatedCommand (sdclt) variants remained exploitable through subsequent Windows 10 builds and into Windows 11 [@uacme][@mitre-t1548002]. None of these were patched as security vulnerabilities, because, per Russinovich 2007, UAC is not a security boundary [@russinovich-blog-2007].

7.2 The DLL-search-order class

The second durable class is the DLL-search-order attack against auto-elevated binaries. Mechanism: an auto-elevated binary calls LoadLibrary on a DLL name resolved via the standard Windows search order: the application directory, the system directory, the current directory, the PATH environment variable, and so on. If any path on that search order earlier than the legitimate one is writable by the Medium-IL caller, the caller can plant an attacker DLL at that path. When the auto-elevated binary loads the legitimate name, the search order returns the attacker's DLL first, and the DLL is loaded at the binary's elevated IL [@davidson-2009].

The foundational canonical example is the December 2009 Leo Davidson essay Windows 7 UAC whitelist: Code injection issue (and more). Davidson demonstrated that sysprep.exe (Microsoft-signed, in System32, auto-elevation-allowlisted) loads cryptbase.dll from its working directory before the system directory. By copying sysprep.exe and a malicious cryptbase.dll into a writable directory and launching sysprep.exe from there, an attacker could load the malicious DLL into a High-IL process [@davidson-2009]. The same essay introduced the IFileOperation COM-object technique that founded the second durable class (§7.3), making the December 2009 Davidson essay the single most-cited primary in the entire UAC bypass literature.

Coverage in the trade press confirmed the class's significance immediately. In February 2009, The Register reported on a related Long Zheng / Rafael Rivera disclosure that demonstrated piggybacking on auto-elevation via rundll32.exe [@register-2009], establishing that the auto-elevation surface had been understood as exploitable from the moment Windows 7 shipped.

Microsoft's mitigations against the DLL-search-order class have been incremental. SafeDllSearchMode was made the default in Windows XP SP2 and reshuffled the search order so the application directory came before the current directory. The LOAD_LIBRARY_SEARCH_* flags introduced in Windows Vista let applications opt into stricter search behaviour. Side-by-side manifest pinning and the KnownDLLs mechanism shrink the surface further. All of these are application-author opt-ins; an auto-elevated binary that does not use them remains exploitable, and UACMe's catalogue of 81 methods includes numerous DLL-search-order entries across Windows versions [@uacme].

7.3 The auto-elevated COM-object behaviour-abuse class

The third durable class abuses the behaviour of auto-elevation-eligible COM classes. Mechanism: a COM class registered as auto-elevation-eligible (the IFileOperation / ICMLuaUtil / IColorDataProxy family historically, then the explicit COMAutoApprovalList registry surface introduced in Windows 10 RS1 / build 14393 in August 2016) can be instantiated High-IL by a Medium-IL caller via the COM Elevation Moniker. Once instantiated, the High-IL object exposes methods (file copy, registry write, executable launch) that perform actions at High IL using whatever parameters the caller passes [@davidson-2009][@ifileoperation].

Davidson's IFileOperation proof of concept from December 2009 is the canonical example. A Medium-IL caller instantiates IFileOperation via the COM Elevation Moniker. The resulting dllhost.exe runs at High IL and exposes IFileOperation::CopyItem and related methods. The caller invokes CopyItem("evil.dll", "C:\\Windows\\System32\\"). The High-IL dllhost.exe performs the copy, because the High-IL token has write access to %SystemRoot%\System32. The caller has now planted a DLL in System32 without ever holding a High-IL token itself [@davidson-2009][@ifileoperation].

The COMAutoApprovalList era began in August 2016 with the Windows 10 Anniversary Update (RS1, build 14393). Microsoft added a dedicated registry surface at HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\UAC\COMAutoApprovalList enumerating which CLSIDs consent.exe would auto-elevate without a prompt. The change was unannounced: there is no Microsoft-published security bulletin naming the introduction. The community anchor is UACMe Method 49, whose fix-note carries the verbatim "Side effect of consent.exe COMAutoApprovalList introduction" against the TpmInit.exe ICreateNewLink technique, dated to RS1 / build 14393 [@uacme]. Method 27 captures the subsequent narrowing in RS3 / 16299, when Microsoft removed the UninstallStringLauncher interface from the list.

Class	Mechanism	Canonical research	Microsoft response
Registry-hijack (DelegateExecute)	Auto-elevated binary resolves user-writable HKCU handler	Nelson, eventvwr Aug 2016; sdclt and fodhelper 2017	Patched individual binaries; class never classified as security vulnerability
DLL-search-order	Auto-elevated binary loads attacker DLL via standard search path	Davidson, December 2009 (sysprep + cryptbase)	`SafeDllSearchMode`, `LOAD_LIBRARY_SEARCH_*`, KnownDLLs; shrunk but not eliminated
Auto-elevated COM behaviour	Medium-IL caller invokes High-IL methods via moniker	Davidson, December 2009 (IFileOperation); COMAutoApprovalList RS1 Aug 2016	Curated allowlist; entries added or removed in feature updates without CVEs

7.4 The doctrine and the aha

The two distinct 2007 sources need precise attribution, because the citation chain is the load-bearing artifact of the entire UAC-as-not-a-boundary argument.

Note: The verbatim "Neither UAC elevations nor Protected Mode IE define new Windows security boundaries" sentence lives in the PsExec, User Account Control and Security Boundaries TechNet Blogs post by Mark Russinovich, dated February 12, 2007 [@russinovich-blog-2007]. The architectural reference that most practitioners cite, Security: Inside Windows Vista User Account Control, was published in the June 2007 issue of TechNet Magazine and is the canonical reference for the integrity model, file/registry virtualisation, and the elevation pipeline [@russinovich-tnm-2007]. The architectural article does not contain the "not a security boundary" sentence; the February blog post does. Conflating the two is a citation error and gives the wrong impression of when Microsoft committed to the boundary classification.

The Microsoft Security Response Center's published servicing criteria define a security boundary as one that "provides a logical separation between the code and data of security domains with different levels of trust" [@msrc-criteria]. The MSRC servicing-criteria page enumerates which Windows boundaries qualify under that definition. Through the Vista-through-Windows-10 era (2007-2024), UAC was explicitly classified as a security feature, not a boundary, in the enumeration table on that page. The enumeration is rendered client-side (in JavaScript) and not visible through static fetches; the canonical confirmation for the classification is the Russinovich February 2007 sentence above, repeated and re-affirmed in Microsoft public statements throughout the period [@russinovich-blog-2007].

Forshaw's January 2026 Project Zero post on Administrator Protection reads the doctrine clearly in retrospect: "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-adminprot-jan26]. The "downgraded" framing is exact. UAC was promoted to a security feature, not a security boundary, from the moment it shipped. The reclassification in November 2024 was a re-promotion with new architecture, not a fix to the old architecture.

Note: The twenty-year UAC bypass-research record is empirical confirmation, not counterargument, of the architect's 2007 disclaimer. Microsoft did not fix the bypasses as security vulnerabilities because Russinovich had already said in writing that there was nothing to "fix": the consent prompt was a convenience, not a boundary. The bypass record is the proof that the disclaimer was honest from week one.

For the Windows administrator who has watched the bypass-research industry produce a new fileless bypass every six to twelve months, the reframing is the load-bearing aha of the entire article. The bypasses are not bugs Microsoft has failed to fix. They are the empirical map of the access-control versus information-flow gap that any access-control primitive runs into in a backward-compatible OS. The empirical record from 2009 forward (Davidson, Nelson, hfiref0x, Forshaw) is the cumulative confirmation that the disclaimer was honest.

If MIC, UIPI, and the split-token model are sound primitives, and the bypasses do not violate Microsoft's own classification of them, what are the actual theoretical limits of integrity-level systems? What can MIC and UIPI never do, by design?

8. Theoretical Limits: What MIC and UIPI Cannot Do, by Design

The 2007 disclaimer was not just an admission of weakness. It was an accurate statement of the theoretical limits of any access-control primitive in a backward-compatible operating system. The bypass-research industry of 2009 to 2026 has empirically traced out those limits one technique at a time, and a careful reading of the theory tells us why the trace looks the way it does.

Biba 1977 and the three rules

The integrity model MIC implements comes from Kenneth J. Biba's 1977 MITRE technical report MTR-3153 [@biba-wiki]. Biba's model is the integrity-side mirror of the better-known Bell-LaPadula confidentiality model [@blp-wiki]: where Bell-LaPadula's "no read up" prevents confidentiality leaks, Biba's "no write up" prevents integrity contamination. The Biba model defines three rules.

Simple Integrity Property (no read down): a subject at integrity level $I_s$ cannot read an object at integrity level $I_o < I_s$. A High-IL subject cannot read Low-IL data, because Low-IL data may have been written by an untrusted source and might contaminate the subject's state.
Star Integrity Property (no write up): a subject at integrity level $I_s$ cannot write an object at integrity level $I_o > I_s$. A Low-IL subject cannot write to a High-IL object, because the Low-IL subject's writes would degrade the High-IL object's integrity.
Invocation Property: a subject at integrity level $I_s$ cannot invoke (call, request services from) a subject at integrity level $I_o > I_s$. A Low-IL caller cannot ask a High-IL server to perform an action on the caller's behalf, because the High-IL server would then act on Low-IL inputs.

MIC implements the Star Integrity Property as the default NO_WRITE_UP policy. Every object that does not explicitly request a different policy is protected against lower-IL writes [@mic-doc][@mandatory-label-ace]. That is the one Biba rule MIC actually enforces.

MIC does not implement Biba's Simple Integrity Property at all. There is no NO_READ_DOWN policy in the winnt.h mandatory-label-policy enumeration. The opt-in NO_READ_UP bit MIC exposes points the other way: it stops a lower-IL subject from reading a higher-IL object, which is structurally Bell-LaPadula's Simple Security Property (no read up for confidentiality) repurposed onto an integrity SID rather than a confidentiality label [@blp-wiki][@mandatory-label-ace]. By default, a Low-IL process can read a High-IL file. This is the design choice Forshaw's Reading Your Way Around UAC series turned into a research program in 2017 [@forshaw-reading-uac].

MIC does not implement the Invocation Property either. A Medium-IL process can invoke a High-IL service via the COM Elevation Moniker, via ShellExecuteEx "runas", via any of the auto-elevated binaries, via RPC to Appinfo. The absence of the Invocation Property is exactly what makes UAC operationally usable: a strict reading of Biba would forbid every brokered elevation surface in Windows, and the OS would be unbearable to use. The omission is deliberate, and it is the theoretical reason why every "bypass" of UAC is technically a use of an architectural surface, not a violation of it.

flowchart LR subgraph BIBA ["Biba 1977 -- integrity model"] A["Biba 1977
integrity model"] --> B["Simple Integrity
(no read down)"] A --> C["Star Integrity
(no write up)"] A --> D["Invocation Property
(no invoke up)"] B --> E["MIC: not implemented
(no NO_READ_DOWN policy in winnt.h)"] C --> F["MIC: default NO_WRITE_UP
(on by default)"] D --> G["MIC: not implemented
(COM moniker, runas verb, Appinfo)"] end subgraph BLP ["Bell-LaPadula 1973 -- confidentiality model"] H["Bell-LaPadula 1973
confidentiality model"] --> I["Simple Security
(no read up)"] I --> J["MIC: opt-in NO_READ_UP
(off by default, repurposed onto IL)"] end Strict Biba would forbid every brokered-elevation primitive in Vista. The COM Elevation Moniker, `ShellExecuteEx "runas"`, the entire RPC interface to Appinfo, the `IFileOperation`-class auto-elevated COM objects, the manifest-based elevation request: all of these are explicitly *invocations* by a lower-IL caller of a higher-IL server [@biba-wiki].

Microsoft's architectural decision was that brokered elevation is the operationally usable workaround. A Medium-IL caller cannot invoke a High-IL server directly, but a Medium-IL caller can ask the SYSTEM-trusted Appinfo broker to create a High-IL process whose initial state the broker controls. The broker is the mediation point. The brokered model is structurally weaker than strict Biba, and that weakness is exactly the surface the bypass-research industry has operated in for sixteen years. Every COM-elevation moniker bypass, every auto-elevation registry hijack, every DLL-search-order attack is a refinement of the same observation: brokered elevation lets Medium-IL inputs influence High-IL outputs in ways the broker cannot fully validate.

The access-control versus information-flow gap

The deeper bound is information-flow. Dorothy Denning's May 1976 Communications of the ACM paper A lattice model of secure information flow established the formal framework [@denning-1976]. Denning's result is fundamental: information-flow enforcement is undecidable in the general case, because verifying that a program never leaks information from class $A$ to class $B$ requires deciding properties of arbitrary programs, which reduces to the halting problem.

MIC enforces access control, not information flow. The distinction is essential. Access control answers "can this subject perform this operation on this object?" in O(1) at operation time. Information flow asks "does the final state of this system contain any information derived from data the subject was not authorised to read?" That is undecidable.

What this means for UAC: even when MIC perfectly enforces NO_WRITE_UP, a Low-IL process can still influence a High-IL process via shared state the High-IL process reads. Forshaw's January 2026 lazy DOS device directory hijack [@forshaw-adminprot-jan26] is exactly such an attack: it places attacker-controlled state in a location a High-IL process will later read, without ever writing up directly. MIC cannot prevent this; no access-control primitive can. Closing the gap requires information-flow analysis, which is provably undecidable for arbitrary code.

The five concrete limits

The theoretical bounds map onto five concrete limits any practitioner can observe on a default Windows 11 install.

The first limit is that no-write-up does not imply no-influence-up. A Low-IL process cannot write to High-IL objects directly, but it can place state (registry keys, files, environment variables, named objects) that a High-IL process will subsequently read or be influenced by. Every fileless UAC bypass in §7.1 walks through this gap.

The second limit is that NO_READ_UP is opt-in [@mic-doc]. By default, a Low-IL process can read a High-IL file. This is intentional: accessibility tools, antivirus, and diagnostic utilities depend on cross-IL reads. The cost is that any High-IL data placed at a default-policy location is readable by every Medium-IL or lower process on the system.

The third limit is that UIPI covers only the windowing layer. Sockets, named pipes, COM, RPC, shared memory, MIDL-defined RPC interfaces, and every other inter-process channel that does not go through win32k.sys is out of scope [@uipi-wiki]. UIPI is necessary, but it is not sufficient for cross-IL isolation; the full bound requires MIC on the file system, the registry, and every named object the higher-IL process might consume.

The fourth limit is the same-IL same-desktop attack surface. Two Medium-IL processes on the user's Default desktop are not isolated from each other by either MIC or UIPI. They have the same IL (no MIC bound) and they own windows on the same desktop with the same IL (no UIPI bound). Every modern browser sandbox addresses this separately, by combining MIC (the renderer runs at Low IL or Untrusted IL) with AppContainer (capability-based identity isolation) and restricted tokens (CreateRestrictedToken-style SID denial) [@chromium-sandbox][@appcontainer-isolation]. Where MIC alone is insufficient, the stack layers additional primitives, but those primitives are additions to MIC, not replacements for it.

The fifth limit is the auto-elevated-binary surface. As long as a Medium-IL process can cause a High-IL process to come into existence executing user-controllable inputs (registry handlers, DLL search-order resolution, COM moniker activation, command-line arguments), the bypass-research industry has architectural space to operate. The fix would be to apply the Invocation Property strictly, which would break elevation.

Why MIC has to be a separate evaluator

The Harrison-Ruzzo-Ullman 1976 result is the theoretical reason MIC could not be implemented as discretionary ACEs [@hru-1976]. HRU prove that the safety question (given an initial access matrix, will any future sequence of operations cause subject $s$ to acquire permission $p$ on object $o$?) is undecidable for the general access-matrix model. That undecidability is what makes mandatory policy necessary as a separate evaluator: if integrity were encoded as discretionary ACEs, the safety of an object's integrity label would inherit HRU undecidability through every principal with rights over the ACE.

By making MIC a separate evaluator with non-discretionary semantics, Windows answers the integrity-safety question in O(1) per access check: compare two SIDs, consult three policy bits, decide. The decidability comes from the separation. MIC is bounded because it is structurally simpler.

None of the bypass classes in §7 violate any of these limits. They all operate within them. The registry-hijack class places Low-IL state where a High-IL reader will consume it (limit #1). The DLL-search-order class abuses the auto-elevated-binary surface (limit #5). The COM-behaviour-abuse class operates on the absent Invocation Property. Microsoft's response, repeated for sixteen years, was to acknowledge these as architectural realities of the design rather than as bugs to fix. The bypass-research literature is the empirical map of the access-control versus information-flow gap that no mainstream OS has closed.

Did Microsoft ever try to actually move the boundary? What does it look like when a security feature finally becomes a security boundary?

9. The Adminless Successor and the Open Problems

In November 2024, Microsoft did something it had not done in seventeen years. It moved the security-boundary line. Administrator Protection, announced as a Windows 11 platform feature, became the first generation in the integrity-level lineage that Microsoft classifies as a security boundary [@admin-protection][@msft-devblog-adminprot]. The reclassification is structurally substantial. It is not Microsoft renaming UAC; it is Microsoft adding the architectural primitives a boundary classification requires.

What the split-token model shared, and what Administrator Protection separates

The four shared properties between the filtered token and the linked token were the structural reason UAC could not be a security boundary. They are listed verbatim in Forshaw's May 2017 Reading Your Way Around UAC framing [@forshaw-reading-uac]: same user SID, same %USERPROFILE%, same HKCU hive, same logon-session LUID. Administrator Protection attacks all four.

The per-user separate identity Windows 11 Administrator Protection provisions at first elevation. Has a different SID, `%USERPROFILE%`, `HKCU` hive, and LUID from the calling user, defeating the registry-hijack class of UAC bypasses by structurally separating elevated-process state from the caller's state.

Property	2007 Split-Token (UAC)	2024 Administrator Protection
User SID	Same as caller	Different (per-user System Managed Administrator Account, SMAA)
`%USERPROFILE%`	Same as caller	Different: `C:\Users\ADMIN_<random>\`
`HKCU` registry hive	Same hive as caller	Different hive (per-SMAA)
Logon session LUID	Same session as caller	Fresh logon session per elevation
Authentication	Consent click only	Windows Hello integrated authentication
Classification	Security feature, not boundary	Security boundary

SMAA expands as "System Managed Administrator Account" per the May 19, 2025 Microsoft Windows Developer Blog explainer Enhance your application security with Administrator protection [@msft-devblog-adminprot]. Earlier Microsoft Learn documentation from 2024 used the working name "Adminless" without the SMAA acronym. The corpus's Adminless / Administrator Protection article (#52) covers the SMAA lifecycle and the Insider-Preview timeline in more depth than this article does.

The concrete operational consequence of the SMAA identity change is structural defeat of the entire registry-hijack class. When an attacker writes the canonical fodhelper bypass key to HKCU\Software\Classes\ms-settings\shell\open\command, the attacker writes to the caller's HKCU hive. When fodhelper.exe is then elevated under Administrator Protection, the elevated process runs under the SMAA identity, with the SMAA's own HKCU hive, which does not contain the attacker's key. The auto-elevated binary resolves the ms-settings association via the SMAA's HKCU, falls through to HKLM, and gets the legitimate handler. The attacker's bypass is structurally defeated by the identity change, not by a per-binary fix [@admin-protection][@forshaw-adminprot-jan26].

The 2025 timeline

Administrator Protection's rollout has been incremental. Microsoft released it as an opt-in toggle in early 2024 Insider Preview builds, then shipped a generally-available implementation in optional update KB5067036 on October 28, 2025 [@forshaw-adminprot-jan26]. The Microsoft Learn Administrator protection page acknowledges a temporary revert on December 1, 2025 "while an application compatibility issue is dealt with" [@admin-protection][@forshaw-adminprot-jan26]. The expected re-enablement is in 2026.

Forshaw's January 26, 2026 Project Zero post Bypassing Windows Administrator Protection documents the application-compatibility revert with verbatim precision. He notes that "the issue is unlikely to be related to anything described in this blog post," meaning that the December 2025 revert was a third-party application compatibility regression rather than a security issue with the feature itself [@forshaw-adminprot-jan26]. The revert is operational, not architectural.

The 2026 retrospective: nine bypasses, five via UI Access

Forshaw's January and February 2026 Project Zero pair is the canonical modern retrospective on Administrator Protection's architectural maturity. The January post documents nine separate Administrator Protection bypasses Forshaw reported to Microsoft during the Insider Preview cycle, all of which were fixed before general availability [@forshaw-adminprot-jan26]. The post details one in depth (the lazy DOS device directory hijack) and summarises the rest.

If the weaknesses in UAC can be mitigated then it can be made a secure boundary. -- James Forshaw, *Bypassing Windows Administrator Protection*, Project Zero, January 26, 2026

The February 2026 follow-on post, Bypassing Administrator Protection by Abusing UI Access, is the more architecturally significant of the pair. It documents that five of the nine pre-GA Administrator Protection bypasses operated entirely through the uiAccess=true exemption, the long-standing UIPI carve-out for accessibility software inherited unchanged from Vista 2007 [@forshaw-adminprot-feb26].

The reading is structural. Administrator Protection successfully closes the bypass surface that the split-token model's shared identity created (limit #1 through limit #4 in §8). It does not close the bypass surface created by the UI Access carve-out, because UI Access is a deliberate exemption from UIPI. Closing UI Access would break screen readers, on-screen keyboards, remote-control tools, and every accessibility utility that depends on cross-IL window-message access. The exemption is necessary; the residual attack surface is the cost of accessibility.

The three gating conditions for uiAccess=true (manifest assertion, valid Authenticode signature, admin-only install location) are documented in the Security Considerations for Assistive Technologies Microsoft Learn page [@uia-security]. Forshaw's February 2026 post enumerates them verbatim and describes the RAiLaunchAdminProcess Appinfo RPC entry point the UI-Access bypasses operate through [@forshaw-adminprot-feb26]. The trade press picked up the story immediately: The Register covered Forshaw's January 2026 post under the headline "Google researcher sits on UAC bypass for ages, only for it to become valid with new security feature" on January 28, 2026 [@register-2026].

The downstream legacy

MIC and UIPI outlived UAC. The integrity-SID primitive is the connective tissue of every later sandbox model on Windows.

flowchart TD A["Integrity-SID primitive
(MIC + UIPI, Vista 2006/2007)"] --> B["AppContainer
(Windows 8, 2012)"] A --> C["IE Protected Mode
(IE7, Vista 2006)"] A --> D["Edge / Chrome / Firefox sandbox tiers
(2008-present)"] A --> E["Protected Process Light
(Windows 8.1, 2013)"] A --> F["Administrator Protection / SMAA
(Windows 11, 2024)"] A --> G["RunAsPPL for LSASS
(Windows 8.1, 2013)"] A --> H["Office Protected View
(Office 2010+)"]

AppContainer (Windows 8, 2012) layers package SIDs above the integrity SID and rides the same SeAccessCheck infrastructure [@appcontainer-isolation]. IE Protected Mode (Windows Vista IE7, 2006) was the first non-UAC consumer of Low IL, running browser-rendered content as a Low-IL process before the user's Medium-IL interactive shell. Modern browser sandbox tiers (Chrome, Edge, Firefox content processes) use Low-IL or Untrusted-IL sandbox processes, layered with AppContainer and restricted tokens [@chromium-sandbox]. Protected Process Light (Windows 8.1, 2013) is a signature-based generalisation of the integrity-SID concept that PPL-protects LSASS against OpenProcess by lower-IL callers. Administrator Protection itself uses the integrity-SID primitive: SMAA processes run at High IL while the calling Medium-IL admin shell stays Medium [@admin-protection].

The twenty-year experiment was a success. The integrity-level stack did exactly what it was designed to do: bound integrity, not authority. The consent prompt was honestly never the security boundary. Microsoft's November 2024 reclassification finally promotes a feature to a boundary by adding the architectural support the boundary classification requires (separate identity, separate profile, separate hive, separate LUID, Windows Hello-mediated transition). The bypass-research literature is the empirical proof that the 2007 disclaimer was honest, and the proof that the architecture worked exactly as architected.

Key idea: MIC and UIPI outlived UAC. The integrity-SID primitive is the connective tissue of AppContainer, every modern browser sandbox, Protected Mode, Protected Process Light, and the Administrator Protection successor. The yellow dialog is the smallest, most replaceable piece of the system.

On December 1, 2025, Microsoft temporarily reverted Administrator Protection in KB5067036 pending an application-compatibility fix [@admin-protection][@forshaw-adminprot-jan26]. Forshaw's exact framing matters: "the issue is unlikely to be related to anything described in this blog post." The revert was *not* a security regression; it was a third-party application-compatibility issue, with re-enablement expected in 2026. As of May 2026, Administrator Protection can be enabled manually on Windows 11 24H2 and later but is not the default on consumer or enterprise SKUs pending re-enablement [@admin-protection].

10. Inspecting the Stack on a Real Box

Every primitive in this article is observable on the Windows install you are reading on. Here are the five commands and the two tools that will let you walk the stack yourself.

Inspecting integrity levels

whoami /groups | findstr Mandatory prints the mandatory label of the current process token. From an unelevated PowerShell on an administrator account, it will read Mandatory Label\Medium Mandatory Level. From an elevated PowerShell, it will read Mandatory Label\High Mandatory Level. From a renderer-process command inside a Chromium-based browser, it would read Mandatory Label\Low Mandatory Level or Untrusted Mandatory Level, depending on the sandbox tier.

whoami /all is the longer view. It prints every group SID, every privilege, and the full mandatory label.Process Explorer (and System Informer) will show you the same data graphically, but whoami is the canonical first-party command for getting at the same kernel information from the shell. Run it twice -- once from an unelevated PowerShell, once from an elevated PowerShell on the same admin account -- and diff the outputs to see what the elevation actually changed. That is the empirical re-creation of §1's hook.

Sysinternals' Process Explorer has an Integrity column you can add via View / Select Columns / Process Image. Once enabled, it shows the IL of every running process at a glance. System Informer (the open-source Process Explorer successor) supports the same column plus richer SACL inspection. The accesschk -e -l <object> Sysinternals command prints the mandatory label of a file, registry key, or other securable object: accesschk -e -l C:\Windows\System32\drivers\ reveals the System-IL label that protects the driver directory.

The PowerShell-native equivalent of `whoami /all` that programs can consume is:

[System.Security.Principal.WindowsIdentity]::GetCurrent() |
  Select-Object -ExpandProperty Groups |
  ForEach-Object { $_.Translate([System.Security.Principal.NTAccount]) }

This produces the same SID-to-account-name resolution whoami /groups does, and is useful inside automation that needs to test deny-only group membership programmatically.

Inspecting UIPI

UIPI is harder to observe directly because the OS does not log dropped messages. The practical demonstration is to run Spy++ (the Visual Studio windowing inspector) from a Medium-IL process and attempt to subclass a window owned by an elevated High-IL process. The subclass call silently fails. SendMessage returns 0 with GetLastError reading ERROR_ACCESS_DENIED. The ChangeWindowMessageFilterEx documentation page is the Microsoft Learn entry point for understanding the per-window, per-message exemption surface [@changewindowfilter].

Enumerating the auto-elevation list

sigcheck -m C:\Windows\System32\*.exe | findstr /i autoelevate walks every executable in System32 and prints the manifest of each. The findstr filter narrows to lines containing autoElevate, surfacing the binaries that assert the manifest flag. On a Windows 11 25H2 install, the resulting list runs to thirty to forty binaries. Remember that the manifest-asserting list is not the same as Appinfo's internal operational allowlist; the operational subset is what UACMe enumerates [@uacme].

Watching Appinfo in action

Procmon (Sysinternals Process Monitor) filtered on consent.exe shows every elevation event: the registry reads against the manifest, the SACL reads on the binary, the token-information queries against the caller's filtered token. The Windows Event Viewer's Applications and Services Logs / Microsoft / Windows / User Account Control channel logs elevation events at the OS level. The combination of Procmon (mechanism) and the Event Viewer (audit trail) is the standard observability surface for elevation operations.

A safe lab for the bypass classes

UACMe is the community catalogue of 81 documented UAC bypass methods, each with author, technique, target binary, and Windows-version applicability annotations [@uacme]. For inspection of the integrity-level state of running processes from an analyst's workstation, James Forshaw's sandbox-attacksurface-analysis-tools repository (the NtObjectManager, TokenViewer, and NtCoreLib PowerShell modules) is the standard research toolchain [@forshaw-tools]. The UACMe reference implementations (akagi32.exe, akagi64.exe) are flagged by Microsoft Defender as HackTool:Win32/Welevate, the detection name Davidson noted as early as 2009 [@davidson-2009]. This is research tooling, not endpoint operations: run UACMe only on a snapshot VM with Defender exclusions documented, and treat the output as an empirical confirmation of the bypass-research record rather than as an offensive primitive.

Note: The minimum five commands a reader can run on their own Windows box to verify everything in this article: 1. whoami /all (run twice: once unelevated, once elevated; diff the outputs) 2. whoami /groups | findstr Mandatory (inspect the IL of the current token) 3. sigcheck -m C:\Windows\System32\eventvwr.exe (read the autoElevate manifest) 4. tasklist /v /fi "imagename eq svchost.exe" | findstr Appinfo (confirm the Appinfo service host) 5. Process Explorer with the Integrity column enabled, sorted by IL (the entire stack at a glance) The whole tour takes ten minutes. By the end you will have seen the split-token model, the integrity-level lattice, the auto-elevation allowlist, the Appinfo broker, and the Medium-vs-High distribution of your interactive desktop, with your own eyes.

11. Five Misconceptions That Will Not Die

Five UAC misconceptions come up so often in practitioner discussions that any complete treatment owes the reader explicit corrections. Two practical questions round out the FAQ.

No, and Microsoft's own documentation has said so since February 2007. The canonical "Neither UAC elevations nor Protected Mode IE define new Windows security boundaries" sentence appears in the *PsExec, User Account Control and Security Boundaries* TechNet Blogs post by Mark Russinovich, dated February 12, 2007 -- see §7.4 for the full quote and the citation-chain disambiguation against the *Inside Windows Vista User Account Control* TechNet Magazine architectural article [@russinovich-blog-2007][@russinovich-tnm-2007]. The boundary line was finally moved in November 2024 with Administrator Protection, which Microsoft does classify as a security boundary [@admin-protection][@forshaw-adminprot-jan26]. The original split-token UAC was never a boundary, by design, and the bypass-research record from 2009 to 2024 is the empirical confirmation that the disclaimer was honest. No. The Secure Desktop is on the `Winlogon` desktop within `WinSta0`, *within* the user's interactive session (Session 1, 2, ...) -- §6.1 walks the full Object-Manager hierarchy and contrasts it with the separate Vista Session 0 Isolation feature that moved Windows services into a non-interactive Session 0 [@russinovich-tnm-2007]. The two features ship together in Vista and are constantly confused, but they live at different layers of the Object Manager hierarchy and address different threats. No. The manifest entry is necessary but not sufficient. Appinfo enforces three additional gates: the binary must carry a valid Microsoft Authenticode signature, the binary must reside under a trusted system directory (`%SystemRoot%\System32` or `%SystemRoot%\SysWOW64`), and the binary's name must appear on an internal allowlist enforced in code in `appinfo.dll`, not in any user-visible policy file [@davidson-2009][@app-manifests]. Copying `autoElevate=true` into your own binary's manifest does nothing on its own. The community-standard enumeration technique is `sigcheck -m C:\Windows\System32\*.exe | findstr /i autoelevate`, but that enumerates the manifest-asserting set, not the operational allowlist. No -- UIPI blocks a specific dangerous subset (window-state mutators, hooks, input injection, journal record / playback); mouse messages, most paint messages, and read-only window queries pass. The complete row-by-row enumeration of blocked vs allowed vs degraded-but-passes message classes is in the §4.2 table. The "blocks all `WM_*`" misconception is one of the most common errors in Windows-security literature [@uipi-wiki][@russinovich-blog-2007]. No. `ShellExecuteEx` with the `"runas"` verb is whole-process elevation: Appinfo creates a new process under the caller's linked full token, and the new process runs at High IL for its entire lifetime [@shellexecuteexa]. The COM Elevation Moniker is per-object elevation: a Medium-IL caller instantiates a single COM object in a new elevated `dllhost.exe` exposing only that one CLSID's methods at High IL [@com-elevation-moniker]. The caller stays Medium; only the COM object's host process is elevated. The bypass-research literature attacks the second surface far more than the first, because per-object elevation exposes a narrower, more abusable *behavioural* surface (the methods of one CLSID), while whole-process elevation requires a path-class bypass like DLL-search-order to weaponise. Partially. The registry-hijack class (the eventvwr / fodhelper / sdclt / ComputerDefaults family from 2016-2017) is structurally defeated by the SMAA identity change: the attacker writes to the caller's HKCU hive, but the elevated process runs under the SMAA's different HKCU hive and never consults the attacker's key [@admin-protection]. The DLL-search-order class is partially mitigated by the SMAA's different `%USERPROFILE%` and different working directory. The UI Access class is *not* mitigated: it is the long-standing carve-out for accessibility software, inherited unchanged from Vista 2007, and Forshaw's February 2026 Project Zero post documents that this carve-out carried five of nine pre-GA Administrator Protection bypasses [@forshaw-adminprot-feb26]. UACMe remains the canonical operational catalogue for the bypass classes that survive Administrator Protection. No. Setting `EnableLUA=0` in `HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System` reverts the OS to the pre-Vista posture: no split-token model, every admin-account process running High-IL by default, every interactive shell holding the full admin SID set and the complete privilege list. The integrity-level *primitive* (MIC) remains in the kernel; the *policy* that makes it operationally useful (the default-Medium-IL filtered token for interactive admins) is disabled. Browser sandbox tiers still function, because they construct restricted Low-IL tokens explicitly. The admin's daily shell does not benefit, and a malware drop in any process under the admin's interactive session immediately holds High IL [@uac-how-it-works]. This is structurally the XP situation. Leaving `EnableLUA=1` (the default) is correct on every modern Windows install.

12. The Plumbing Outlived the Yellow Dialog

Return to the two whoami outputs from §1. The user is the same. The session is the same. The clock has barely moved. Read them again, and now read what each line means.

The administrator group SID was present in both tokens, marked deny-only on the filtered token and enabled on the elevated token. The integrity level changed from Medium (S-1-16-8192) to High (S-1-16-12288). The privilege set expanded from the small user-mode subset to the full administrator set. The bits that moved were the kernel-level token-assignment bits in the new process Appinfo created via CreateProcessAsUser, using the dormant linked token that LSA had constructed thirty minutes earlier at logon. The yellow dialog was the consent surface on top of a token-swap primitive that existed before the dialog rendered and that can move bits without the dialog (via auto-elevation).

Four primitives carried the work. Mandatory Integrity Control added an axis to the access check that runs before the DACL and short-circuits on a Low-to-High write attempt, regardless of what the DACL says. User Interface Privilege Isolation closed the cross-IL variant of the shatter-attack class that Paget published in 2002, by dropping the dangerous subset of window messages and hook calls from lower-IL senders to higher-IL receivers. The split-token model gave every administrator a Medium-IL filtered token at logon and held the full token dormant. The Appinfo SYSTEM-trusted broker mediated the token swap when consent or auto-elevation called for it.

The bypass-research industry of 2009 to 2024 was the empirical confirmation of the architect's 2007 disclaimer. Davidson's December 2009 essay opened the auto-elevation surface; Nelson's 2016-2017 series productised the registry-hijack class; hfiref0x's UACMe catalogued 81 methods and counting; Forshaw's 2017 Reading Your Way Around UAC series named the read-side surface; the cumulative record was a sixteen-year demonstration that UAC was not a security boundary, exactly as Russinovich had publicly stated in February 2007. Microsoft never classified any of these as security vulnerabilities, because the architectural commitment from week one had been that they would not be [@russinovich-blog-2007][@msrc-criteria].

The November 2024 Administrator Protection reclassification is the line finally moving. The split-token model's four shared properties between filtered and linked tokens (same SID, same %USERPROFILE%, same HKCU, same LUID) are replaced by an SMAA identity that differs on all four dimensions, plus Windows Hello-mediated authentication for every elevation [@admin-protection][@msft-devblog-adminprot]. The registry-hijack class is structurally defeated; the residual surface is the UI Access carve-out inherited unchanged from Vista 2007, which Forshaw's February 2026 Project Zero post documents as the source of five of nine pre-GA bypasses [@forshaw-adminprot-feb26].

The yellow dialog is the only piece of UAC most users will ever see. It is also the one piece the OS could replace tomorrow without changing what UAC is. MIC and UIPI outlived UAC. AppContainer, every modern browser sandbox, IE Protected Mode, Office Protected View, Protected Process Light, and Administrator Protection itself all ride on the integrity-SID and WinSta0 primitives that shipped on January 30, 2007 [@vista-press-release][@appcontainer-isolation][@chromium-sandbox]. The quiet plumbing did the work.

Next time you click "Yes" on the consent prompt, the bits that move are the same bits that move when Edge spawns a renderer at Low IL, when Defender protects LSASS as PPL, and when a SMAA process shadows your administrator identity on a Windows 11 25H2 install with Administrator Protection enabled. The dialog is the smallest part of the system. Twenty years of empirical research proved the architect right: UAC was never the boundary. The integrity-level stack was, and is [@russinovich-blog-2007][@admin-protection].

<StudyGuide slug="integrity-level-stack-mic-uipi-uac" keyTerms={[ { term: "Mandatory Integrity Control (MIC)", definition: "An access-check evaluator that compares the integrity level of a subject token to the integrity level of a target object before consulting the object's DACL. Denials short-circuit the access check; integrity beats identity." }, { term: "Integrity Level (IL)", definition: "A well-known SID under S-1-16-X carried on every token and securable object. Seven values: Untrusted, Low, Medium, Medium Plus, High, System, Protected Process." }, { term: "User Interface Privilege Isolation (UIPI)", definition: "The windowing-layer analog of MIC. Blocks dangerous window messages, hooks, and input injection from lower-IL processes targeting higher-IL windows on the same desktop." }, { term: "Split-token model", definition: "Admin Approval Mode: an administrator's logon produces a Medium-IL filtered token plus a dormant High-IL linked token. The filtered token runs the interactive shell." }, { term: "Secure Desktop", definition: "A separate desktop object (Winlogon) within WinSta0 in the user's interactive session, on which consent.exe renders the UAC prompt. Not Session 0." }, { term: "Application Information service (Appinfo)", definition: "The SYSTEM-trusted Windows service that mediates the filtered-to-linked token swap at elevation time. Exposes RAiLaunchAdminProcess." }, { term: "Auto-elevation allowlist", definition: "The internal Appinfo allowlist of Microsoft-signed binaries in trusted directories whose manifests assert autoElevate=true. Four gates: manifest, signature, path, allowlist entry." }, { term: "COM Elevation Moniker", definition: "Per-object elevation via Elevation:Administrator!new:{CLSID}. Spins up a single CLSID in an isolated High-IL dllhost.exe while the caller stays Medium." }, { term: "System Managed Administrator Account (SMAA)", definition: "The per-user separate identity Administrator Protection provisions at first elevation. Different SID, profile, HKCU, LUID from the calling user." }, { term: "Biba Star Integrity Property", definition: "No write up: a subject at integrity level Is cannot write an object at integrity level Io > Is. MIC implements this as the default NO_WRITE_UP policy." } ]} questions={[ { q: "Why is MIC a separate evaluator rather than another ACE in the DACL?", a: "Because DACLs are discretionary by definition; an object owner can rewrite the DACL. MIC's mandatory semantics require an evaluator that runs before the DACL and cannot be overridden by it. The HRU 1976 undecidability of the access-matrix safety question is the formal reason mandatory policy cannot be encoded as discretionary ACEs and remain decidable." }, { q: "Why doesn't the consent prompt elevate?", a: "Because the elevated token was constructed at logon by LSA, not at consent time by the prompt. The prompt asks the user whether the OS may use the already-existing linked full token to launch a new process. The token swap is performed by Appinfo, not by consent.exe; the prompt is the consent surface on top of a token-swap primitive." }, { q: "Why does UIPI block WM_SETTEXT but not WM_PAINT?", a: "Because WM_SETTEXT mutates the receiving window's state (the message replaces the window's text), and an attacker who can mutate a higher-IL window's state has gained influence over the higher-IL process. WM_PAINT only asks the window to redraw itself; it carries no attacker-controlled mutation, so allowing it from lower-IL senders is safe." }, { q: "Which Biba rules does MIC actually implement?", a: "Just one. MIC implements the Star Integrity Property (NO_WRITE_UP) as the default policy on every object that does not specify otherwise. MIC does not implement Biba's Simple Integrity Property (no read down) at all -- there is no NO_READ_DOWN policy in winnt.h. The opt-in NO_READ_UP bit MIC exposes is structurally a Bell-LaPadula simple-security analog applied to integrity SIDs, not a Biba rule. MIC does not implement the Invocation Property either; brokered elevation (COM Elevation Moniker, ShellExecuteEx 'runas', Appinfo) is the operationally usable workaround." }, { q: "What changed in November 2024 that turned UAC's elevation transition into a security boundary?", a: "Administrator Protection replaced the split-token model's four shared properties (same SID, same %USERPROFILE%, same HKCU, same LUID) with a System Managed Administrator Account that differs on all four dimensions, and required Windows Hello integrated authentication for every elevation. The structural identity separation defeats the entire registry-hijack bypass class. The residual surface is the UI Access carve-out inherited unchanged from Vista 2007." } ]} />

"Can This Code Do This?" -- Twenty-Five Years of Attacks on the Windows Access-Control Model

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

Windows answers the question *can this code do this?* with one kernel function, `SeAccessCheck`, evaluated against five inputs: a security descriptor, an access token, a desired-access mask, a generic-mapping table, and any previously-granted access. The function and its inputs have not structurally changed since July 27, 1993. Every famous Windows local-privilege-escalation tool of the last twenty-five years -- Mimikatz, JuicyPotato and seven other Potatoes, the seventy AutoElevate-redirect methods catalogued in UACMe -- attacks one of those inputs. This article tells that story as one system, names the five structural limits Microsoft has publicly conceded, and explains why Adminless, NTLMless, VBS Trustlets, and Credential Guard are the four non-overlapping ways to close them.

1. One Question, Billions of Times a Second

Open a Windows PowerShell window and run whoami /priv. Read the column on the right. SeShutdownPrivilege. SeUndockPrivilege. SeIncreaseWorkingSetPrivilege. SeTimeZonePrivilege. About twenty rows of capabilities, almost all marked Disabled, on a token that lives inside explorer.exe's memory and that the kernel consults billions of times a second.

Now run icacls C:\Windows\System32\drivers\etc\hosts. The output reads BUILTIN\Administrators:(F), NT AUTHORITY\SYSTEM:(F), BUILTIN\Users:(R). Six characters per principal, decoded by something inside the kernel called SeAccessCheck, applied to a data structure called a security descriptor, against a credential called an access token, every time any process anywhere on the machine asks for read access to that single file [@ms-learn-access-control].

This article is about the model behind those two outputs. A model that has not structurally changed since July 27, 1993, when Windows NT 3.1 shipped from Redmond [@en-wiki-windows-nt-3-1]. A model that every famous Windows local-privilege-escalation tool of the last twenty-five years -- Mimikatz, JuicyPotato, fodhelper.exe, the seventy methods in the open-source UACMe catalogue -- exists to attack [@github-gentilkiwi-mimikatz, @github-ohpe-juicy-potato, @github-hfiref0x-uacme].

The thesis comes in three convictions:

SeAccessCheck is the answer. Every securable Windows operation that touches a securable object resolves through one decision function with one set of inputs [@ms-learn-how-dacls-control-access].
Every famous Windows escalation tool attacks one of those inputs. JuicyPotato attacks the token. Mimikatz attacks the privilege list. Fodhelper attacks the elevation flow that produces the token. HiveNightmare attacks the DACL on a single file [@nvd-cve-2021-36934]. The vocabulary scales.
The model has five structural limits its keepers have publicly conceded [@msrc-servicing-criteria], and Adminless, NTLMless, VBS Trustlets, and Credential Guard are the four non-overlapping ways to close them.

The forecast for the next 14,000 words: ten primitives (the Security Reference Monitor, security identifiers, tokens, security descriptors, DACLs, SACLs, ACEs, privileges, Mandatory Integrity Control, User Account Control), one canonical oracle (SeAccessCheck), two attack families (the Potato lineage and the UACMe bypass tradition), and four successor architectures (Adminless, NTLMless, VBS Trustlets, Credential Guard).

If the model has not structurally changed since 1993, why has it taken thirty-three years and seventy bypasses to map its failure modes -- and what does each generation tell us about the next?

2. Origins: From Lampson's Matrix to Cutler's Kernel (1971-1993)

The vocabulary starts in a paper Butler Lampson presented at Princeton in 1971 and the ACM republished in Operating Systems Review in January 1974. Lampson framed protection as a 2-D matrix: rows index the subjects (users, processes), columns index the objects (files, devices, memory pages), and the cell at the intersection holds the operations the subject is permitted on the object. The matrix is a sparse, mostly-empty table the size of every-process times every-file. No real system has ever stored it that way.

Two implementation strategies fall out of the formalism. Slice the matrix by row and you get capability lists: each subject carries a token that names the objects it can touch. Slice by column and you get access-control lists: each object carries a list of subjects allowed to touch it. Lampson worked through both in the paper. Operating systems built on the second slice came to dominate, partly because hardware in 1971 made unforgeable capabilities expensive, partly because file systems could carry an ACL at the inode without changing every program. Decades later, the gap between the two implementations would still matter; we will reach Norm Hardy's "Confused Deputy" in a moment.

The lever that turned theory into Windows came from procurement, not academia. On December 26, 1985, the U.S. Department of Defense published DoD 5200.28-STD, the Trusted Computer System Evaluation Criteria, known by the colour of its cover as the Orange Book [@nist-csrc-rainbow]. The Orange Book defined four divisions of trusted-system assurance, and its C2 class -- "Controlled Access Protection" -- made discretionary access control plus auditing a federal procurement floor. The September 30, 1987 Neon Orange Book (NCSC-TG-003) and the July 28, 1987 Tan Book (NCSC-TG-001) elaborated DAC and audit respectively [@nist-csrc-rainbow]. After 1985, no operating system that wanted U.S. federal customers could ship without per-user ACLs and an audit log.

A year before the Orange Book ossified DAC into procurement, Norm Hardy of the Tymshare / KeyKOS lineage published a three-page paper in Operating Systems Review that named the structural limit of the entire ACL-shaped class: "The Confused Deputy (or why capabilities might have been invented)" [@wayback-cap-lore-hardy]. Hardy described a privileged compiler that wrote billing records to a system file. A user could trick the compiler into writing the user's output file over the billing file, because the compiler used its own authority on every write and could not distinguish "authority I have" from "authority the caller asked me to use."

The Wikipedia summary of the field is exact: "Capability systems protect against the confused deputy problem, whereas access-control list-based systems do not" [@en-wiki-confused-deputy]. Hold this paper. It will come back in Section 10.

The team that built Windows NT was not assembled in Redmond. David Cutler arrived in October 1988 from Digital Equipment Corporation [@en-wiki-cutler], where he had led VMS and the cancelled Mica successor, and brought with him a fraction of his old DEC team.

The cultural import mattered: VAX/VMS, announced October 25, 1977 alongside the VAX-11/780 (V1.0 shipped August 1978) [@en-wiki-openvms], introduced UIC-based file protection and a kernel-mode security architecture, and by the mid-1980s the VAX/VMS line had been evaluated at TCSEC Class C2 [@en-wiki-openvms], by which time the system had been hardened with per-object ACLs, audit channels, and an explicit reference monitor. That C2-hardened VMS was the cultural reference Cutler brought with him to Microsoft. G. Pascal Zachary's Showstopper! tells the story of the four-year build of NT 3.1 from that team [@showstopper-zachary].

The point for this article is narrower. NT 3.1's nine access-control primitives -- Security Reference Monitor, security identifier, access token, security descriptor, DACL, SACL, ACE, privileges, audit channel -- did not arrive piecemeal. They were specified together, before the first line of SeAccessCheck was written, against a procurement standard the team intended to clear.

NT 3.1 released to manufacturing on July 27, 1993 [@en-wiki-windows-nt-3-1]. NT 3.5, released to manufacturing on September 21, 1994 [@en-wiki-nt-3-5], was hardened through Service Pack 3 (June 21, 1995) and was rated by the National Security Agency in July 1995 as complying with TCSEC C2 criteria against the standalone single-user configuration [@en-wiki-nt-3-5]; NT 4.0 Service Pack 6a was evaluated at TCSEC C2 in a standalone (non-networked) configuration, consistent with NT 3.5 SP3. The combination froze the model. Once C2 evaluation was on the books, structural changes to the access-control surface would have required re-evaluation. Federal procurement obligations have kept the structural shape intact for thirty-one years, even after the Department of Defense formally retired TCSEC in favour of the Common Criteria.

Cutler shipped a model that has answered "can this code do this?" the same way for thirty-three years. What is the actual function -- and what are its inputs?

3. The Kernel Oracle: `SeAccessCheck` and Its Inputs

The function has one signature, one return value, and one job. Microsoft's Win32 documentation exposes a user-mode mirror called AccessCheck that lets userland code ask the question without holding a handle, and a kernel routine called SeAccessCheck that the kernel invokes at every securable operation [@ms-learn-access-control, @ms-learn-access-tokens]. The shape is the same in both directions:

$$ \textsf{SeAccessCheck}(\textit{SD}, \textit{Token}, \textit{DesiredAccess}) \to (\textit{GrantedAccess}, \textit{Status}) $$

Three inputs in (a security descriptor, an access token, a requested-access mask), two outputs out (the access mask actually granted, and a STATUS_ACCESS_DENIED flavour if any). Two more hidden inputs make the kernel signature precise: a generic mapping table that translates the four generic rights (GENERIC_READ, GENERIC_WRITE, GENERIC_EXECUTE, GENERIC_ALL) into object-type-specific bits, and a previously-granted-access mask that the kernel carries forward when an access check happens in two phases. Together: five inputs, one decision, one log entry (the documented kernel routine carries a few additional parameters of kernel-internal bookkeeping -- a synchronization flag, an AccessMode discriminator that elides the check for kernel-mode callers, and a privileges out-parameter -- which the explanatory five-input model collapses; the user-mode AccessCheck mirror is closer to the model the article uses).

The kernel-mode component of the Windows NT executive that performs all access checks against securable objects. It owns `SeAccessCheck` and the audit log generation routines. The SRM is a *subsystem*, not a feature: every other kernel component that needs to grant or deny access calls into it. The Windows kernel routine that decides whether a thread may perform a requested set of operations on an object. It takes a security descriptor, an access token, a desired-access mask, a per-object-type generic-mapping table, and any previously-granted access. (The documented kernel signature also carries a synchronization flag, an `AccessMode` discriminator that elides the check for kernel-mode callers, and a privileges out-parameter; the five-input model used here is an explanatory simplification that the user-mode `AccessCheck` mirror tracks more closely.) It returns the subset of the desired-access mask that the kernel grants and a status code. Every call site that opens or modifies a securable object eventually reaches this function [@ms-learn-how-dacls-control-access].

The five inputs are not equally exotic. The desired-access mask and the generic-mapping table are bookkeeping that an object type defines once at registration time. The previously-granted-access input is the kernel handing itself a pencil for two-phase access checks, mostly invisible to userland. The two inputs the rest of the article will keep returning to are the security descriptor and the access token.

A security descriptor is the data structure attached to the object. It carries an owner SID, a primary-group SID, a discretionary access-control list (DACL) of allow / deny / audit entries, and a system access-control list (SACL) holding audit and integrity-label entries [@ms-learn-mic]. The DACL is what icacls prints. The SACL is what writes Event Log entries when something the descriptor's writer wanted to watch happens.

An access token is the data structure attached to the caller. It names the user (one SID), the user's groups (a list of SIDs), the privileges the user holds (a list of named superpowers), the integrity level the kernel will compare against the object's label, and a flag that says whether the token is a primary token (one per process) or an impersonation token (one per thread, used to act on a client's behalf) [@ms-learn-access-tokens].

Microsoft's documentation lists the token's contents almost as bullet points: "The security identifier (SID) for the user's account; SIDs for the groups of which the user is a member; A logon SID that identifies the current logon session; A list of the privileges held by either the user or the user's groups; An owner SID; The SID for the primary group; The default DACL; ... Whether the token is a primary or impersonation token; An optional list of restricting SIDs; Current impersonation levels..." [@ms-learn-access-tokens].

The flow inside SeAccessCheck is mechanical. The kernel maps DesiredAccess from generic to specific bits using the type's mapping table. It checks the integrity label of the object against the integrity level on the token (Mandatory Integrity Control runs before the DACL walk, a point Section 7 expands). It walks the DACL in order, deny-first, accumulating bits granted by allow ACEs whose SID is in the token's list. It applies a privilege bypass short-circuit if the caller holds SeBackupPrivilege, SeRestorePrivilege, SeDebugPrivilege, or one of the other privileges that grants access to whole classes of objects without consulting the DACL. It returns the accumulated GrantedAccess, or STATUS_ACCESS_DENIED if the requested bits were not all granted.

sequenceDiagram participant App as User-mode caller participant ObjMgr as Object Manager participant SRM as Security Reference Monitor participant Audit as Audit channel App->>ObjMgr: OpenObject(name, DesiredAccess, ImpersonationToken) ObjMgr->>ObjMgr: Resolve name (\BaseNamedObjects, \Device, \??) ObjMgr->>ObjMgr: Fetch security descriptor from object header ObjMgr->>SRM: SeAccessCheck(SD, Token, DesiredAccess) SRM->>SRM: Map generic rights via type mapping SRM->>SRM: Check mandatory integrity label SRM->>SRM: Privilege-bypass short-circuit (SeBackup, SeRestore, SeDebug) SRM->>SRM: Walk DACL in canonical order, deny-first SRM-->>ObjMgr: GrantedAccess + STATUS code ObjMgr->>Audit: Emit SACL audit ACE if matched ObjMgr-->>App: HANDLE or STATUS_ACCESS_DENIED

Five inputs. One function. One log entry on the way out. The thesis statement of this article is the consequence: every later section is an attack on one of those inputs. JuicyPotato attacks the token. Mimikatz attacks the privilege list. Fodhelper attacks the elevation flow that produces the token. HiveNightmare attacks the security descriptor on a single file. Conditional ACEs and Dynamic Access Control extend the matrix's subject dimension by adding claims to the token. UAC tries to keep the token small by default and only inflate it on demand. Every primitive in the article maps cleanly onto one of SeAccessCheck's five inputs, and every famous attack tool in the article maps cleanly onto one primitive.

The function is fixed. The inputs are five. So how does the kernel actually walk a DACL -- and where does the wrong answer come from?

4. The DACL Algorithm and the SID Namespace

"Walk the DACL in order." Six words that have generated hundreds of thousands of misconfigured ACLs since 1993. The Microsoft Learn page that ships the algorithm is short and exact. The system "examines each ACE in sequence until... an access-denied ACE explicitly denies any of the requested access rights to one of the trustees listed in the thread's access token... one or more access-allowed ACEs for trustees listed in the thread's access token explicitly grant all the requested access rights... All ACEs have been checked and there is still at least one requested access right that has not been explicitly allowed, in which case, access is implicitly denied" [@ms-learn-how-dacls-control-access].

Three terminations. Deny terminates with denial. Enough allows terminates with grant. End-of-list with anything left ungranted terminates with denial. Note the asymmetry the algorithm encodes: a single deny anywhere in the DACL kills the request, but an allow has to be paired with explicit coverage of every desired bit. The default is denial.

The ordered list of access-control entries (ACEs) attached to a securable object's security descriptor that specifies which trustees are granted or denied which access rights. *Discretionary* means the object's owner controls the list, in contrast to a mandatory list whose entries the system enforces independent of owner intent. A single grant, deny, audit, or mandatory-label record inside a DACL or SACL. Each ACE carries an SID identifying the trustee, a 32-bit access mask, a flags byte controlling inheritance, and a type discriminator. Windows defines four primary ACE types (`ACCESS_ALLOWED_ACE`, `ACCESS_DENIED_ACE`, `SYSTEM_AUDIT_ACE`, `SYSTEM_MANDATORY_LABEL_ACE`) plus callback variants for conditional ACEs [@ms-learn-ace-strings].

{` // Faithful implementation of the algorithm at // learn.microsoft.com/en-us/windows/win32/secauthz/how-dacls-control-access-to-an-object // Inputs: token (set of SIDs), DACL (ordered ACEs), desiredAccess mask. // Output: granted mask + a per-ACE trace of why.

function seAccessCheck(token, dacl, desiredAccess) { let remaining = desiredAccess; // bits still needed let granted = 0; // bits accumulated so far const trace = [];

// NULL DACL grants everything; empty DACL grants nothing. if (dacl === null) { return { status: 'GRANTED (NULL DACL)', granted: desiredAccess, trace: ['NULL DACL: full access'] }; } if (dacl.length === 0) { return { status: 'DENIED (empty DACL)', granted: 0, trace: ['Empty DACL: no access'] }; }

for (let i = 0; i < dacl.length; i++) { const ace = dacl[i]; const sidMatches = token.sids.includes(ace.sid); if (!sidMatches) { trace.push(`ACE ${i} (${ace.type} ${ace.sid}): SID not in token; skip`); continue; } if (ace.type === 'DENY') { const deniedBits = ace.mask & remaining; if (deniedBits !== 0) { trace.push(`ACE ${i}: DENY hits 0x${deniedBits.toString(16)} -> ACCESS_DENIED`); return { status: 'DENIED', granted: 0, trace }; } trace.push(`ACE ${i}: DENY ${ace.sid} 0x${ace.mask.toString(16)} -- no requested bit hit; skip`); } else if (ace.type === 'ALLOW') { const newBits = ace.mask & remaining; granted |= newBits; remaining &= ~newBits; trace.push(`ACE ${i}: ALLOW grants 0x${newBits.toString(16)}, remaining 0x${remaining.toString(16)}`); if (remaining === 0) { return { status: 'GRANTED', granted, trace }; } } } return { status: 'DENIED (end of DACL with bits unsatisfied)', granted: 0, trace }; }

// Demo: a token with the user's SID and BUILTIN\Users; DACL with explicit deny + Everyone allow. const token = { sids: ['S-1-5-21-A-B-C-1001', 'S-1-5-32-545', 'S-1-1-0'] }; const dacl = [ { type: 'DENY', sid: 'S-1-5-21-A-B-C-1001', mask: 0x00040000 }, // deny WRITE_DAC { type: 'ALLOW', sid: 'S-1-1-0', mask: 0x00120089 }, // FILE_GENERIC_READ { type: 'ALLOW', sid: 'S-1-5-32-545', mask: 0x001200A9 }, // GENERIC_READ + EXECUTE ]; console.log(seAccessCheck(token, dacl, 0x00040089)); `}

The runnable above implements three subtleties the prose can flatten. First: the NULL DACL versus empty DACL distinction. A descriptor with no DACL at all -- a literal NULL pointer where the list would be -- grants full access, on the theory that the writer expressed no policy and the kernel will not invent one. A descriptor with a DACL that exists but contains zero ACEs denies everything, because the writer expressed a policy and that policy has no allows. The single most common high-impact misconfiguration in the Windows codebase is code that meant to write the second and wrote the first, or vice versa.

Note: Newly-written code that "creates a file with no protection" almost always wants an empty DACL but ends up with a NULL DACL because of how the SECURITY_DESCRIPTOR initialisation defaults work. Verify with Get-Acl or icacls after creation; a NULL DACL surface in icacls looks like Everyone:(F) and is almost always a bug, not a feature [@ms-learn-how-dacls-control-access].

Second: ACE order is the caller's responsibility. The kernel walks the list in the order it finds it. The "canonical" order Windows expects is four-step, quoted verbatim from the Microsoft Learn reference [@ms-learn-order-of-aces]: "1. All explicit ACEs are placed in a group before any inherited ACEs. 2. Within the group of explicit ACEs, access-denied ACEs are placed before access-allowed ACEs. 3. Inherited ACEs are placed in the order in which they are inherited... 4. For each level of inherited ACEs, access-denied ACEs are placed before access-allowed ACEs."

The same page underlines who has to enforce the order: "Functions such as AddAccessAllowedAceEx and AddAccessAllowedObjectAce add an ACE to the end of an ACL. It is the caller's responsibility to ensure that the ACEs are added in the proper order." If the writer of the DACL hands the kernel an out-of-order list with a deny ACE buried after a wide allow ACE, the deny will be unreachable and the descriptor will silently grant more than the writer intended.

Third: there is no special case for "Everyone." The well-known SID S-1-1-0 exists in every token of every process on the machine; an ACE against it applies to every caller. There is no extra logic that says "if this is Everyone, treat it differently from any other group." James Forshaw made the point with characteristic bluntness in 2020: "don't forget S-1-1-0, this is NOT A SECURITY BOUNDARY. Lah lah, I can't hear you!" [@tiraniddo-sharing-logon-session]. The DACL evaluation algorithm does not know "Everyone" is special. It is a SID like any other.

That makes the SID namespace itself worth a tour. Microsoft documents the structure as a revision number, an identifier authority (a six-byte field that says which authority issued the SID), a list of sub-authorities, and a final relative identifier (RID) [@ms-learn-security-identifiers]. Microsoft's own page on SIDs is precise: "A security identifier (SID) is a unique value of variable length used to identify a trustee... When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group."

The well-known SIDs the kernel recognises by name include SYSTEM (S-1-5-18), LocalService (S-1-5-19), NetworkService (S-1-5-20), Everyone (S-1-1-0), Authenticated Users (S-1-5-11), and the four Mandatory Integrity Control levels (S-1-16-4096 / 8192 / 12288 / 16384) [@en-wiki-mic, @ms-learn-mic]. Machine-issued SIDs encode the machine's domain identity in the sub-authorities; domain-issued SIDs encode the domain identity. RID 500 is, by convention, the local Administrator account; RID 501 is the Guest account.

A variable-length, never-reused identifier for a trustee (user, group, machine, service, or capability) inside the Windows security model. SIDs are encoded in canonical form `S-R-I-S1-S2-...-RID`, where R is a revision number, I is the identifier authority, the Sn are sub-authorities issued by that authority, and RID is the relative identifier. Every ACE references an SID; every token contains a list of them [@ms-learn-security-identifiers].

James Forshaw documented in 2017 that Windows generates the per-service SID for NT SERVICE\<ServiceName> deterministically: it is the SHA-1 hash of the uppercased service name, formatted into the SID's sub-authority fields. This is why Windows can refer to running services as security principals without an explicit registration step -- the kernel derives the SID on demand [@tiraniddo-trustedinstaller-blog].

Two SID families this article will not derive: AppContainer Package SIDs (S-1-15-2-...) and capability SIDs (S-1-15-3-...). Both arrived with Windows 8 in 2012 and extend the matrix's subjects with code identity and capability tokens. The sibling App Identity article in this series carries the canonical derivation, including the Crockford-Base32 PublisherId derivation that produces a Package SID from an MSIX package signature [@app-identity-sibling]. Section 5 of this article will mention those SIDs in tokens; we will not redefine them here.

The DACL is half the story. What does the thread bring to the access check -- and why is the answer "whoever happens to hold the handle"?

5. Tokens as Bearer Credentials

A token is not a credential the way a password is. A token is a credential the way cash is: whoever holds it gets the rights. This is the single most important property in the article.

Microsoft splits tokens into two flavours by purpose [@ms-learn-access-tokens]. A primary token hangs off a process and represents the security identity that process runs as. Every process has exactly one. An impersonation token hangs off a thread and lets that thread temporarily act as someone else -- typically a network client whose request the thread is servicing. Tokens are kernel objects with handles, and like every other kernel object the kernel does not care how a process obtained the handle. If the handle resolves to a token in the kernel's table, the kernel grants the rights the token names.

A kernel object that names the security identity of a thread or process. It carries the user's SID, the SIDs of the user's groups, the privileges the user holds, an integrity level, an integrity-level mandatory policy, an optional list of *restricting* SIDs, a flag distinguishing primary from impersonation tokens, and the impersonation level (Anonymous / Identification / Impersonation / Delegation) [@ms-learn-access-tokens]. The kernel consults a token on every access check for the thread that holds it. A *primary token* is owned by a process and represents the identity the process runs as; every process has exactly one primary token. An *impersonation token* is owned by a thread and represents an identity the thread is temporarily acting on behalf of -- typically a network client. The primary / impersonation distinction is a discriminator inside the token itself, set when the token is created or duplicated [@ms-learn-access-tokens].

The impersonation flavour acquired its modern shape in Windows 2000. A token's impersonation level takes one of four values, ordered from least to most privileged for the impersonator. Anonymous lets the server know nothing about the client. Identification lets the server learn the client's SIDs but not act as the client. Impersonation lets the server perform local access checks as the client; this is the level a typical RPC server requests. Delegation lets the server forward the client's identity onto another machine, useful for multi-hop scenarios but a frequent source of relay-style bugs. Almost every Potato lineage attack consumes an Impersonation-level token; that is enough to call ImpersonateLoggedOnUser and run as the client [@itm4n-printspoofer-blog].

Microsoft documents a third token shape, the restricted token, that is rare in practice but worth understanding because it is the only place in the model where an explicit deny-list lives on the token itself rather than the descriptor. A restricted token combines three knobs: a list of SIDs converted to deny-only (their grants count for no allow ACE but their presence still triggers deny ACEs), a list of restricting SIDs that the access check must independently permit, and a list of privileges removed from the token's privilege set [@ms-learn-restricted-tokens].

The kernel runs SeAccessCheck twice and grants only the intersection: "When a restricted process or thread tries to access a securable object, the system performs two access checks: one using the token's enabled SIDs, and another using the list of restricting SIDs. Access is granted only if both access checks allow the requested access rights" [@ms-learn-restricted-tokens]. Restricted tokens are operationally niche because the same documentation requires applications using them to "run the restricted application on desktops other than the default desktop. This is necessary to prevent an attack by a restricted application, using SendMessage or PostMessage, to unrestricted applications on the default desktop" [@ms-learn-restricted-tokens]. Few applications can spare the desktop overhead.whoami /priv shows available privileges, not enabled privileges. The Enabled column is the load-bearing one: an available-but-disabled privilege does not affect any access check until the process explicitly enables it via AdjustTokenPrivileges. The discipline of leaving privileges disabled by default is a defence in depth that depends on the application not having an exploitable bug between disable and use.

A token also carries flags that drive specific runtime behaviours: a split-token indicator points at a linked full-administrator counterpart for the UAC scenario in Section 8; an AppContainer flag plus a Package SID and capability SIDs name an AppContainer-bound process. In every case, the kernel consults the token by handle and trusts the contents. The kernel does not ask how a process obtained the handle. It asks only what the token says.

This is the property that organises the rest of the article.

Key idea: The Windows access token is a bearer credential. Whichever process holds the handle gets the rights. The kernel does not ask how the handle was obtained; it asks only what the token says. This single property explains the entire Potato lineage, Mimikatz token::elevate, and most of the privilege-abuse canon. Once you see it, every later attack section in the article becomes the same bug repeated against a different token-acquisition primitive.

If the token is a bearer credential, anyone with a way to obtain a SYSTEM token's handle is SYSTEM. Every Potato in Section 10 will be a different way to provoke a SYSTEM-token handle into the attacker's process. But the access check has another input that bypasses the DACL entirely. What is it, and which attackers know about it?

6. Privileges as a Different Dimension

Privileges are not access rights. They are pre-checked superpowers. They live on the token, they bypass the DACL for specific operations, and they are baked into the kernel for those operations alone.

Microsoft's framing on Learn is exact: "Privileges differ from access rights in two ways: Privileges control access to system resources and system-related tasks, whereas access rights control access to securable objects" [@ms-learn-privileges]. The same page makes the operational consequence clear: "Most privileges are disabled by default" [@ms-learn-privileges]. A process that holds a privilege but has not enabled it (via AdjustTokenPrivileges) cannot use it. The discipline is "principle of least privilege at the millisecond level" -- the privilege is on the token, but it does nothing until the program explicitly turns it on for the next system call.

A named, kernel-recognised authority on the access token that lets the holder perform a specific class of operations the DACL evaluation alone would not permit. Privileges include `SeDebugPrivilege` (read/write any process), `SeImpersonatePrivilege` (act on a client's token), `SeAssignPrimaryTokenPrivilege` (start a process under a token), `SeBackupPrivilege` (read any file regardless of DACL), `SeRestorePrivilege` (write any file regardless of DACL), `SeTcbPrivilege` (act as the operating system), and `SeLoadDriverPrivilege` (load a kernel driver). Most are disabled by default and must be enabled via `AdjustTokenPrivileges` before use [@ms-learn-privileges].

The reason privileges deserve a section of their own is that five of them are equivalent to "I am SYSTEM" and the other dozen are housekeeping. The five-versus-housekeeping split is the load-bearing audit decision in any Windows hardening review. Step through them.

SeDebugPrivilege lets the holder open any process for full read and write, including processes running as SYSTEM. The privilege exists so that Visual Studio and WinDbg can debug code other users have started. The first move in almost every Mimikatz session is privilege::debug, which enables the privilege the local administrator already has on the token [@github-gentilkiwi-mimikatz, @en-wiki-mimikatz]. Once enabled, the next Mimikatz command opens lsass.exe and reads the credentials.

SeImpersonatePrivilege lets the holder accept any token offered by a client and act as that client. The privilege is held by every Windows service account by default -- IIS, SQL Server, the Print Spooler, scheduled tasks, Docker containers, Citrix, the entire population of background services that need to handle authenticated requests. This is the load-bearing privilege for the Potato lineage [@itm4n-printspoofer-blog]. Section 10 will spend twenty paragraphs on what a service account holding SeImpersonate can be tricked into doing; the privilege is the entry condition.

SeAssignPrimaryTokenPrivilege lets the holder launch a new process under any primary token. Combined with SeImpersonate, the pair gives an attacker the entire token-replay attack: get an impersonation handle to a SYSTEM token, then call CreateProcessAsUser to run a command as SYSTEM. itm4n quotes decoder_it on the operational consequence.

if you have SeAssignPrimaryToken or SeImpersonate privilege, you are SYSTEM. -- decoder_it, quoted by itm4n in the PrintSpoofer disclosure [@itm4n-printspoofer-blog]

SeBackupPrivilege lets the holder read any file regardless of DACL, on the theory that backup software has to. SeRestorePrivilege is the symmetric write privilege. The two together mean that a process holding both can rewrite any file on the machine, including service binaries.

The 2021 HiveNightmare / SeriousSAM vulnerability (CVE-2021-36934) is the worked example of what happens when the model assumes nobody but the backup process has read access to a sensitive file and the assumption breaks. The NVD description is exact: "An elevation of privilege vulnerability exists because of overly permissive Access Control Lists (ACLs) on multiple system files, including the Security Accounts Manager (SAM) database" [@nvd-cve-2021-36934]. The DACL on the live \Windows\System32\config\SAM was correct; the DACL on the Volume Shadow Copy mirror was overly permissive enough that any local user could read the SAM hashes through the shadow-copy device path.

Microsoft's fix required not just a patch but a manual operator step: "After installing this security update, you must manually delete all shadow copies of system files, including the SAM database, to fully mitigate this vulnerability" [@nvd-cve-2021-36934]. A patch alone could not erase the historical shadow copies that already had the wrong DACL.

SeTcbPrivilege lets the holder "act as the operating system" -- it is the privilege that grants identity to the kernel itself. Held only by LocalSystem services in well-administered environments. A non-system process that somehow acquired SeTcb is, in effect, indistinguishable from the kernel.

SeLoadDriverPrivilege lets the holder load a kernel driver. By itself the privilege is harmless, because the loaded driver still has to be properly signed for HVCI / Driver Signature Enforcement to accept it. Combined with a known-vulnerable signed driver, however, the privilege becomes the entry point for bring-your-own-vulnerable-driver (BYOVD) attacks: load a benign-looking but exploitable signed driver, then use its bug to execute arbitrary kernel code. Two worked examples bracket the class.

The kernel-read/write half of the class is best illustrated by Micro-Star's RTCore64.sys (CVE-2019-16098 [@nvd-cve-2019-16098]), the MSI Afterburner driver that "allows any authenticated user to read and write to arbitrary memory, I/O ports, and MSRs" [@nvd-cve-2019-16098]. In October 2022, the threat actors behind the BlackByte ransomware weaponised the primitive at scale [@sophos-blackbyte]: the dropper loaded RTCore64.sys, then walked the kernel's PspCreateProcessNotifyRoutine callback array and zeroed every entry, blinding every registered process-creation callback before the encryption stage ran.

Sophos's October 4, 2022 disclosure named the technique exactly: "We found a sophisticated technique to bypass security products by abusing a known vulnerability in the legitimate vulnerable driver RTCore64.sys. The evasion technique supports disabling a whopping list of over 1,000 drivers on which security products rely to provide protection" [@sophos-blackbyte].

The kernel-code-execution half of the class is GIGABYTE's gdrv.sys (CVE-2018-19320 [@nvd-cve-2018-19320]). The NVD description states the primitive directly: "The GDrv low-level driver in GIGABYTE APP Center v1.05.21 and earlier... exposes ring0 memcpy-like functionality that could allow a local attacker to take complete control of the affected system" [@nvd-cve-2018-19320]. A signed IOCTL accepts an attacker-supplied source pointer, destination pointer, and length, and copies kernel memory at ring 0 -- a write-what-where primitive that the attacker can compose with the read-anywhere primitive of RTCore64.sys to mint arbitrary kernel code execution.

CISA added GIGABYTE Multiple Products to the Known Exploited Vulnerabilities Catalog on October 24, 2022 with a remediation due date of November 14, 2022, citing in-the-wild exploitation [@nvd-cve-2018-19320]. The U.S. federal-civilian executive branch had two weeks to remediate; the rest of the install base did not.

Microsoft's structural answer is the Microsoft-recommended driver blocklist, enabled by default on every device since the Windows 11 2022 update [@ms-learn-driver-blocklist]. The Learn page is exact about coverage: the blocklist targets drivers with "known security vulnerabilities that an attacker could exploit to elevate privileges in the Windows kernel", and explicitly catches drivers whose behaviours "circumvent the Windows Security Model" [@ms-learn-driver-blocklist].

Both RTCore64.sys and gdrv.sys appear on the blocklist; the ride from disclosure to default-on enforcement was four years for RTCore64, four years for gdrv, and the same arc applies to every member of the class. Honourable mention: aswArPot.sys (CVE-2022-26522 / CVE-2022-26523 [@sentinelone-avast-avg]) shows the same pattern from a security-product driver, with SentinelLabs reporting "two high severity flaws in Avast and AVG... that went undiscovered for years affecting dozens of millions of users" before the silent fix [@sentinelone-avast-avg].

Note: On a Windows machine, holding any of SeDebugPrivilege, SeImpersonatePrivilege, SeAssignPrimaryTokenPrivilege, SeBackupPrivilege, or SeRestorePrivilege is operationally indistinguishable from being SYSTEM. The other privileges in the standard token (the long tail of SeShutdown, SeIncreaseWorkingSet, SeTimeZone, SeChangeNotify, SeUndock, SeIncreaseQuota...) are housekeeping. Audit the holders of the five accordingly: any non-LocalSystem-equivalent account that holds them is a target.

The DACL is the load-bearing thing for file access, but exactly one bad DACL on a sensitive file ends the model. HiveNightmare proved that the cost of getting a single security descriptor wrong on a single file is the entire credential database. The general rule the lesson encodes: every primitive in Section 3's input list has at least one production example where misuse of that primitive alone dropped the security model to zero.

Discretionary access control assumes the principal -- the user -- is the right unit of authorisation. By 2006, exploitable user-mode code had proven the principal was wrong. What did Microsoft do?

7. Mandatory Integrity Control: Stapling No-Write-Up onto DAC

November 2006. Vista releases to manufacturing, and for the first time in Windows history, the kernel's access check fires before the DACL walk -- on something other than the user's identity. The new layer is Mandatory Integrity Control (MIC), and it adds a four-level lattice to every securable object in the system.

Microsoft Learn frames MIC compactly. "MIC uses integrity levels and mandatory policy to evaluate access. Security principals and securable objects are assigned integrity levels that determine their levels of protection or access. For example, a principal with a low integrity level cannot write to an object with a medium integrity level, even if that object's DACL allows write access to the principal" [@ms-learn-mic]. The same page enumerates the levels: "Windows defines four integrity levels: low, medium, high, and system" [@ms-learn-mic]. The levels are encoded as four well-known SIDs: Low (S-1-16-4096), Medium (S-1-16-8192), High (S-1-16-12288), System (S-1-16-16384) [@en-wiki-mic].

A Windows kernel mechanism, introduced with Vista (released to manufacturing November 8, 2006; consumer general availability January 30, 2007 [@en-wiki-windows-vista]), that adds an integrity-level check to `SeAccessCheck`. Each securable object carries an integrity label inside its SACL; each access token carries an integrity level. An access whose direction violates the configured *mandatory policy* (typically *no-write-up*) is denied at the integrity check before the DACL walk runs. MIC is the mandatory layer the Windows DAC model historically lacked [@ms-learn-mic]. A linearly-ordered tag (Low / Medium / High / System) carried on every Windows process token and every securable object. The kernel uses the relative ordering to enforce mandatory policy independent of the object's DACL. The four well-known SIDs are S-1-16-4096 (Low), S-1-16-8192 (Medium), S-1-16-12288 (High), and S-1-16-16384 (System) [@en-wiki-mic].

The default policy is no-write-up. A process at integrity level $L$ cannot modify an object at integrity level greater than $L$, regardless of what the DACL says. Microsoft's example is the load-bearing one: a process running at Low IL cannot write to a Medium-IL object even if the DACL says Everyone has full control. The integrity check fires before the DACL walk; if the integrity check denies, the DACL is not consulted [@ms-learn-mic].

The integrity label is stored as a SYSTEM_MANDATORY_LABEL_ACE inside the SACL, not the DACL [@ms-learn-system-mandatory-label-ace]. The mask field on the label ACE encodes which directions of access the policy forbids: SYSTEM_MANDATORY_LABEL_NO_WRITE_UP (0x1), SYSTEM_MANDATORY_LABEL_NO_READ_UP (0x2), and SYSTEM_MANDATORY_LABEL_NO_EXECUTE_UP (0x4) [@ms-learn-system-mandatory-label-ace].

Storing the label in the SACL is a deliberate choice with one operational consequence: tools that copy the DACL but not the SACL silently drop the integrity label. The most common consequence is a Low-IL file getting copied to a new location and emerging with no integrity label, which defaults to Medium and unintentionally raises the object's protection. The opposite mistake -- a Medium-IL file losing its label and dropping to Low -- is the more dangerous one.

The no-write-up mask is the one to memorise, because it is the policy almost every label uses. When a Low-IL caller tries to act on a Medium-IL object, the kernel denies any access whose mapped result contains write-class bits, including the standard-rights WRITE_DAC (bit 18 of the 32-bit ACCESS_MASK [@ms-learn-access-mask]) and WRITE_OWNER (bit 19), the type-generic DELETE (bit 16), and the file-specific FILE_WRITE_DATA (0x2), FILE_APPEND_DATA (0x4), FILE_WRITE_EA (0x10), and FILE_WRITE_ATTRIBUTES (0x100) [@ms-learn-file-access-rights].

The presence of FILE_APPEND_DATA in that list matters operationally: a careless reader of the spec might assume that "append" semantics escape the no-write-up rule because they do not modify existing bytes. They do not. MIC denies both write modes, so log-only append handlers cannot be used as a write-up channel into a higher-IL object.

A second rule completes the model: process integrity inheritance. When a process is created, the kernel assigns it the minimum of the user's integrity level and the file's integrity level [@ms-learn-mic]. A medium-IL user running a low-IL executable gets a low-IL process. This is the rule that lets Internet Explorer 7 run at Low even when launched from a Medium user session.

The first MIC consumer was IE7 Protected Mode, which shipped with Windows Vista RTM (released to manufacturing November 8, 2006) [@wayback-skywing-uninformed-v8a6, @en-wiki-windows-vista]. (IE7 standalone for Windows XP, released October 18, 2006 [@en-wiki-ie7], runs without Protected Mode -- the feature depends on Vista's MIC kernel layer.) Skywing's Uninformed Volume 8 Article 6, "Getting Out of Jail: Escaping Internet Explorer Protected Mode," is the first public reverse-engineering of the implementation.

Skywing's framing remains the most-cited primer on the subject: "With the introduction of Windows Vista, Microsoft has added a new form of mandatory access control to the core operating system. Internally known as 'integrity levels', this new addition to the security manager allows security controls to be placed on a per-process basis. This is different from the traditional model of per-user security controls used in all prior versions of Windows NT" [@wayback-skywing-uninformed-v8a6]. IE7's Protected Mode pattern -- a Low-IL worker that does the dangerous parsing, paired with a Medium-IL broker that performs the system-changing operations on the worker's behalf -- became the template Windows would later generalise into AppContainer.User Interface Privilege Isolation (UIPI) is the window-message gate that uses MIC at the desktop. A Low-IL window cannot send SendMessage or PostMessage traffic to a Medium-IL or higher window. UIPI is the reason you cannot click-jack a UAC consent prompt from a normally-running browser process: the consent prompt runs at High IL, the browser runs at Medium [@en-wiki-mic].

Windows 8 generalised the MIC pattern into AppContainer. An AppContainer process gets a fresh Low-IL token plus an AppContainer flag, a Package SID that identifies the app, and a list of capability SIDs the app declared in its manifest. Microsoft Learn states the resulting isolation directly: "Windows ensures that processes running with a low integrity level cannot obtain access to a process which is associated with an app container" [@ms-learn-mic]. The Package SID and capability SID derivations are the subject of the App Identity sibling article in this series; we will not redefine them here [@app-identity-sibling].

MIC fixed the integrity boundary inside the kernel. But the same year shipped a separate retrofit for a different problem: why was the consumer admin running every clicked-on .exe with full administrative authority? And why did Microsoft refuse to call its answer a security boundary?

8. UAC, the Split-Token, and the Bypass Tradition

Vista's User Account Control is the most famous Windows security retrofit, and the only one whose own keepers explicitly published a document declaring it not a security boundary [@msrc-servicing-criteria]. The mechanism is precise. The bypass tradition is enormous. The classification is honest.

The mechanism first. Microsoft's documentation on how UAC works gives the verbatim recipe [@ms-learn-uac]: "When an administrator logs on, two separate access tokens are created for the user: a standard user access token and an administrator access token. The standard user access token... contains the same user-specific information as the administrator access token, but the administrative Windows privileges and SIDs are removed... is used to display the desktop by executing the process explorer.exe. Explorer.exe is the parent process from which all other user-initiated processes inherit their access token. As a result, all apps run as a standard user unless a user provides consent or credentials to approve an app to use a full administrative access token."

A Windows mechanism, introduced with Vista (released to manufacturing November 8, 2006 [@en-wiki-windows-vista]), in which an administrative user receives two linked tokens at logon: a *filtered* Medium-IL token without administrative privileges or SIDs, used by `explorer.exe` and every process descended from it, and a *full* High-IL administrative counterpart that the kernel hands out only after the user clicks through a consent prompt or supplies credentials. The two tokens reference each other through the `LinkedToken` field. UAC is a UX-and-default-behaviour mechanism, not an enforced security boundary [@ms-learn-uac, @msrc-servicing-criteria].

The split-token mechanism produces three elevation triggers. First, an executable can declare its required level in its manifest via the requestedExecutionLevel element (asInvoker, highestAvailable, or requireAdministrator). Second, certain Microsoft-signed binaries appear on an AutoElevate whitelist that the kernel consults; processes on the whitelist transparently get the full token without prompting. Third, COM components can be marked elevatable via the COM Elevation Moniker, which lets code instantiate Elevation:Administrator!new:{guid} (or Elevation:Highest!new:{guid}) to obtain a High-IL administrator COM caller -- not a SYSTEM caller; the moniker's supported run levels are Administrator and Highest [@ms-learn-com-elevation-moniker]. Method 41 (Oddvar Moe's ICMLuaUtil construction) is the canonical worked example.

The classification next. Microsoft's Security Servicing Criteria for Windows defines a security boundary as the logical separation between security domains with different trust levels, and gives the kernel-mode / user-mode separation as the canonical example [@msrc-servicing-criteria]. The criteria document then enumerates which boundaries Microsoft commits to servicing. UAC and admin-to-kernel are not on the enumerated list.

A security boundary provides a logical separation between the code and data of security domains with different levels of trust... the separation between kernel mode and user mode is a classic [...] security boundary. Microsoft software depends on multiple security boundaries to isolate devices on the network, virtual machines, and applications on a device. -- Microsoft Security Servicing Criteria for Windows [@msrc-servicing-criteria]

The "outside the enumerated list" classification has a concrete consequence: bypasses of UAC are not eligible for the same security-update treatment a kernel-mode-to-user-mode bypass would get. Mitigations are issued per-redirect, when an attacker's specific path becomes operationally noisy enough to warrant attention. The seventy-plus methods catalogued in UACMe are the empirical consequence.

Key idea: UAC was never a security boundary. The seventy-plus methods catalogued in UACMe are not bugs in UAC. They are the formal consequence of UAC's classification. Once you recognise that UAC is a UX-and-default-behaviour mechanism rather than an enforced boundary, the bypass tradition is legible as a feature being used as designed and the structural arc to Adminless makes sense.

The bypass canon. Walk it generation by generation.

Method 1 -- Leo Davidson, 2009. Davidson's Windows 7 UAC Whitelist writeup is the genealogical root of the UAC bypass tradition [@pretentiousname-davidson, @github-hfiref0x-uacme]. He noticed that sysprep.exe is on the AutoElevate whitelist and that, when launched from C:\Windows\System32\sysprep\, it loads several DLLs from the working directory. Use the IFileOperation COM interface (which the elevator treats as AutoApprove, enabling the file copy without prompting) to drop a malicious cryptbase.dll into %SystemRoot%\System32\sysprep\. Then trigger sysprep.exe -- which is on the AutoElevate whitelist -- and the auto-elevated process loads the attacker's DLL, and the attacker has a High-IL full administrative token.

Davidson's writeup quotes himself bluntly: "This works against the RTM (retail) and RC1 versions of Windows 7" [@pretentiousname-davidson]. UACMe Method 1 records the technique with structured metadata: "Author: Leo Davidson / Type: Dll Hijack / Method: IFileOperation / Target(s): \system32\sysprep\sysprep.exe / Component(s): cryptbase.dll / Implementation: ucmStandardAutoElevation / Works from: Windows 7 (7600) / Fixed in: Windows 8.1 (9600)" [@github-hfiref0x-uacme].

Method 25 -- Matt Nelson (enigma0x3), August 15, 2016. Seven years after Davidson, Nelson published "Fileless UAC Bypass Using eventvwr.exe and Registry Hijacking" [@enigma0x3-eventvwr-blog]. The bypass replaces the file-system DLL hijack with a registry redirect. Nelson noticed that eventvwr.exe, an AutoElevated binary, queries HKCU\Software\Classes\mscfile\shell\open\command before HKCR\mscfile\shell\open\command to find the command to run for the mscfile ProgID. His verbatim observation: "From the output, it appears that 'eventvwr.exe', as a high integrity process, queries both HKCU and HKCR registry hives to start mmc.exe" [@enigma0x3-eventvwr-blog]. HKCU is writable by the standard user; the user writes a malicious command line under that key, runs eventvwr.exe, and the auto-elevated process happily executes the user-supplied command line. The first fileless UAC bypass.

Method 33 -- winscripting.blog, 2017. Same primitive, different target. The fodhelper.exe binary is on the AutoElevate whitelist and queries HKCU\Software\Classes\ms-settings\shell\open\command to launch the Settings app. UACMe records the credit precisely: "Author: winscripting.blog / Type: Shell API / Method: Registry key manipulation / Target(s): \system32\fodhelper.exe / Component(s): Attacker defined / Implementation: ucmShellRegModMethod / Works from: Windows 10 TH1 (10240) / Fixed in: unfixed" [@github-hfiref0x-uacme]. Fixed in: unfixed. This is what "outside the enumerated list" looks like in practice: nine years after Method 1 and a year after Method 25 demonstrated the underlying class, the registry-redirect template was still being applied to fresh AutoElevate targets and shipping unmitigated.

Method 41 -- Oddvar Moe. The COM elevation moniker route. UACMe records: "Author: Oddvar Moe / Type: Elevated COM interface / Method: ICMLuaUtil" [@github-hfiref0x-uacme]. Instantiate the CMLuaUtil COM object via the elevation moniker from a Medium-IL process, get back a High-IL COM caller, and call its ShellExec method to run an attacker command line at High IL. The seam is the COM moniker registry's Elevation\Enabled key, which marks specific CLSIDs as elevation-capable.

Method 31 (sdclt), 29, 34, ... The pattern repeats. Matt Nelson's sdclt.exe variants exploit the backup-restore UI's registry lookups. Forshaw's schtasks variant exploits the scheduled-task COM interface. The UACMe README enumerates the lot with the laconic one-liner "Defeating Windows User Account Control by abusing built-in Windows AutoElevate backdoor" [@github-hfiref0x-uacme]. Most of the methods reduce to the same primitive: an AutoElevated Microsoft-signed binary performs a lookup that the standard user can redirect, the standard user supplies an attacker-controlled answer, and the auto-elevated binary executes attacker-controlled work.

flowchart TD A[User Medium-IL process] --> B[Write attacker command line into HKCU writable seam: registry key, file system path, scheduled-task XML] B --> C[Trigger AutoElevated Microsoft-signed binary: sysprep.exe / eventvwr.exe / fodhelper.exe / sdclt.exe / etc.] C --> D[AutoElevate flag honoured by kernel] D --> E[Binary launched at High IL with full administrative token] E --> F[Binary performs lookup: HKCU registry / DLL search path / scheduled-task definition] F --> G[Lookup returns attacker-supplied content] G --> H[High-IL process executes attacker work] Mark Russinovich's June 2007 *TechNet Magazine* cover story, "Inside Windows Vista User Account Control," is the canonical practitioner walkthrough of the split-token model and is preserved on the Wayback Machine [@wayback-russinovich-uac-technet]. Russinovich opens by naming the misunderstanding: "User Account Control (UAC) is an often misunderstood feature in Windows Vista... In this article I discuss the problems UAC solves and describe the architecture and implementation of its component technologies." The framing throughout the article is that UAC's purpose is to create the *expectation* that consumer software would run as a standard user, and to push the developer community to refactor away from gratuitous administrator requirements. That framing -- UAC as a UX and migration mechanism -- is consistent with the eventual MSRC servicing-criteria position: not a defended boundary, but a behaviour gate.

Note: Microsoft's servicing-criteria position means a UAC bypass that does not also cross a serviced security boundary is not, by policy, eligible for a security update. Mitigations land when the operational footprint of a particular bypass becomes large enough to justify one. Track UAC mitigations by KB number, not by feature description; consult the UACMe README's Fixed in: field as the institutional memory [@github-hfiref0x-uacme, @msrc-servicing-criteria].

UAC bypasses redirect the elevation flow that produces a token. A different attack family takes the result and steals tokens from already-elevated SYSTEM services. Where do those attacks come from, and why are they all the same bug?

9. The Object Manager and the Lookup Surface

SeAccessCheck evaluates a security descriptor it has been handed. Who hands it the descriptor?

The kernel's Object Manager does, after walking a name. Every named kernel object lives somewhere in a hierarchical namespace rooted at \. Devices live under \Device. Synchronisation primitives live under \BaseNamedObjects. Pre-resolved DLL names live under \KnownDlls. Per-session subtrees live under \Sessions. The DOS device prefix \GLOBAL?? (and its session-local sibling \??) holds drive-letter symbolic links into the device tree. When a process calls OpenObject, the Object Manager parses the name, walks the tree, and returns the object whose security descriptor SeAccessCheck will then evaluate.

The kernel performs the lookup before the access check. This sequencing creates a parallel attack surface that bypasses SeAccessCheck entirely. If the attacker can influence the name resolution -- redirect a \??\ symbolic link, plant a junction in NTFS that re-targets a directory traversal, hardlink a low-privilege file at a path the kernel will trust because of the parent directory's descriptor -- then by the time SeAccessCheck runs, it is being asked about a different object than the original code path intended to open.

The HiveNightmare lookup path is the canonical worked example. The exploit reads the SAM database not via \Windows\System32\config\SAM (which has a tight DACL) but via \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy*\Windows\System32\config\SAM. That path resolves through the Object Manager's \GLOBAL?? symbolic link, into the device tree, into a Volume Shadow Copy mirror of the original volume, into a copy of SAM whose DACL was, until the August 2021 patch, readable by any authenticated local user (BUILTIN\Users) [@nvd-cve-2021-36934].

The lookup-phase attack class is wider than file-system shadow copies. Object Manager symbolic links and NTFS hard links both produce the same primitive: the kernel resolves a name through an attacker-influenced redirect and ends up evaluating SeAccessCheck against a different security descriptor than the calling code intended.

CVE-2020-0668, the Service Tracing elevation-of-privilege bug Clément Labro disclosed in February 2020, is the textbook symbolic-link case [@itm4n-cve-2020-0668-blog]. The Service Tracing infrastructure under HKLM\SOFTWARE\Microsoft\Tracing is user-writable, and several SYSTEM services -- IKEEXT, RasMan, the Update Session Orchestrator service -- consult those keys to find a tracing log path. When the log file exceeds the configured MaxFileSize, the service renames it from MODULE.LOG to MODULE.OLD, deleting any existing MODULE.OLD first.

itm4n's exploit is exactly the one his blog post names: "All you need to do is set the target directory as a mountpoint to the \RPC Control object directory and then create two symbolic links: A symbolic link from MODULE.LOG to a file you own; A symbolic link from MODULE.OLD to any file on the file system" [@itm4n-cve-2020-0668-blog]. The mountpoint reroutes the kernel's name resolution into an Object Manager directory the attacker controls; the two symlinks reroute the rename operation; the SYSTEM service ends up performing an arbitrary file move with kernel authority. Forshaw's googleprojectzero/symboliclink-testing-tools repository [@github-projectzero-symlink-tools] provides the primitive library the exploit consumes -- CreateSymlink, CreateMountPoint, BaitAndSwitch -- and the repository is, in effect, the institutional library every Object Manager lookup-phase attack of the past decade has linked against.

The NTFS hard-link case predates the symbolic-link case by half a decade. James Forshaw's December 2015 Project Zero post, "Between a Rock and a Hard Link," is the canonical primary source [@projectzero-blog-rockandhardlink]. Forshaw observes that hard links have been a feature of NTFS "since it was originally designed", and that their relevance to local privilege escalation is exactly the lookup-vs-access-check sequencing this section describes: "Why are hard links useful for local privilege escalation? One type of vulnerability is exploited by a file planting attack, where a privilege service tries to write to a file in a known location" [@projectzero-blog-rockandhardlink].

The worked example Forshaw walks is CVE-2015-4481, a Mozilla Maintenance Service hard-link primitive: any user can write a status log to C:\ProgramData\Mozilla\logs\maintenanceservice.log, and during the service's pre-write BackupOldLogs rename a brief window opens in which the attacker can replace the about-to-be-written log path with a hard link to an arbitrary system file. The service's subsequent write -- which it performs with its own SYSTEM authority -- ends up overwriting the system file. The DACL on the source file (the Mozilla log directory) was correct; the DACL on the destination file (the system binary) was correct; the kernel arrived at the destination by resolving a hard-link name the attacker had planted, and SeAccessCheck saw only the destination DACL, not the planted-link DACL [@projectzero-blog-rockandhardlink]. Microsoft's MS15-115 mitigation tightened the kernel's hard-link semantics for sandboxed callers (the kernel's NtSetInformationFile now requires FILE_WRITE_ATTRIBUTES on the target handle when the caller's token has the sandboxed-token flag, matching what the user-mode CreateHardLink wrapper had always opened the target with). The fix closes the sandboxed-process branch of the bug class but, as Forshaw notes, does nothing for the Maintenance Service vulnerability itself, which is exploited by a non-sandboxed local user; the structural fix is to write the log to a directory the user cannot create files in, not to enforce a hard-link mask -- a structural fix to the lookup phase, not the access-check phase.

The two examples generalise the rule. The kernel resolves names before checking the requesting user's authority over the destination. The DACL at target.path and the DACL at attacker.planted.path after a junction or hard-link redirect can be different; SeAccessCheck evaluates the descriptor it arrives at, not the descriptor the original caller intended. Capability systems would resolve names through unforgeable handles instead of strings, and the redirect class would not exist by construction [@en-wiki-capability-based-security]. Windows checks the descriptor on every OpenObject because the name is a forgeable string. The Object Manager namespace is therefore an attack surface whose load-bearing fix is structural rather than per-bug.The Object Manager's namespace is not documented as policy in the same way SeAccessCheck's algorithm is. The de facto modern documentation is empirical: practitioners enumerate the namespace with tools that read kernel structures directly. James Forshaw's NtObjectManager PowerShell module, part of the Project Zero sandbox-attacksurface-analysis-tools repository, is the dominant such tool [@github-projectzero-sandbox-attacksurface]. The repository's banner is exact: "NtObjectManager: A powershell module which uses NtApiDotNet to expose the NT object manager."

The James Forshaw / Project Zero corpus is the systematic reference for the Object Manager attack surface. Forshaw's "Sharing a Logon Session a Little Too Much" (April 2020) names a primitive PrintSpoofer would later consume: when the LSA creates a token for a new logon session, it caches the token for later retrieval. Forshaw's verbatim explanation: "when LSASS creates a Token for a new Logon session it stores that Token for later retrieval. For the most part this isn't that useful, however there is one case where the session Token is repurposed, network authentication" [@tiraniddo-sharing-logon-session]. The cached token plus a named-pipe path-validation bug becomes a non-DCOM SYSTEM-token primitive that no DACL touches.

The lookup surface is half the attack story. The other half is the token surface, and the canonical example of the token surface is a six-year, eight-tool lineage.

10. The Potato Lineage: Eight Tools, One Bug (2016-2021)

January 16, 2016. Stephen Breen of Foxglove Security publishes "Hot Potato." The disclosure post opens with a sentence the article will earn the right to repeat: "Microsoft is aware of all of these issues and has been for some time (circa 2000). These are unfortunately hard to fix without breaking backward compatibility and have been [used] by attackers for over 15 years" [@foxglove-hot-potato-blog]. Six years and seven tools later, that admission still describes the situation.

The single underlying primitive. A low-privileged service account holding SeImpersonatePrivilege (which IIS, SQL Server, the Print Spooler, scheduled tasks, Docker, Citrix, and almost every managed-service account hold by default) tricks SYSTEM into authenticating to a TCP, RPC, or named-pipe endpoint the attacker controls. The attacker's endpoint accepts the authentication, ends up with an impersonation handle to a SYSTEM token, and calls ImpersonateLoggedOnUser followed by CreateProcessAsUser to run arbitrary code as SYSTEM. Same primitive, eight tools, six years.

sequenceDiagram participant Attacker as Attacker (service account, SeImpersonate) participant Coercer as Coercion primitive (NBNS / DCOM / EFSRPC / Spooler RPC) participant SYSTEM as SYSTEM service participant Endpoint as Attacker-controlled local endpoint Attacker->>Coercer: Trigger coercion (e.g. EfsRpcOpenFileRaw, BITS CoGetInstanceFromIStorage) Coercer->>SYSTEM: Tell SYSTEM to authenticate SYSTEM->>Endpoint: NTLM authentication to attacker endpoint Endpoint->>Endpoint: Accept NTLM, build impersonation token Attacker->>Attacker: ImpersonateLoggedOnUser(SYSTEM token) Attacker->>Attacker: CreateProcessAsUser(SYSTEM token, "cmd.exe") Note over Attacker: SYSTEM shell

Walk the lineage one paragraph at a time.

Hot Potato (Stephen Breen / Foxglove, January 2016) [@foxglove-hot-potato-blog]. The original. Hot Potato chains three Windows defaults: NBT-NS (NetBIOS name service) spoofing on the local network, the Web Proxy Auto-Discovery (WPAD) protocol's automatic proxy lookup, and Windows Update's HTTP-to-SMB NTLM relay. The exploit poisons NBT-NS so that the SYSTEM-running Windows Update service resolves WPAD to the attacker's local listener; the attacker's listener serves a proxy configuration that proxies SMB through localhost; the Windows Update service authenticates to the attacker's localhost SMB endpoint as SYSTEM. Foxglove's verbatim summary: "Hot Potato (aka: Potato) takes advantage of known issues in Windows to gain local privilege escalation in default configurations, namely NTLM relay (specifically HTTP->SMB relay) and NBNS spoofing" [@foxglove-hot-potato-blog].

Rotten Potato (Stephen Breen and Chris Mallz / Foxglove, September 2016) [@foxglove-rotten-potato-blog]. The successor abandons the network-protocol fragility for a DCOM activation trick that James Forshaw had published as Project Zero issue 325. The attacker calls CoGetInstanceFromIStorage with the BITS CLSID {4991d34b-80a1-4291-83b6-3328366b9097} and a custom marshalled IStorage pointer; the COM activation runs on the local DCOM server (which runs as SYSTEM) and authenticates back to a TCP listener the attacker controls.

The Foxglove blog states the three steps verbatim: "1. Trick the 'NT AUTHORITY\SYSTEM' account into authenticating via NTLM to a TCP endpoint we control. 2. Man-in-the-middle this authentication attempt (NTLM relay) to locally negotiate a security token for the 'NT AUTHORITY\SYSTEM' account. 3. Impersonate the token... This can only be done if the attackers current account has the privilege to impersonate security tokens" [@foxglove-rotten-potato-blog]. The same post credits the Project Zero work directly: "this work is derived directly from James Forshaw's BlackHat talk and Google Project Zero research" [@foxglove-rotten-potato-blog].

Juicy Potato (decoder_it and ohpe, 2018) [@github-ohpe-juicy-potato]. A weaponised, configurable Rotten Potato. The repository README is exact about lineage and entry conditions: "RottenPotatoNG and its variants leverages the privilege escalation chain based on BITS service having the MiTM listener on 127.0.0.1:6666 and when you have SeImpersonate or SeAssignPrimaryToken privileges. ... We decided to weaponize RottenPotatoNG: Say hello to Juicy Potato" [@github-ohpe-juicy-potato].

Juicy Potato adds a CLSID brute-list (so the attacker can cycle through DCOM activations until one works on the target Windows version), a configurable listener port, and a configurable target binary. The repo's own framing of when it works is the article's PullQuote-worthy line: "If the user has SeImpersonate or SeAssignPrimaryToken privileges then you are SYSTEM" [@github-ohpe-juicy-potato]. Juicy Potato was killed by a Windows 10 1809 / Server 2019 mitigation that prevented the OXID resolver from being queried on a port other than 135. The mitigation was the first time Microsoft had touched the underlying primitive.

Rogue Potato (Antonio Cocomazzi and Andrea Pierini, May 2020) [@decoder-rogue-potato-blog]. The bypass for the loopback-OXID mitigation. Decoder's blog states the engineering problem and the fix in two sentences: "Starting from Windows 10 1809 & Windows Server 2019, its no more possible to query the OXID resolver on a port different than 135" [@decoder-rogue-potato-blog]. Rogue Potato works around the constraint by routing the OXID resolution through an attacker-controlled remote OXID resolver, typically reached via socat tcp-listen:135,fork TCP:attacker:9999. The remote resolver returns a string binding pointing back at the attacker's local listener; the constraint is satisfied (the OXID resolver is on port 135) but the listener it ultimately reaches is the attacker's. The lineage extends.

PrintSpoofer (Clément Labro / itm4n, May 2020) [@github-itm4n-printspoofer, @itm4n-printspoofer-blog]. The same week as Rogue Potato, a different no-DCOM, no-OXID variant lands. PrintSpoofer drops DCOM entirely. It uses the Print Spooler RPC method RpcRemoteFindFirstPrinterChangeNotificationEx to coerce the spooler (running as SYSTEM) to call back to a named pipe whose path the attacker controls. A path-validation bypass on the named-pipe name lets the attacker capture the SYSTEM credential the spooler offers.

itm4n's repository description summarises the entry condition: "From LOCAL/NETWORK SERVICE to SYSTEM by abusing SeImpersonatePrivilege on Windows 10 and Server 2016/2019" [@github-itm4n-printspoofer]. The blog post opens with credit and the canonical decoder_it quote: "I want to start things off with this quote from @decoder_it: 'if you have SeAssignPrimaryToken or SeImpersonate privilege, you are SYSTEM'" [@itm4n-printspoofer-blog].

RemotePotato0 (Cocomazzi and Pierini, 2021) [@github-antoniococo-remotepotato0]. The first Potato to escape the local machine. A cross-session DCOM activation lets the attacker reach a token from a different logged-on user; a cross-protocol RPC-to-LDAP relay then turns that user's authentication into a domain-administrator action against Active Directory.

The README is candid about the shape of the response: "UPDATE 21-10-2022: The main exploit scenario RPC->LDAP of RemotePotato0 has been fixed... Just another 'Won't Fix' Windows Privilege Escalation from User to Domain Admin. RemotePotato0 is an exploit that allows you to escalate your privileges from a generic User to Domain Admin... It abuses the DCOM activation service and trigger an NTLM authentication of any user currently logged on in the target machine" [@github-antoniococo-remotepotato0]. Just another "Won't Fix" Windows Privilege Escalation is the precise framing: the underlying primitive is structural, the 2022 fix addressed the specific RPC-to-LDAP path, and the construction continues to work for other relay targets.

PetitPotam (Lionel Gilles / topotam77, July 2021) [@github-topotam-petitpotam, @nvd-cve-2021-36942]. Not strictly a local-LPE Potato, but the source of the EFSRPC coercion primitive that local-LPE Potatoes consume. PetitPotam exploits the Encrypting File System remote-procedure-call protocol's EfsRpcOpenFileRaw (and several other functions) to coerce a Windows host to authenticate to an attacker-controlled endpoint.

The README is exact about the interface choices: "PoC tool to coerce Windows hosts to authenticate to other machines via MS-EFSRPC EfsRpcOpenFileRaw or other functions :) The tools use the LSARPC named pipe with inteface c681d488-d850-11d0-8c52-00c04fd90f7e because it's more prevalent. But it's possible to trigger with the EFSRPC named pipe and interface df1941c5-fe89-4e79-bf10-463657acf44d" [@github-topotam-petitpotam]. PetitPotam's most-cited use case is cross-machine relay against Active Directory Certificate Services, but the EFSRPC coercion is also locally consumable.

SharpEfsPotato (bugch3ck, 2021) [@github-bugch3ck-sharpefspotato]. The local-machine variant of the PetitPotam coercion. The README is precise about lineage: "Local privilege escalation from SeImpersonatePrivilege using EfsRpc. Built from SweetPotato by @_EthicalChaos_ and SharpSystemTriggers/SharpEfsTrigger by @cube0x0" [@github-bugch3ck-sharpefspotato]. SharpEfsPotato uses EfsRpcOpenFileRaw against the local LSARPC pipe to coerce SYSTEM to authenticate to a local endpoint, then performs the by-now-familiar token capture and CreateProcessAsUser.This article's stage-4 source verification corrected an attribution that had been carried forward from the original scope file: SharpEfsPotato's canonical repository is bugch3ck/SharpEfsPotato, not the often-cited ly4k/SharpEfsPotato. The latter URL returns HTTP 404. Cross-references that point at the ly4k URL should be updated to point at bugch3ck [@github-bugch3ck-sharpefspotato].

The pattern across the lineage is that the mitigation that did break a tool was always specific (the loopback-OXID restriction, the cross-session DCOM partial fix, the EFSRPC coercion partial mitigation in KB5005413), and the mitigation that would break the family is structural (remove SeImpersonatePrivilege from service accounts, end NTLM-to-self-as-machine relay, retire the bearer-credential property of tokens). Microsoft has shipped the first kind of fix seven times across the lineage and continues to ship them; the second kind requires architectural changes that arrive in successor articles in this series.

Tool	Year	Author(s)	Coercion vector	Mitigation that broke it	Mitigation that did not
Hot Potato	2016	Breen	NBT-NS + WPAD + HTTP-to-SMB relay	Disable WPAD; KB3146965	`SeImpersonate` on services
Rotten Potato	2016	Breen, Mallz	DCOM `CoGetInstanceFromIStorage` (BITS)	(none specific until Juicy fix)	`SeImpersonate` on services
Juicy Potato	2018	decoder_it, ohpe	DCOM CLSID brute-list, configurable port	Loopback-OXID restriction (1809 / 2019)	`SeImpersonate` on services
Rogue Potato	2020	Cocomazzi, Pierini	Remote OXID resolver via `socat`	Cross-session DCOM partial fix	`SeImpersonate` on services
PrintSpoofer	2020	Labro	Spooler RPC + named-pipe path bypass	KB5005010 (PrintNightmare-era spooler hardening) [@nvd-cve-2021-34527]	`SeImpersonate` on services
RemotePotato0	2021	Cocomazzi, Pierini	Cross-session DCOM + RPC-to-LDAP relay	RPC-to-LDAP relay fix (October 2022)	`SeImpersonate` on services; remaining relay targets
PetitPotam	2021	Gilles	EFSRPC coercion via LSARPC	KB5005413 partial; ADCS hardening [@nvd-cve-2021-36942]	`SeImpersonate` on services; other relay targets
SharpEfsPotato	2021	bugch3ck	Local EFSRPC coercion	(none specific to local variant)	`SeImpersonate` on services

Eight tools. One privilege. Every "mitigation that did not" cell points at the same thing: a bearer-token model plus SeImpersonatePrivilege on a service account.

Eight tools in six years against the same underlying primitive is not a tooling coincidence. It is the empirical signature of the bearer-credential property and the omnipresent service-account `SeImpersonate` privilege. The Hot Potato post's verbatim "hard to fix without breaking backward compatibility" admission [@foxglove-hot-potato-blog] is the same argument Microsoft eventually formalised in the security-servicing-criteria position: this surface is intentionally retained for compatibility, and structural changes belong in a different architecture. The article earns the bridge to the Adminless and NTLMless successors here, six years before the calendar gets there.

Note: A service account holding SeImpersonatePrivilege plus any RPC interface that authenticates to attacker-controllable endpoints equals SYSTEM. Eight Potatoes in six years prove this is structural, not a tooling fad. Audit every server: any non-LocalSystem-equivalent process holding SeImpersonate or SeAssignPrimaryToken should be treated as a Potato target until proven otherwise. Pre-deploy per-service SIDs and Group Managed Service Accounts where possible to constrain the blast radius [@github-itm4n-printspoofer].

Eight Potatoes prove the bearer-token property is unkillable by point fixes. But what does an attacker who is already admin do? The answer is the most-cited offensive Windows tool of the past fifteen years.

11. Mimikatz, Conditional ACEs, and the Edges of the Model

May 2011. Benjamin Delpy releases the first version of Mimikatz [@en-wiki-mimikatz]. Wikipedia's biographical summary is precise: "He released the first version of the software in May 2011 as closed source software" [@en-wiki-mimikatz]. Fifteen years later, every offensive Windows engagement on Earth still reaches for it.

Mimikatz contains many modules. Two of them sit directly on the access-control surface and are worth naming explicitly. The repository's own command surface lists them as privilege::debug and token::elevate [@github-gentilkiwi-mimikatz].

privilege::debug is one line of code: the command enables SeDebugPrivilege on the caller's token. Any local administrator on stock Windows holds the privilege on the token by default; the command flips it from Available to Enabled via AdjustTokenPrivileges. With SeDebugPrivilege enabled, the calling process can OpenProcess against any other process on the machine, including SYSTEM-level services such as lsass.exe. Every Mimikatz session that wants to read process memory begins with privilege::debug.

token::elevate is three lines of code in spirit. The command opens a SYSTEM-owned process (typically lsass.exe), calls OpenProcessToken to retrieve a handle to the SYSTEM token, calls DuplicateTokenEx to duplicate the handle for impersonation, and calls SetThreadToken to attach the duplicated SYSTEM token to the calling thread. The thread is now SYSTEM. The bearer-token property in three lines of code.

This article does not cover sekurlsa::logonpasswords. That command is the most-cited Mimikatz capability in journalism (it reads cached credentials from lsass.exe), but the credential-storage surface and the Credential Guard mitigation belong to the Secure Kernel sibling article in this series [@secure-kernel-sibling]. For the purposes of this article, the lesson stops at token::elevate.

The lesson is the structural concession. With administrator rights on the local machine and SeDebugPrivilege enabled, the access-control model has no defence for "I will pretend to be a different process," because admin equals kernel by Microsoft's own boundary definition [@msrc-servicing-criteria]. The DACL evaluation algorithm does not protect against a caller who can read and write arbitrary kernel memory. The privilege list does not protect against a caller who can rewrite the privilege check. The integrity check does not protect against a caller who can edit the integrity label. Every primitive in the model is, by construction, defenceless against an attacker who has crossed the boundary the model considers itself responsible for defending.

Note: With administrator rights and SeDebugPrivilege, the Windows access-control model has no defence for "I will pretend to be a different process," because admin equals kernel by Microsoft's own boundary definition. Mimikatz token::elevate is the canonical demonstration. The structural fix for selected secrets is Credential Guard, which moves the secret out of the NT kernel's address space entirely. See the Secure Kernel sibling article for the architecture [@secure-kernel-sibling, @msrc-servicing-criteria].

The model has been extended in only one structural direction since 1993, and that direction is the subject of the access matrix. Conditional ACEs and Dynamic Access Control (DAC) shipped together in Windows Server 2012 and Windows 8 [@ms-learn-dac]. They are the only extension of the access-matrix subject Microsoft has shipped in thirty-three years.

The mechanism is twofold. First, ACEs gain an expression syntax. The SDDL ACE strings page documents XA, XD, XU, and ZA as conditional callback variants of the basic allow / deny / audit / object-allow ACE types [@ms-learn-ace-strings]. A conditional ACE carries an expression in addition to a SID and an access mask, and the kernel evaluates the expression against the token's claims at access time. The canonical example is (XA;;FA;;;AU;(@User.Department=="Finance")) -- an allow-callback ACE that grants FILE_ALL_ACCESS to Authenticated Users if the token carries a Department claim equal to "Finance".

Second, the token gains claims. A claim is a typed key-value pair attached to the token by Active Directory at logon. Claims can be sourced from the user's AD attributes, the device's AD attributes, or resource properties on the object. Microsoft Learn states the role they play: "A central access rule is an expression of authorization rules that can include one or more conditions involving user groups, user claims, device claims, and resource properties. Multiple central access rules can be combined into a central access policy" [@ms-learn-dac].

A Central Access Policy (CAP) is a set of Central Access Rules (CARs), each of which is a conditional-ACE expression. The CAP is applied to file shares; the file-share metadata says "evaluate this CAP for every access," and the CAP's expressions reference token claims. The DAC scenario guidance enumerates the deployment-side primitives -- automatic and manual file classification, central access policies for safety-net authorisation, central audit policies for compliance reporting, and Rights Management Service encryption for data-in-use protection [@ms-learn-dac-scenario].

The reason DAC has not displaced classic DAC outside file-server scenarios is in the same Microsoft Learn page: "Dynamic Access Control is not supported in Windows operating systems prior to Windows Server 2012 and Windows 8. When Dynamic Access Control is configured in environments with supported and non-supported versions of Windows, only the supported versions will implement the changes" [@ms-learn-dac]. Heterogeneous environments fall back to classic DAC. Airgapped environments without a working AD plus AD FS plane have no claims to evaluate. Conditional ACEs are a real extension of the model's subject dimension; they are also a real bet that the AD-and-Kerberos plane is healthy enough to evaluate them on every access.AppContainer's Package SIDs (Windows 8) and conditional ACEs (Server 2012) shipped the same year. Both extend the subject dimension of the access matrix -- one with code identity, one with attribute claims. Neither closes the kernel-equals-admin gap. The two extensions are coordinate, not stacked: a conditional ACE can reference a Package SID; a Package SID can be the subject of a conditional ACE [@ms-learn-dac, @app-identity-sibling].

The model has been extended in two coordinate dimensions in thirty-three years. It has not been replaced. So what does the whole thing look like put together -- and what does it actually fail at?

12. The 2026 Plane: Ten Primitives, One Decision

Run a single OpenObject call on a Windows 11 machine and walk the kernel's path. Every primitive the article has introduced fires for that one call.

flowchart LR A[User-mode caller] -->|OpenObject name, DesiredAccess, Token| B[Object Manager] B -->|Resolve name in namespace| C[Namespace lookup] C -->|Fetch security descriptor| D[Object header SD] D --> E[SeAccessCheck] E --> F[Generic-to-specific mapping] F --> G[Mandatory Integrity Control check] G -->|Pass| H[AppContainer / capability check] H --> I[Privilege bypass: SeBackup / SeRestore / SeDebug] I --> J[DACL walk in canonical order] J --> K[Conditional ACE expression evaluation] K --> L[GrantedAccess accumulated] L --> M[SACL audit ACE emit if matched] M --> N[Return HANDLE or STATUS_ACCESS_DENIED]

The diagram is the article in one figure. Read it left to right. Every box is a primitive named in Sections 3 to 11. Every famous Windows escalation tool of the last twenty-five years targets one of those boxes:

#	Primitive	Section introduced	Year shipped	Canonical primary citation	Canonical attack
1	Security Reference Monitor	3	1993	[@ms-learn-access-control]	(Underlying surface; not directly attacked)
2	Security Identifier (SID)	4	1993	[@ms-learn-security-identifiers]	Misused well-known SIDs ("Everyone is just a SID")
3	Access Token	5	1993	[@ms-learn-access-tokens]	The Potato lineage; Mimikatz `token::elevate`
4	Security Descriptor	3	1993	[@ms-learn-how-dacls-control-access]	HiveNightmare (CVE-2021-36934)
5	DACL + ACE	4	1993	[@ms-learn-how-dacls-control-access, @ms-learn-order-of-aces]	NULL DACL misconfigurations; out-of-order ACEs
6	SACL + audit	3	1993	[@ms-learn-access-control]	Tools that copy DACL but not SACL silently drop integrity labels
7	Privilege	6	1993	[@ms-learn-privileges]	Mimikatz `privilege::debug`; `SeBackup` abuse
8	Mandatory Integrity Control	7	2007	[@ms-learn-mic]	IE7 Protected Mode broker bypasses
9	UAC split-token	8	2007	[@ms-learn-uac]	UACMe: 70+ AutoElevate-redirect methods [@github-hfiref0x-uacme]
10	Conditional ACE / DAC	11	2012	[@ms-learn-dac, @ms-learn-ace-strings]	Falls back to classic DAC in heterogeneous environments

Note: The Windows access-control model is one decision plane, not a feature catalogue. Every securable Windows operation resolves through SeAccessCheck against five fixed inputs. Every famous escalation tool of the last twenty-five years attacks one of those inputs. Recognising the model as a single plane is the key to using its vocabulary against any specific attack.

The plane is whole. It is also full of structural holes its own keepers have publicly admitted. What are they?

13. The Five Structural Limits

Microsoft's Security Servicing Criteria for Windows defines a security boundary as "a logical separation between the code and data of security domains with different levels of trust... the separation between kernel mode and user mode is a classic [...] security boundary" [@msrc-servicing-criteria]. The criteria document then enumerates which boundaries Microsoft commits to servicing. The kernel-mode / user-mode boundary qualifies. UAC and admin-to-kernel are not in the enumerated list. Once that admission is on the public record, the model's structural arc becomes legible. Five derived limits flow from the concession.

Limit 1: Admin equals kernel. Any compromise with administrator rights can rewrite the model's own enforcement code. Consequence: Mimikatz, every kernel-driver-loading attack, every signed-driver bring-your-own-vulnerable-driver path. Successor: VBS Trustlets, which host secrets and policy enforcement in the Virtual Trust Level 1 user-mode environment that the VTL0 NT kernel cannot read or modify. Detailed coverage belongs to the Secure Kernel sibling article in this series [@secure-kernel-sibling].

Limit 2: Tokens are bearer credentials. Whichever process holds the handle gets the rights. The kernel does not ask how the handle was obtained. Consequence: the entire Potato lineage (eight tools, six years), Mimikatz token::elevate, every cross-session token-theft attack. Successor: Adminless / Administrator Protection, which retires the long-lived filtered/full token pair in favour of a fresh, time-limited, just-in-time elevation flow gated by Windows Hello plus a hidden, system-generated, profile-separated user account that issues an isolated admin token [@ms-learn-administrator-protection, @techcommunity-admin-protection]. The forthcoming Adminless article in this series will cover the architecture in detail.

Limit 3: SeImpersonatePrivilege on every service account. IIS, SQL Server, the Print Spooler, scheduled tasks, Docker, Citrix, almost every managed-service account by default. Consequence: every Potato, by construction. Partial successor today: per-service SIDs and Group Managed Service Accounts let administrators constrain the blast radius of a compromised service. Structural successor: Adminless, which removes the privilege from the daily authentication path and demands a fresh elevation per privileged action [@ms-learn-administrator-protection, @techcommunity-admin-protection].

Limit 4: NTLM relay surface. As long as Windows services accept NTLM and the operating system signs NTLM challenges with the local-machine credential, the local-NTLM-to-self attack is structurally available. Consequence: PetitPotam, RemotePotato0, every cross-protocol relay. Successor: NTLMless, which formally retires NTLM as a default Windows authentication protocol [@techcommunity-windows-auth-evolution]. The on-ramp is the NTLM auditing channel introduced in Windows 11 24H2 and Windows Server 2025 (KB5064479, original publish date July 11, 2025), which records NTLMv1 usage in Microsoft\Windows\NTLM\Operational and gives administrators a per-workload deprecation telemetry [@ms-support-ntlm-auditing]. The forthcoming NTLMless article in this series will cover the architecture in detail.

Limit 5: The DACL is local. Conditional ACEs and Dynamic Access Control claims need a working AD-and-AD-FS plane to evaluate; airgapped or heterogeneous environments fall back to user / group SIDs as the only available subject. Consequence: the access-matrix subject is, in practice, still "user and group" for most non-file-server workloads. The 2012 extension to claims and code identity is real but operationally bounded.

The deepest of the five limits is the one Norm Hardy named in 1988. Hardy's framing returned in Section 2 [@en-wiki-confused-deputy] holds: capability systems close the gap structurally; ACL engineering does not.

seL4 closes it with machine-checked correctness proofs and a capability-based design that makes ambient authority a category error [@en-wiki-capability-based-security]. Windows closes it, when it closes it at all, with VBS Trustlets that move the right to perform the operation into a separate execution domain. The Potato lineage is the textbook confused-deputy instance: a service running with SeImpersonatePrivilege is the privileged compiler; the attacker is the user holding a billing-records-shaped pointer; the service uses its own authority on every authentication it accepts.

Note: Hardy's 1988 paper [@wayback-cap-lore-hardy] and the Wikipedia summary [@en-wiki-confused-deputy] both say the same thing: ACL systems are structurally vulnerable to confused-deputy attacks; capability systems are not. The gap is not asymptotic. ACL engineering does not close it. The Potato lineage is what the gap looks like in the field, repeated against eight different coercion primitives over six years.

Key idea: The next generation of Windows defences cannot live inside the kernel, because the kernel is on the wrong side of the boundary the model draws. Microsoft's own servicing criteria admit it. Adminless, NTLMless, VBS Trustlets, and Credential Guard are the four non-overlapping ways to fix it. Each successor was scoped to close a specific gap the access-control model could not.

The five limits are named. The successors are shipping. What replaces what?

14. The Successors: Adminless, NTLMless, VBS Trustlets, Credential Guard

One paragraph each. This section is a forward-reference index, not a detailed walk-through.

Adminless. Removes the local Administrators group from the daily authentication path. The long-lived filtered / full token pair the UAC model produces at logon is replaced with a fresh, time-limited, just-in-time elevation flow: when a user wants to perform a privileged action, the system gates the action behind Windows Hello plus a hidden, system-generated, profile-separated user account that issues an isolated admin token, and the resulting token is bounded in time and scope [@ms-learn-administrator-protection].

The Microsoft Tech Community announcement (modified November 19, 2024) summarises the security argument: "By requiring explicit authorization for every administrative task, Administrator protection protects Windows from accidental changes by users and changes by malware... Malicious software often relies on admin privileges to change device settings and execute harmful actions. Administrator protection breaks the attack kill chain" [@techcommunity-admin-protection]. Closes: limits #2 and #3 -- there is no long-lived bearer credential to steal, and SeImpersonatePrivilege does not need to live on every service account because services run as bounded principals issued capabilities at the moment of need. Forthcoming article in this series.

NTLMless. Formally retires NTLM as a default Windows authentication protocol [@techcommunity-windows-auth-evolution]. The Tech Community announcement is unambiguous about direction: "Reducing the use of NTLM will ultimately culminate in it being disabled in Windows 11. We are taking a data-driven approach and monitoring reductions in NTLM usage to determine when it will be safe to disable" [@techcommunity-windows-auth-evolution].

The transition rests on a local KDC (IAKerb) that lets Kerberos service both local and domain accounts, plus an audit channel introduced in Windows 11 24H2 and Windows Server 2025 (KB5064479, original publish date July 11, 2025) that records NTLMv1 usage in Microsoft\Windows\NTLM\Operational and gives administrators per-service telemetry on which workloads still require the protocol [@ms-support-ntlm-auditing]. The local-NTLM-to-self attack class -- coerce a SYSTEM service to authenticate with the local-machine credential, accept the challenge, relay it back to a local service that trusts the credential -- ends when the local-machine NTLM credential ends. Closes: limit #4. Forthcoming article in this series.

VBS Trustlets and Isolated User Mode. Shipped in Windows 10 1507 in 2015. Virtualization-Based Security (VBS) uses the Hyper-V hypervisor to host a second user-mode environment, Virtual Trust Level 1 (VTL1), whose memory the NT kernel running in VTL0 cannot read or write. A Trustlet is a process that runs in VTL1. Closes: limit #1, for selected secrets. The ordinary NT kernel still runs the show for ordinary processes; VTL1 is a side-channel for secrets and policy decisions that the model wants to protect even from a kernel-level attacker. Detailed coverage in the Secure Kernel sibling article [@secure-kernel-sibling].

Credential Guard. The canonical first Trustlet. lsass.exe continues to run in VTL0 and answer authentication requests; the credential blobs lsass.exe historically held are moved to a Trustlet called LsaIso in VTL1. The VTL0 lsass.exe retains handles to the blobs but cannot read their contents; authentication happens by calling into the Trustlet. Mimikatz sekurlsa::logonpasswords returns no plaintext credentials against a Credential-Guard-on system, because the plaintext does not live in VTL0 memory at all. The default-enablement timeline and the SKU-specific configuration matrix are covered in the Secure Kernel sibling article [@secure-kernel-sibling].

Pluton-rooted attestation and the hardware foundation. The successor architectures rest on a hardware identity chain that begins below the firmware, in Microsoft's Pluton in-die security processor. Pluton holds the keys that vouch for the boot measurements that the OS in turn uses to attest its own integrity to a remote relying party. The Pluton article in this series covers the architecture and the Caliptra root-of-trust direction it foreshadows [@pluton-sibling]. The TPM 2.0 architecture that the same chain extends and the Secure Boot chain that runs before the access-control model boots are covered in their own sibling articles in this series.

The five limits enumerated in Section 13 and the four successor articles in this section are in one-to-one correspondence: Adminless closes #2 and #3, NTLMless closes #4, VBS Trustlets close #1, and Credential Guard is the canonical first Trustlet that demonstrates #1 closing for a specific high-value secret. Limit #5 -- the DACL is local -- is operational rather than architectural and is closed by deployment investment in AD plus AD FS rather than by a new mechanism. The correspondence is not a coincidence. Each successor was scoped to close a specific gap the access-control model could not close from inside.

With the gaps named and the successors mapped, what does an administrator actually do today?

15. Practical Guide

Six concrete recommendations for 2026, each tied to a primary Microsoft Learn or named-expert source.

Note: whoami /all prints the SIDs in the calling thread's token, the integrity level, every privilege with its Enabled / Disabled / Default Enabled state, and -- on AD-joined machines with claims -- the user and device claim set. It is the single most useful diagnostic command for understanding what a session can do. Read the Enabled column carefully: an available-but-disabled privilege does not affect any access check until the process explicitly enables it [@ms-learn-access-tokens].

Note: icacls <path> prints the DACL on a file or directory; the mass-rights letters are (F) full, (M) modify, (RX) read and execute, (R) read, (W) write, (D) delete, (GA) generic all, (GR) generic read, (GW) generic write [@ms-learn-how-dacls-control-access]. PowerShell's Get-Acl returns the same descriptor as a structured object that can be filtered and audited at scale. Sysinternals accesschk.exe answers the inverted query (which paths grant a given SID a given right) and is the right tool for catching descriptor misconfigurations across a large file system. Treat NULL DACL and empty DACL surfaces as the most-likely misconfiguration vectors.

Note: On every Windows server, enumerate the principals whose tokens hold SeImpersonatePrivilege or SeAssignPrimaryTokenPrivilege in their Default or Available lists. Treat any non-LocalSystem-or-equivalent holder as a Potato target until proven otherwise. Where a service must hold the privilege (most managed-service workloads do), constrain the blast radius with per-service SIDs and Group Managed Service Accounts so that a compromise of one service does not extend to a compromise of every service that shares the host's identity [@github-itm4n-printspoofer].

Note: The UACMe README is the institutional memory for the seventy-method bypass canon. Every method's Fixed in: field cites a specific Windows version or unfixed. Before declaring a binary "patched," consult the README; a method with a Fixed in: unfixed annotation is structurally available on every supported Windows version. The institutional position is that UAC bypasses do not, by Microsoft's own servicing-criteria policy, earn CVEs of their own, so the mitigations are issued per-redirect rather than per-feature [@github-hfiref0x-uacme, @msrc-servicing-criteria].

Note: Windows Event ID 4688 ("A new process has been created") is the most-cited detection signal for the Potato lineage and the UAC bypass tradition, because almost every member of both families ends in a CreateProcessAsUser or a redirected AutoElevate launch with a command-line argument that does not match the legitimate use of the parent binary. Enable command-line auditing under Audit Process Creation and forward the log; Sysmon Event ID 1 is the equivalent and richer signal in environments that deploy Sysinternals' Sysmon.

Note: The access matrix is the part of the model with deliberately extensible subjects. New code that lives behind an AppContainer SID gets a Low-IL token, a Package SID, and a capability list that constrain what it can touch even when the user running it is an administrator. New file shares that need attribute-based authorization should use conditional ACEs and Dynamic Access Control rather than ad-hoc group membership. Cross-link to the App Identity sibling article for Package SID derivation [@app-identity-sibling] and to the Dynamic Access Control overview [@ms-learn-dac].

{` // Inputs: // token -- {sids:[...], integrity:'Low'|'Medium'|'High'|'System', // appContainer:bool, capabilities:[...], claims:{...}, // privileges:{enabled:[...]}} // descriptor -- {dacl:[...], integrityLabel:'Low'|...|'System', // policyNoWriteUp:bool} // desired -- access mask (number) // Output: {granted, status, fired:[...]}

function fullAccessCheck(token, descriptor, desired) { const fired = []; const ilOrder = {Low:1, Medium:2, High:3, System:4};

// 1. MIC check fires before DACL walk. if (descriptor.policyNoWriteUp) { const writeBits = 0x00040000 | 0x00000002 | 0x00000004; // WRITE_DAC|WRITE|APPEND if ((desired & writeBits) && ilOrder[token.integrity] < ilOrder[descriptor.integrityLabel]) { fired.push('MIC no-write-up: token IL ' + token.integrity + ' < object IL ' + descriptor.integrityLabel); return {granted:0, status:'DENIED at integrity check', fired}; } }

// 2. Privilege bypass short-circuit. if (token.privileges.enabled.includes('SeBackupPrivilege') && (desired & 0x80000000)) { fired.push('SeBackupPrivilege bypass: GENERIC_READ granted'); return {granted: desired, status:'GRANTED via SeBackupPrivilege', fired}; }

// 3. AppContainer capability check (simplified). if (token.appContainer && descriptor.requiresCapability) { if (!token.capabilities.includes(descriptor.requiresCapability)) { fired.push('AppContainer capability check: missing ' + descriptor.requiresCapability); return {granted:0, status:'DENIED at AppContainer check', fired}; } }

// 4. DACL walk, deny-first, in canonical order. let remaining = desired; let granted = 0; for (const ace of (descriptor.dacl || [])) { if (!token.sids.includes(ace.sid)) continue; if (ace.condition && !evalCondition(ace.condition, token.claims)) continue; if (ace.type === 'DENY' && (ace.mask & remaining) !== 0) { fired.push('Conditional/plain DENY: ' + ace.sid); return {granted:0, status:'DENIED at DACL', fired}; } if (ace.type === 'ALLOW') { const newBits = ace.mask & remaining; granted |= newBits; remaining &= ~newBits; fired.push('ALLOW ' + ace.sid + ': granted 0x' + newBits.toString(16)); } if (remaining === 0) { return {granted, status:'GRANTED', fired}; } } return {granted, status: remaining === 0 ? 'GRANTED' : 'DENIED end of DACL', fired}; }

function evalCondition(expr, claims) { // Toy evaluator for "(@User.Department == \"Finance\")"-style expressions. const m = expr.match(/@User\.(\w+)\s*==\s*"([^"]+)"/); if (!m) return true; return claims[m[1]] === m[2]; }

// Demo: a Medium-IL user trying to write to a System-IL object via an allow ACE. console.log(fullAccessCheck( {sids:['S-1-5-21-X-Y-Z-1001'], integrity:'Medium', appContainer:false, capabilities:[], claims:{Department:'Finance'}, privileges:{enabled:[]}}, {dacl:[{type:'ALLOW', sid:'S-1-5-21-X-Y-Z-1001', mask:0xFFFFFFFF}], integrityLabel:'System', policyNoWriteUp:true}, 0x00040000)); // WRITE_DAC `}

The simulator runs the full plane in order: MIC integrity check, privilege bypass short-circuit, AppContainer capability check, DACL walk with conditional-ACE evaluation. Reading the fired log in the output tells you which primitive made the decision and why. It is the mental model the rest of the article has been building toward.

The six tips and the simulator together close the practical loop. With them, the practitioner can reason about any specific access decision the way the kernel does -- not by remembering features, but by walking the same plane.

The Sysinternals accesschk and psgetsid utilities have long been first-line investigative tools for ACL audits. Both ship in the Sysinternals Suite today and continue to surface the same descriptors Get-Acl and icacls print, in the form most useful to an administrator working at scale.

16. Frequently Asked Questions

No. By Microsoft's own *Security Servicing Criteria for Windows*, UAC and admin-to-kernel are not on the enumerated security-boundary list [@msrc-servicing-criteria]; bypasses are not, by policy, eligible for security servicing as boundary violations. The seventy-plus methods catalogued in UACMe are the empirical consequence of the classification, not a long string of bugs in a feature that was meant to defend against the techniques [@github-hfiref0x-uacme]. No. `Everyone` (the well-known SID `S-1-1-0`) is just a SID. ACEs that reference it are subject to the same DACL walk as any other SID; if a deny ACE for `Everyone` precedes an allow ACE for `Authenticated Users`, access is denied. The DACL evaluation algorithm does not know `Everyone` is special. Forshaw made the point with a meme-able rant in 2020: "S-1-1-0 is NOT A SECURITY BOUNDARY" [@tiraniddo-sharing-logon-session]. No. *Empty* DACL denies all access. *No* DACL (a NULL DACL) grants full access. Newly-written code that "creates a file with no protection" almost always gets this distinction wrong [@ms-learn-how-dacls-control-access]. Verify with `Get-Acl` or `icacls` after creation; an `icacls` output of `Everyone:(F)` on an object you intended to lock down is almost always a NULL DACL, not the policy you meant to write. For DACL alone, yes. For MIC, no -- a System-IL administrator still cannot write to a process at higher integrity if MIC denies the request, because the integrity check fires before the DACL walk [@ms-learn-mic]. For AppContainer, no -- AppContainer-bound objects require the capability SID, not just an administrator SID. For VBS Trustlets, no -- secrets in VTL1 are unreachable from VTL0 even with administrator rights, which is the whole point of the architecture [@secure-kernel-sibling]. No. The list shows *available* privileges. The `Enabled` column is the one that matters for runtime decisions; available-but-disabled privileges must be enabled via `AdjustTokenPrivileges` before any privileged operation can use them. Most privileges are disabled by default precisely so that a process must explicitly opt in to using one, which lets a security-conscious application minimise the window in which a bug can abuse the privilege [@ms-learn-privileges]. No. The underlying NTLM-to-self surface is still open. SharpEfsPotato (2021) [@github-bugch3ck-sharpefspotato] is the most recent member of the lineage; new tools using fresh coercion primitives (EFSRPC, the spooler, the schedule-task COM interface, cross-session DCOM) appear every twelve to eighteen months. Microsoft's own Hot Potato post called the underlying issue "hard to fix without breaking backward compatibility" [@foxglove-hot-potato-blog]; the structural fix is the Adminless and NTLMless successor articles, not a point patch on any one primitive. Partially. AppContainer is a process-level isolation mechanism with a Low-IL token plus a capability-SID list. It is also a *named principal* in the Windows access-control model -- something Chrome's sandbox is not -- which means AppContainer-bound code can be referenced by SID in a DACL or conditional ACE, and Windows can refuse access to it as a principal in its own right. The sibling App Identity article in this series covers the Package SID derivation and the relationship to Authenticode and App Control for Business [@app-identity-sibling].

17. Closing: Return to the Hook

Open a Windows PowerShell window again. Run whoami /priv. Read the column on the right, this time with the article's vocabulary annotated above each line.

SeShutdownPrivilege -- a privilege, in the kernel sense of a pre-checked superpower; bookkeeping rather than power.

SeIncreaseWorkingSetPrivilege -- the same. Most of the twenty rows are housekeeping that the kernel checks at specific call sites to gate non-security-critical operations.

The five rows that matter are easy to spot once you know what to look for. SeDebugPrivilege -- Mimikatz starts here. SeImpersonatePrivilege -- the entire Potato lineage starts here. SeAssignPrimaryTokenPrivilege -- the second half of every token-replay attack. SeBackupPrivilege -- HiveNightmare's privilege class. SeRestorePrivilege -- service-binary replacement. The kernel reads the same column on every securable operation, billions of times a second, and the answer to "can this code do this?" is built out of this list every time.

Now run icacls C:\Windows\System32\drivers\etc\hosts again. BUILTIN\Administrators:(F) is an allow ACE granting full control to the well-known SID S-1-5-32-544. NT AUTHORITY\SYSTEM:(F) is an allow ACE granting full control to S-1-5-18. BUILTIN\Users:(R) is an allow ACE granting FILE_GENERIC_READ to S-1-5-32-545. The DACL is in canonical order: explicit entries before inherited entries, deny entries (none here) before allow entries within each group. SeAccessCheck will walk this DACL on every read of hosts from any process on the machine, and the output will be deterministic -- the same answer every time, for the same caller -- because the model that produces it is closed and finite.

The article's payoff. Every later post in this series starts where this one ends. The Adminless article retires the bearer-credential property of long-lived tokens. The NTLMless article retires the local-NTLM-to-self relay surface. The Secure Kernel article hosts secrets in VTL1 outside the NT kernel's address space and tells the Credential Guard story in detail [@secure-kernel-sibling]. The Pluton article roots the hardware identity chain that the successor architectures all eventually verify against [@pluton-sibling]. The TPM article and the Secure Boot article cover the static-time and boot-time chains that run before the access-control model even loads. Each successor was scoped to close a specific gap the access-control model could not close from inside.

NT 3.1 froze a model in July 1993 because federal procurement demanded it. That model has not structurally changed in thirty-three years. The accumulated attack surface against it -- twenty-five years, eight Potatoes, seventy UAC bypasses, one Mimikatz -- is the empirical proof that "frozen" was always going to mean "attackable from below." The next generation of defences takes that lesson and stops trying to fix the model from inside. The model is not a feature catalogue. It is a decision plane with five inputs, ten primitives, and five publicly conceded structural limits, and the four successor architectures of the next decade are the four non-overlapping ways to close those limits without re-evaluating against TCSEC C2 again.

SeAccessCheck decides every time. The next decade decides what it decides about.