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

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 ^[1].

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 ^[2]. 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 ^{[3, 4, 5]}.

The thesis comes in three convictions:

1. SeAccessCheck is the answer. Every securable Windows operation that touches a securable object resolves through one decision function with one set of inputs ^[6].
2. 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 ^[7]. The vocabulary scales.
3. The model has five structural limits its keepers have publicly conceded ^[8], 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 ^{[9, 10]}. 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 ^[11]. 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 ^[11]. 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)" ^{[12, 13]}. 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" ^[14]. Hold this paper. It will come back in Section 10.

NT 3.1 released to manufacturing on July 27, 1993 ^[2]. NT 3.5, released to manufacturing on September 21, 1994 ^[18], 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 ^[18]; NT 4.0 Service Pack 6a later cleared the C2 network class against the Red Book's Trusted Network Interpretation ^[11]. 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 ^{[1, 19]}. The shape is the same in both directions:

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 ^{[20, 21]}).

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 ^[22]. 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) ^[19].

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..." ^[19].

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" ^[6].

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.

// 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.

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 ^[24]: "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!" ^[25]. 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) ^[26]. 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) ^{[27, 22]}. 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.

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 ^[29]. 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 ^[19]. 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.

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 ^[30].

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 ^[31].

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" ^[31]. 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" ^[31]. Few applications can spare the desktop overhead.

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.

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" ^[32]. The same page makes the operational consequence clear: "Most privileges are disabled by default" ^[32]. 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.

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 ^{[3, 33]}. 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 ^[30]. 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 ^[30]

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" ^[7]. 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" ^[7]. 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 ^[34]), the MSI Afterburner driver that "allows any authenticated user to read and write to arbitrary memory, I/O ports, and MSRs" ^[34]. In October 2022, the threat actors behind the BlackByte ransomware weaponised the primitive at scale ^[35]: 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" ^[35].

The kernel-code-execution half of the class is GIGABYTE's gdrv.sys (CVE-2018-19320 ^[36]). 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" ^[36]. 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 ^[36]. 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 ^[37]. 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" ^[37].

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 ^[38]) 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 ^[38].

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" ^[22]. The same page enumerates the levels: "Windows defines four integrity levels: low, medium, high, and system" ^[22]. 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) ^[27].

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 ^[22].

The integrity label is stored as a SYSTEM_MANDATORY_LABEL_ACE inside the SACL, not the DACL ^[40]. 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) ^[40].

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 ^[41]) 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) ^[42].

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 ^[22]. 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) ^{[43, 39]}. (IE7 standalone for Windows XP, released October 18, 2006 ^[44], 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" ^[43]. 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.

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" ^[22]. 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 ^[29].

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 ^[8]. 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 ^[45]: "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."

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 ^[46]. 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 ^[8]. 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 ^[8]

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.

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 ^{[47, 5]}. 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. Drop a malicious cryptbase.dll next to sysprep.exe, launch sysprep.exe via the IFileOperation COM interface (which has an AutoApprove flag honoured by the elevator), and sysprep.exe runs with a full token, loads the attacker's DLL, and the attacker has SYSTEM.

Davidson's writeup quotes himself bluntly: "This works against the RTM (retail) and RC1 versions of Windows 7" ^[47]. 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)" ^[5].

Method 25 -- Matt Nelson (enigma0x3), August 15, 2016. Seven years after Davidson, Nelson published "Fileless UAC Bypass Using eventvwr.exe and Registry Hijacking" ^[48]. 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" ^[48]. 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" ^[5]. 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" ^[5]. 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" ^[5]. 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]

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, world-readable ^[7].

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 ^{[50, 51]}. 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" ^[51]. 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 ^[52] 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 ^[53]. 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" ^[53].

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 ^{[54, 53]}. 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 ^[55]. 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 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" ^[25]. 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" ^[57]. 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) ^{[57, 58]}. 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" ^[57].

Rotten Potato (Stephen Breen and Chris Mallz / Foxglove, September 2016) ^{[59, 60]}. 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" ^[59]. 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" ^[59].

Juicy Potato (decoder_it and ohpe, 2018) ^[4]. 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" ^[4].

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" ^[4]. 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) ^{[61, 62]}. 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" ^[62]. 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) ^{[63, 30]}. 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" ^[63]. 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'" ^[30].

RemotePotato0 (Cocomazzi and Pierini, 2021) ^[64]. 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" ^[64]. 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) ^{[65, 66]}. 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" ^[65]. 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) ^[67]. 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" ^[67]. 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.

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.

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 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 ^[33]. Wikipedia's biographical summary is precise: "He released the first version of the software in May 2011 as closed source software" ^[33]. 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 ^[3].

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 ^[69]. 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 ^[8]. 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.

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 ^[70]. 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 ^[23]. 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" ^[70].

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 ^[71].

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" ^[70]. 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.

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:

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" ^[8]. 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 ^[69].

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 ^{[72, 73]}. 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 ^{[72, 73]}.

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 ^[74]. 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 ^[75]. 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 ^[14] 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 ^[55]. 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.

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 ^[72].

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" ^[73]. 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 ^[74]. 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" ^[74].

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 ^[75]. 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 ^[69].

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 ^[69].

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 ^[76]. 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 ^{[77, 78]}.

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.

// 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 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.

16. Frequently Asked Questions#

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 ^[69]. The Pluton article roots the hardware identity chain that the successor architectures all eventually verify against ^[76]. 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 ^{[77, 78]}. 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.

---WRITER METRICS---
Word count: 17108
Citations: 150
Mermaid diagrams: 4
Definitions: 11
Sidenotes: 6
FAQ questions: 7
---END WRITER METRICS---