Inspiration for my posts comes from different places – news events mostly, but they also come from things that happen in my everyday life. The inspiration for this post comes from a topic on Alternate Data Streams I was teaching to my students. In itself it wasn’t enough to write a post, but by chance, it came on the same day as a post by Elastic Research Labs which identified a weakness in Mark of the Web that can be abused to compromise a victim PC. And so it spawned the idea for this post.
What is Mark of the Web?
Mark of the Web (MotW) is the common name given to a special tag applied to files by browsers when you download data from remote locations that informs the operating system and other security utilities how to treat the file. This post will take a look at what MotW is, how it works, and how others try to defeat it.
It starts with NTFS
MotW is data added to a special part of a Windows file called an Alternate Data Stream (ADS) when the system uses the New Technology File System (NTFS); So before we try to understand what MotW is we need to have a brief understanding of NTFS.
NTFS is the default file system used by Windows operating systems since the release of Windows NT3.1 back in 1993 – prior to the release of NTFS, Windows machines used the File Allocation Table (FAT) format for storage devices.
NTFS introduced many new features to file storage, previously unavailable when using FAT. Features such as Access Control Lists (ACLs), File encryption, Transparent compression, Sparse files, and File system journaling were introduced with NTFS.
Alternate Data Streams (ADS) were introduced with Windows NT 3.1, to enable Services for Macintosh (SFM) to store resource forks – A fork a set of data associated with a file-system object – A resource fork stores structured data containing details such as icon bitmaps, the shapes of windows, definitions of menus and their contents, and application code, among other things.
The MoTW data is held in an ADS named “Zone.Identifier”. This ADS is added by most browsers to mark files downloaded from external locations as possibly unsafe to run. When a downloaded file is executed by a user, the local shell will require user confirmation before continuing.
If a user indicates that they no longer want to see the pop-up warning (effectively marking files from that domain as safe), the Zone.Identifier ADS is deleted from the file.
There are 5 default categories of Zone.Identifier:
- Local Intranet Zone
- Trusted Sites Zone
- Internet Zone
- Restricted Sites Zone
- Local Machine Zone
Local Intranet Zone
The Local Intranet zone is for content located on an organization’s intranet. Because the servers and information are behind an organization’s firewall, it is reasonable to assign a higher trust level to content on the intranet.
Trusted Sites Zone
The Trusted Sites zone is for content located on Web sites that are considered more reputable or trustworthy than other sites on the Internet. Assigning a higher trust level to these sites minimizes the number of authentication requests. The user adds the URLs of these trusted Web sites to this zone.
Internet Zone
The Internet zone is for Web sites on the Internet that do not belong to another zone. This default setting causes the browser to prompt the user whenever potentially unsafe content is about to download. Note: Web sites that are not mapped into other zones automatically fall into this zone.
Restricted Sites Zone
The Restricted Sites zone is for Web sites that contain content that can cause (or have previously caused) problems when downloaded. Use this zone to cause the browser to alert that potentially-unsafe content is about to download, or to prevent that content from downloading. The user adds the URLs of these untrusted Web sites to this zone.
Local Machine Zone
The Local Machine zone is an implicit zone for content that exists on the local computer. The content found on the user’s computer is treated with a high level of trust.
Security Templates
In early Windows systems, URLs accessed by users via the Internet Explorer browser were added to one of the zones as described above and Security Templates were applied to the zones that dictated how the device managed the resource being requested.
The use of Chromium-based browsers, such as Google Chrome, or Microsoft Edge has changed this slightly, with these browsers dropping most support for security zones. Chromium-based browsers however, still use Windows’ Security Zones by default in two cases:
- When deciding how to handle File Downloads
- When deciding whether or not to release Windows Integrated Authentication (Kerberos/NTLM) credentials automatically
Viewing ADS
There are a few ways to see if a file has an Alternate Data Stream – one of which is via the CMD prompt.
When running a directory list (dir), you can add the switch /R which will show the presence of any Alternate Data Streams
In the example shown above, Wireshark has been downloaded, and by running dir /R, it shows that a Zone.Identifier ADS has been added which contains 135 bytes of data.
To see the content of the ADS, we need to turn to PowerShell, and the Get-Content cmdlet.
Running Get-Content with the switch -stream will display the data held within the identified ADS.
E.G.
Get-Content .\Wireshark-4.2.6-x64.exe -stream Zone.Identifier
In this example, we can see that the Wireshark download has a ZoneId of 3 (Internet Zone), but it also some extra data that identifies the details of the URL where the file was downloaded from.
Clicking the file to run it causes Windows to invoke the User Account Control (UAC) security to interrupt the action and prompt the user with a security warning. This is due to the presence of the Zone.Identifier.
Abusing MotW entries
The post by Elastic Research Labs which sparked the idea for this post identifies how threat actors have been abusing a flaw in Windows SmartScreen and Windows Smart App Control (SAC) to allow malicious apps to run without triggering the UAC security pop-ups.
LNK stomping
During their research, the Elastic Research Labs analysts identified a MotW bypass that is trivial to exploit. It involves crafting LNK files that have non-standard target paths or internal structures. When clicked, these LNK files are modified by explorer.exe with their canonical formatting. This modification leads to removal of the MotW label before any security checks are performed.
The easiest demonstration of this issue is to append a dot or a space to the target executable path (e.g., powershell.exe. Note the extra dot at the end of the filename). Alternatively, one can create a LNK file that contains a relative path such as .\target.exe.
After clicking the link, explorer.exe will search for the matching .exe name, and will automatically correct the full path, update the file on disk (at whi point it removes the MotW), and finally launch the target.
Due to the lack of the MotW, no UAC prompt is triggered and the (possibly) malicious executable now has the ability to compromise the machine.
Not the first time MotW has been abused
Due to the fact that MotW tags form part of the front-line of defence in Windows Systems, it has been the target of abuse in a number of cases.
In September 2022, a malware strain known as Magniber abused MotW to allow its ransomware cryptor to run without alerting the user. In this case, the Magniber file contained a malformed digital Authenticode signature which confused Windows to allow the script to run even though its MotW flag is set.
In another attack, threat actors have used compressed archive files to bypass security.
When a victim downloads a specially crafted archive file, it gets flagged with a MotW identifier, however by manipulating the files within the archive, it is possible that the files in the archive do not inherit these Zone.Identifiers and as such do not trigger UAC when decompressed and executed.
