Parag Mali - tag: protected-process-light

Protected Process Light: When the Administrator Isn't Enough

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

**Windows Protected Process Light (PPL) re-asks the question of who can touch whom one level below the token model.** A single byte in `EPROCESS` packs a process's protection type, audit bit, and signer rung; the kernel's lattice check inside `NtOpenProcess` rejects memory-read attempts from below the target's rung even when the caller is SYSTEM with `SeDebugPrivilege` enabled. Every public bypass since 2018 lives in one structural class -- the kernel verifies the channel by which code enters a PPL, not the behaviour of that code once mapped -- which is why Microsoft classifies PPL as defense in depth rather than a security boundary, and why Credential Guard / `LsaIso.exe` is its necessary VBS-anchored companion.

1. Mimikatz on a Protected Box

A red team operator has done everything right. The shell is SYSTEM-integrity. SeDebugPrivilege is enabled in the token. whoami /priv shows every privilege Windows defines. The operator types mimikatz.exe, then privilege::debug -- OK. Then sekurlsa::logonpasswords -- and Mimikatz answers:

ERROR kuhl_m_sekurlsa_acquireLSA ; Handle on memory : (0x00000005) Access is denied

The mechanism that just denied them is not a privilege check at all. It is not an ACL decision. It is not the integrity-level mediator. itm4n recreated exactly this failure in 2021 against a vanilla Windows install with one registry value set [@itm4n-runasppl]. The error code 0x00000005 is ERROR_ACCESS_DENIED -- the Win32 surface that GetLastError exposes for the kernel's NTSTATUS STATUS_ACCESS_DENIED = 0xC0000022. The kernel returns the NTSTATUS out of NtOpenProcess before the security descriptor of lsass.exe has been consulted; RtlNtStatusToDosError then maps it to the Win32 0x5 that surfaces in kuhl_m_sekurlsa.c.

A kernel-enforced gating model that decorates a process with a *protection level* -- a structured byte combining a type field, an audit bit, and a signer rung -- and rejects `OpenProcess` requests from callers whose protection level is below the target's, regardless of token privileges or security-descriptor ACLs.

Picture the scenario concretely. A 2026 red-team engagement against a hardened Windows 11 24H2 endpoint. RunAsPPL audit-mode is on by default after the Windows 11 22H2 rollout extended audit-default to consumer SKUs [@learn-runasppl]. A third-party EDR daemon is already running, signed at the Antimalware rung via the vendor's Microsoft Virus Initiative enrollment. The operator owns local administrator. The operator has SYSTEM. The operator holds every privilege Windows defines. They still cannot read a single byte of LSASS memory.

The denial trace, walked carefully, looks like this. Mimikatz calls OpenProcess(PROCESS_VM_READ | PROCESS_QUERY_INFORMATION, FALSE, lsass_pid). The Win32 thunk lands on NtOpenProcess, which dispatches to the object-manager callback PspProcessOpen. That callback calls PspCheckForInvalidAccessByProtection, which calls RtlTestProtectedAccess against the caller's EPROCESS.Protection byte and the target's EPROCESS.Protection byte. The lattice test fails. The kernel strips PROCESS_VM_READ from the requested mask. With the surviving limited mask, the request continues into SeAccessCheck, but Mimikatz never wanted the limited mask; it wanted to read memory. The handle returned (or the failure path taken) gives Mimikatz exactly the path that produces 0x00000005 in kuhl_m_sekurlsa.cThe relevant commit is fe4e98405589e96ed6de5e05ce3c872f8108c0a0, cited by itm4n as the source for the exact failure path that yields 0x00000005 [@mimikatz-sekurlsa]..

sequenceDiagram participant Mim as Mimikatz (SYSTEM, SeDebugPrivilege) participant K32 as kernel32 / OpenProcess participant NtOP as NtOpenProcess participant PsPO as PspProcessOpen participant CHK as PspCheckForInvalidAccessByProtection participant Lat as RtlTestProtectedAccess participant SAC as SeAccessCheck

Mim->>K32: OpenProcess(PROCESS_VM_READ, lsass)
K32->>NtOP: syscall NtOpenProcess
NtOP->>PsPO: object-manager callback
PsPO->>CHK: check caller.Protection vs target.Protection
CHK->>Lat: lattice rule (signer rungs)
Lat-->>CHK: full mask denied
CHK-->>PsPO: strip PROCESS_VM_READ
PsPO->>SAC: residual mask (limited only)
SAC-->>NtOP: limited handle (read denied)
NtOP-->>Mim: STATUS_ACCESS_DENIED (NTSTATUS 0xC0000022, Win32 GetLastError = 5)

Note: If every privilege Windows defines is held by the caller, what is doing the denying? The answer is a kernel structure that the token model does not see and the security descriptor does not influence -- a byte in EPROCESS named Protection, mediating a lattice the access check consults before it ever asks SeAccessCheck about privileges.

This is not a workaround pattern. It is a new dimension. The token model is unchanged. The integrity level is unchanged. The security descriptor on lsass.exe is unchanged. What changed is that the kernel now answers a question it did not ask before: what kind of trust does the caller have to manipulate the address space of the callee?

PPL re-asks the question of who can touch whom one level below the token model.

That mechanism has a name (Protected Process Light), an encoding (a single UCHAR), and a history that does not begin where you would expect. To understand the byte, we have to understand why Microsoft built it in the first place. The next section starts where the history starts: a 2006 Microsoft whitepaper about Hollywood.

2. Historical Origins -- Vista, DRM, and the First Protected Process

The kernel mechanism that today denies admins access to LSASS was invented in 2006 to keep Hollywood happy. The cover page of Microsoft's process_vista.doc whitepaper opens with a sentence almost no one quotes today:

The Microsoft Windows Vista operating system introduces a new type of process known as a protected process to enhance support for Digital Rights Management functionality in Windows Vista.

The whitepaper was published November 27, 2006, two months before Vista's GA, and it is the architectural seed of the byte we will be staring at for the rest of this article [@vista-process-doc]. The motivation was not credential theft. It was HD-DVD and Blu-ray content protection. Studio licensing agreements required that even an administrator on the local machine could not read the audio device graph isolation host's memory while protected content was playing. The Protected Media Path required a kernel-enforced barrier between admin user-mode and the media pipeline.

The Vista-era set of components that decrypt and render high-definition video and audio content under DRM. PMP requires kernel-enforced isolation of `audiodg.exe` and a small set of related processes so that local administrators cannot dump intermediate content keys from process memory.

The Vista design was minimal. A single bit in EPROCESS marks a process as protected. At NtCreateUserProcess, the kernel parses the main image's Authenticode signature and looks for a specific Microsoft EKU OID that only the PMP signing root can issue [@forshaw-2018-10]. If the EKU is present and the chain resolves to that root, the kernel flips the bit. On every subsequent NtOpenProcess against that process, the kernel strips a fixed set of access rights from the mask, no matter who is asking.

Alex Ionescu, then a Windows internals researcher and now CrowdStrike's Chief Technology Innovation Officer, enumerated the denials in 2007 [@ionescu-pp-bad-idea]:

A typical process cannot perform operations such as the following on a protected process: Inject a thread into a protected process; Access the virtual memory of a protected process; Debug an active protected process; Duplicate a handle from a protected process; Change the quota or working set of a protected process.

Five denials. One bit. One certificate root. Ionescu's same essay, titled "Why Protected Processes Are A Bad Idea," made a structural argument that aged well: putting a DRM mechanism in the kernel is a category error. The mechanism is too narrow for non-DRM use because the only certificate accepted is Microsoft's PMP signing root, and the only operations gated are the ones Hollywood cared about. Third parties cannot opt in, and Microsoft itself cannot graduate the level of trust.Ionescu's 2007 critique remains worth reading on its own merits. The argument that DRM-shaped kernel features tend to be reused for security mitigations and that this reuse changes their threat-model semantics is exactly what plays out over the next seven years [@ionescu-pp-bad-idea].

The seven-year pause is its own story. Vista shipped, Vista was followed by Windows 7, and Windows 7 was followed by Windows 8 -- and through all of it, the access-check primitive that protects audiodg.exe from administrators remained a DRM artefact. The primitive existed; the graduated trust dimension did not. Two parallel failures pushed Microsoft toward widening the encoding.

The first was Mimikatz. Benjamin Delpy's tool was first released in May 2011 and refined through 2013 [@mimikatz-wikipedia]; it made it trivial for an administrator to extract NTLM hashes and Kerberos session keys from lsass.exe. The countermeasure of restricting SeDebugPrivilege was useless; an attacker who has SYSTEM has every privilege. What Mimikatz exploited was a primitive gap: the kernel had no way to say "lsass is protected against administrators but reachable from privileged Microsoft services."

The second was Mateusz Jurczyk's CSRSS jailbreak of Windows 8 RT in 2013. Jurczyk (who writes as j00ru) catalogued more than seventy Win32k system calls that the kernel guarded with the pattern if (PsGetCurrentProcess() != gpepCsrss) return STATUS_ACCESS_DENIED; [@j00ru-1393]. That gating mechanism worked only as long as nobody could inject code into csrss.exe. On Windows 8 RT, an attacker who could inject into csrss.exe could bypass Microsoft's locked-down Surface RT shell. Ionescu later observed that "In Windows 8.1 RT, this jailbreak is 'fixed', by virtue that code can no longer be injected into Csrss.exe for the attack" [@ionescu-part2]. The fix made csrss.exe a PPL at the WinTcb rung, and the same machinery was generalised to lsass.exe and the Antimalware tier.

Note: Mimikatz proved Microsoft needed a graduated trust dimension for lsass.exe. The j00ru CSRSS jailbreak proved Microsoft needed it for csrss.exe too. The same widening of the encoding answered both.

flowchart LR subgraph Vista2006[Vista 2006 -- single bit] V1[EPROCESS protected = 0 or 1] V2[Certificate root: PMP only] V3[Access denials: hardcoded 5-tuple] end subgraph Win81[Windows 8.1 -- _PS_PROTECTION byte] W1[Type: 3 bits] W2[Audit: 1 bit] W3[Signer rung: 4 bits] W4[Certificate roots: per-EKU sub-OIDs] W5[Access denials: lattice over signer] end V1 --> W1 V2 --> W4 V3 --> W5 The DRM-to-credentials repurposing is not unique to PPL. The same pattern shows up in HVCI (originally a Hyper-V kernel-mode integrity feature, later repurposed for general code-integrity enforcement) and in Trustlets (originally an enterprise feature for Credential Guard, later generalised). Kernel mechanisms born in one threat model rarely stay confined to it.

Microsoft already had the access-check primitive. What it didn't have, in 2007, was a way to ask "how much trust does this process carry?" The fix would not arrive until Windows 8.1 in October 2013, and when it arrived, it would fit in a single byte.

3. `_PS_PROTECTION` -- The Single-Byte Encoding

The 8.1 fix is so compact it fits in a single byte. Ionescu's Part 1 of the "Evolution of Protected Processes" series, published November 22, 2013, gives the kernel structure verbatim [@ionescu-part1]:

typedef struct _PS_PROTECTION {
    union {
        UCHAR Level;
        struct {
            UCHAR Type   : 3;
            UCHAR Audit  : 1;
            UCHAR Signer : 4;
        };
    };
} PS_PROTECTION, *PPS_PROTECTION;

Three fields. One byte. The union with Level:UCHAR exists so that two _PS_PROTECTION values can be compared with a single byte load and a single byte compare. The kernel does this on every NtOpenProcess. Speed matters; this is the hot path of the security model.

The kernel structure that encodes a process's protection state in eight bits: three bits of Type (`None`, `ProtectedLight`, `Protected`), one bit of Audit (intended as a forensic side-channel hint, although the exact runtime semantics are not enumerated in the public sources cited here), and four bits of Signer rung. Stored as `EPROCESS.Protection`.

The Type field has three values. PsProtectedTypeNone = 0 marks a regular process. PsProtectedTypeProtectedLight = 1 marks a PPL -- the graduated path introduced in 8.1. PsProtectedTypeProtected = 2 marks a "heavy" Vista-style PP. Heavy PPs still exist; they retain the original DRM semantics where almost nothing from below the protection level may touch them. PPLs are the new general-purpose path where the signer rung mediates a graduated lattice.

The Audit bit is the least documented of the three fields. Ionescu Part 1 lists it as Audit : Pos 3, 1 Bit with no semantic gloss; itm4n's RunAsPPL header annotates it as // Reserved; Microsoft Learn enumerates CodeIntegrity events 3033, 3063, 3065, and 3066, but those are triggered by the AuditLevel configuration under Image File Execution Options\LSASS.exe and concern DLL-load failures, not per-process OpenProcess denials [@ionescu-part1] [@itm4n-runasppl] [@learn-runasppl]. The field's name implies a forensic side-channel, and the bit-position is reserved; the precise runtime emission shape is not enumerated in the public sources cited here.

The Signer field is the structurally interesting one. Ionescu's 2013 enumeration names eight values [@ionescu-part1]:

Signer constant	Value	Used for
`PsProtectedSignerNone`	0	Non-protected (no rung)
`PsProtectedSignerAuthenticode`	1	Generic third-party Authenticode (early PPL guests)
`PsProtectedSignerCodeGen`	2	.NET native runtime code generators
`PsProtectedSignerAntimalware`	3	EDR / AV daemons admitted via ELAM
`PsProtectedSignerLsa`	4	`lsass.exe` under `RunAsPPL`
`PsProtectedSignerWindows`	5	Microsoft Windows components below TCB
`PsProtectedSignerWinTcb`	6	`csrss.exe`, `smss.exe`, `services.exe` -- the inbox TCB
`PsProtectedSignerMax`	7	Sentinel value (enumeration upper bound)

Note: Ionescu's 2013 list is the authoritative baseline enumeration. It is not a permanent enumeration. By 2018, James Forshaw's PowerShell tooling (NtApiDotNet) was enumerating an additional App = 8 signer used for AppContainer / TruePlay scenarios [@forshaw-2018-10]. Newer builds of Windows extend the enumeration further. The article will name WinTcb (Microsoft's documented inbox-TCB rung) and Antimalware (the only non-Microsoft-admissible rung) repeatedly, because they are the load-bearing ones. The intermediate values evolve.

Adjacent to EPROCESS.Protection are two related fields, EPROCESS.SignatureLevel and EPROCESS.SectionSignatureLevel, which Ionescu introduces in Part 3 [@ionescu-part3]. These fields encode the binary integrity the kernel demands at process creation and at every subsequent section load, and they are filled in from a 16-entry Signing Level table that runs from Unchecked = 0 up to Windows TCB = 14. The Signer rung in Protection answers "what kind of trust does this process hold?" The SignatureLevel pair answers "what binaries is this process allowed to map?" They are not the same question.

Now the worked decode. Given the byte value 0x41, the encoding falls out by hand:

Low three bits (Type): 0x41 & 0x07 = 0x01 -- PsProtectedTypeProtectedLight.
Bit 3 (Audit): (0x41 >> 3) & 0x01 = 0 -- Audit off.
High four bits (Signer): (0x41 >> 4) & 0x0F = 0x04 -- PsProtectedSignerLsa.

A process with EPROCESS.Protection = 0x41 is a PPL signed at the Lsa rung. That is exactly what lsass.exe looks like on a host with RunAsPPL = 1. Ionescu's blog explicitly states: "it's easy to read 0x41 as Lsa (0x4) + PPL (0x1)" [@ionescu-part1]. The Defender service MsMpEng.exe, signed at the Antimalware rung, has Protection = 0x31. The session manager csrss.exe, signed at WinTcb, has Protection = 0x61.

flowchart TD B[byte: 8 bits] B --> F1[bits 0..2: Type] B --> F2[bit 3: Audit] B --> F3[bits 4..7: Signer] F1 --> T0[0 = None] F1 --> T1[1 = ProtectedLight PPL] F1 --> T2[2 = Protected PP] F3 --> S0[0 None] F3 --> S1[1 Authenticode] F3 --> S2[2 CodeGen] F3 --> S3[3 Antimalware] F3 --> S4[4 Lsa] F3 --> S5[5 Windows] F3 --> S6[6 WinTcb]

{` function decodeProtection(byteValue) { const type = byteValue & 0x07; const audit = (byteValue >> 3) & 0x01; const signer = (byteValue >> 4) & 0x0F; const typeNames = ['None', 'ProtectedLight', 'Protected']; const signerNames = [ 'None', 'Authenticode', 'CodeGen', 'Antimalware', 'Lsa', 'Windows', 'WinTcb', 'Max' ]; return { raw: '0x' + byteValue.toString(16).padStart(2, '0'), type: typeNames[type] || 'unknown(' + type + ')', audit: audit ? 'on' : 'off', signer: signerNames[signer] || 'unknown(' + signer + ')' }; }

// Worked examples from real Windows processes console.log('MsMpEng.exe (Defender):', decodeProtection(0x31)); console.log('lsass.exe under RunAsPPL:', decodeProtection(0x41)); console.log('csrss.exe (WinTcb):', decodeProtection(0x61)); `}

Note: One byte, three fields, eight signer rungs. The kernel reads it on every OpenProcess, before any token check, before any ACL evaluation. The encoding is the entire vocabulary the kernel has for asking how trusted a process is.

The encoding tells the kernel what kind of trust a process holds. It says nothing about who can touch whom across rungs. That rule -- the lattice -- is the structure imposed on top of the bytes. The next section is the lattice.

4. The Signer Lattice -- Who Can Open Whom

itm4n's 2021 walkthrough states the three rules verbatim, and they have the rare quality of being short enough to memorise [@itm4n-scrt]:

A PP can open a PP or a PPL with full access if its signer type is greater or equal. A PPL can open a PPL with full access if its signer type is greater or equal. A PPL cannot open a PP with full access, regardless of its signer type.

Three rules. They settle every cross-process access question PPL gates. Let us name them and then read off their consequences.

Rule 1. A PP at signer $S_c$ may open with full access a PP or PPL at signer $S_t$ if and only if $S_c \ge S_t$.

Rule 2. A PPL at signer $S_c$ may open with full access a PPL at signer $S_t$ if and only if $S_c \ge S_t$.

Rule 3. A PPL cannot open a PP with full access, regardless of signer.

The qualifier "with full access" is load-bearing. PPL's lattice gates the full mask -- PROCESS_VM_READ, PROCESS_VM_WRITE, PROCESS_CREATE_THREAD, PROCESS_DUP_HANDLE, PROCESS_ALL_ACCESS. A separate limited mask (SYNCHRONIZE, PROCESS_QUERY_LIMITED_INFORMATION, PROCESS_SET_LIMITED_INFORMATION, PROCESS_SUSPEND_RESUME, and -- for callers below the Authenticode/CodeGen/Windows tier -- PROCESS_TERMINATE) is allowed when the security descriptor permits. The tier matters. Ionescu's verbatim RtlProtectedAccess[] table widens the deny mask from 0xFC7FE to 0xFC7FF at the Antimalware, Lsa, and WinTcb rungs -- one extra bit, bit 0, which is PROCESS_TERMINATE [@ionescu-part2]. So an administrator can still call OpenProcess(PROCESS_QUERY_LIMITED_INFORMATION, ...) against a protected lsass.exe to enumerate threads, but cannot terminate a PPL/Antimalware, PPL/Lsa, or PPL/WinTcb daemon via a direct kill. The lattice does not lock the process; it locks the interesting access, and for the top-tier rungs it also locks the kill.

Caller signer \ Target signer	None	Authenticode (1)	Antimalware (3)	Lsa (4)	Windows (5)	WinTcb (6)
None (admin, integrity SYSTEM)	full	denied	denied	denied	denied	denied
PPL/Authenticode (1)	full	full	denied	denied	denied	denied
PPL/Antimalware (3)	full	full	full	denied	denied	denied
PPL/Lsa (4)	full	full	full	full	denied	denied
PPL/Windows (5)	full	full	full	full	full	denied
PPL/WinTcb (6)	full	full	full	full	full	full

Where "denied" means the full mask is rejected; the limited mask continues to apply per the target's security descriptor.

flowchart BT None[None / unprotected] Auth[Authenticode] CG[CodeGen] AM[Antimalware] Lsa[Lsa] Win[Windows] Tcb[WinTcb] None --> Auth Auth --> CG CG --> AM AM --> Lsa Lsa --> Win Win --> Tcb

The Enhanced Key Usage side of the design holds the lattice together. Microsoft's EKU OID arc 1.3.6.1.4.1.311.10.3.* defines sub-OIDs per signer rung [@iana-pen311] [@oid-base-eku-arc], and at process creation the kernel parses the main image's Authenticode signature and walks its EKU extensions to determine which rung the binary is entitled to claim. If the certificate chain resolves cleanly to a Microsoft-issued root and carries the rung's sub-OID, the kernel records the rung. Otherwise the process either starts unprotected or refuses to start at all.

An X.509 v3 certificate extension that asserts what specific purposes a certificate is allowed to certify. Microsoft uses sub-OIDs under `1.3.6.1.4.1.311.10.3.*` to encode protected-process signer rungs as EKU values [@iana-pen311] [@oid-base-eku-arc]. The kernel checks the EKU at process creation; the certificate chain anchors which Microsoft-issued sub-CA may issue at each rung.The IANA Private Enterprise Number `311` is registered to Microsoft under the PEN prefix `1.3.6.1.4.1.` [@iana-pen311], so `1.3.6.1.4.1.311.*` is the catch-all namespace for Microsoft-specific X.509 extensions; the `10.3.*` arc within it is the Microsoft Enhanced Key Usage (purpose) sub-tree [@oid-base-eku-arc], and `10.3.` slots map to specific signer purposes including protected-process rungs.

The most important property of this design is the resolution point. The kernel parses the EKU exactly once, at NtCreateUserProcess. It stores the resulting rung in EPROCESS.Protection. On every subsequent OpenProcess against that process, the kernel consults the byte, not the certificate. This makes the access check fast (one byte load, one byte compare) and decouples policy at runtime from policy at signing time. It also creates the structural seam that every public bypass since 2018 has exploited, because the kernel's confidence in the byte is exactly the confidence it had in the certificate at process-create time, projected forward indefinitely.

Ionescu's Part 2 names the implementation directly. The lattice is not code; it is a data table named RtlProtectedAccess[] baked into ntoskrnl.exe [@ionescu-part2]. Each row of that table corresponds to a (signer, target-type) pair and encodes which access bits are allowed in the full mask. The relevant runtime routines are PspProcessOpen and PspThreadOpen (the object-manager open callbacks), PspCheckForInvalidAccessByProtection (which performs the check), RtlTestProtectedAccess (which applies the lattice row), and RtlValidProtectionLevel (which sanity-checks the encoded byte for consistency).

Note: The decision of who can touch whom is encoded in a table inside ntoskrnl.exe. Changing the lattice means changing a table; widening or narrowing it does not require new code. This is why Microsoft can add App = 8 to the enumeration over time without touching the access-check routine.

Note one symmetry that becomes important later. "Greater or equal" means that within a rung, every PPL can read every other PPL. Two co-resident PPL/Antimalware daemons -- Microsoft Defender's MsMpEng.exe and a third-party EDR's agent -- can call PROCESS_VM_READ on each other. Within-rung peers leak to each other by design. The lattice prevents escalation, not peer access.

The lattice settles the rule. The next question is admission: who decides which binaries are allowed to claim the Antimalware rung, and how does Microsoft admit third-party code into it at all? The answer is a driver.

5. The Antimalware Rung -- ELAM and Third-Party Code at PPL

PPL is interesting only if it admits non-Microsoft code at some rung. The Vista PP design admitted nobody; it required a Microsoft PMP root certificate, full stop. PPL inherited that constraint at every rung except one. The Antimalware rung -- signer value 3 -- is the only rung where third-party vendors can ship their own user-mode binaries as protected processes. The admission mechanism is the Early Launch Anti-Malware driver.

A specially signed Microsoft-certified kernel driver shipped by an anti-malware vendor that loads before any other boot-start driver. The ELAM driver participates in trusted-boot measurement, vouches for follow-on drivers, and -- critical to PPL -- carries an embedded resource section enumerating the vendor's user-mode signing certificate hashes. The kernel uses that resource section to admit the vendor's user-mode daemon binaries to `PPL/Antimalware` at service start.

Microsoft Learn's "Protecting Anti-Malware Services" page describes the boot-time admission flow in two sentences [@learn-am-services]:

The driver must have an embedded resource section containing the information of the certificates used to sign the user mode service binaries. During the boot process, this resource section will be extracted from the ELAM driver to validate the certificate information and register the anti-malware service.

Two consequences. First, the third-party signer set is bounded by a kernel-readable resource section, not by an open EKU. Microsoft, not the vendor, controls which user-mode binaries are admissible. Second, the certificate hashes are baked into the driver at signing time and re-validated at every service start. A vendor cannot widen the admissible set after the fact; an attacker cannot drop in their own user-mode binary unless its hash is already listed.

The gate that decides which vendors get ELAM drivers in the first place is the Microsoft Virus Initiative. Microsoft Learn's MVI criteria page enumerates the requirement explicitly [@learn-mvi]:

Your security solution must be certified within the last 12 months by at least one of the organizations listed below: AV-Comparatives, AVLab Cybersecurity Foundation, AV-Test, MRG Effitas, SE Labs, SKD Labs, VB 100, West Coast Labs.

The same page requires "use of Trusted Signing," Microsoft's cloud-managed code signing service. The implications are operational. To ship code at PPL/Antimalware, a vendor must (a) hold MVI membership, (b) maintain independent-lab certification, (c) author an ELAM driver, (d) get the driver through Microsoft WHQL and have it Microsoft co-signed, and (e) embed the user-mode certificate hashes in the driver's resource section.

A Microsoft program for anti-malware vendors that gates access to ELAM driver signing and to specific Defender APIs. Membership requires independent-lab certification (renewed annually) and Trusted Signing usage; in practical terms, MVI membership is the entry ticket to deploying user-mode binaries at `PPL/Antimalware`. The implication of MVI is that an indie security tool, however technically sound, cannot deploy as `PPL/Antimalware`. The gate is not technical but commercial: independent-lab certification fees, annual renewals, and the engineering investment of building a production-grade ELAM driver. The signer rung is *signed*; the signing program is *gated*. sequenceDiagram participant BM as Boot manager participant K as Windows kernel participant ELAM as Vendor ELAM driver (.sys) participant SCM as Service Control Manager participant CI as ci.dll (CodeIntegrity) participant Svc as Vendor service (e.g. EDR daemon) BM->>K: load boot drivers K->>ELAM: load ELAM driver early K->>ELAM: read embedded ELAM resource section K->>K: cache vendor user-mode cert hashes Note over K,SCM: Boot continues, OS initialises SCM->>Svc: start vendor service Svc->>CI: validate service binary signature CI->>K: lookup vendor cert against cached hashes K-->>CI: match -- admit at PPL/Antimalware CI-->>Svc: launch as PPL/Antimalware (Protection = 0x31)

By 2024, every major commercial EDR ships through this path. Microsoft Defender's MsMpEng.exe uses the inbox WdBoot.sys ELAM driverWdBoot.sys ("Windows Defender Boot Driver") is Microsoft's inbox first-party ELAM driver; it ships in every Windows install and is loaded before any third-party ELAM driver. The canonical reference implementation of the ELAM resource-section pattern is Microsoft's Windows-driver-samples/security/elam repository [@ms-elam-sample], which also documents the Early Launch EKU 1.3.6.1.4.1.311.61.4.1 verbatim.. Third-party members of Microsoft's Virus Initiative -- the cohort gated by the MVI criteria quoted above [@learn-mvi] -- ship their own vendor ELAM drivers and run their main user-mode daemons at PPL/Antimalware. Microsoft Learn's "Early Launch Antimalware" page is the canonical confirmation [@learn-elam]:

Because an ELAM service runs as a PPL (Protected Process Light), you need to debug using a kernel debugger.

One Microsoft-signed sentence and a billion endpoints. EDR vendors get protection against administrator-level tampering for free, on top of the kernel telemetry their drivers already collect. Microsoft gets a viable third-party security market without widening the EKU gates beyond a controllable set of vendors.

ELAM admits the daemon. The next operational question is what Microsoft does for lsass.exe itself -- the canonical credential store, the original Mimikatz target. The mechanism is called RunAsPPL.

6. RunAsPPL -- Hardening LSASS

The registry value that produced the Mimikatz failure in Section 1 is a single DWORD. itm4n's walkthrough names it verbatim [@itm4n-runasppl]:

Open the key HKLM\SYSTEM\CurrentControlSet\Control\Lsa; add the DWORD value RunAsPPL and set it to 1; reboot.

After reboot, lsass.exe launches at PPL/Lsa, signer rung 4, protection byte 0x41. Mimikatz running with full SYSTEM-integrity and SeDebugPrivilege then receives 0x00000005 on OpenProcess(PROCESS_VM_READ, lsass.exe). The registry knob is one DWORD; the consequences are large.

The Windows user-mode process that holds NTLM password hashes, Kerberos Ticket Granting Tickets, MSV1_0 credential caches, DPAPI master keys, and (on legacy builds before Microsoft's 2014 KB2871997 update [@ms-kb2871997]) WDigest plaintext passwords. The canonical target of credential-theft tooling since 2011.

The threat being mitigated is simple. Mimikatz reads LSASS memory via OpenProcess(PROCESS_VM_READ, lsass.exe), walks the internal key-store structures, and extracts NTLM hashes, Kerberos session keys, and (on older configurations) cached plaintext. Restricting SeDebugPrivilege does not work, because an attacker with SYSTEM has every privilege. Restricting the security descriptor on lsass.exe does not work either, because legitimate services need to interact with it. PPL is the right primitive: it gates the full mask irrespective of token state, and the kernel admits only Microsoft-signed code into the Lsa rung.

RunAsPPL = 1 is the stronger form of the setting on Secure Boot-capable machines. On the next boot, the kernel automatically mirrors the policy into a Secure Boot-anchored UEFI variable; once set, the protection survives registry rollback. An attacker who removes the registry key finds that LSASS still launches as PPL on the next boot. The only path to remove the protection is to disable Secure Boot at the firmware level, which requires physical access and which trips other defences. Microsoft Learn's documentation describes it verbatim [@learn-runasppl]:

You can achieve further protection when you use Unified Extensible Firmware Interface (UEFI) lock and Secure Boot. When these settings are enabled, disabling the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa registry key has no effect.

This is RunAsPPL = 1. For environments that need admin-removable protection without the UEFI lock, RunAsPPL = 2 (available on Win11 22H2 and later) omits the UEFI variable. The policy lives in the registry only and is removable by any administrator (or by malware running as administrator) who simply deletes the registry value before reboot.

`RunAsPPL` value	Behaviour	Removable by?	Persistence
`0` (or absent)	LSASS runs unprotected	n/a	none
`1`	LSASS runs as PPL/Lsa; policy mirrored to UEFI variable on Secure Boot machines	Physical access + Secure Boot disable	Firmware-anchored
`2`	LSASS runs as PPL/Lsa; registry only (Win11 22H2+ only)	Any admin who deletes the key	Registry only

Note: The RunAsPPL = 1 setting is the practical answer to "what stops an attacker who is willing to reboot?" Once the UEFI variable is set, neither registry rollback nor PE-based offline attacks on the registry hive can disable LSA protection on the next boot.

The deployment cost of RunAsPPL is compatibility with third-party authentication modules. LSASS hosts a set of plug-ins: smart-card middleware, third-party Cryptographic Service Providers (CSPs), password-filter DLLs, alternative authentication packages. Under RunAsPPL, the kernel demands that every DLL loaded into LSASS be Microsoft-signed at the LSA level (signer rung 4). Vendor DLLs that lack the right EKU are rejected at section creation. The rejections surface as CodeIntegrity events in the system event log. Microsoft Learn enumerates the two relevant event IDs [@learn-runasppl]:

Event 3065 occurs when a code integrity check determines that a process, usually LSASS.exe, attempts to load a driver that doesn't meet the security requirements for shared sections.

Event 3066 occurs when a code integrity check determines that a process, usually LSASS.exe, attempts to load a driver that doesn't meet the Microsoft signing level requirements.

This is why Microsoft recommends running the setting in audit mode before enforcement. Audit mode is enabled by setting a separate AuditLevel DWORD to 8, but -- critically -- under a different registry key from the one that hosts RunAsPPL. Microsoft Learn places AuditLevel under the Image File Execution Options hive for LSASS.exe and names the path verbatim [@learn-runasppl]:

Open the Registry Editor, or enter RegEdit.exe in the Run dialog, and then go to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\LSASS.exe registry key. Open the AuditLevel value. Set its data type to dword and its data value to 00000008.

Note: RunAsPPL sits under HKLM\SYSTEM\CurrentControlSet\Control\Lsa. AuditLevel = 8 sits under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\LSASS.exe. A defender who edits "the same key" silently sets the wrong value and audit mode never engages. The deployment looks correct from the registry; the log surface is empty; the rollout breaks production on enforcement day. Two values. Two hives. Read this twice.

In audit mode, the kernel emits the same 3065 / 3066 events for would-be load rejections but allows the loads to proceed. Two months of audit-mode telemetry typically surfaces every smart-card middleware DLL, every password-filter, every third-party CSP on a corporate fleet. Once the audit log is clean (every vendor's modules have been re-signed at the LSA level or replaced), enforcement mode can be turned on without breaking production logins.

Note: Skipping audit mode is the most common cause of LSA protection rollouts being rolled back after a wave of authentication failures. See §11 Item 1 for the full audit-then-enforce-then-UEFI-lock recipe.

The deployment cadence has been deliberately glacial. RunAsPPL shipped in Windows 8.1 in October 2013 -- opt-in. It remained opt-in for nine years. Microsoft Learn records the inflection [@learn-runasppl]:

Audit mode for added LSA protection is enabled by default on devices running Windows 11 version 22H2 and later.

Audit mode default-on. Not enforcement. The Windows 11 24H2 release expanded the audit-mode rollout further. Eleven years from opt-in to effective default. The pace reflects the compatibility risk: every domain with a single non-Microsoft-signed LSASS plug-in would have surfaced as a support call.

The registry knob is simple. The kernel check that enforces it is not. The next section walks the access-check pipeline in detail, because the structural reason SeDebugPrivilege cannot help an attacker is the order in which the kernel asks its questions.

7. The Kernel Access Check -- What Happens Inside `NtOpenProcess`

Recall the trace from Section 1. The denial happens before SeAccessCheck runs. The reason SeDebugPrivilege does not help is not that the kernel decided to override the privilege; it is that the kernel never asked about the privilege. The order matters. Let us walk it.

The Win32 caller invokes OpenProcess, which thunks through kernel32.dll to the syscall NtOpenProcess. NtOpenProcess does its handle-lookup and dispatches to the process-type object-manager open callback, PspProcessOpen. Ionescu's Part 2 names the path verbatim [@ionescu-part2]:

Access to protected processes (and their threads) is gated by the PspProcessOpen and PspThreadOpen object manager callback routines, which perform two checks. The first, done by calling PspCheckForInvalidAccessByProtection (which in turn calls RtlTestProtectedAccess and RtlValidProtectionLevel) ...

PspCheckForInvalidAccessByProtection does two things. First, it splits the caller's requested access mask into two subsets:

The limited mask -- a fixed set of bits (SYNCHRONIZE, PROCESS_QUERY_LIMITED_INFORMATION, and a small handful of others) that the lattice never forbids. The limited mask is subject only to the standard SeAccessCheck against the target's DACL.
The full mask -- everything else, including PROCESS_VM_READ, PROCESS_VM_WRITE, PROCESS_CREATE_THREAD, PROCESS_DUP_HANDLE, and PROCESS_ALL_ACCESS. The full mask is subject to the lattice rule.

The subset of `PROCESS_*` access rights that the PPL lattice always allows the standard `SeAccessCheck` to evaluate. Includes `SYNCHRONIZE`, `PROCESS_QUERY_LIMITED_INFORMATION`, `PROCESS_SET_LIMITED_INFORMATION`, and `PROCESS_SUSPEND_RESUME`. `PROCESS_TERMINATE` is included for callers below the Antimalware tier (deny mask `0xFC7FE`), but the kernel widens the deny mask to `0xFC7FF` at the `Antimalware`, `Lsa`, and `WinTcb` rungs -- bit 0, `PROCESS_TERMINATE` -- making those three rungs unkillable except from peers or higher.

Second, it indexes into RtlProtectedAccess[] using the caller's signer rung and the target's type, retrieves the row of permissible access bits, and ANDs the row with the full mask. If the result is non-empty, the access proceeds; if the result is zero, the kernel strips the full-mask bits from the request and returns either the limited subset (if the caller asked for any limited bits) or STATUS_ACCESS_DENIED. RtlValidProtectionLevel runs alongside as a sanity check on the encoded byte to catch malformed EPROCESS.Protection values that would otherwise let the lattice walk off the end of the table.

sequenceDiagram participant App as Caller (any token) participant Nt as NtOpenProcess participant PsPO as PspProcessOpen participant Chk as PspCheckForInvalidAccessByProtection participant Rtl as RtlTestProtectedAccess + RtlValidProtectionLevel participant Tab as RtlProtectedAccess[] table participant SAC as SeAccessCheck App->>Nt: NtOpenProcess(DesiredAccess) Nt->>PsPO: dispatch PsPO->>Chk: protection check Chk->>Rtl: lookup caller / target rungs Rtl->>Tab: index row, retrieve allowed bits Tab-->>Rtl: row of allowed access bits Rtl-->>Chk: full mask allowed or stripped Chk-->>PsPO: residual mask (full or limited) PsPO->>SAC: residual mask vs DACL + token SAC-->>Nt: final mask Nt-->>App: handle or STATUS_ACCESS_DENIED

Key idea: The protection check runs before SeAccessCheck. Privileges are evaluated by SeAccessCheck. The reason SeDebugPrivilege does not help is structural -- it is not consulted at the moment of denial.

Four worked traces make this concrete.

Case (a): admin -> lsass with PROCESS_ALL_ACCESS. The caller has no EPROCESS.Protection.Type (it is None). The target is PPL/Lsa. The lattice forbids the full mask. The kernel strips every bit of PROCESS_ALL_ACCESS except the limited subset. The caller wanted to write memory; the limited subset cannot write memory; the operation effectively fails. This is the Mimikatz scenario.

Case (b): admin -> lsass with PROCESS_QUERY_LIMITED_INFORMATION. Same caller, same target, but the requested mask sits entirely in the limited subset. The lattice does not gate the limited mask. SeAccessCheck evaluates the DACL on lsass.exe, finds that administrators are permitted to query basic process information, and the call succeeds. This is why Process Explorer can still enumerate lsass.exe and show its threads even when LSA protection is enabled.

Case (c): MsMpEng.exe (PPL/Antimalware, rung 3) -> lsass.exe (PPL/Lsa, rung 4) with PROCESS_VM_READ. The lattice rule: caller rung 3 < target rung 4, so the full mask is denied. Defender cannot read LSASS memory. Defender does not need to; the cross-rung isolation prevents one Microsoft service from reading another Microsoft service's secrets even within the same trusted system.

Case (d): hypothetical PPL/WinTcb (rung 6) -> lsass.exe (PPL/Lsa, rung 4) with PROCESS_VM_READ. The lattice rule: caller rung 6 >= target rung 4, so the full mask is allowed. A process signed at the WinTcb rung can read LSASS memory by design. This is how Service Control Manager and Windows Error Reporting can still interact with protected lsass.exe.

Caller	Target	Mask	Lattice rule	Outcome
Admin, no Protection	PPL/Lsa	PROCESS_ALL_ACCESS	Caller has no rung	Full mask stripped (denied)
Admin, no Protection	PPL/Lsa	PROCESS_QUERY_LIMITED_INFORMATION	Limited mask	Allowed (DACL permitting)
PPL/Antimalware (3)	PPL/Lsa (4)	PROCESS_VM_READ	3 < 4	Denied
PPL/WinTcb (6)	PPL/Lsa (4)	PROCESS_VM_READ	6 >= 4	Allowed

The Audit bit revisits the table from a different angle. The bit is annotated Reserved in itm4n's public structure definition and named without semantic gloss in Ionescu Part 1; the precise runtime emission shape on an OpenProcess denial is not enumerated in any of Ionescu Part 1, Forshaw 2018, itm4n's RunAsPPL writeup, or Microsoft Learn's RunAsPPL page (whose CodeIntegrity events 3033/3063/3065/3066 are scoped to AuditLevel under IFEO\LSASS.exe and to DLL-load failures, not per-process Audit-bit denials) [@ionescu-part1] [@itm4n-runasppl] [@learn-runasppl]. The field name and bit position imply a forensic side-channel; the exact event shape is not in the public record.Two adjacent kernel mechanisms exist in the same neighbourhood but mediate different threat models. PROCESS_TRUST_LABEL_ACE (a Trust SID ACL entry, introduced in Windows 8.1 alongside PPL) is an ACL-side companion that runs inside SeAccessCheck -- it adds a token-style trust label that interacts with the security descriptor in the standard way. Code Integrity Guard (ProcessSignaturePolicy) is a per-process signed-image enforcer settable at CreateProcess time via the PROC_THREAD_ATTRIBUTE_MITIGATION_POLICY attribute. Neither is part of PPL; both interact with the same problem space.

The kernel verifies who is asking, what they are asking for, and at what rung the target sits. What the kernel cannot verify is the behaviour of code that arrives through a signed channel and then executes against attacker-controlled data. That structural seam is the entire premise of the bypass arms race, and it is the next section.

8. The Bypass Arms Race -- Forshaw, itm4n, Landau

If the kernel only verifies the channel by which code enters a PPL, every bypass should attack the seam between channel and behaviour. Test that prediction against the public record. Since 2018, four named bypass acts have hit major Microsoft research blogs. All four sit in the same structural class.

Key idea: The kernel verifies the channel. It does not verify the behaviour. Every public PPL bypass since 2018 attacks the seam between what the channel proves (a signature, an EKU, a section identity) and what the code does once mapped.

Act I (2018) -- Forshaw and JScript-into-PPL

James Forshaw, then at Google Project Zero, published "Injecting Code into Windows Protected Processes Using COM" in October 2018 [@forshaw-2018-10]. The mechanism: a PPL can be made to instantiate a COM object whose CLSID resolves to scrobj.dll, the Microsoft-signed Windows Script Component scripting host. Once loaded into the PPL, the script object accepts attacker-supplied source code and executes it inside the protected process. The DLL is signed. The kernel admits it. The kernel cannot reason about the JScript source it then runs.

Microsoft's fix in Windows 10 1803 (April 2018, deployed broadly through that year) was a hardcoded deny-list in CI.DLL. Forshaw's own writeup gives the source verbatim [@forshaw-2018-10]:

UNICODE_STRING g_BlockedDllsForPPL[] = {
    DECLARE_USTR("scrobj.dll"),
    DECLARE_USTR("scrrun.dll"),
    DECLARE_USTR("jscript.dll"),
    DECLARE_USTR("jscript9.dll"),
    DECLARE_USTR("vbscript.dll")
};

NTSTATUS CipMitigatePPLBypassThroughInterpreters(
    PEPROCESS Process, LPBYTE Image, SIZE_T ImageSize)
{
    if (!PsIsProtectedProcess(Process)) return STATUS_SUCCESS;
    // walk g_BlockedDllsForPPL; if any match, return STATUS_DYNAMIC_CODE_BLOCKED
    ...
}

Five DLLs, hardcoded. Microsoft Learn corroborates the policy on the user-facing side [@learn-am-services]:

The following scripting DLLs are forbidden by CodeIntegrity inside a protected process: scrobj.dll, scrrun.dll, jscript.dll, jscript9.dll, and vbscript.dll.

Channel: a Microsoft-signed DLL. Behaviour: arbitrary attacker script. The fix narrows the channel by name-listing the five DLLs known to admit attacker behaviour. The class survives.The mechanism was previewed at Recon Montreal 2018 in the joint Forshaw-Ionescu talk "Unknown Known DLLs and other Code Integrity Trust Violations" (June 15-17, 2018) [@recon-mtl-2018]. Forshaw's August 2017 "Bypassing VirtualBox Process Hardening" essay [@forshaw-2017-vbox] is the structural precursor -- it makes the same channel-vs-behaviour argument against a different kernel-supported process-hardening regime.

Act II (2018-2021) -- DefineDosDevice and PPLdump

In his August 2018 post on object-directory exploits [@forshaw-2018-08], Forshaw added a single throwaway sentence that the security community would spend three years productising. itm4n quotes it verbatim in his 2021 SCRT walkthrough [@itm4n-scrt]:

Abusing the DefineDosDevice API actually has a second use, it's an Administrator to Protected Process Light (PPL) bypass.

The mechanism, fully worked out by itm4n in April 2021, is structural and uses that same primitive. As an administrator, call DefineDosDevice to create a symbolic link in \KnownDlls\ (the object-directory subkey that the loader uses for fast known-DLL lookups). The call is dispatched via RPC to csrss.exe, which runs at PPL/WinTcb (rung 6) and so has the lattice authority to write into protected directories. The administrator gets a \KnownDlls\ entry pointing at an attacker-controlled section. Now start a PPL. The PPL's loader resolves DLL names through \KnownDlls\ and finds the administrator's entry. The PPL maps the attacker's section without re-validating its on-disk signature, because \KnownDlls\ is the kernel's vouched-for fast path.

itm4n's PPLdump tool, published April 2021, automated the attack. The README test matrix lists every Windows version it ran against [@ppldump-repo]. For fifteen months, an administrator could dump any PPL's memory, including lsass.exe, despite RunAsPPL.

Microsoft's fix arrived in build 19044.1826 (the July 2022 update to Windows 10 21H2). itm4n's "End of PPLdump" writeup describes the patch and the BinDiff diff verbatim [@itm4n-end-of-ppldump]:

The conclusion is that PPLs now appear to be behaving just like PPs and therefore no longer rely on Known DLLs.

The fix patched LdrpInitializeProcess in NTDLL to skip \KnownDlls\ for PPL processes, behind a Velocity feature flag (Feature_Servicing_2206c_38427506__private_IsEnabled). PPLdump's repository README now opens with [@ppldump-repo]:

2022-07-24 - As of Windows 10 21H2 10.0.19044.1826 (July 2022 update), the exploit implemented in PPLdump no longer works. A patch in NTDLL now prevents PPLs from loading Known DLLs.

itm4n's structural finding -- that *PPLs honoured \KnownDlls\ while PPs did not* -- is the most interesting failure in the eight-year run, because the asymmetry sat in plain sight from 2013 to 2022 and nobody had asked "why are PPs and PPLs loading sections differently?" The fix closes one asymmetry. The structural class survives.PPLdump's substitution chain uses NTFS transactions and Forrest Orr's "phantom DLL hollowing" technique to materialise the attacker-controlled section on disk in a way the kernel section creator will accept [@forrest-orr-hollow]. Orr's writeup is the original publication of the hollowing primitive; PPLdump composes it with the \KnownDlls\ redirection trick.

Act III (2022-2024) -- Landau's PPLFault CI TOCTOU

Gabriel Landau, then at Elastic, presented "PPLdump Is Dead. Long Live PPLdump!" at Black Hat Asia 2023 [@bh-asia-2023-pdf]. The mechanism is a Time-Of-Check / Time-Of-Use bug at the section-creation layer.

A class of bug in which a security property is verified at one point in time but the underlying object is mutable between the check and the use. The protected resource passes its check, then changes between check and access, and the operation proceeds against the changed state without re-verification.

The TOCTOU here is subtle. When a PPL calls NtCreateSection on a Microsoft-signed DLL, the kernel's memory manager calls MiValidateSectionCreate, which calls into ci.dll to verify the file's Authenticode signature. The check succeeds. The section is created. But the memory manager does not page in the file contents at section-create time; it pages them in lazily, on demand, when threads first touch the mapped pages. If an attacker can keep the section's backing file unsubstituted during the signature check and substituted during the lazy page-in, the kernel will execute attacker bytes through a section whose signature it already verified.

Landau's exploit uses Windows' CloudFilter API. An attacker holds an exclusive oplock on a Microsoft-signed DLL during the section-create signature check. After the check passes, the attacker's CloudFilter FetchDataCallback provides different bytes (the payload) when the kernel pages in the section. The PPL maps and executes the payload. Landau's Elastic post documents the chain verbatim [@elastic-pplfault]:

The internal memory manager function MiValidateSectionCreate relies on the Code Integrity module ci.dll to handle the requisite cryptography and PKI policy.

Microsoft's fix shipped in Windows Insider Canary build 25941 on September 1, 2023 [@elastic-pplfault]:

On September 1, 2023, Microsoft released a new build of Windows Insider Canary, version 25941 ... Build 25941 includes improvements to the Code Integrity (CI) subsystem that mitigate a long-standing issue that enables attackers to load unsigned code into Protected Process Light (PPL) processes.

The fix narrows the immediate channel by extending page-hash validation to PPL-loaded images that reside on remote (SMB redirector) paths -- the precise surface that PPLFault required to drive its CloudFilter FetchDataCallback substitution [@elastic-pplfault]. Locally-cached PPL DLL loads continue to rely on the section-create signature check, so the structural seam survives. The GA patch shipped on February 13, 2024 [@pplfault-repo]:

2024-02 UPDATE: Microsoft patched PPLFault on 2024-02-13.

Channel: a signed Microsoft DLL whose hash matched at section create. Behaviour: attacker payload mapped via the lazy page-in. The fix narrows the channel by widening the verification surface from "the file at section-create time" to "every page at fault time." The class survives.

Act IV (2022-2024) -- BYOVDLL and itm4n's KeyIso chain

Bring Your Own Vulnerable DLL. Coined by Gabriel Landau on Twitter in October 2022 (itm4n screenshots the original tweet [@itm4n-ghost-part1]; tweet status 1580067594568364032). Productised by itm4n in August 2024 in "Ghost in the PPL Part 1."

A bypass class against any signature-gated security mechanism in which the attacker loads a *legitimately signed but historically vulnerable* binary and exploits the known vulnerability inside it. The signature check passes; the vulnerability does the work. The structural property that makes the class hard to fix is that the kernel cannot deny-list legitimately signed older Microsoft DLLs without breaking the deployments that still depend on them.

itm4n's specific chain targets the CNG Key Isolation service ("KeyIso"), which runs in lsass.exe and so inherits its PPL/Lsa protection. The chain is precise [@itm4n-ghost-part1]:

As administrator, stop the KeyIso service.
Set HKLM\SYSTEM\CurrentControlSet\Services\KeyIso\Parameters\ServiceDll to point at an older keyiso.dll extracted from Microsoft update KB5023778. This DLL is Microsoft-signed; the kernel admits it.
Restart the KeyIso service. The older keyiso.dll loads into LSASS at PPL/Lsa.
Trigger CVE-2023-36906, an out-of-bounds read information disclosure in the older keyiso.dll, to leak an address.
Trigger CVE-2023-28229, one of six use-after-frees in the same DLL, to obtain control of a CALL target via the RAX register.
Execute attacker code at PPL/Lsa.

The CVEs are real and tracked. k0shl's writeup is the primary root-cause analysis [@k0shl-keyiso]:

Microsoft patched vulnerabilities I reported in CNG Key Isolation service, assigned CVE-2023-28229 and CVE-2023-36906, the CVE-2023-28229 included 6 use after free vulenrabilities with similar root cause and the CVE-2023-36906 is a out of bound read information disclosure.

NVD records both [@nvd-2023-28229] [@nvd-2023-36906]. Y3A's GitHub repository [@y3a-cve-poc] provides a public PoC for CVE-2023-28229 that itm4n's chain composes.

Channel: an actually-Microsoft-signed DLL. Behaviour: the memory-safety vulnerability inside it. There is no general fix announced. Microsoft fixed the specific CVEs by shipping a newer keyiso.dll, but the older DLL remains in circulation (it ships inside every patched cumulative update bundle), and a kernel that has to admit every legitimately signed older Microsoft DLL has no general defense against the next CVE-of-the-month.

Note: BYOVDLL has no general patch. Microsoft fixes each underlying CVE on the standard cumulative-update cadence. The class persists for as long as the kernel admits older signed Microsoft DLLs into PPLs, which is for as long as legitimately deployed software depends on the older DLLs.

timeline title PPL Bypass Arms Race (2018-2024) 2018-10 : Forshaw JScript-into-PPL : Fix 1803 Apr 2018 : g_BlockedDllsForPPL deny-list 2021-04 : itm4n PPLdump (KnownDlls) : Fix Jul 2022 build 19044.1826 : LdrpInitializeProcess patch 2022-09 : Landau PPLFault (TOCTOU) : Fix Feb 2024 13 GA : CI page-hash for PPLs 2024-08 : itm4n BYOVDLL KeyIso chain : No general fix : CVEs patched piecewise

Act	Year	Channel verified	Behaviour exploited	Microsoft fix	Fix date
I	2018	Microsoft-signed `scrobj.dll`	JScript source executed by COM object	`g_BlockedDllsForPPL` deny-list of 5 DLLs	Apr 2018 (1803)
II	2021	`\KnownDlls\` symlink (CSRSS-blessed)	Attacker section mapped without re-validation	NTDLL `LdrpInitializeProcess` patch	Jul 2022 (19044.1826)
III	2023	Signed DLL passed `MiValidateSectionCreate`	CloudFilter substitutes bytes on lazy page-in	`/INTEGRITYCHECK` page hashes for PPLs	Feb 2024 (GA)
IV	2024	Legitimately-signed older `keyiso.dll`	Use-after-free + OOB read (CVE-2023-28229, CVE-2023-36906)	None (CVE-by-CVE)	open

flowchart TD A[Admin stops KeyIso service] B[Repoint ServiceDll to older keyiso.dll
from KB5023778] C[Restart KeyIso service] D[Older keyiso.dll loads
into lsass.exe PPL/Lsa] E[Trigger CVE-2023-36906
OOB read for info leak] F[Trigger CVE-2023-28229
UAF for RAX control] G[Code execution at PPL/Lsa] A --> B --> C --> D --> E --> F --> G itm4n explicitly attributes the BYOVDLL framing to Landau's October 2022 tweet, even though itm4n's KeyIso chain is the first public productisation. The attribution chain matters because it documents how a one-line research observation (Twitter status 1580067594568364032, screenshot preserved in [@itm4n-ghost-part1]) became a working exploit two years later. The pattern repeats in this domain: Forshaw's one-sentence DefineDosDevice comment to PPLdump (3 years); Landau's BYOVDLL tweet to itm4n's KeyIso chain (2 years). The structural class outlives its discoverer.

Four acts, one class. Every public bypass since 2018 has lived in the same narrow shape: code that becomes part of a PPL through a signed channel and executes attacker-influenced data once mapped. Each generation of fix narrows what the channel admits -- name-list five DLLs; ignore \KnownDlls\; page-hash every section; CVE-patch every vulnerable older DLL. The class survives because the kernel cannot reason about behaviour. By Rice's theorem it cannot reason about behaviour in general; in practice, it has nowhere even to start.

If lsass.exe code execution is reachable through BYOVDLL, where are the actual secrets? Not in lsass.exe. Not anywhere the kernel can read at all. The next section is the companion boundary.

9. The Companion Boundary -- Credential Guard, VBS, and `LsaIso.exe`

itm4n opens his RunAsPPL walkthrough with a warning [@itm4n-runasppl]:

I noticed that this protection tends to be confused with Credential Guard, which is completely different.

The confusion is understandable. Both run on Windows. Both protect LSASS. Both are configured by domain administrators. Both yield "ACCESS_DENIED" to Mimikatz when working correctly. They are nonetheless answering different questions, and they stack rather than replace each other.

PPL stops an administrator from reading kernel-trusted user-mode memory. It does nothing against a kernel-mode attacker who can simply zero the Protection byte in the target EPROCESS. The kernel-mode attacker is the next threat-model rung up, and the kernel-mode attacker is the threat that Credential Guard answers, by moving the credentials themselves out of lsass.exe entirely.

A Hyper-V-based isolation regime in which the Windows hypervisor partitions the system into Virtual Trust Levels (VTLs). VTL0 contains the normal Windows kernel and user-mode processes. VTL1 contains the Secure Kernel and a small set of user-mode trustlets. Memory in VTL1 is inaccessible to VTL0, even from VTL0 kernel-mode code. A user-mode process running inside VTL1. Trustlets are Microsoft-signed at a specific protected-process equivalent rung within VTL1 and serve as the user-mode hosts for VBS-isolated functionality. `LsaIso.exe` is the trustlet that holds the actual credential material on Credential Guard-enabled hosts.

The architecture is, at the highest level, three layers: VTL0 user-mode, VTL0 kernel, and VTL1 (Secure Kernel plus trustlets). On a Credential Guard-enabled host, lsass.exe still exists in VTL0 user-mode, still protects itself with PPL/Lsa, and still answers authentication requests. But it no longer holds the NTLM hashes, Kerberos TGT keys, or Cred Manager domain credentials. Those secrets live in LsaIso.exe, a trustlet in VTL1. When LSASS needs to authenticate a credential, it makes a hypercall into VTL1, and LsaIso.exe performs the cryptographic operation entirely within VTL1 memory, returning only the result. The keys never leave VTL1.

Microsoft's documentation states the threat model directly [@learn-cg]:

Credential Guard prevents credential theft attacks by protecting NTLM password hashes, Kerberos Ticket Granting Tickets (TGTs), and credentials stored by applications as domain credentials.

Credential Guard uses Virtualization-based security (VBS) to isolate secrets so that only privileged system software can access them.

Malware running in the operating system with administrative privileges can't extract secrets that are protected by VBS.

The third sentence is the load-bearing one. Malware running with administrative privileges maps cleanly to a PPL bypass that achieves code execution at PPL/Lsa. Even from inside lsass.exe, the secrets are not there.

flowchart TD subgraph VTL0[VTL0 normal world] Admin[Admin / SYSTEM token] Lsass[lsass.exe at PPL/Lsa] Kern0[VTL0 kernel] end subgraph VTL1[VTL1 secure world] SK[Secure Kernel] Iso[LsaIso.exe trustlet] Secrets[NTLM hashes, Kerberos TGT keys] end Admin -- "PPL barrier (lattice)" --x Lsass Lsass -- hypercall --> Iso Kern0 -- "VBS barrier (VTL boundary)" --x Iso Iso --> Secrets

The two mechanisms stack rather than overlap. PPL prevents an admin from OpenProcess(PROCESS_VM_READ, lsass) at the user-mode lattice level. Credential Guard prevents a kernel-mode attacker who succeeds against PPL from finding the keys, because the keys are in VTL1 memory that the VTL0 kernel cannot read at all. itm4n's "complementary" framing in the RunAsPPL writeup is the right operational summary [@itm4n-runasppl]: deploy both, always both.

Note: PPL gates user-mode admins out of LSASS code memory. Credential Guard gates everything else (kernel-mode attackers, BYOVDLL execution-at-PPL/Lsa) out of the secrets themselves by moving the secrets to VTL1. Each mechanism answers a layer of the threat model the other does not.

Dimension	PPL (LSA protection)	Credential Guard
Threat model	Administrator -> user-mode LSASS	VTL0 kernel + admin -> credential material
Layer	VTL0 user-mode lattice	VTL0 / VTL1 VBS boundary
Kernel-mode attacker	Cannot stop them	Stops them (VBS-isolated memory)
MSRC classification	Defense in depth	Security boundary
Default-on (consumer)	Audit mode, Win11 22H2	n/a (enterprise)
Default-on (enterprise)	Audit mode, Win11 22H2	Enabled, Win11 22H2 / Win Server 2025 (domain-joined non-DC)

The architecture of `LsaIso.exe`, its trustlet ID, its IUM EKU, and the hypercall plumbing between LSASS and the trustlet are the subject of a separate article in this series ("VBS Trustlets: What Actually Runs in the Secure Kernel"). The cross-link is deliberate: PPL and Credential Guard are paired in practice, but the architectural depth of VTL1 is its own subject.

Credential Guard's default-on rollout, recorded in Microsoft Learn [@learn-cg]:

Starting in Windows 11, 22H2 and Windows Server 2025, Credential Guard is enabled by default on domain-joined, non-DC systems that meet hardware requirements.

Two stacked mechanisms; one classified as a security boundary, one not. The next section asks what the classification means.

10. Where PPL Isn't a Security Boundary -- Microsoft's Servicing Criteria

Gabriel Landau's "Inside Microsoft's Plan to Kill PPLFault" essay states the classification in one sentence [@elastic-pplfault]:

Microsoft does not consider PPL to be a security boundary, meaning they won't prioritize security patches for code-execution vulnerabilities discovered therein, but they have historically addressed some such vulnerabilities on a less-urgent basis.

Microsoft's "Windows Security Servicing Criteria" defines the term security boundary directly [@msrc-servicing]:

A security boundary provides a logical separation between the code and data of security domains with different levels of trust. For example, the separation between kernel mode and user mode is a classic [...] security boundary.

A logical separation between code and data of security domains with different levels of trust. Microsoft commits to servicing security boundary violations with out-of-band patches when the severity bar is met. The kernel-mode / user-mode separation is the canonical example. Per Microsoft's published servicing criteria, PPL is *not* on the security-boundary list. A security feature that raises the cost of an attack without guaranteeing prevention. Microsoft treats defense-in-depth features as servicing targets on the standard cumulative-update cadence, not as out-of-band patch priorities. PPL falls into this category per Microsoft's published classification.

The relevant excerpts of the criteria page enumerate which surfaces are and are not boundaries. The live MSRC page renders that enumeration table client-side via JavaScript; the raw HTML returned by automated fetchers contains only the React shell. The text of the enumeration is preserved in the Wayback Machine capture at archive date 2023-05-06 [@msrc-criteria-archive], and Landau's follow-on Elastic post quotes the relevant administrative-process row verbatim [@elastic-byovd-admin]:

Administrative processes and users are considered part of the Trusted Computing Base (TCB) for Windows and are therefore not strong[ly] isolated from the kernel boundary.

The corresponding row for PPL is the same shape: administrative-process-to-PPL is not isolated as a security boundary. Landau filed VULN-074311 with MSRC in September 2022 disclosing both an admin-to-PPL and a PPL-to-kernel zero-day. The Elastic post records MSRC's classification of the disclosure verbatim [@elastic-byovd-admin]:

MSRC similarly does not consider admin-to-PPL a security boundary, instead classifying it as a defense-in-depth security feature.

The MSRC servicing-criteria page's *definition* of "security boundary" is retrievable from raw HTML and verified against the live page. The *enumeration* of which Windows surfaces are or are not boundaries lives in a client-side rendered table and is not present in the raw HTML payload. The verifiable trail for "PPL is excluded from the boundary list" is the Wayback Machine capture combined with Elastic's verbatim quotation of MSRC's classification.

The operational consequence is direct. A published PPL bypass does not trigger an out-of-band patch. It is fixed on the next major-release cadence, sometimes faster if Microsoft has internal motivation. The disclosure-to-fix half-lives are public record:

Bypass	Disclosed	Microsoft fix	Disclosure-to-fix
Forshaw 2018 JScript-into-PPL	Oct 2018	Apr 2018 (1803, pre-disclosure)	~0 months (Microsoft fixed first)
itm4n 2021 PPLdump (KnownDlls)	Apr 2021	Jul 2022 (build 19044.1826)	~15 months
Landau 2023 PPLFault (CI TOCTOU)	Apr-Sep 2023	Feb 2024 (GA)	~5-11 months
itm4n 2024 BYOVDLL (KeyIso chain)	Aug 2024	none (open, CVE-by-CVE)	open

Note: A correctly classified PPL bypass is fixed on the standard cumulative-update cadence, not out-of-band. The implication for defenders is operational: PPL is exactly as strong as the engineering velocity Microsoft chooses to invest in it. Treat detection (Section 11) and the Credential Guard companion (Section 9) as load-bearing.

The reader takeaway is the third Aha moment of the article. PPL is real, kernel-enforced, structurally elegant, and demonstrably effective against the threat it was designed for (administrator-from-user-mode reads of LSASS). It is also explicitly not a security boundary per Microsoft's own published servicing policy, and that classification is the most important fact about it. Plan for bypasses. Stack with Credential Guard. Treat detection as primary, not secondary.

11. Practical Guide -- Configuring, Verifying, and Monitoring PPL

If you are deploying PPL on a corporate fleet, run this checklist. The order is deliberate: audit before enforce, verify before trust the verifier, and detect because no static control survives unmotivated.

Deploy

Note: Enable AuditLevel = 8 under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\LSASS.exe for two months [@learn-runasppl]. This is a different registry hive from RunAsPPL (which lives under HKLM\SYSTEM\CurrentControlSet\Control\Lsa); mixing the two values up is the most common Stage 0 deployment error (see §6). Collect CodeIntegrity events 3065 and 3066 to enumerate every LSASS plug-in that would fail enforcement (smart-card middleware, third-party CSPs, password-filter DLLs). Re-sign or replace the failing modules. Set RunAsPPL = 1 on Secure Boot-capable machines; the kernel automatically stores the policy in a UEFI variable. RunAsPPL = 2 (Win11 22H2+) is the softer option that omits the UEFI variable for environments requiring admin-removable protection.

Note: For third-party EDR, confirm the agent daemon runs at PPL/Antimalware (signer rung 3, byte 0x31). Process Explorer exposes this via View -> Select Columns -> Protection. System Informer (the modern Process Hacker fork that itm4n recommends in his BYOVDLL writeup [@itm4n-ghost-part1]) shows the same field in its process list. If your EDR is not running at PPL/Antimalware, it does not have the kernel's protection against admin tampering even when its vendor claims "protected" in marketing material. Process Explorer's "Protection" column ships in the canonical Sysinternals distribution [@sysinternals-procexp]; it reads EPROCESS.Protection via the NtQueryInformationProcess entry point [@learn-ntqueryinfoproc], although the specific ProcessProtectionInformation information-class value is not enumerated in the public Learn PROCESSINFOCLASS table -- the value is community-documented from Windows headers and reverse engineering rather than from a Microsoft Learn API reference.

Verify

Note: On a host you suspect of misconfiguration, attach WinDbg to the kernel and run !process 0 7 lsass.exe. The output includes the _PS_PROTECTION byte. Decode it with the formula from §3 above: ((value & 0xF0) >> 4) is the signer rung; value & 0x07 is the type; (value >> 3) & 1 is the audit bit. A RunAsPPL = 1 host yields 0x41 (PPL + Lsa). The Defender service yields 0x31 (PPL + Antimalware). csrss.exe yields 0x61 (PPL + WinTcb). If lsass.exe shows 0x00, the registry policy did not take effect on this boot.

{function decode(b) { const t = b & 0x07, a = (b >> 3) & 0x01, s = (b >> 4) & 0x0F; const tn = ['None', 'ProtectedLight', 'Protected']; const sn = ['None','Authenticode','CodeGen','Antimalware', 'Lsa','Windows','WinTcb','Max']; return '0x' + b.toString(16).padStart(2,'0') + ' = ' + (sn[s] || s) + '-' + (tn[t] || t) + (a ? ' (Audit on)' : ''); } // Three benchmark values you should be able to recognise by sight console.log(decode(0x31)); // MsMpEng.exe (Defender at PPL/Antimalware) console.log(decode(0x41)); // lsass.exe under RunAsPPL=1 console.log(decode(0x61)); // csrss.exe (PPL/WinTcb)}

Monitor

Note: The CodeIntegrity provider emits three event IDs that matter for PPL monitoring [@learn-runasppl]: | Event ID | Provider | What it tells you | |---|---|---| | 3033 | Microsoft-Windows-CodeIntegrity | A DLL load was blocked by CI (PPL or otherwise) | | 3063 | Microsoft-Windows-CodeIntegrity | Enforcement-mode: LSASS plug-in failed the shared-section security requirement (complement of audit-mode event 3065) | | 3065 | Microsoft-Windows-CodeIntegrity | LSASS plug-in failed the shared-section requirement | | 3066 | Microsoft-Windows-CodeIntegrity | LSASS plug-in failed the Microsoft signing level requirement | Sysmon Event 10 (ProcessAccess) captures OpenProcess denials with the requested access mask and is the cheapest detection for a Mimikatz-shaped attempt against an RunAsPPL-protected lsass.exe. A burst of 3033 events from a non-Microsoft process targeting lsass.exe is the canonical signal that a PPL bypass attempt is under way.

Note: PPL prevents admin-from-user-mode reads of LSASS. Credential Guard prevents kernel-mode reads of the credentials themselves (and BYOVDLL-style execution at PPL/Lsa). Deploy both. itm4n's "complementary" framing in his RunAsPPL writeup [@itm4n-runasppl] is the right operational model. On Win11 22H2 and Windows Server 2025, Credential Guard is default-on for domain-joined non-DC systems with VBS-capable hardware [@learn-cg]; on older fleets, enable it explicitly via Group Policy or the Device Guard / Credential Guard configuration script. Always both -- either alone leaves a layer of the threat model uncovered.

Note: If you are an EDR vendor wanting your daemon to run at PPL/Antimalware, the path is fixed [@learn-mvi] [@learn-am-services]: 1. Hold Microsoft Virus Initiative membership; maintain independent-lab certification (AV-Comparatives, AV-Test, SE Labs, MRG Effitas, SKD Labs, VB 100, West Coast Labs, AVLab Cybersecurity Foundation). 2. Author an ELAM driver with an embedded <ELAM> resource section enumerating your user-mode binary signing-certificate hashes. 3. Submit the driver through WHQL for Microsoft co-signing. 4. Use Trusted Signing for your user-mode binaries. 5. Verify with Process Explorer that the service launches at PPL/Antimalware after install.

Practitioners who follow the checklist still need to know the common misconceptions. The next section catalogues them.

12. FAQ -- Common Misconceptions

Seven questions practitioners ask after their first PPL deployment.

Yes for full-access termination via `OpenProcess(PROCESS_TERMINATE, ...)`; an admin without a higher signer rung cannot terminate a `PPL/Antimalware` daemon by a direct kill. No for legitimate uninstall: the vendor's MSI installer (or equivalent) typically signals the daemon to shut itself down through its own service-control path, which is gated by ACL and not by the PPL lattice. Operationally, expect administrators to be able to uninstall your EDR but not to terminate its main process from outside the vendor toolchain. No. itm4n's verbatim warning is worth repeating [@itm4n-runasppl]: "I noticed that this protection tends to be confused with Credential Guard, which is completely different." PPL protects `lsass.exe` *as a process* from admin-from-user-mode reads. Credential Guard moves the *credentials themselves* into VTL1 memory via VBS. PPL is a VTL0 user-mode lattice control. Credential Guard is a VTL0 / VTL1 hypervisor boundary. They stack; see Section 9 for the layering and Section 11 Item 5 for the deployment recommendation. Because Microsoft has not classified PPL as a security boundary. The Windows Security Servicing Criteria define a security boundary as a logical separation between security domains at different levels of trust, and Microsoft's published enumeration excludes administrative-process-to-PPL from that list [@msrc-servicing] [@elastic-byovd-admin]. PPL is treated as a defense-in-depth feature. The operational implication is that PPL bypasses are fixed on the next major release cadence rather than out-of-band, with disclosure-to-fix half-lives ranging from approximately five to fifteen months historically (see Section 10 for the data). Practically no for non-AV applications. The protected-process EKU OIDs are gated by Microsoft's certificate authorities; only the Antimalware rung admits third-party certificates, and admission is mediated by ELAM driver + Microsoft Virus Initiative membership [@learn-mvi]. Hobbyist tooling cannot opt in. There is no public path for a non-AV third-party application to claim a PPL rung. If your application requires PPL-style anti-tampering, the realistic options are (a) become an MVI member if your application is an AV/EDR, (b) use Process Mitigation Policies such as Code Integrity Guard for code-injection resistance, or (c) deploy your sensitive operations inside a separate Microsoft-signed service. "Protected service" is informal terminology for a Windows service whose host process runs as a PPL, with the Service Control Manager configured to launch it at a specific signer rung. The deployment plumbing (SCM service configuration, service-DLL packaging, the signing of the host binary) is what makes a service "protected." The PPL machinery is what makes the host process actually resistant to tampering. The two terms describe the same thing from different angles -- one from the SCM-management view, one from the kernel-access-check view. Only if the smart-card middleware DLL is not signed at the LSA level (signer rung 4). Most major smart-card vendors have updated their middleware to be Microsoft-signed at the required level, but legacy or in-house middleware frequently fails enforcement. The recommended workflow is to run `AuditLevel = 8` for two months [@learn-runasppl], collect CodeIntegrity 3065 / 3066 events, enumerate the failing modules, re-sign or replace them, and only then switch to `RunAsPPL = 1`. Skipping the audit period is the single most common cause of authentication outages during LSA protection rollouts. Because the threat model PPL answers is *administrator-from-user-mode*, not *administrator-from-kernel-mode*. PPL is a kernel-enforced gate in the access-check pipeline, but a kernel-mode driver that can write to `EPROCESS.Protection` can zero the byte and disable the gate for any process. The defense against the kernel-mode attacker is a different mechanism: VBS-isolated credentials in VTL1 (Credential Guard), with HVCI / kernel-mode integrity controls preventing arbitrary kernel-mode code from running in the first place. PPL stops one threat; Credential Guard stops the threat one rung up; and the two are intended to be deployed together (Section 9, Section 11 Item 5).

The arc has run from a single Mimikatz error code to a kernel-enforced lattice, a third-party admission path mediated by ELAM and MVI, an arms race shaped by a single structural insight that the kernel verifies the channel and not the behaviour, and a stacked companion boundary that lives in VTL1 because VTL0 has run out of places to hide a key. PPL is not a security boundary. That classification is not a footnote; it is the most important fact about it, because it tells defenders that the mechanism is exactly as strong as the engineering velocity Microsoft chooses to invest. Deploy it. Stack it with Credential Guard. Monitor for the next bypass.

Key idea: The kernel verifies the channel. It does not verify the behaviour. Every PPL bypass since 2018 has lived in that seam, every fix has narrowed the channel, and the seam survives because behaviour is, by Rice's theorem, structurally outside what static signature verification can reason about.

"Who Is This Code?" -- The Quiet 33-Year Reinvention of App Identity in Windows

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

Windows NT 3.1 (1993) could prove which **user** typed at the keyboard but had no answer to **which code was running**. Over the next thirty-three years, eight successive primitives -- Authenticode, Kernel-Mode Code Signing, Protected Process Light, AppContainer with the Package SID, App Control for Business, Mark of the Web with SmartScreen, the Vulnerable Driver Block List, and Pluton-rooted attestation -- accreted into a single layered code-identity stack. Each was forced into existence by a specific, named failure of the one before it. This is that story, told as one system.

Two identities, one operating system

On July 27, 1993 -- the day Windows NT 3.1 shipped -- the new operating system could prove with cryptographic precision who Alice was, which group she belonged to, which file she was allowed to open, and at what level of privilege she was running. It could prove exactly nothing about the program she had just double-clicked.

Thirty-three years later, "Alice" has barely changed. The code she runs has acquired a publisher signature stamped onto its Portable Executable file, a kernel-loader gate that refuses to load unsigned drivers, a signer level in a runtime lattice that decides whether one process can read another's memory, a Package SID derived from a Crockford-Base32 hash of the manifest publisher [@ms-package-identity], a publisher-rule entry in a centrally managed App Control policy [@ms-appcontrol], a Mark-of-the-Web alternate data stream from the browser that downloaded it [@ms-fscc-motw], a SmartScreen reputation score [@learn-smartscreen], a possible entry on a Microsoft-curated denylist that overrides its own valid signature [@msft-driver-blocklist], and -- on a Pluton-equipped 2026 laptop -- a hardware-attested measurement of the boot chain that loaded it [@learn-pluton]. Every one of those identities was forced into existence by a specific failure of the one before. This is that story.

A modern symptom makes the asymmetry concrete. In April 2026, attackers seized the publishing pipeline for the @bitwarden/cli npm package -- a credential they had no business holding -- and shipped a backdoored release for ninety-three minutes before maintainers caught it [@bitwarden-statement]. Code identity, as it existed at every layer of every operating system that consumed that package, said the artifact was authentic. The signature was valid. The publisher's account was real. The package metadata was correct. Every check passed. And the binary was hostile. That gap, between "who shipped it" and "is it safe to run," is the same gap NT 3.1 first stepped over in 1993 and that Windows has been trying to close ever since.

The Bitwarden case sits in a long company. Stuxnet's stolen Realtek and JMicron driver-signing keys (2010) [@symantec-stuxnet], Flame's MD5 collision against Microsoft's own intermediate CAs (2012) [@ms-2718704], the ASUS ShadowHammer pipeline compromise (operation 2018, disclosed 2019) [@securelist-shadowhammer], every "Bring Your Own Vulnerable Driver" rootkit since 2018 -- they all have the same shape. A valid Windows-anchored signature, on code the publisher did not intend to ship, on a machine that loaded it without complaint.

Key idea: Every Windows code-identity primitive introduced since 1996 was forced into existence by a specific failure of the layer before it. The article's spine is that cascade.

The pieces in 2026 are not a feature checklist. They are a layered system, each layer answering a question its predecessor structurally could not. If you read the Microsoft Learn pages one at a time you see eight unrelated products. If you read them in the order their failures forced them into existence, you see one operating system slowly learning to name the code it runs.

timeline title Windows code identity, 1993 to 2026 1993 : NT 3.1 ships : user-only principal 1996 : Authenticode : publisher signature on PE 2002 : Trustworthy Computing memo : SDL forcing function 2006 : Vista x64 KMCS : refusal of unsigned kernel code 2010 : Stuxnet : stolen Realtek + JMicron keys 2012 : AppContainer : per-app SID 2012 : Flame : MD5 collision against MS CA 2013 : Windows 8.1 PPL : signer level as runtime ACL 2015 : Device Guard / WDAC : publisher policy 2019 : ASUS ShadowHammer disclosed : compromised pipeline (2018 operation) 2020 : Pluton announced : in-die security processor 2022 : Driver Block List default-on : signed != trusted 2024 : CrowdStrike outage : placement is identity 2025 : MVI 3.0 user-mode preview : kernel/user split

Timeline sources, in row order (Mermaid syntax does not permit inline tokens inside the timeline block; each event is independently cited in the surrounding prose as well): 1993 NT 3.1 [@custer-inside-nt]; 1996 Authenticode [@ms-news-1996-authenticode]; 2002 Trustworthy Computing memo [@cnet-gates-memo] [@theregister-tcm]; 2006 Vista x64 KMCS [@ms-kmcs]; 2010 Stuxnet [@symantec-stuxnet]; 2012 AppContainer [@ms-package-identity]; 2012 Flame MD5 collision [@ms-2718704] [@msrc-2718704]; 2013 Windows 8.1 PPL [@ionescu-ppl] [@ms-protected-processes]; 2015 Device Guard / WDAC [@ms-appcontrol]; 2019 ASUS ShadowHammer disclosed (operation 2018) [@securelist-shadowhammer]; 2020 Pluton announced [@learn-pluton]; 2022 Driver Block List default-on [@msft-driver-blocklist]; 2024 CrowdStrike outage [@ms-crowdstrike-blog] [@msft-crowdstrike-best-practices]; 2025 MVI 3.0 user-mode preview [@weston-2024] [@weston-2025].

If user identity was easy, why did code identity take thirty-three years -- and where exactly did each generation break?

Why code had no name

Helen Custer's 1992 Inside Windows NT opens its security chapter on a single principle: the user is the principal [@custer-inside-nt]. Every action the kernel arbitrates is attributable to a user account. The token that the kernel manufactures at logon carries a Security Identifier (SID) for the user, SIDs for each group the user belongs to, a privilege bitmap, and a set of impersonation flags. Every Discretionary Access Control List on every securable object is evaluated against that token [@ms-sids]. The kernel never asks what binary is running. It asks who is running it.

A variable-length value that uniquely identifies a security principal in Windows. Users, groups, computer accounts, and (later) packages and capabilities all receive SIDs. Until Windows 8, every SID encoded a *user* or *group*; AppContainer and Package SIDs (the `S-1-15-2-...` form) extended SIDs to name code instead.

For 1993's threat model, the user-as-principal model was defensible. NT 3.1 lived on multi-user workstations in a trusted local-area network. The attacker the designers worried about was a malicious insider, a contractor with the wrong group membership, an admin who exceeded his authority. Code arrived on floppies and CDs from coworkers and shrink-wrapped vendors; nobody downloaded executables off the public internet, because for most of the world there was no public internet to download them from.Integrity levels (Low, Medium, High, System) were added later, in Vista (2006), and they are still attributes of the token, not of the binary on disk. A Low-integrity Internet Explorer process and a Low-integrity Notepad receive the same write restrictions because their tokens carry the same Mandatory Integrity Control label, regardless of which binary loaded.

Then came Internet Explorer 3.0 in August 1996 and ActiveX. Microsoft repositioned OLE/COM as a cross-internet component model and committed to letting any compliant ActiveX control execute inside the browser [@ms-news-1996-authenticode]. The decision was not casually made; it was the strategic foundation of Microsoft's bet on the web. But its consequence at the security layer was immediate and devastating.

If Alice double-clicks a control on a web page, the operating system's question is "who is running this?" The answer is "Alice." She is allowed to run anything she wants. The control does whatever it likes -- with her token, her files, her privileges, her network access. The user-as-principal model has no second axis to invoke.

There was no theoretical fix at this layer. Alice did genuinely request the download. She did genuinely double-click. NT had no other principal to consult. The model was complete, internally consistent, and exactly wrong for the new threat surface.

What was missing was a cryptographic, network-portable identity for the code itself, attached to the binary in a way nobody downstream could forge. If the kernel cannot see the code, who can put a name on it -- and how do we attach that name to a running PE?

The first naive attempt: Authenticode (1996)

On August 7, 1996, Microsoft and VeriSign jointly announced the first cryptographic answer Windows had ever offered to "who is this code?" The press release ran twenty-two paragraphs and named every design choice that the next thirty years of Windows code identity would inherit: an X.509 certificate issued by an external commercial Certificate Authority, a PKCS#7 SignedData blob attached directly to the binary, and verification at download or install time by Internet Explorer 3.0 [@ms-news-1996-authenticode].

A cryptographic format for binding a publisher's identity and a tamper-evident hash to a Portable Executable. The signature is stored in the PE Attribute Certificate Table as a PKCS#7 SignedData structure containing an X.509 certificate chain and a hash that excludes the checksum field, the certificate-table directory entry, and the certificate table itself. Authenticode names the *publisher*, not the code; this is the founding constraint the rest of the article is forced to work around. The new Microsoft Authenticode technology uniquely identifies the publisher of a piece of software and provides assurance to end users that it has not been tampered with or modified. -- Microsoft press release, August 7, 1996 [@ms-news-1996-authenticode]

That sentence is the founding promise of Windows code identity. Read it once and the rest of the article becomes inevitable. Authenticode promises two things. It identifies the publisher. It detects tampering. It does not promise that the publisher is trustworthy, that the publisher's key is uncompromised, or that the bytes it covers are safe to execute. Three decades of failure modes follow from exactly that scoping.

The mechanism is precise enough to demand a diagram. SignTool computes a hash that deliberately skips three regions of the PE: the checksum field (which the loader recomputes), the certificate-table directory entry, and the certificate table itself. The signature does not have to sign the bytes of its own embedding [@ms-pe-format].

It then forms a PKCS#7 SignedData structure [@rfc-2315] containing the hash, an algorithm identifier, the X.509 chain, and an optional RFC 3161 timestamp. That blob is appended to the certificate table. At verify time, WinVerifyTrust recomputes the hash, walks the chain to a trusted root, and (if a timestamp is present) honours signatures that were valid as of the timestamped time even if the issuer has since revoked the certificate [@ms-cryptotools].

sequenceDiagram participant Dev as Developer participant Sign as SignTool participant PE as PE binary participant Win as WinVerifyTrust participant CA as CA / chain store Dev->>Sign: signtool sign /a app.exe Sign->>PE: hash bytes (skip checksum + cert table) Sign->>PE: build PKCS#7 SignedData Sign->>PE: append RFC 3161 timestamp Sign->>PE: write into Attribute Cert Table Note over Win: at install / download time Win->>PE: re-hash same byte ranges Win->>PE: extract PKCS#7 SignedData Win->>CA: verify X.509 chain to trusted root CA-->>Win: chain ok Win-->>Win: trust verdict (advisory pre-Vista)

Three structural failure modes shipped on day one and still ship in 2026.

Userland was advisory. A signed .exe ran. An unsigned .exe also ran. Internet Explorer would prompt the user with a publisher name, but the prompt was a UI feature, not a kernel gate. The signature was a credential offered for inspection, never a wall the loader refused to cross. Closing this gap took ten years for kernel code (Authenticode 1996 [@ms-news-1996-authenticode] -> KMCS, Vista 2006 [@ms-kmcs]) and nineteen years for managed user-mode policy (Authenticode 1996 [@ms-news-1996-authenticode] -> Device Guard, 2015 [@ms-appcontrol]). Unmanaged consumer Windows in 2026 still permits arbitrary unsigned .exe to run if the user clicks through SmartScreen.

The signed hash did not cover the whole file. This is CVE-2013-3900, disclosed by Microsoft on December 10, 2013 in security bulletin MS13-098 [@ms13-098]. The Authenticode hash skips the certificate-table region by design, and the verifier in WinVerifyTrust did not constrain the size of the unsigned PKCS#7 blob. An attacker could append arbitrary unauthenticated bytes inside the WIN_CERTIFICATE structure of an already-signed PE without invalidating the signature.

The fix was a registry value, EnableCertPaddingCheck=1, that turned on strict verification. Microsoft chose not to enable it by default. Twelve years later, the National Vulnerability Database still records the same scoping note: "Microsoft does not plan to enforce the stricter verification behavior as a default functionality on supported releases of Microsoft Windows" [@nvd-cve-2013-3900]. CISA added CVE-2013-3900 to its Known Exploited Vulnerabilities catalog on January 10, 2022 -- eight years after disclosure, because attackers were still abusing the unfixed default [@nvd-cve-2013-3900].

Note: CVE-2013-3900 is still default-off in 2026. On any Windows endpoint where strict signature verification matters, set HKLM\Software\Microsoft\Cryptography\Wintrust\Config\EnableCertPaddingCheck=1 (and the WOW6432Node mirror on 64-bit). Microsoft documents the change as opt-in by design [@msrc-cve-2013-3900].

Timestamped signatures survive revocation. The trust evaluator in WinVerifyTrust is told to trust signatures as of the timestamped instant, not as of now. Removing this property would invalidate large catalogs of legitimate, archived signed software whose signing certificates have since expired [@ms-cryptotools]. The same property is what let the Stuxnet drivers load on every Windows machine that received them, because Microsoft revoked the Realtek and JMicron certificates after Stuxnet had already shipped.The architectural choice here is genuinely hard. Synchronous global revocation would break offline software install. Asynchronous revocation, the alternative Microsoft chose, lets pre-revocation signatures continue to verify forever. There is no third option inside the Authenticode design.

Pull these three threads together and the first aha falls out. Authenticode names the publisher, not the code. A signed binary is a credential, not a verdict. The signature proves the bytes came from a holder of the publisher's private key. It does not prove the publisher is trustworthy, that the publisher's key has not been stolen, or that the bytes are safe to execute. Every failure mode of the next twenty-five years lives in that gap.

Six years of failure modes had to accumulate before Microsoft executive priorities caught up. On January 15, 2002, Bill Gates sent the "Trustworthy Computing" memo company-wide, declaring security a higher priority than features and freezing engineering work for security review across its Windows product line (with SDL processes later extended company-wide) [@cnet-gates-memo] [@theregister-tcm]. The memo did not specify a code-identity mechanism. It is in this story because every later code-identity primitive -- the Security Development Lifecycle's mandatory SignTool integration, the XP SP2 hardening pass that produced MOTW, and the Vista work that produced KMCS -- shipped under the executive cover the memo provided [@windows-internals-7e].

If unsigned code still runs in userland, what makes us think the same primitive will work for a kernel driver -- where the wrong binary owns the operating system?

The first refusal: KMCS, EV, and the WHQL pipeline (Vista, 2006)

Vista x64 shipped in November 2006 as the first Windows release that refuses to load unsigned kernel code [@ms-kmcs]. The refusal was uncompromising. The kernel loader and the Plug-and-Play manager call into WinVerifyTrust for every driver image; if the chain does not terminate at one of a small set of Microsoft-trusted roots, MmLoadSystemImage returns STATUS_INVALID_IMAGE_HASH and the driver does not load.

The Vista-era policy that requires every kernel-mode driver to carry an Authenticode signature chained to a Microsoft-trusted root. From Windows 10 1607 onward (the August 2016 Anniversary Update), only drivers signed by Microsoft via the Hardware Developer Center are accepted on Secure-Boot systems; end-entity cross-signed certificates issued before July 29, 2015 are grandfathered for legacy devices [@ms-kmcs].

The mechanism is a load-time gate. In 2026, Microsoft offers three signing tiers that all terminate at a Microsoft cross-signed cert: HLK-tested (the full Windows Hardware Lab Kit run, eligible for retail Windows Update distribution), attestation-signed (lighter-weight, EV cert plus Microsoft attestation key, no hardware testing), and preproduction (developer signing for pre-release Windows builds) [@learn-driver-signing-offerings] [@ms-attestation-signing]. Driver .cat catalog files extend Authenticode coverage from a single PE to an entire driver package, including INF files and supporting executables [@learn-embedded-sig].

EV certificates -- Extended Validation, with mandatory hardware-security-module key storage and audited issuance -- became the practical floor for kernel signing. The reason was not pedagogical. A Domain Validated Authenticode cert from a commodity CA in that era could be obtained cheaply, often with little more than a working email address. EV raised the cost and binding strength of the publisher claim by an order of magnitude.

Then, on June 17, 2010, Sergey Ulasen of the Belarusian anti-virus vendor VirusBlokAda flagged a strange piece of malware on a customer machine in Iran. It had been signed [@wikipedia-stuxnet].

The Stuxnet dropper carried two kernel drivers, mrxnet.sys and mrxcls.sys, signed with legitimate Authenticode certificates issued to Realtek Semiconductor and JMicron Technology -- two Taiwanese hardware vendors. Investigators concluded the private keys had been physically exfiltrated from the publishers' Taiwanese offices. VeriSign revoked the Realtek certificate on July 16, 2010 (and the JMicron certificate shortly afterward); Microsoft issued advisories and pushed Windows CTL updates to propagate the revocation [@symantec-stuxnet]. While the certs were valid, Vista x64 KMCS happily loaded both drivers on every system it touched.

Note: KMCS verifies who signed, never whether the signed code is safe. Every kernel-mode-identity failure between 2010 and 2026 reduces to that single sentence.

The Stuxnet certificates were not anomalies. The same failure shape -- valid Microsoft-rooted signature, on code the publisher did not intend to ship, on a healthy KMCS-enforcing kernel -- replays at predictable intervals.

The Flame espionage toolkit produced a *forged* Microsoft-rooted certificate by exploiting an MD5 chosen-prefix collision against Microsoft's Terminal Services Licensing Service, which still issued MD5-hash code-signing certificates years after MD5's brokenness was known. Microsoft Security Advisory 2718704 revoked three of its own intermediate CAs and emergency-deployed a new Untrusted Certificate Store mechanism through Windows Update [@ms-2718704] [@msrc-2718704]. The episode forced Microsoft to deprecate MD5 in code signing and led directly to the curation infrastructure the Driver Block List uses today.

ASUS ShadowHammer in 2018, disclosed by Kaspersky in 2019, added a third variant. The attackers did not steal an HSM-bound key. They compromised ASUS's signing pipeline and got their backdoor signed by ASUS's production signing key in the normal course of a normal release, distributed through ASUS Live Update [@securelist-shadowhammer]. Kaspersky's analysis recorded "trojanized updaters were signed with legitimate certificates (eg: 'ASUSTeK Computer Inc.')" and that "over 57,000 Kaspersky users have downloaded and installed the backdoored version of ASUS Live Update." The trust root, the chain, the cert -- all valid. The bytes -- attacker-controlled.

KMCS verified that a driver was signed, not that it was safe. Signing alone was not enough. But what was?

The second refusal: identity as a runtime attribute (PPL, 2013)

Until October 17, 2013, code identity gated whether code could load. Windows 8.1 quietly shipped a structural shift: code identity now also gated what one running process could do to another [@ionescu-ppl]. Alex Ionescu, then CrowdStrike's founding Chief Architect and previously a co-author of Windows Internals, was the first person to publish a detailed external map of the new mechanism. The lineage runs back to Vista's 2006 Protected Process model, originally introduced as a DRM container for protected media playback; PPL is the security-grade descendant of that primitive, repurposed seven years later as a general-purpose process-protection mechanism [@windows-internals-7e].

A protection attribute attached to running processes that mediates inter-process access checks above and beyond the user-token DACL. PPL processes carry a *signer level* (in increasing order, roughly: `Authenticode`, `CodeGen`, `Antimalware`, `Lsa`, `Windows`, `WinTcb`, `WinSystem`). A process can open `PROCESS_VM_READ`, `PROCESS_VM_WRITE`, or `CREATE_THREAD` rights against another protected process only if its own signer level is greater than or equal to the target's [@ionescu-ppl] [@ms-protected-processes].

The mechanism lives in the kernel's EPROCESS object. When process A opens process B, the kernel calls into RtlTestProtectedAccess (and downstream PsTestProtectedProcessIncompatibility) before any DACL evaluation [@scrt-ppl-bypass]. If A's signer level is below B's, sensitive access masks are silently stripped from the returned handle. The classic effect: an attacker running with a SYSTEM token, holding SeDebugPrivilege, calling OpenProcess on LSASS, gets back a handle without PROCESS_VM_READ. Mimikatz can no longer dump the LSASS process memory.

The signer level itself is set by an Enhanced Key Usage extension on the Authenticode certificate Microsoft issues to the binary's publisher. Antimalware vendors receive a certificate carrying the Antimalware EKU; only Microsoft-internal binaries carry WinTcb [@itm4n-runasppl]. Identity, in this model, is an EKU OID baked into a Microsoft-issued Authenticode cert, attached to the binary, evaluated by the kernel at every cross-process access check.

flowchart TD A[WinSystem] B[WinTcb] C[Windows] D[Lsa] E[Antimalware] F[CodeGen] G[Authenticode] A --> B --> C --> D --> E --> F --> G H["Caller (signer level X)"] -- "OpenProcess(target T, signer Y)" --> I{"X >= Y ?"} I -- yes --> J["full access mask"] I -- no --> K["VM_READ / VM_WRITE / CREATE_THREAD stripped"]

LSASS-as-PPL is the canonical demonstration of the mechanism in practice. Setting HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL=1 causes the next boot's LSASS to start with PsProtectedSignerLsa. From that moment, no process below the Lsa signer level can read LSASS memory, regardless of the user account. Mimikatz still runs as code; its OpenProcess(LSASS, PROCESS_VM_READ) call returns a handle with the read right stripped, and its memory dump fails with STATUS_ACCESS_DENIED before it ever sees a credential blob [@itm4n-runasppl].The RunAsPPL=1 setting is mirrored into a UEFI variable on Secure Boot systems precisely so that an attacker with HKLM\SYSTEM registry write but no firmware-level access cannot disable LSA Protection by editing the registry and rebooting. The UEFI mirror is checked before the registry value is read [@itm4n-runasppl].

ELAM -- Early Launch Antimalware -- is the same idea applied to boot. An ELAM driver, signed with a Microsoft-issued antimalware certificate, runs before any third-party boot driver and gets to vote on which subsequent drivers are allowed to load [@learn-elam]. Signer level enters the boot chain at the earliest moment third-party code can enter the boot chain.

Key idea: PPL's invention is conceptual, not just mechanical. Code identity becomes a runtime ACL between two running processes, not merely a load-time gate. App Control, HVCI, and the Driver Block List all operate on this same conceptual frame: identity continuously evaluated, in context, while code is executing.

PPL was, and is, the right idea. It is also incomplete in two ways that drove every subsequent layer.

The first gap is BYOVD -- Bring Your Own Vulnerable Driver. A signed-but-vulnerable driver such as RTCore64.sys (shipped with MSI Afterburner), Capcom.sys (shipped with the Street Fighter V anti-cheat), or gdrv.sys (shipped with Gigabyte motherboard utilities) gives any local administrator arbitrary kernel read/write through an IOCTL. Because these drivers are validly KMCS-signed, they load. From kernel mode, the attacker simply zeroes the Protection byte in the target process's EPROCESS structure, and PPL evaporates. The signing chain is sound. The signer level is correctly evaluated. The mechanism that decides which kernel code is allowed to exist -- not just to be signed -- is what fails.

Note: PPL is bypassed not by attacking PPL itself but by editing EPROCESS.Protection from kernel mode. That is exactly why the Driver Block List had to exist as a separate layer above KMCS [@msft-driver-blocklist].

The second gap is the user-mode side. PPLdump and PPLfault demonstrated that confused-deputy DLL loads inside higher-PPL services could be turned into an arbitrary memory read of LSASS. Microsoft eventually patched PPLdump in Windows 10 21H2 build 19044.1826, but the failure class remains structural: trusting a higher-signer process to safely load DLLs from publisher-controlled paths is a foot-gun every time a new such service ships [@ppldump-github] [@scrt-ppl-bypass].

If signer level is the principal for OS-internal processes, what is the principal for the next layer up -- the application?

The application becomes a principal: AppContainer and the Package SID

Two processes, same user, same machine. One can read the user's SSH private keys. The other cannot. Same token. Same DACLs on the file. Different verdict. That is the AppContainer promise [@ms-appcontainer-isolation], and to keep it the operating system needs a cryptographic identity for the application itself -- something derived from the application, not from the user, that ACLs can name.

Windows 8 shipped AppContainer in 2012. Internally it was called LowBox, the name surviving in the legacy documentation [@ms-appcontainer-legacy]. Windows 10 generalised the model into MSIX, the modern app-package format [@ms-msix].

AppContainer is a per-process sandbox that augments the user-token security check with an *AppContainer SID* (`S-1-15-2-...`) derived from the package identity of the running application. ACLs and capability claims (such as `internetClient` or `picturesLibrary`) are evaluated against this SID, not against the user. Two processes running as the same user can therefore receive different access verdicts because their AppContainer SIDs differ.

The cryptographic move is in how the SID is built.

Every MSIX/APPX package is identified by a five-element tuple: `(Name, Version, Architecture, ResourceId, Publisher)` [@ms-package-identity]. The `Publisher` field is the X.509 subject Distinguished Name of the certificate that signed the package. A 13-character `PublisherId` is derived deterministically from the Publisher DN by Crockford-Base32 encoding the first 64 bits of a SHA-256 hash (per community reverse-engineering; Microsoft's public documentation does not confirm the specific algorithm). The *Package Family Name* is then `_`; the *AppContainer SID* is computed deterministically from the full identity tuple and slotted into the `S-1-15-2-...` namespace.

The derivation is dense enough to deserve a worked example. Microsoft Corporation plus the Microsoft.WindowsCalculator package name yields Microsoft.WindowsCalculator_8wekyb3d8bbwe -- the suffix is the Crockford-Base32 PublisherId of Microsoft Corporation's subject DN [@ms-package-identity]. Every MSIX package whose Publisher DN matches will share that suffix; every package whose Publisher DN differs will have a different suffix; an attacker who does not hold the publisher's signing key cannot make a package masquerade as belonging to that publisher's family.

{async function publisherIdOf(publisherDN) { const data = new TextEncoder().encode(publisherDN); const digest = await crypto.subtle.digest('SHA-256', data); const first8 = new Uint8Array(digest.slice(0, 8)); // Crockford Base32 alphabet (no I, L, O, U) const alpha = '0123456789abcdefghjkmnpqrstvwxyz'; let bits = 0n; for (const b of first8) bits = (bits << 8n) | BigInt(b); let out = ''; for (let i = 0; i < 13; i++) { out = alpha[Number(bits & 31n)] + out; bits >>= 5n; } return out; } const dn = 'CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US'; publisherIdOf(dn).then(pid => console.log('PFN suffix candidate:', pid)); console.log('Real PFN: Microsoft.WindowsCalculator_8wekyb3d8bbwe'); console.log('Note: the real algorithm is documented in package-identity-overview; this snippet demonstrates the structure, not the exact hash.');}

Capabilities sit at the same layer. When an MSIX manifest declares <Capability Name="internetClient" />, the package is tagged at install time with a capability SID of the form S-1-15-3-1, and the Windows Filtering Platform evaluates outbound TCP connections against that SID, not against the user's [@p0-appcontainer]. Mandatory Integrity Control labels (Low/Medium/High) compose with the AppContainer SID rather than replacing it [@learn-mic]. A broker process running outside the AppContainer is the only path back to user-scoped resources, and the broker keys its trust decisions on the calling Package SID.

Windows Hello's biometric authentication broker is itself an MSIX-style protected service whose AppContainer-flavoured identity is the Package SID derived from its Microsoft-signed manifest. Other processes that want to ask Hello to verify a face or a fingerprint must talk to the broker, and the broker decides whether to honour the request based partly on the caller's package identity. The reason this matters is the same as the LSASS reason: the secret material the broker holds (the user's TPM-bound private key) needs a principal that an attacker holding a SYSTEM token cannot impersonate. User-SID equality is not enough. Package-SID equality is.

The 8wekyb3d8bbwe suffix you see on Calculator, Edge, the Microsoft Store, and most other in-box apps is Microsoft Corporation's PublisherId. Once you know what it is, you start seeing it everywhere -- it is the cryptographic fingerprint of "Microsoft signed this package" [@ms-package-identity].

The aha is the same shape as the PPL aha but at the layer above. Two binaries running as the same user can be authorised differently because the Package SID is derived from the manifest publisher and the package cannot forge it. AppContainer is not a sandbox you opt into. It is a SID you have. Capability ACLs name that SID. The firewall keys on it. The MIC label composes with it. The broker checks it.

The limits are also visible. AppContainer is opt-in for Win32 desktop apps that have not been packaged. Forshaw's 2021 Project Zero analysis of the AppContainer firewall identified loopback-exemption and namespace-isolation holes that Microsoft classified as WontFix [@p0-appcontainer]. Per-app sandbox identity solves the Modern-app problem; it does not solve the legacy Win32 problem. For that, the operating system needs a policy plane that names code in publisher vocabulary instead of path vocabulary.

What does an enterprise admin do when the application refuses to be packaged at all?

The policy plane: AppLocker, App Control, and the publisher rule

Path-based whitelisting failed for the same reason path-based ACLs failed. Anything writeable can be planted. AppLocker, shipped in Windows 7 in 2009, still stays in the box for compatibility, but Microsoft's own documentation recommends App Control for Business -- the rebranded Windows Defender Application Control -- for new deployments [@ms-applocker] [@ms-appcontrol]. The change is not cosmetic. It is the difference between filename-as-identity and Authenticode-publisher-as-identity.

A Code Integrity policy mechanism that expresses allow and deny rules in Authenticode-publisher vocabulary. Policies are authored in XML, compiled to a binary `siPolicy.p7b`, and enforced by the Code Integrity engine at every PE load. With HVCI active, enforcement happens inside the Hyper-V-protected secure kernel, immune to a compromised NT kernel [@ms-appcontrol].

The certificate-and-publisher rule levels run from strictest to broadest as Hash > FileName > FilePath > FilePublisher > SignedVersion > LeafCertificate > Publisher > PcaCertificate, with a parallel WHQL-only family for kernel drivers ordered WHQLFilePublisher > WHQLPublisher > WHQL [@ms-appcontrol]. Hash is the strictest (this exact byte string); PcaCertificate is the broadest signer-based level (anything signed under that intermediate CA). Microsoft documents RootCertificate as not supported, and FilePath -- available for user-mode binaries from Windows 10 1903 onward -- is path-based and so inherits the failure modes the publisher-rule model was designed to escape.

The LeafCertificate > Publisher adjacency is the subtle one. LeafCertificate pins to one specific signing certificate, so a renewal under a new leaf cert no longer matches. Publisher matches any certificate with the same PCA + leaf-CN combination, including future renewals. LeafCertificate is the stricter of the two [@ms-appcontrol].

The practical sweet spot is FilePublisher. It binds an allow rule to the tuple (certificate authority + leaf publisher CN + original filename + minimum version). That tuple survives recompiles: a benign update from the same publisher under the same name, signed by the same key, with a higher version still passes. It does not survive tampering. Change the original filename in the resource section, change the publisher, change the leaf certificate, and the rule no longer matches.

Policy primitive	Era	Rule basis	Kernel coverage	Default state
Software Restriction Policies (SRP)	XP, 2001	path / hash / certificate	none	unmanaged
AppLocker	Windows 7 Enterprise, 2009	path / publisher / hash	none	off
WDAC (Device Guard)	Windows 10, 2015	publisher / file attributes / hash	full (with HVCI)	off
App Control for Business	renamed 2023	publisher / file attributes / hash	full (with HVCI)	off; on by default in S Mode and on Windows 11 SE

The Code Integrity engine evaluates an App Control policy on every PE load -- user mode and kernel mode alike. With HVCI active, the policy lives behind the Hyper-V security boundary; even an NT-kernel-level attacker with arbitrary memory write cannot edit it without breaking out of the virtualization layer [@ms-appcontrol]. Deny rules always win; an explicit deny can never be undone by any number of allows on the same binary.

Note: Author every App Control policy in audit mode for at least one full reference-image cycle before promoting to enforce. Audit mode logs every load that would have been blocked, into the Microsoft-Windows-CodeIntegrity/Operational event channel, without breaking anything. The pre-deployment failure rate of strict policies on real fleets is high enough that audit mode is not optional [@ms-appcontrol].

App Control inherits the same structural ceiling Authenticode put in place. Allow Signer = Microsoft Windows admits the entire LOLBins inventory -- regsvr32, mshta, installutil, rundll32, every signed-by-Microsoft binary an attacker can call to execute arbitrary content. Allow Signer = ASUSTeK would have admitted ShadowHammer (operation 2018, disclosed 2019), every byte of which carried a valid ASUS production signature [@securelist-shadowhammer]. The publisher-rule model is the right primitive for managed endpoints, and the LOLBins / supply-chain-attack failure modes are the structural ceiling on what the primitive can prove.

PKI-rooted publisher policy still trusts the publisher's key custody. When the key is stolen or the binary is signed but malicious, what does the operating system fall back on?

Reputation as identity: Mark of the Web and SmartScreen

A novel binary, signed by a freshly issued EV cert, has zero history. PKI says yes. Reputation says: I have never seen this before -- run it past the user.

An NTFS alternate data stream named `Zone.Identifier` written by browsers, mail clients, and other downloaders to record the trust zone of a downloaded file. The stream contains an INI-style `[ZoneTransfer]` block with `ZoneId=3` for files from the public internet, plus optional `ReferrerUrl=` and `HostUrl=` fields. The protocol is documented in the MS-FSCC reference [@ms-fscc-motw]. SmartScreen, Office Protected View, and the Attachment Execution Service all read MOTW to gate behaviour on origin.

MOTW is not an Authenticode replacement. It is a parallel, origin-based identity: the binary's provenance, encoded as data the file system carries with it, separate from any signature. Origin is the input to SmartScreen. SmartScreen submits a hash of the binary together with publisher metadata to a Microsoft-hosted reputation service; if the service has not seen the binary before, or has not seen enough downloads to be confident, the user gets the familiar "Windows protected your PC" prompt that requires an explicit More info / Run anyway click [@learn-smartscreen].

The pipeline is parallel to Authenticode and App Control, not a successor. PKI says "this signature chains to a real publisher." Reputation says "this hash has been observed N times in the last 30 days, with prevalence trending up; the publisher account is six years old; M of the downloads were from machines later flagged for malware." None of those signals are derivable from a signature.The Defender machine-learning pipeline that powers SmartScreen reputation is the deeper version of the same idea -- already covered in The Defender's Dilemma sibling article, which traces the twenty-year arc from Defender's 0.5/6 AV-TEST score to its 100% MITRE detection rate. The reputation primitive sits on top of that ML pipeline.

The bypass surface is now well-known. Container formats (ISO, IMG, VHD, 7z) historically did not propagate MOTW to files extracted from them, because their on-disk representation does not preserve alternate data streams. Phishing campaigns adapted: send the attacker's .exe inside an .iso, the user mounts the .iso, double-clicks the .exe, and SmartScreen sees a binary with no MOTW and offers no warning.

Microsoft's response combined fixes -- VHD and ISO MOTW propagation shipped in the December 2022 cumulative update for Windows 11 22H2, MOTW-aware extraction in OneDrive and the new Windows Archive APIs -- with two attack-surface-reduction rules that gate execution on prevalence and trust independently of MOTW [@learn-asr-reference]. The most useful is rule 01443614-cd74-433a-b99e-2ecdc07bfc25, "Block executable files from running unless they meet a prevalence, age, or trusted list criterion."

Office is the most consequential consumer of MOTW. A Word, Excel, or PowerPoint file carrying a ZoneId=3 Mark of the Web opens in Protected View: read-only, in a sandboxed renderer, with macros and active content disabled, until the user clicks "Enable Editing" on the message bar [@learn-protected-view].

The 2022 wave of HTML-smuggling and ISO-borne malware that bypassed SmartScreen still tripped over Protected View at the document layer, and the post-2022 macro-blocked-by-default change extended the same MOTW-gated logic from container files to embedded VBA. Origin is now an input to two parallel pipelines: SmartScreen's reputation check on the executable, and Office's read-only-until-confirmed gate on the document.

The full ASR rule GUIDs are in the Defender for Endpoint reference. Memorise none of them; pin the page.

A useful way to read the layered system at this point: Authenticode answered "who shipped it?" KMCS answered "is the kernel allowed to load it?" PPL answered "is this running process allowed to touch that one?" AppContainer answered "what application is this?" App Control answered "does the enterprise honour this publisher?" MOTW and SmartScreen answer the question PKI cannot: "have we seen this before, and from where?" When PKI identity is necessary but not sufficient, reputation closes the gap -- statistically, never absolutely.

PKI says yes; reputation says unknown. What does the operating system do when Microsoft itself says no to a signature it just minted?

The breakthrough: signed is not trusted (Driver Block List, 2022)

December 8, 2021. Microsoft launches the Vulnerable and Malicious Driver Reporting Center [@msft-driver-reporting]. The blog post enumerates the failure shape that drove it: drivers that "map arbitrary kernel, physical, or device memory to user mode," drivers that "provide access to storage that bypass Windows access control," drivers whose IOCTLs let a local admin become an arbitrary kernel writer. Every one of those drivers was signed. Every one of those signatures was valid. Every one of those binaries was loadable on a default Windows install.

By the Windows 11 22H2 update in September 2022, the Vulnerable Driver Block List was enabled by default [@msft-driver-blocklist]. The mechanism is a Microsoft-curated SiPolicy.p7b (the same WDAC binary policy format), distributed through Windows Update and Defender intelligence updates, enforced by the Code Integrity engine -- with HVCI when present -- at every driver load. The published rules deny drivers by publisher, original filename, and hash. Critically, the publisher's signature is still valid. The Block List is an explicit Microsoft veto layered on top of a working PKI verdict.

The blocklist included in this article ... usually contains a more complete set of known vulnerable drivers than the version in the OS and delivered by Windows Update. -- Microsoft Learn, *Microsoft recommended driver block rules* [@msft-driver-blocklist]

That sentence, in Microsoft's own documentation, is the breakthrough. Microsoft is openly admitting that the version of the list shipped with the operating system trails the curated reference list. Curation is now a continuous, asynchronous activity, distinct from signing. The list ships on a quarterly cadence. New BYOVD drivers ship faster than that. The LOLDrivers community catalogue tracks hundreds of vulnerable drivers, many of which are not (yet) on Microsoft's list [@loldrivers].

The Block List has a write-time companion. ASR rule 56a863a9-875e-4185-98a7-b882c64b5ce5, "Block abuse of exploited vulnerable signed drivers," prevents writing a known-vulnerable driver to disk in the first place [@learn-asr-reference]. The defence is layered: the Block List denies load; the ASR rule denies install; together they form a curtain across the BYOVD attack class. Together they do not close the BYOVD class -- the catalogue is a list, the threat is a set, and the gap is structural.

Key idea: A signature attests who. A reputation score attests unfamiliar versus seen-good. A block list attests Microsoft has revoked trust at runtime, even though the signature still verifies. These are three distinct identity layers, and 2022 is the year all three were finally co-deployed by default on the same operating system.

Note: "Curated identity at runtime" is the conceptual breakthrough. "Quarterly cadence" is its operational ceiling. The Driver Block List is a list, the BYOVD threat is a set, and the gap between them is the open problem the next layer (Pluton + attestation + faster curation pipelines) is being asked to close.

The Driver Block List is the operational expression of a 25-year admission. After 1996's "the new Microsoft Authenticode technology uniquely identifies the publisher," after Vista's "we will refuse unsigned kernel drivers," after Windows 8.1's "signer level mediates inter-process access," after Windows 10's "App Control names policy in publisher vocabulary," Microsoft's December 2021 blog post said something different. It said: a signature is a publisher claim; trust is a different claim; we, Microsoft, will curate the second claim continuously, even when we ourselves issued the first one. Identity has become curated, not just verified.

If even Microsoft can no longer trust a valid signature, where does trust ultimately have to live?

The 2026 stack and the hardware future

The eight primitives from the previous sections do not run in isolation. They compose. A modern Windows boot -- on a Pluton-equipped 2026 laptop running Windows 11 24H2 with HVCI on, App Control in enforce mode, Smart App Control on, and Microsoft Defender as the active anti-malware -- evaluates code identity continuously, top to bottom, from firmware through user mode.

flowchart LR A["UEFI Secure Boot
firmware-rooted PKI"] --> B["Pluton / TPM
measured boot, PCRs"] B --> C["KMCS
chain-to-Microsoft"] C --> D["Driver Block List
Microsoft curated veto"] D --> E["ELAM
signer-level boot gate"] E --> F["User-mode Authenticode
publisher attribution"] F --> G["PPL signer-level
runtime ACL"] G --> H["AppContainer + Package SID
per-app principal"] H --> I["App Control for Business
publisher policy"] I --> J["MOTW + SmartScreen
origin + reputation"] J --> K["Pluton attestation
device-identity claim"]

The hardware root has shifted in five years. Pluton, announced on November 17, 2020 by Microsoft together with AMD, Intel, and Qualcomm, is a security processor integrated into the CPU die rather than a discrete TPM chip on the motherboard bus [@ms-pluton-blog]. AMD Ryzen 6000-series and later (including Ryzen AI), Intel Core Series 3, Core Ultra Series 3, and Core Ultra 200V, and Qualcomm Snapdragon 8cx Gen 3 and Snapdragon X Series ship Pluton as the on-die TPM. Pluton's firmware is updated through Windows Update -- not through OEM-controlled SPI flash patches -- and Microsoft started delivering Rust-based Pluton firmware on 2024 AMD and Intel systems, with broader rollout ongoing [@learn-pluton].

The architectural significance is twofold. The trust root is no longer a chip with its bus exposed to a trace-and-sniff attacker. The firmware update path is now a Microsoft-controlled channel rather than thirty different OEM-controlled channels. The same hardware root is what BitLocker depends on when it seals the Volume Master Key to a measured boot chain via TPM PCRs [@ms-bitlocker]. On Pluton, those PCR measurements live in-die rather than on a bus-exposed chip, and the sibling article BitLocker on Windows traces what that buys and what it does not.

Apple Gatekeeper plus Notarization is a single-CA model. All Mac binaries that pass Gatekeeper are notarized by Apple, scanning happens server-side, and Apple's own notary signature is the trust root [@apple-gatekeeper]. Linux IMA-Appraisal expresses code identity as a per-host keyring of cryptographic measurements; the kernel evaluates a load against a policy stored in the same keyring [@linux-ima]. Android APK Signature Scheme v3 binds the APK to a per-app signing key with an explicit proof-of-rotation chain that lets a publisher rotate keys without breaking the app's identity [@apksigning-v3]. Windows is the only one of the four that accepts third-party CAs in user mode while reserving Microsoft roots for the kernel. The cost of pluralism is exactly the long tail of failure modes this article enumerates; the benefit is the freedom every Windows ISV has used since 1996 to ship without asking Microsoft's permission.

Then came July 19, 2024.

CrowdStrike's Falcon kernel driver loaded a malformed Channel File 291 update that triggered an out-of-bounds memory read inside csagent.sys and raised an invalid page fault [@msft-crowdstrike-best-practices], bug-checking roughly 8.5 million Windows endpoints simultaneously [@ms-crowdstrike-blog]. The driver was correctly Microsoft-signed through the Hardware Developer Center attestation pipeline. Every code-identity layer in the stack -- KMCS, the cross-cert, the EV cert, the attestation key, even the Block List -- said yes. The thing that went wrong was not identity. It was that an identity-blessed driver, running in kernel mode, can fail in ways that take entire continents offline.

Note: The CrowdStrike outage proves that a correctly-signed, attested kernel driver is still a planet-scale liability if its placement is wrong. Identity is not the only dimension. Where in the privilege hierarchy a binary runs is itself a dimension that signing cannot capture.

Microsoft's reaction was structural. On September 12, 2024, David Weston published the recap of the September 10 WESES summit Microsoft had hosted with its endpoint-security partners, committing to provide "additional security capabilities outside of kernel mode" so that EDR vendors could run their detection logic in user mode [@weston-2024].

On June 26, 2025, the Windows Resiliency Initiative announced a private preview of the new endpoint security platform, scheduled for July 2025 delivery to selected MVI partners: Bitdefender, CrowdStrike, ESET, and SentinelOne [@weston-2025]. CrowdStrike's representative was Alex Ionescu, now its Chief Technology Innovation Officer -- the same Alex Ionescu whose 2013 Breakpoint talk publicly mapped PPL signer levels. The arc had closed in twelve years.

MVI 3.0 -- the Microsoft Virus Initiative, version three -- adds Safe Deployment Practices as a contractual condition: staged rollouts, deployment rings, monitoring. The same playbook Microsoft itself follows for Windows updates after the 2024 outage [@msft-crowdstrike-best-practices].

The conceptual move is the same one PPL made in 2013, projected one layer higher. Then: identity becomes a runtime ACL between processes. Now: identity-bound placement (kernel mode versus user mode) becomes a trust dimension co-equal with identity-bound signing. The question is no longer "is this driver signed and on the allow list?" The question is "should code with this identity be running in this context at all?"

If even attested, signed, blessed kernel code can fail catastrophically, what could code identity in principle ever prove -- and what is provably out of reach?

Theoretical bounds and open problems

Two papers from the 1980s bound everything that followed.

Fred Cohen's 1984 paper at IFIP-Sec, republished in Computers & Security in 1987, proved that perfect virus detection is undecidable: there is no algorithm that, given an arbitrary program, can decide whether it is a virus [@cohen-1986]. Reputation systems are necessarily heuristic. The "first 1,000 downloads" gap -- the window where SmartScreen has not yet seen enough of a new binary to be confident -- is structural, not a tuning problem. You cannot close it by waiting harder.

Ken Thompson's 1984 ACM Turing Award lecture, "Reflections on Trusting Trust," made a different point about a different layer [@thompson-trusting-trust]. Thompson exhibited a compiler that, when used to build itself, inserted a backdoor into a target program; when used to build the compiler, propagated the backdoor invisibly to the next-generation binary. Signing what the compiler emitted never proved the compiler was unmodified. SLSA Level 3+ provenance, reproducible builds, hermetic build environments [@slsa-spec] push the bound back one level. They do not eliminate it.

A third bound is Authenticode-specific. Asynchronous revocation, the property that lets pre-revocation timestamped signatures continue to verify forever, is the reason Stuxnet's drivers loaded after Realtek's certificate was revoked, and the reason every other stolen-key compromise has a window of cryptographic legitimacy [@symantec-stuxnet]. Synchronous global revocation would invalidate large catalogs of legitimate, archived, signed software whose signing certs have since expired. There is no fix inside the design.

Pulled together, these bounds explain the persistent gap. Stolen-but-not-yet-revoked publisher keys are the same failure mode replayed three times in sixteen years: Stuxnet (2010, Realtek and JMicron), ASUS ShadowHammer (operation 2018, disclosed 2019, ASUSTeK production key), Bitwarden CLI (2026, npm publishing credential). The Pluton firmware-update pipeline is the most credible architectural response yet -- a Microsoft-controlled key-rotation channel that does not depend on OEM-side custody -- but it does not eliminate the class. It compresses the response window.

The other open problem is identity for non-PE artifacts. The Authenticode hash and the WDAC publisher rule were designed for Portable Executable files; everything else gets uneven coverage. PowerShell .ps1 scripts can be signed and gated through Constrained Language Mode, which the runtime enters automatically when an AppLocker or App Control policy is in force [@learn-clm]. .NET assemblies have strong-name signatures, separate from Authenticode and explicitly not a security boundary; Microsoft's own documentation warns "do not rely on strong names for security" [@learn-strong-name].

JIT-compiled code -- the most common shape of "code" in 2026 -- is signed only insofar as the JIT host is signed. The JIT itself produces unsigned bytes. Container images, WSL guests, AI model files, and (now) agent prompts all live outside the Authenticode universe entirely. Each is its own substrate, with its own emerging signing scheme, and the unification has not happened.

$$\text{trust}_{2026}(\text{binary}) = \text{publisher}(\text{binary}) \land \text{provenance}(\text{build}) \land \text{placement}(\text{runtime}) \land \text{reputation}(\text{telemetry}) \land \neg \text{revoked}(\text{Microsoft})$$

That conjunction is the 2026 verdict. None of its terms are sufficient on their own. Each was forced into existence by a failure of the term before. The arc from "who launched this thread?" in 1993 to that conjunction in 2026 is what thirty-three years of forced moves produced.

What does the layered system look like in practice on a 2026 endpoint -- and what should an admin actually do?

Practical guide

Six concrete recommendations for a 2026 Windows fleet, each tied to a primary Microsoft Learn or MSRC source.

Note: On Windows 11 22H2 and later it is enabled by default. On Windows 10, Server, and downlevel Windows 11 builds, enable it explicitly through Settings > Privacy & security > Windows Security > Device security > Core isolation > Microsoft Vulnerable Driver Blocklist. HVCI must be on for full enforcement [@msft-driver-blocklist].

Note: The published Microsoft baseline policies (Default Windows, Allow Microsoft, the Windows S Mode policy) are the right starting points. Run any custom policy in audit mode for a full reference-image cycle, mine the Microsoft-Windows-CodeIntegrity/Operational event log for blocked loads, then promote to enforce. Pair with HVCI so the policy lives behind the secure-kernel boundary [@ms-appcontrol]. Deploy through Microsoft Intune (or your MDM of choice), Configuration Manager, or Group Policy -- App Control policy distribution is a first-class managed-endpoint scenario rather than a per-machine hand edit [@learn-appcontrol-deployment].

Note: On Secure Boot systems the value is mirrored into a UEFI variable, so registry-only attackers cannot turn it off. Verify with Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name RunAsPPL and the corresponding RunAsPPLBoot UEFI variable [@itm4n-runasppl].

Note: SmartScreen alone is bypassed by container-format MOTW stripping. Pair it with ASR rule 01443614-cd74-433a-b99e-2ecdc07bfc25, which gates execution on prevalence, age, or a trusted list, independently of MOTW [@learn-smartscreen] [@learn-asr-reference].

Note: The Package SID is a free identity for any internal app you ship as MSIX. ACL sensitive resources to it, declare capabilities explicitly in the manifest, and let the AppContainer SID enforce the ACL at the kernel boundary [@ms-package-identity] [@ms-msix].

Note: Treat your code-signing key like a credential, not a build artifact. Rotate the EV cert, revoke the old one, notify customers, and -- if the binary already shipped -- request the offending hash on the Driver Block List or the ASR rule [@msft-driver-reporting]. The Bitwarden CLI 2026 incident took 93 minutes from release to containment, with rollback continuing for several hours afterward [@bitwarden-statement]; have the playbook ready before you need it.

```js function loadDecision({ signed, signerLevel, motwed, onBlockList, allowedByAppControl, smartScreenVerdict }) { if (onBlockList) return 'BLOCK -- Microsoft veto, signature ignored'; if (signed === false && allowedByAppControl === false) return 'BLOCK -- unsigned, App Control denies'; if (signerLevel === 'WinTcb' || signerLevel === 'WinSystem') return 'LOAD -- protected process'; if (allowedByAppControl === false) return 'BLOCK -- App Control deny'; if (motwed && smartScreenVerdict === 'unknown') return 'WARN -- SmartScreen, user gate'; if (motwed && smartScreenVerdict === 'malicious') return 'BLOCK -- SmartScreen'; return 'LOAD'; } console.log(loadDecision({ signed: true, signerLevel: 'Authenticode', motwed: true, onBlockList: false, allowedByAppControl: true, smartScreenVerdict: 'good', })); ``` The decision tree is the practical mental model. Every branch of it is the consequence of one of the failures this article tracks. No. A signature attests *publisher identity* and *binary integrity*. It does not attest safety. Microsoft trust is a separate, runtime claim expressed through the Driver Block List, App Control policies, and Defender reputation -- evaluated continuously, even on signatures Microsoft itself once minted [@msft-driver-blocklist]. Extended Validation Authenticode signing vets organisational identity through an audited issuance process and mandates that the private key live in a hardware security module; the publisher's signature is the trust root. Attestation signing is Microsoft's lighter-weight pipeline for kernel drivers: the publisher submits an EV-signed binary to the Hardware Developer Center, Microsoft re-signs with its own attestation key, and the result is delivered back. Attestation-signed drivers are not WHQL tested and are not distributed via retail Windows Update [@learn-driver-signing-offerings] [@ms-attestation-signing]. MOTW plus low prevalence. SmartScreen sees a binary it has not observed enough times in the global telemetry to be confident, on a file marked as having been downloaded from the internet. Sign the binary with an EV certificate, accumulate downloads on a stable hash, and the warning fades. Internal binaries can have MOTW stripped at deployment time if your distribution channel is itself trusted [@learn-smartscreen]. No. AppLocker is the Windows 7-era policy mechanism with rules in path/publisher/hash form, no kernel coverage, and no virtualization-based protection of the policy itself. App Control for Business -- formerly Windows Defender Application Control -- is the publisher-rule Code Integrity policy mechanism with HVCI enforcement at the kernel boundary. Microsoft recommends App Control for new deployments and keeps AppLocker for compatibility [@ms-applocker] [@ms-appcontrol]. LSASS is running as a Protected Process Light at the `Lsa` signer level. Signer-level gating sits *above* the token DACL check. Even a SYSTEM-token caller with `SeDebugPrivilege` gets a process handle with `PROCESS_VM_READ` and `PROCESS_VM_WRITE` stripped, because PPL strips access masks before the DACL evaluation. Disable LSA Protection (`RunAsPPL=0`) on a test machine and the same call succeeds [@itm4n-runasppl] [@scrt-ppl-bypass]. Only if the publisher's signing-key custody and build pipeline are themselves uncompromised. Stuxnet (stolen Realtek and JMicron keys, 2010), ASUS ShadowHammer (compromised production signing pipeline, operation 2018 / disclosed 2019), and the Bitwarden CLI npm incident (2026) all produced cryptographically valid signatures on attacker-controlled bytes [@symantec-stuxnet] [@securelist-shadowhammer] [@bitwarden-statement]. SLSA-level build provenance and Pluton-rooted attestation are the architectural responses; neither is yet universally deployed [@slsa-spec] [@learn-pluton].

Where this is going

Pluton-rooted device attestation, MVI 3.0's user-mode security platform, SLSA build provenance, and the post-CrowdStrike push to make placement a first-class identity attribute are all in motion in 2026 [@weston-2025] [@slsa-spec]. The follow-on articles -- Driver Block List in production, App Control with HVCI on real fleets, Secure Boot internals, the Pluton firmware-update channel -- are the operational complement to the conceptual story this article has told.

The arc that began with Windows NT 3.1 having no answer to "who is this code?" now has eight overlapping answers, each insufficient on its own. Identity in 2026 is a multi-layered claim about a binary's publisher, its build provenance, its runtime placement, and its reputation, evaluated continuously while the code is running. The arc from 1993's "who launched this thread?" to 2026's "is this signed binary, in this placement, with this build provenance, on Microsoft's curated honour list, today, on this hardware-attested device?" is the answer thirty-three years of forced moves produced -- and the question the next thirty-three years will keep asking, because none of the bounds Cohen and Thompson proved have moved.