Editor’s note: While the detection opportunities and analysis on this page are still relevant, it has not been updated since 2023. 

Why do adversaries seek to bypass the Mark-of-the-Web?

Windows uses the Mark-of-the-Web (MotW) to indicate that a file originated from the Internet, which gives Microsoft Defender SmartScreen an opportunity to perform additional inspection of the content. MotW also supplies the basis for prompting a user with an additional prompt when high-risk extensions are opened.

MotW is applied to a file by appending a Zone.Identifier Alternate Data Stream (ADS) to the downloaded file that indicates the URL, and, optionally, the referrer URL from which the file originated. Antivirus (AV) and endpoint detection and response (EDR) products can use this information to supplement their reputation lookups.

To see what MotW looks like, try downloading a file from a browser and inspect it with PowerShell. For this example, we downloaded PuTTY.

A ZoneId of 3 indicates that the file originated from the “Internet Zone.”

While browsers can write a Zone.Identifier stream manually, Microsoft provides the IAttachmentExecute interface for browsers, email clients, etc. to manage downloads where MotW is applied automatically. An example of the Chrome browser interfacing with IAttachmentExecute can be found here.

When MotW is applied to a downloaded file, there are two types of prompts a user may see: those associated with SmartScreen low-reputation executables and any file with a “high-risk” extension. The SmartScreen reputation prompt appears like so:

A prompt resulting from a “high-risk” extension appears like so:

An extension is considered high risk when the AssocIsDangerous function is called and it returns true. The AssocIsDangerous function is a wrapper for the AssocGetUrlAction function, which contains a hardcoded list of default high-risk extensions. As of this writing, the following extensions are considered high risk by default:

MotW poses a barrier to successful phishing attacks because the potential victim is offered the opportunity to deny execution. Additionally, MotW supplies SmartScreen with a hook into the registered AV engine, giving it the opportunity to perform additional signature and reputation checks. If an adversary can deliver a phishing attachment that either completely evades the additional prompt/inspection or if they can deliver a malicious extension that retains the “look and feel” of something legitimate, a victim is more likely to unwittingly enable the adversary’s initial access.

How do adversaries bypass the Mark-of-the-Web?

Adversaries have many choices available to them when deciding on an ideal file format with which to deliver their phishing payloads. Not all file formats are created equally—though when it comes to the scrutiny that security products and MotW will apply, however, an adversary has to be prudent when selecting a file format that is the most likely to slip past defenses and achieve their initial access objectives.

Adversaries make the following considerations when researching and selecting a specific phishing attachment to carry their initial access payload:

1. Is the file extension a container file format that supports file systems that are not NTFS? MotW is applied as an Alternate Data Stream (ADS), which requires an NTFS file system. ISO is an example of a container file format that doesn’t support NTFS. Other examples of container file formats that support file formats outside of NTFS are: .iso, .img, .vhd, and .vhdx. Additionally, Windows can automatically mount these file systems, so all an adversary needs their victim to do is double-click the container file and then double-click the embedded malicious file that won’t have MotW applied.
2. Does the victim have a utility that doesn’t honor MotW? A common example is 7-Zip which, until recently, did not honor MotW, and it is still only an opt-in feature.
3. Can a malicious payload be contained within a signable file format without invalidating the signature? If so, while the additional prompt will not be avoided, it is likely to circumvent reputation checks while also retaining the “look and feel” of a legitimate file signed by a reputable source. For example, CVE-2020-1599 allowed an adversary to append malicious HTA code to a PE file without invalidating the signature. Fortunately, Microsoft considers such bypasses to be serviceable bugs and patches these issues when they arise.
4. Does the file extension support the embedding/execution of malicious code that is not on the list of high-risk extensions? This situation arises on occasion when new file formats are introduced that have yet to be recognized as phishing payloads and have not yet been included in the list of high-risk extensions.
5. Is the file format a default registered extension? An adversary is unlikely to deliver attachments that do not have a registered extension because a victim would be unable to double-click on it to execute it.

Ultimately, Microsoft is responsible for defense-in-depth mitigations against MotW bypasses. The following (non-exhaustive) list of CVEs have been issued addressing MotW bypasses:

• CVE-2022-41091 – Windows Mark of the Web Security Feature Bypass Vulnerability
  • This patch aims to propagate MotW to files embedded within container file formats.
• CVE-2020-1599 – Windows Spoofing Vulnerability
  • This patch addressed an issue in Authenticode validation that would allow an adversary to insert malicious code into an executable without invalidating its signature.

For organizations that may want some additional protections around extensions beyond the default “high-risk” extension list, a GPO is available wherein a custom list of extensions can be defined in addition to forcing AV to scan the specified extension.

Additional resources

• Why so, ISO? Mark-of-the-Web, explained
• Microsoft fixes Windows zero-day bug exploited to push malware
• Information about the Attachment Manager in Microsoft Windows
• Monitoring malware abusing CVE-2020-1599

Note: The visibility sections in this report are mapped to MITRE ATT&CK data sources and components.

File monitoring

Due to the number of methods for bypassing MotW, there is no single, definitive source of visibility. A high-value data source in general would be file creation telemetry. Detection engineers can focus on identifying files written to disk that are likely to be abused—e.g. .iso, .img, .vhd, .vhdx, .7z, etc. For added benefit, if an EDR sensor supports logging file creation in the case of the Zone.Identifer ADS, false positives could be reduced by focusing only on file creation that originated from the internet.

Note: The collection sections of this report showcase specific log sources from Windows events, Sysmon, and elsewhere that you can use to collect relevant security information.

Endpoint Detection and Response (EDR) tools

EDR tools will provide file-related telemetry that security teams can use to observe and detect aspects of MotW bypassing.

Sysmon event ID 15: FileCreateStreamHash events

Sysmon is a wonderful tool for collecting Zone.Identifer file creation events with its support of FileCreateStreamHash events (event ID 15). These events not only indicate the file that was written but also display the contents of the Zone.Identifer stream.

The following Sysmon configuration snippet can be used to log the full contents of any Zone.Identifer stream:

Here is the content of an example captured event:

To reduce potential noise associated with tracking Zone.Identifier stream creation, the above Sysmon rule could also be modified to only log in cases where the extension is a container file format (.iso, .img, .vhd, .vhdx).

Raw telemetry

For EDR sensor vendors, the following Event Tracing for Windows (ETW) providers and events may be worth investigating for collection as they include relevant file and network source information.

Microsoft-Windows-SmartScreen

Microsoft-Windows-IE-SmartScreen

Anaheim-SmartScreen

As of this writing, the most common variation of MotW bypassing involves delivering a container file format (.iso, .img, .vhd, .vhdx) with embedded malicious content. An organization should drive to have visibility of all of these file formats when they originate from the internet (i.e., any of the above file extensions with a Zone.Identifier stream). Depending on the environment, such a collection/detection strategy could be overly broad and false positive-prone.

A more narrow detection strategy could involve applying existing behavioral detections to scenarios with file paths executing from an external or mounted volume (e.g., any drive letter besides C:). This could also present false positives in cases where file shares are used often.

One strategy could be to simply alert on any container format file writing to a user/world-writable directory, a common tactic of adversaries:

To validate the execution of file formats that contain MotW, one option is to host sample payloads on a web server, download them and execute them. This process can be replicated locally without a web server by manually adding a Zone.Identifier stream to a file. The following PowerShell function can be used to simulate a file originating from the internet:

For example, to produce a SmartScreen dialog for a low-reputation executable, the following PowerShell commands can be used to create an executable on the fly and add MotW to it:

Then, upon double-clicking the executable, a SmartScreen dialog will appear.

A dialog box for high-risk extensions can also be simulated writing any content to one of the extensions and adding MotW to it. Here’s an example for a simulated .vbs file: