Malware Triggers in Outlook Preview Without User Opening Word Document

Please follow me on:
Twitter Telegram

A recent malware sample forwarded to our Threat Intelligence service had some very interesting properties which we think would be useful to share. The sample itself is a Word document which is emailed as part of a phishing attack. If the user interacts with the document, it would download a payload to run on the user’s machine. So far, nothing particularly unusual, this infection route is de rigueur and the Bromium blog contains many recent examples, including my write-up on an Emotet campaign and Mathew Rowen’s excellent post.

There are three reasons why this specific sample is somewhat unusual. Firstly, the user does not have to open the document for the malware to trigger. Secondly, it still works if the file is marked with an ADS security Zone identifier of 3 (meaning the file is known to come from an untrustworthy location). And finally, it successfully avoids having the payload it downloads scanned by some AV APIs. In this blog I intend to cover the first two issues, and there will be a follow-up post in a few days to cover the final part of the attack.

For those that wish to dig a little deeper, the hash for the malicious document is:

• 3FEA120D39B1F0B63DC6A73D0EE2D197169FC765DD5B1EAFC5658C6799D4B00F

How do you get infected without opening the document?

Short answer is—document preview! When you highlight a document in Windows Explorer or Outlook, there is a Preview pane on the right-hand side (or below, depending on your preferences) that gives you a small image of what the document looks like. This is a convenient usability feature, but it has issues from a security perspective—in order to create the image, the content of the document needs to be parsed. Microsoft has generally done a good job of securing this. For example, all the macros will be switched off, and we rarely see attacks that are triggered in the preview.

This attack triggered when the document is highlighted and opened in the Windows Explorer Preview on my corporate laptop (yes, I run malware on my work laptop, but it’s safely isolated within a uVM). Since macro support in the preview is disabled, it leads us to the conclusion that this attack is not using a macro within Word itself, which is indeed unusual. From the above image, you can notice that PowerShell is executing inside the Explorer Preview pane, which is not something we see often.

This same executable is used for the preview of attachments in Outlook, and it results in the same behaviour. If Outlook loads the attachment in the Office Preview, the attack will run. The user never needs to open the attachment directly.

How did the bad guys manage that?

As expected, the document does not contain a macro, but instead, it makes use of a feature of RTF document format that allows the embedding of Excel using “\objupdate” to force an update. It contains five embedded Excel workbooks in the footer, each holding some base64 encoded text in cell G135 (See image above). The embedded workbook itself does contain a macro that runs on opening of Excel, which in turn reads the content of cell G135 and converts that text into the script to run in PowerShell. This results in a child Excel instance that isn’t running in the same security state as the preview process that launched it, which in turn gives the attacker the ability to launch PowerShell.

Mark of the web

When you use your web browser or your Outlook client to download a file, there is some clever code which looks at the location (such as the domain the file came from) to see if it originated inside the enterprise or from some unknown place. If it originated outside the enterprise, an ADS zone identifier is applied to the file, which allows other processes to recognize that there is an increased risk of using this file and behave differently. From this point forward, I will refer to this as “mark of the web”.

The standard use of “mark of the web” is to disable macros in Office documents, should they come from an untrusted location, which is referred to as Office Protected View. This is a powerful security feature because it forces malware authors to have some social engineering in the document to get the user to take it out of the protected view to allow the malware to run. Users who are familiar with security protocols are significantly less likely to fall for such social engineering, and thus are more protected, even if the document is opened. I was surprised to see that there was no attempt at social engineering on this document, even though in my experience, most other documents are taking that route. We tested out what happens if the file has the “mark of the web” applied to it. Maybe no social engineering effort has been made because none is needed?

The behaviour in the test was interesting: if I opened the document after the “mark of the web” was applied, the malware would no longer execute, since the method used to launch Excel no longer worked. So far, it behaves as expected, and this outcome is desirable. However, even with the “mark of the web” applied to the file, the Office Preview-mode attack still worked, so it seems that the Office Preview process is not respecting this security feature. I speculate that since macros are disabled in the preview anyway, no one considered the need to look whether the “mark of the web” is set on the file. This would be reasonable if it wasn’t for the issue where the preview would allow Excel to be invoked from an RTF document.

How dangerous is this?

The severity of the attack may vary depending on security stack and configuration. Microsoft has also done good things to help – if the Office installation is in the default configuration, there is a prompt displayed to the user before any macro can run in Excel by way of a modal dialog indicating that the document might not be trustworthy. This feature could prevent this attack from getting as far as the payload without at least some user interaction. Unfortunately, this specific configuration is often switched off since it leads to usability issues, where legitimate Excel workbooks always display the prompt, annoying users. Even if the dialog does appear, there’s no guarantee that the user will not click on it by mistake. If a user works with a lot of Excel documents and has many of them open at any given time, they may not realise a particular Excel instance is unexpected. It is possible they may just allow the macro to run anyway since they might be used to having to clear a warning dialog when working with legitimate files.

Finally, there’s a concern that although this attack required a macro in Excel to run, which could be prevented by paying attention to the prompt, it is fair to say that Excel is a complex program and it is entirely possible that a future sample would be able to come up with a smarter way to infect the host.

Since the attack also works with the preview mode in Outlook, the risk of infection increases, the user does not need to save the file to disk so that it could be run by the Explorer Preview. Just clicking on the attachment in Outlook with previews enabled would be enough for the attack to work.

Bromium considers this attack to have a significantly higher chance of success than other attack methods that we traditionally see in Office documents. With the reduction in social engineering required for the attack to be successful, even well-trained users will be at risk of infection.

Mitigation:

We recommend that the Office Preview feature is disabled. Doing so will reduce the risk to a similar level to other Office malware varieties that we see in the wild.

source: https://www.bromium.com/new-malware-launches-in-preview-pane/