Downloads and the Mark-of-the-Web


Windows uses a simple technique to keep track of which binary files were downloaded from the Internet (or a network share).

Each downloaded file is is tagged with a hidden NTFS Alternate Data Stream file named Zone.Identifier. You can check for the presence of this “Mark of the Web” (MotW) using dir /r or programmatically, and you can view the contents of the MotW stream using Notepad:

Zone.Identifier Stream shown in Notepad

Within the file, the ZoneTransfer element contains a ZoneId element with the ordinal value of the URLMon Zone from which the file came. The value 3 indicates that the file is from the Internet Zone.

Aside: One common question is “Why does the file contain a Zone Id rather than the original URL? There’s a lot of cool things that we could do if a URL was preserved!” The answer is mostly related to privacy—storing a URL within a hidden data stream is a foot gun that would likely lead to accidental disclosure of private URLs. This problem isn’t just theoretical—the Alternate Data Stream is only one mechanism used for MotW. Another mechanism involves writing a <!–saved from url=> comment to HTML markup; that form does include a raw URL. A few years ago, attackers noticed that they could use Google to search for files containing a MOTW of the form <!—saved from url(0042) –> and collect credentials. Oops.

UpdateMicrosoft apparently either forgot or decided the tradeoff was worth it. Windows 10 includes the referrer URL, source URL and other information.

Browsers and other internet clients (e.g. email and chat programs) can participate in the MOTW-marking system by using the IAttachmentExecute interface’s methods or by writing the Alternate Data Stream directlyUpdate: Chrome uses IAttachmentExecute and thus includes the URL information on Windows 10. Firefox writes the Alternate Data Stream directly (but as of February 2021, it includes the URL).

Handling Marked Files

Windows and some applications treat files with a Mark-of-the-Web differently than those without. For instance, examining a downloaded executable file’s properties shows the following notice:

Windows Explorer Property Sheet

More importantly, attempting to run the executable using Windows Explorer or ShellExecute() will first trigger evaluation using SmartScreen Application Reputation (Win8+) and any installed anti-virus scanners. The file’s digital signature will be checked, and execution will be confirmed with the user, either using the older Attachment Execution Services prompt, or the newer UAC elevation prompt:

Authenticode AES Prompt
UAC Prompt

Microsoft Office documents bearing a MotW open in Protected View, a security sandbox that attempts to block many forms of malicious content.

Trivia: Some applications inherit protections against files bearing a MotW, but don’t have any user-interface that explains what is going on. For instance, if you download a CHM with a MotW, its HTML content will not render until you unblock it using the “Always ask before opening this file” or the “Unblock” button:

Blocked CHM file with blank HTML

What Could Go Wrong?

With such a simple scheme, what could go wrong? Unfortunately, quite a lot.

Internet Clients Must Participate

The first hurdle is that Internet clients must explicitly mark their downloads using the Mark-of-the-Web, either by calling IAttachmentExecute or by writing the Alternate Data Stream directly. Most popular clients will do so, but support is neither universal nor comprehensive.

For instance, for a few years, Firefox failed to mark downloads if the user used the Open command instead of Save.

In other cases, some browser plugins may allow attackers to save files to disk and bypass MotW tagging.

Microsoft Outlook (tested v2010) and Microsoft Windows Live Mail Desktop (tested v2012 16.4.3563.0918) both tag message attachments with a MotW you double-click on an attachment or right-click and choose Save As. Unfortunately, however, both clients fail to tag attachments if the user uses drag-and-drop to copy the attachment to somewhere in their filesystem. This oversight is likely to be seen in many different clients, owing to the complexity in determining the drop destination.

Target File System Must Be NTFS

The Zone.Identifier stream can only be saved in an NTFS stream. These streams are not available on FAT32-formatted devices (e.g. some USB Flash drives), CD/DVDs, or the new ReFS file system introduced with Windows Server 2012.

If you copy a file tagged with a MotW to a non-NTFS filesystem (or try to save it to such a file system to start with), the Mark of the Web is omitted and the protection is lost.

Originating Location Must Be Internet or Restricted Zone

The IAttachmentExecute:Save API will not write the MotW unless the URL provided in the SetSource method is in the Internet or Restricted Sites zone.

On some systems, code may have added domains to the user’s Trusted Sites zone without their knowledge.

On other systems, a proxy configuration script may cause Internet sites to be treated as belonging to the  Intranet zone.

The Attachment Execution Services API also will not write a MoTW to an Internet Zone download if that Zones’ Launching applications and unsafe files option is set to Enable. Normally, Windows will howl about this unsafe configuration, but there’s a registry key that turns off the security-settings-are-bad warning.

Not Disabled by Policy

Writing of the MoTW can be suppressed in the AttachmentExecuteServices API via Group Policy. In GPEdit.msc, see Administrative Templates > Windows Components > Attachment Manager > Do not preserve zone information in file attachments


A value of 1 will prevent the MoTW from being written to files.

Source scheme must be HTTP/HTTPS/FILE/FTP-like

If the source of the download is a data URI, the browser has no great way to know what marking to put on the file. blob URIs have a similar issue, but because blob URIs only exist within a security context (https://example can create blob:https://example/guid) you can write that security context URL as the MoTW to get proper handling.

For data URIs or other anonymous sources, writing a default of about:internet is a common conservative choice to ensure that the file was treated as if it came from the Internet Zone. Similarly, about:untrusted causes the file to be treated as originating from the Restricted Sites Zone.

Origin Laundering via Archives

One simple trick that attackers use to try to circumvent MotW protections is to enclose their data within an archive like a .ZIP, .7z, or .RAR file. Attackers may go further and add a password to block virus scanners; the password is provided to the victim in the attacking webpage or email.

In order to remain secure, archive extractors must correctly propagate the MotW from the archive file itself to each file extracted from the archive.

Despite being one of the worst ZIP clients available, Windows Explorer gets this right:

Security prompt for embedded file

In contrast, 7-zip does not reliably get this right. Malware within a 7-zip archive can be extracted without propagation of the MotW. 7-zip v15.14 will add a MotW if you double-click an exe within an archive, but not if you extract it first. The older 7-zip v9.2 does not tag with MotW either way.

Embedded Executable runs without prompt

A quick look at popular archive extractors shows:

  • Windows Explorer – Not vulnerable
  • WinRar 5.31 – Not vulnerable
  • WinZip 20.0.11649 – Not vulnerable
  • 7-Zip 15.14 – Vulnerable (bug)
  • IZArc 4.2 – Vulnerable (Developer says: “Will be fixed in next version”)

Tested another? Let me know your findings in the comments.

SmartScreen & the User May Unmark

Finally, users may unmark files using the Unblock button on the file’s Properties dialog, or by unticking the “Always ask before opening this file” checkbox. Similarly, on systems with Microsoft SmartScreen, SmartScreen itself may unmark the file (actually, it replaces the ZoneId with an (undocumented) value AppZoneId=4).

Mark-of-the-Web is valuable, but fragile.

-Eric Lawrence

Published by ericlaw

Impatient optimist. Dad. Author/speaker. Created Fiddler & SlickRun. PM @ MSFT '01-'12, and '18-, presently working on Microsoft Edge. My words are my own.

6 thoughts on “Downloads and the Mark-of-the-Web

  1. Is the UAC prompt only triggered in place of the AES prompt whenever the executable needs to elevate or are there other variables? Another neat security-related thing that Microsoft could do is updated and include the File Checksum Integrity Verifier tool with Windows.

    I know there are FOSS tools like the *sum set (md5sum, sha1sum, etc.) and HashCheck but a native OS tool with both console and graphical UIs benefits everyone.

    1. UAC replaces the Attachment Execution Services prompt only when elevating.

      Windows can natively calculate file hashes via certutil.exe -hashfile c:\Windows\system32\notepad.exe [MD2 MD4 MD5 SHA1 SHA256 SHA384 SHA512] but this is only useful if the expected hash is securely communicated (and you are able to validate the sender). Authenticode helps resolve both of those challenges.

  2. I tested it with the venerable Info-Zip unzip program (from cygwin) and it doesn’t propagate the MotW.

  3. Writing of the MoTW can be suppressed in the AttachmentExecuteServices API via

    GPEdit.msc > Administrative Templates > Windows Components > Attachment Manager > “Do not preserve zone information in file attachments”

    [HKEY_CURRENT_USER \Software \Microsoft \Windows \CurrentVersion\Policies \Attachments]
    SaveZoneInformation = 1 (On = 1, Off = 2)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: