← All posts

Mark-of-the-Web Auditing: The Zone.Identifier Stream That Powers SmartScreen and Office Protected View

How the MOTW zone identifier ADS gates SmartScreen and Office Protected View, why attackers strip it, and how to audit MOTW enforcement on Windows.

Almost every Windows defense that fires when a user opens a downloaded file — SmartScreen reputation checks, Office Protected View, macro blocking, the "Do you want to run this?" dialog — depends on a single, invisible piece of metadata: the Mark-of-the-Web (MOTW). It is not a policy, a signature, or a reputation score. It is a tiny NTFS alternate data stream named Zone.Identifier that Windows tags onto files that came from an untrusted source. If that stream is missing, every one of those protections silently steps aside. Understanding — and auditing — where MOTW lives, how it propagates, and how attackers strip it is one of the highest-leverage things a Windows defender can do.

What MOTW actually is

When an application that supports the Attachment Manager API (browsers, mail clients, chat apps, archive tools) writes a file it received from the internet, it attaches an alternate data stream. You can see it on any downloaded file:

Get-Content .\invoice.docx -Stream Zone.Identifier

[ZoneTransfer]
ZoneId=3
ReferrerUrl=https://example.com/
HostUrl=https://example.com/invoice.docx

The critical field is ZoneId. The values map to Internet Explorer security zones that Windows still uses internally: 0 Local Machine, 1 Local Intranet, 2 Trusted Sites, 3 Internet, 4 Restricted Sites. A ZoneId of 3 or 4 is what makes SmartScreen and Office treat the file as suspicious. No stream at all means the file is treated as though it originated locally — fully trusted.

Why it matters: the whole chain hangs off one stream

MOTW is the shared trigger for a surprising number of controls:

MOTW is a single point of failure by design: one missing stream disables reputation checks, Protected View, and macro blocking all at once. That is exactly why "MOTW bypass" is a recurring theme in real-world phishing chains.

How attackers strip or dodge MOTW

Threat actors have industrialized MOTW evasion because it converts a blocked payload into a trusted one for free:

  1. Container formats that don't propagate MOTW. For years, ISO, IMG, and VHD/VHDX files mounted as virtual drives, and the files inside them did not inherit the mark. This drove the shift to ISO-delivered loaders. Microsoft has since closed several of these gaps, but legacy and third-party tools still vary.
  2. Archive tools that drop the stream. Some third-party extractors did not copy Zone.Identifier to extracted files. 7-Zip added a propagation option; many older builds and configs still lose it.
  3. Manual removal. A one-liner clears it: Unblock-File or deleting the stream directly with Remove-Item -Stream Zone.Identifier. Malware droppers do the same programmatically after writing to disk.
  4. Non-NTFS volumes. Alternate data streams are an NTFS feature. Files staged on FAT/exFAT USB media or network shares that don't preserve ADS lose the mark in transit.

Auditing MOTW posture with WinSentinel

MOTW is a per-machine, host-level control, so this is squarely in the free tier — WinSentinel runs all 64 modules with no limits on a single machine. The relevant checks look at whether the enforcement plumbing is intact rather than scanning every file on disk:

A quick manual spot-check on any endpoint tells you whether marking is even happening:

# Find recently downloaded files still carrying MOTW
Get-ChildItem $env:USERPROFILE\Downloads -Recurse -File |
  ForEach-Object {
    $z = Get-Content $_.FullName -Stream Zone.Identifier -ErrorAction SilentlyContinue
    if ($z) { [pscustomobject]@{ File=$_.Name; Zone=($z -match 'ZoneId=(\d)' | Out-Null; $Matches[1]) } }
  }

If freshly downloaded files show no Zone.Identifier at all, marking is broken somewhere in the chain — a browser policy, an extractor, or a disabled SaveZoneInformation — and that is a finding worth chasing.

Hardening recommendations

Fleet-scale drift detection

On a single machine you fix these settings once. Across an org, the harder problem is that they drift — a helpdesk exclusion here, a disabled SmartScreen policy there, a new imaging profile that ships with macro blocking off. WinSentinel Pro rolls these host-level MOTW findings up across the fleet from a central node, so you can rank machines by posture, catch the moment a node regresses from "marking enforced" to "marking disabled," and get a compliance view instead of logging into 100 endpoints. The audit runs locally on every machine; Pro is what turns those local results into fleet-wide visibility and drift alerts.

MOTW is small, quiet, and load-bearing. Auditing that the mark is written, preserved, and honored is one of the cheapest ways to keep the entire "opened a bad download" defense chain standing.