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

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 and patched on Microsoft's November 2022 Patch Tuesday, the same day CISA added it to the Known Exploited 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.

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 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 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 -- a small integer table whose five named defaults put every URL into one of five buckets. The buckets are still in urlmon.h today:

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

The MS-FSCC Zone.Identifier reference 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 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 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 -- 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 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, which shipped with Internet Explorer 7 on October 18, 2006. 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 when Internet Explorer 8 shipped on March 19, 2009 and then SmartScreen Application Reputation in Internet Explorer 9 (announced 2010, shipped March 14, 2011). The Elastic Security Labs writeup 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, the PE-embedded code-signing scheme that shipped with Internet Explorer 3 in August 1996 and is formally specified by the 2008 Windows Authenticode Portable Executable Signature Format. 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 -- 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 on the ADS name. The Outflank post enumerated the operational gaps and the SANS Internet Storm Center diary by Didier Stevens 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, and the reputation-for-developers page 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 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 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.

Google Threat Analysis Group's Benoit Sevens published the canonical pseudocode reconstruction 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 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; the community-maintained archiver-MOTW-support-comparison matrix on GitHub 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 -- 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 quoted Microsoft's Bill Demirkapi confirming the propagation root cause.
• Internet Shortcut .url handling (November 2023). CVE-2023-36025, exploited in the Phemedrone Stealer campaign that Peter Girnus, Aliakbar Zahravi, and Simon Zuckerbraun documented in a Trend Micro Research writeup. 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 on the in-the-wild exploitation gives the practitioner context.
• Shortcut chains (February 2024). CVE-2024-21412 -- a .url pointing at another .url (typically on an attacker-controlled WebDAV share). Trend Micro's Water Hydra writeup by Peter Girnus documented the use of this chain to deliver the DarkMe RAT to financial-market traders, with the DarkGate companion writeup covering a parallel campaign. BleepingComputer's coverage records the February 13 patch date.
• Shortcut chains, again (April 2024). CVE-2024-29988 and 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 and Help Net Security covered the joint April-2024 disclosure.
• LNK extended-path stomping (September 2024). CVE-2024-38217, disclosed by Joe Desimone of Elastic Security Labs as part of the 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 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 (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 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:

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.

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 falling through to a catalog lookup via 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.

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

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. 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. The AppDefinedZoneId and LastWriterPackageFamilyName keys, added in the Windows 10 era, are on the IZoneIdentifier2 reference.

The supported write surface is IAttachmentExecute, defined in shobjidl_core.h. Microsoft Learn's interface reference 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=<origin page URL>
HostUrl=<payload URL>
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 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 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. 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 and the current PE Format reference 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 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 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, 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" -- 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 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."

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 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 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) and dpkg / APT (1994-1998) 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 (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.

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.

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 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) addressed -- and is therefore exactly where the next propagator bug will live.

Smart App Control silently disabling itself#

Microsoft Learn's SAC 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 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, 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 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 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 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 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.

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.

11. Frequently Asked Questions#

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.