Mark-of-the-Web Bypass

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.

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

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: