MOTW - Mark Of The ... What?
TL;DR
Despite Microsoft's best efforts, MS Office programs may still end-up executing scripts embedded in documents downloaded from the internet. Pretty soon UpSight Security will have you covered. Stay tuned for the next release announcement!
Nerd Alert: this is probably the most technical blog we have released so far, thus we would like to apologize in advance if we have failed to coherently explain the concepts below. Please comment if you have questions!
What is MOTW?
Today I want to touch upon a reasonably old tech that plays an important role and IMHO has not been talked often enough. Enter - MOTW (nope, not mo-town) - Mark Of The Web.
Interestingly enough, searching Google for MOTW returns mostly security related topics, with definite dark nuances:
Subvert Trust Controls: Mark-of-the-Web Bypass https://attack.mitre.org › techniques Adversaries may abuse specific file formats to subvert Mark-of-the-Web (MOTW) controls. In Windows, when files are downloaded from the Internet, ...
Windows Mark of the Web Zero-Days Remain Patchless ... https://www.darkreading.com › attacks-breaches › wind... Oct 25, 2022 — MotW Protections for Untrusted Files ... MotW is a Windows feature designed to protect users against files from untrusted sources. The mark itself ...
Windows Mark of the Web bypass zero-day gets unofficial patch https://www.bleepingcomputer.com › News › Microsoft Oct 17, 2022 — These MotW labels tell Windows, Microsoft Office, web browsers, and other apps that the file should be treated with suspicion and will cause ...
Even more surprisingly, even ChatGPT is kind of stumped, I was really hoping it will help me a bit with the creative writing portion of this blog, but ... sigh, such is my luck. I found the one topic ChatGPT truly sucks at:
ChatGPT: MOTW is likely an acronym and without more context, I can't be sure what it stands for. Can you provide more information or context so I can better understand what you're asking about?
Followed by:
ChatGPT: The "Mark of the Web" (MOTW) is a special HTML comment that is used in web pages to indicate the security context of a page. It is typically used by Internet Explorer (IE) ...
You useless transformer! What Internet Explorer? I thought you were trained with data all the way up to 2021 and not 2011! Anyway - shall we get on with the blog?
MOTW is a metadata that specifies the origin of files downloaded by network facing programs, such as your favorite web browser. MOTW is stored in an Alternative Data Stream (ADS) named "Zone.Identifier", thus it can only be present on NTFS volumes.
If you are familiar with NTFS' support for Alternative Data Streams, you can skip the next paragraph.
In NTFS, each unit of information associated with a file—including its name, its owner, its contents, and so on is implemented as a file attribute. Each attribute consists of a single stream — that is, a simple sequence of bytes. This generic implementation makes it easy to add more attributes (and therefore more streams) to a file; a file's data is just another attribute. Every NTFS file has one default data stream, which has no name, but applications can create additional named data streams. These additional streams are referred to as ADS (Alternative Data Streams) and their name is constructed by appending ':' to the name of the file. ADS are supported only by NTFS. The easiest way to check if a file has ADS is from the command prompt to issue 'dir /r <filename>'.
If we look at the UpSight.exe installer that I just downloaded from upsightsecurity.com:
we can see that the MOTW metadata is an INI stream with one section - [ZoneTransfer]. There are usually 3 name/value pairs :
ZoneId - rough classification of the URL from which the file was downloaded. Microsoft defines the following ZoneIds:
typedefenum tagURLZONE {
URLZONE_LOCAL_MACHINE = 0,
URLZONE_INTRANET = 1,
URLZONE_TRUSTED = 2,
URLZONE_INTERNET = 3,
URLZONE_UNTRUSTED = 4,
URLZONE_PREDEFINED_MAX = 999,
URLZONE_USER_MIN = 1000,
URLZONE_USER_MAX = 10000 } URLZONE;ReferrerUrl - this is the URL from which you clicked on the download link.
HostUrl - the URL from which the file was downloaded - usually will point to a CDN.
Thus the MOTW adds a fairly useful attribution about the origins of a file. There of course are the privacy concerns, since a URL can contain private information (if that said URL was generated as a result of filled out a form), but let's concentrate on the positive aspect of MOTW. Every security feature comes with a trade-off, no free lunch and all that.
The cool part is that this metadata will stay associated with the file, even it it is moved/copied around so as long as: 1) standard copy utils/tools are used and 2) the new copy resides inside of an NTFS volume.
How is the MOTW getting populated? It is done by the net-facing program (aka web browser) that downloads the file, by either directly writing the Zone.Identifier ADS or by utilizing the IAttachmentExecute interface. Based on what Google tells me, Chromium based browsers are using the COM interface, while Mozilla's FireFox is directly populating the ADS. Here is the problem though - there is no OS mechanism that can force the net-clients to willingly participate in the MOTW game and for example, curl does nothing, thus MOTW can be classified as "best-effort" mechanism.
How is Windows using MOTW?
Windows Explorer: Windows Explorer supposedly should warn you before executing files coming from unsafe zones, aka ZoneId >= 3. For whatever reason, I am not able to reproduce this on my win10 machine, but if you right-click on mostly any file in your Downloads folder you will see the following warning:
The above is from the steam installer, which carries the following Zone.Identifier:
[ZoneTransfer]
ZoneId=3
ReferrerUrl=https://store.steampowered.com/
HostUrl=https://cdn.akamai.steamstatic.com/client/installer/SteamSetup.exeMicrosoft Office: Recently Microsoft implemented a policy, which by default will block the VBA macro execution for files coming from an unsafe zone (>= 3). You can find details here. Great! Considering that office macros are one of the most common entry attack vectors on Windows, then mission accomplished, office VBA scripts are not a security concern anymore, right? ;) If only!
Miscreants figured out that if they packaged the office doc inside of an ISO image file, then when the user clicks on say the attachment named yearly_bonus.ISO file, Windows will mount the ISO as an UDF (Universal Disk Format) volume. Since UDF does not support alternative data streams (ADS), then the actual office doc, does not carry MOTW and as a result MS Office will happily execute the VBA script. Oops!
Also, if the office doc is inside of a "specially" crafted ZIP archive, then Windows Explorer may not propagate the MOTW to the new files after they have been extracted from the archive, then MS Office will again be none the wiser and will execute the scripts (details here). Double oops!
The two scenarios from above are not hypothetical and have already been exploited in the wild. Luckily according to the bleepingcomputer, Microsoft fixed both vulnerabilities with last November's patch Tuesday.
I did confirm that by creating a Bonus.iso image, which contains macro.docm file with the following VBA script:
Sub AutoOpen()
MsgBox "Hello World!"
Call Shell("cmd.exe", vbNormalFocus)
End Sub
The script above displays "Hello World!" message box and spawns cmd.exe - you know, normal stuff that Word docs do :).
After assigning ZoneId=3 to Bonus.iso, mounting it and double clicking on macro.docm, I got:
Procmon trace revealed how Word handled MOTW, it first tried to open the ADS on the macro.docm file and when that failed, it opened the Zone.Identifier on the ISO image hosting the volume E:
A reasonable question to ask now would be: how does MS Word know what file precisely is hosting the mounted volume? I am glad you asked, read ON!
UpSight Security and MOTW
Since UpSight Security is all about behavioral state tracking and MOTW represents an important attribution about a downloaded file's origin, you can safely assume that we have implemented the necessary code to correctly track MOTW and not loose its trail regardless of whether the classified file comes from an ISO image or ZIP (or other) archive.
ISO images
<NerdAlert>
The first step is to be able to associate the host file with the mounted volume. One can achieve this by opening the volume (E: in this case) and issuing the FSCTL_QUERY_DEPENDENT_VOLUME. Note: there are some nuances if this is to be done in the kernel from a mini-filter driver; leave us a comment if you want to know what those are ;).
</NerdAlert>
Once we have associated the host file(s) with a volume, we can simply transfer the state from the host file to the files inside the volume. Considering that the hosting file has the following Zone.Identifier
[ZoneTransfer]
ZoneId=3
ReferrerUrl=https://upsightsecurity.com/
HostUrl=https://content.upsightsecurity.net/clientcontent/Bonus.iso
here is an example of UpSight in action:
Just like that we can write rules against FileZoneId/FileHostUrl/FileReferrerUrl attributes! If UpSight starts consuming an URL reputation feed (hopefully soon), then we can directly assign reputation to the downloaded files! And this can be achieved w/o having any yucky browser plugins.
OK, but can we evade the MOTW enforcement performed by Windows? Well ... we can, sort of. What if the macro.docm file is copied from E:\ to say %temp% and MS Word is told to load %temp%\macro.docm? W/o UpSight running, Windows will loose the trail and Word will happily execute the macros. Oops!
Let's take a concrete example and create a Bonus.iso image, which has the following files:
F:\>dir /a
Volume in drive F is Bonus
Volume Serial Number is B94F-8768
Directory of F:\
02/04/2023 12:27 PM 99 BONUS.docx.bat
02/04/2023 12:27 PM 2,221 Bonus.docx.lnk
02/03/2023 10:30 PM 17,691 macro.docm
3 File(s) 20,011 bytes
0 Dir(s) 0 bytes freeNote: that macro.docm is hidden. BONUS.docx.bat copies macro.docm to %temp% and executes MS Word, which opens %temp%\macro.docm (read this blog about this double extension technique). Bonus.docx.lnk does pretty much the same, only it is a link file.
Here at UpSight we are firm believers in the Mitre Att&ck framework and are working as hard as we can to map the various techniques (and sub-techniques) to UpSight rules. These rules are filling out an AttackGraph attribute that is associated with what we call actors. Think of actors as entities that play a role in an event - processes, threads, modules, files, registry keys. UpSight also has a special policy, which is in charge of tracking and transferring state between different actors (yup it is entirely driven by rules). Back to the example above: when cmd.exe loads BONUS.docx.bat, cmd.exe will inherit the AttackGraph attribute from the .bat file; furthermore when cmd.exe lays down %temp%\macro.docm, the latter will inherit the state of its creator. Essentially the MOTW state is transferred as follows:
In essence, %temp%\macro.docm, the winword instance that loaded it and the cmd.exe instance that is spawned by winword (due to executing VBS), will carry the T1553.003 (MOTW) token in their respective AttackGraph attributes.
Now we can actually write a rule to terminate an MS Office program if it carries the T1553.003 attribute and tries to spawn a script processor:
rule terminate_ms_office_with_motw_spawning_script_host:
{
meta:
Reaction = "Terminate, Log"
condition :
if ((Op.Type == "PROCESS_CREATE") and
(Initiator.ProcessClassification & "MSOffice") and
(Initiator.AttackGraph & "T1553.003") and
(Target.ProcessClassification & "ScriptHost")
)
}Pretty cool, right? We are thinking though
... perhaps we should let the machines learn what the actual enforcement rules should look like based on the state of the AttackGraph ;).
Furthermore, when our event graph code is fully developed, we will be able to walk the graph back in time and extract the actual FileZoneId/FileHostUrl/FileReferrerUrl attributes that came from the downloaded Bonus.iso image!
Tracking state from .lnk files is a bit more complex since it involves creation of a transient state transfer rule against the actual target command line, extracted from the .lnk file. Once the link target is invoked, UpSight transfers the state from the link file to the newly created process; from there on, every file created by the link target process will inherit the state of its creator.
Back To Windows
To be fair to Windows, there are decent guard rails against script and link execution from ISO mounted volumes with MOTW. If Defender SmartScreen is Enabled and the user clicks on the Bonus.docx.bat file, then the script execution will be blocked by default:
This is a pretty serious warning and what happens next, really depends on how anxious the user is to see what their bonus is ;). If the user clicks "Run anyway", it is game over, MS Word will execute the script! If the user executes the script from a command prompt, it is game over again! Why Smart Screen operates only when a script is being clicked on is beyond me and only Microsoft PMs in their infinite wisdom might know.
If the user clicks on the Bonus.docx.lnk though, then Windows presents the standard dialog box:
which relies on the behind the keyboard device to notice the double extension and that the file type is "Shortcut". If the user clicks "Open" then it is game over - the MS Word will load %temp%\macro.docm file and execute the embedded VBA script.
New vs. Old
So ... where is the UpSight from UpSight (pun intended)?
The two examples above illustrate very well the difference between UpSight and legacy anti-malware solutions. Let's take an office building security as an example: traditional AV provides very few static and discrete checks (i.e. swipe your card, your bag may get scanned, etc.), and often the perpetrator needs to evade only one in order to wreck havoc.
UpSight on the other hand is like a well coordinated system of cameras, which constantly monitors for suspicious behavior. An attacker can be stopped at every step they take, based on their accumulated behavioral pattern.
Yes, our cameras still have blind corners, but we are working diligently to cover them. Just to clarify: we are drawing a metaphor with the video surveillance here, UpSight has no intention to get into the business of physical security :).
ZIP and Other Archive Files
Windows Explorer
By default Windows Explorer will propagate the Zone.Identifier ADS to all the extracted files. Unfortunately Microsoft Devs decided to change the referrer URL to point to the ZIP/archive file:
[ZoneTransfer]
ZoneId=3
ReferrerUrl=C:\Users\<UserName>\Downloads\WinObj.zipUpSight will make no attempt to transfer the original Host/ReferrerUrl, but will still rely on the ZoneId field to populate the attack graphs of processes that try to execute the uncompressed binaries/scripts.
7-zip and WinRar
The latest 7-zip 22.01 (2022-07-15) and WinRar 6.20 do not propagate MOTW to the extracted files! Actually it seems that WinRar will propagate MOTW only for office files, when extracted from an .iso image file. Seems rather arbitrary and does not make a whole lot of sense, but ... you probably want to test this yourself.
UpSight has rules in place that will transfer state from known archive file formats to 7-zip and WinRar. Once the archiver is tainted with MOTW any files the former lays down will carry the T1553.005 verb in their respective AttackGraph attribute.
Call To Action
This time around the call to action is a bit different - tune in and wait for our next major release announcement, which will contain all of the functionality described here; it is hot off the oven and we need to consume the requisite amount of dog food, before we make it publicly available.
Of course, you should just install the current version of UpSight in order to protect YOU!