# Mark of the Web, SmartScreen, and the Catalog of Trust: How Windows Decides Whether to Warn You
> How Windows stacks three trust layers -- origin, reputation, and signed catalog -- and why the 2022-2024 SmartScreen bypass arc was always a propagation bug, never a cryptography bug.
*Published: 2026-05-13*
*Canonical: https://paragmali.com/blog/mark-of-the-web-smartscreen-and-the-catalog-of-trust-how-win*
*License: CC BY 4.0 - https://creativecommons.org/licenses/by/4.0/*
---
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](https://nvd.nist.gov/vuln/detail/CVE-2022-41091) and patched on Microsoft's November 2022 Patch Tuesday, the same day [CISA added it to the Known Exploited Vulnerabilities catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2022-41091). 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](https://nvd.nist.gov/vuln/detail/CVE-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](https://learn.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/compatibility/ms537628(v=vs.85)) 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:
```
```
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](https://learn.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/ms537175(v=vs.85)) -- 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](https://learn.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/ms537133(v=vs.85)). "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](https://learn.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/ms537183(v=vs.85)) 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](https://support.microsoft.com/en-us/topic/information-about-the-attachment-manager-in-microsoft-windows-c48a4dcd-8de5-2af5-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](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/6e3f7352-d11c-4d76-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:
1. **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.
2. **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).
3. **The [`IZoneIdentifier`](https://learn.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/ms537032(v=vs.85)) 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`](https://learn.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/mt243886(v=vs.85)) -- 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=
HostUrl=
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](https://learn.microsoft.com/en-us/microsoft-365-apps/security/internet-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](https://learn.microsoft.com/en-us/windows/security/operating-system-security/virus-and-threat-protection/microsoft-defender-smartscreen/), which shipped with [Internet Explorer 7 on October 18, 2006](https://en.wikipedia.org/wiki/Internet_Explorer_7). 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](https://learn.microsoft.com/en-us/windows/security/operating-system-security/virus-and-threat-protection/microsoft-defender-smartscreen/) when [Internet Explorer 8 shipped on March 19, 2009](https://en.wikipedia.org/wiki/Internet_Explorer_8) and then [SmartScreen Application Reputation](https://www.elastic.co/security-labs/dismantling-smart-app-control) in [Internet Explorer 9 (announced 2010, shipped March 14, 2011)](https://en.wikipedia.org/wiki/Internet_Explorer_9). The Elastic Security Labs writeup [*Dismantling Smart App Control*](https://www.elastic.co/security-labs/dismantling-smart-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.
Microsoft already had a publisher signal in 1996 -- [Authenticode](https://en.wikipedia.org/wiki/Code_signing), the PE-embedded code-signing scheme that shipped with [Internet Explorer 3 in August 1996](https://en.wikipedia.org/wiki/Internet_Explorer_3) and is formally specified by the [2008 *Windows Authenticode Portable Executable Signature Format*](https://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/Authenticode_PE.docx). 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*](https://www.outflank.nl/blog/2020/03/30/mark-of-the-web-from-a-red-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`](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-deletefilew) on the ADS name. The Outflank post enumerated the operational gaps and the [SANS Internet Storm Center diary by Didier Stevens](https://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](https://learn.microsoft.com/en-us/windows/security/operating-system-security/virus-and-threat-protection/microsoft-defender-smartscreen/), and the [reputation-for-developers page](https://learn.microsoft.com/en-us/windows/apps/package-and-deploy/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](https://threatresearch.ext.hp.com/magniber-ransomware-switches-to-javascript-targeting-home-users-with-fake-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](https://blog.0patch.com/2022/10/free-micropatches-for-bypassing-motw.html) 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](https://nvd.nist.gov/vuln/detail/CVE-2022-44698).
Google Threat Analysis Group's Benoit Sevens published [the canonical pseudocode reconstruction](https://blog.google/threat-analysis-group/magniber-ransomware-actors-used-a-variant-of-microsoft-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](https://nvd.nist.gov/vuln/detail/CVE-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](https://isc.sans.edu/diary/28810); the community-maintained [archiver-MOTW-support-comparison matrix on GitHub](https://github.com/nmantani/archiver-MOTW-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](https://nvd.nist.gov/vuln/detail/CVE-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](https://www.bleepingcomputer.com/news/microsoft/microsoft-fixes-windows-zero-day-bug-exploited-to-push-malware/) quoted Microsoft's Bill Demirkapi confirming the propagation root cause.
- **Internet Shortcut `.url` handling (November 2023).** [CVE-2023-36025](https://nvd.nist.gov/vuln/detail/CVE-2023-36025), exploited in the Phemedrone Stealer campaign that Peter Girnus, Aliakbar Zahravi, and Simon Zuckerbraun documented [in a Trend Micro Research writeup](https://www.trendmicro.com/en_us/research/24/a/cve-2023-36025-exploited-for-defense-evasion-in-phemedrone-steal.html). 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](https://www.bleepingcomputer.com/news/security/windows-smartscreen-flaw-exploited-to-drop-phemedrone-malware/) on the in-the-wild exploitation gives the practitioner context.
- **Shortcut chains (February 2024).** [CVE-2024-21412](https://nvd.nist.gov/vuln/detail/CVE-2024-21412) -- a `.url` pointing at another `.url` (typically on an attacker-controlled WebDAV share). Trend Micro's [Water Hydra writeup](https://www.trendmicro.com/en_us/research/24/b/cve202421412-water-hydra-targets-traders-with-windows-defender-s.html) by Peter Girnus documented the use of this chain to deliver the DarkMe RAT to financial-market traders, with the [DarkGate companion writeup](https://www.trendmicro.com/en_us/research/24/c/cve-2024-21412--darkgate-operators-exploit-microsoft-windows-sma.html) covering a parallel campaign. [BleepingComputer's coverage](https://www.bleepingcomputer.com/news/security/hackers-used-new-windows-defender-zero-day-to-drop-darkme-malware/) records the February 13 patch date.
- **Shortcut chains, again (April 2024).** [CVE-2024-29988](https://nvd.nist.gov/vuln/detail/CVE-2024-29988) and [ZDI-24-361](https://www.zerodayinitiative.com/advisories/ZDI-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](https://www.bleepingcomputer.com/news/microsoft/microsoft-fixes-two-windows-zero-days-exploited-in-malware-attacks/) and [Help Net Security](https://www.helpnetsecurity.com/2024/04/09/april-2024-patch-tuesday-cve-2024-29988/) covered the joint April-2024 disclosure.
- **LNK extended-path stomping (September 2024).** [CVE-2024-38217](https://nvd.nist.gov/vuln/detail/CVE-2024-38217), disclosed by Joe Desimone of Elastic Security Labs as part of the [*Dismantling Smart App Control*](https://www.elastic.co/security-labs/dismantling-smart-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](https://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](https://blogs.windows.com/windowsexperience/2022/09/20/available-today-the-windows-11-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](https://learn.microsoft.com/en-us/windows/apps/develop/smart-app-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:
1. **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.
2. **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.
3. **The OS asks a signed catalog, *is this file's hash vouched for by a publisher Microsoft trusts?*** The answer comes from [`WinVerifyTrust`](https://learn.microsoft.com/en-us/windows/win32/api/wintrust/nf-wintrust-winverifytrust) falling through to a catalog lookup via [`CryptCATAdminCalcHashFromFileHandle`](https://learn.microsoft.com/en-us/windows/win32/api/mscat/nf-mscat-cryptcatadmincalchashfromfilehandle) 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*](https://learn.microsoft.com/en-us/windows-hardware/drivers/install/catalog-files)) and reuses the `SpcIndirectDataContent` structure defined in [the 2008 *Windows Authenticode Portable Executable Signature Format* specification](https://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/Authenticode_PE.docx).
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](https://learn.microsoft.com/en-us/windows/apps/develop/smart-app-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](https://learn.microsoft.com/en-us/windows/apps/develop/smart-app-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](https://learn.microsoft.com/en-us/windows/security/application-security/application-control/app-control-for-business/design/use-appcontrol-with-intelligent-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](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/6e3f7352-d11c-4d76-8c39-2516a9df36e8). Microsoft Edge in 2025 writes a stream that looks like this:
```
[ZoneTransfer]
ZoneId=3
ReferrerUrl=
HostUrl=
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](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/6e3f7352-d11c-4d76-8c39-2516a9df36e8). The `AppDefinedZoneId` and `LastWriterPackageFamilyName` keys, added in the Windows 10 era, are on the [`IZoneIdentifier2` reference](https://learn.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/mt243886(v=vs.85)).
The supported write surface is `IAttachmentExecute`, defined in `shobjidl_core.h`. [Microsoft Learn's interface reference](https://learn.microsoft.com/en-us/windows/win32/api/shobjidl_core/nn-shobjidl_core-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',
];
function parseZoneIdentifier(text) {
const result = {};
let inBlock = false;
for (const line of text.split(/\\r?\\n/)) {
if (line.trim() === '[ZoneTransfer]') { inBlock = true; continue; }
if (!inBlock || !line.includes('=')) continue;
const [k, ...rest] = line.split('=');
result[k.trim()] = rest.join('=').trim();
}
return result;
}
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:
1. The **file-hash signal**: SHA-256 of the file content.
2. 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](https://learn.microsoft.com/en-us/windows/apps/package-and-deploy/smartscreen-reputation) is unambiguous about one thing: EV classification is not a reputation factor (the verbatim Microsoft statement is in the PullQuote below).
3. 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](https://learn.microsoft.com/en-us/windows/security/operating-system-security/virus-and-threat-protection/microsoft-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](https://learn.microsoft.com/en-us/windows/security/application-security/application-control/app-control-for-business/design/use-appcontrol-with-intelligent-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](https://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/Authenticode_PE.docx) and the current [PE Format reference](https://learn.microsoft.com/en-us/windows/win32/debug/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](https://learn.microsoft.com/en-us/windows-hardware/drivers/install/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`](https://learn.microsoft.com/en-us/windows/win32/api/wintrust/nf-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`](https://learn.microsoft.com/en-us/windows/win32/api/mscat/nf-mscat-cryptcatadmincalchashfromfilehandle), 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;
}
function winVerifyTrust(target) {
if (target.embeddedSignature) {
return { ok: true, signer: target.embeddedSignature.signer };
}
const h = calcHash(target.name);
const cat = enumCatalogFromHash(h);
if (!cat) return { ok: false, status: 'TRUST_E_NOSIGNATURE' };
// The catalog's PKCS#7 signature has been pre-verified at this point
return { ok: true, signer: catSigner, viaCatalog: cat.catFile };
}
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"](https://learn.microsoft.com/en-us/windows/security/application-security/application-control/app-control-for-business/design/use-appcontrol-with-intelligent-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.
### 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](https://support.apple.com/guide/security/gatekeeper-and-runtime-protection-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](https://developers.google.com/safe-browsing/reference/rest/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](https://developers.google.com/safe-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)](https://rpm.org/about.html) and [dpkg](https://en.wikipedia.org/wiki/Dpkg) / [APT (1994-1998)](https://en.wikipedia.org/wiki/APT_(software)) 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](https://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.
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](https://github.com/nmantani/archiver-MOTW-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](https://blog.0patch.com/2022/10/free-micropatches-for-bypassing-mark-of.html)) addressed -- and is therefore exactly where the next propagator bug will live.
### Smart App Control silently disabling itself
[Microsoft Learn's SAC overview](https://learn.microsoft.com/en-us/windows/apps/develop/smart-app-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*](https://www.elastic.co/security-labs/dismantling-smart-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](https://learn.microsoft.com/en-us/windows/security/application-security/application-control/app-control-for-business/design/use-appcontrol-with-intelligent-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:
```powershell
# 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):
```powershell
$content = @"
[ZoneTransfer]
ZoneId=3
HostUrl=
"@
Add-Content -Path '.\test.exe' -Stream Zone.Identifier -Value $content
```
Strip it (convenience, not a security boundary -- see Section 11):
```powershell
# 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`:
```cmd
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](https://learn.microsoft.com/en-us/windows/security/application-security/application-control/app-control-for-business/design/use-appcontrol-with-intelligent-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](https://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](https://learn.microsoft.com/en-us/windows/apps/package-and-deploy/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`](https://learn.microsoft.com/en-us/windows/win32/api/shobjidl_core/nn-shobjidl_core-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](https://learn.microsoft.com/en-us/windows/apps/package-and-deploy/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](https://learn.microsoft.com/en-us/windows/apps/package-and-deploy/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](https://chrome.google.com/webstore/detail/windows-defender-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.
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.