An Approach to Bypassing Mail Filters

TLDR

By “nulling” the first one or two bytes of a docm file, some spam filters will allow a malicious document to be delivered despite being explicitly blocked. Upon opening the docm file, Microsoft Word gives the option to repair the document, which allows for the potential execution of a macro embedded in the document.

A number of vendors have independently verified this bypass as an issue, so naturally it’s time to write a blog post. While macro-enabled documents were the focus of our testing, the same methodology could apply to many other file types and applications.

Background

Suppose an email filter is configured to block macro-enabled Word documents (docm), how does that filter decide whether a particular sample is of a “docm” type to support a filtering decision?

Generally, we believe this occurs in two ways, although not always in tandem or mutually exclusive:

1. Extension: The user-friendly way to mark files, this is no more than a string “extension” to the end of a file name. Simply put, extensions provide a nice way to keep track of file types, and are generally used as a shortcut for the operating system to improve user experience. Windows will use a file extension to lookup file registration info in the registry, allowing Windows to pass execution to the correct program with the file as an (optional) argument.
2. Header:  Files can be further recognized by a particular file header, as a result of the file format. Most file types have a well defined structure, and the first 2-24 bytes, commonly referred to as “Magic Bytes”, usually provide a good indication of its contents. You can find a good list of these at https://www.garykessler.net/library/file_sigs.html for anyone curious. Some quick examples:
   1. MZ (4d 5a) for PE files (exe, dll, sys)
   2. PK (50 4b) for zip files (zip, docm)
3. Contents (Bonus) : With the use of more exhaustive parsing, a file could be identified based on its holistic structure matching a known format. Naturally this is rare in filtering mechanisms due to the computational cost of parsing.

In regards to bypassing a mail filter, consider the following:

• A malicious file is created which would normally match an explicit block rule.
• The contents of the file header is tampered with to bypass “in-transit” filtering.
• A file extension is chosen to direct execution to a specific application
• The file is still considered “valid” by the application and executed (semi-)normally.

Testing Parameters

As mentioned above, we were specifically interested in the filtering mechanisms for “Macro-Enabled Word Documents” or DOCM files.

Payload: PlanetExpress.docm, a OpenXML (Office 07+) formatted document with the following embedded macro.

Sub Document_Open()
    MsgBox "Hello!"
End Sub

Delivery Technique: PlanetExpress.docm directly attached to a an e-mail that is delivered to Outlook.

Defense: A mail product configured to block all macro-enabled files, but allow any traditional documents. Each mail filtering product has a different process for handling incoming documents. For example, the first product we tested, all documents were inspected by the filter regardless of blocking rules put in place. Each document was opened, parsed, and inspected. If the document was deemed safe, a link to the document would be sent to the user, rather than the document itself.

The Classic Phish

For our first test we simply changed the file extension from .docm to .doc. This is a common technique, and probably the “original” technique to hide the fact a document with a macro is being sent in. This technique can fool users but not a modern mail filter, as expected this file was blocked every time.

Testing the Extension (Attempt #1)

For our first real attempt at bypassing the filter, we removed the extension completely. To our surprise, the mail filter allowed the document through unopened, unparsed, and uninspected. However, if the user attempted to open the PlanetExpress file, Windows would present a prompt asking which application should be used to handle the file.

Testing the Extension and the File Header (Attempt #2)

For our next attempt, we changed the file extension from .docm to .doc, and nulled the first byte of the file header, as follows:

Again, to our surprise this got past the filter and was delivered to the users inbox (unopened, unparsed, and uninspected). However, if the user opened the document, the ‘File Conversion’ dialog box is brought up by Word.

Putting the Pieces Together (Attempt #3)

We knew from the previous test that we could use any extension, so long as the first byte or two were nulled out. The challenge then became to find something a Windows program could execute, despite being a corrupt file. In our final test, we kept the original docm extension and nulled the first byte of the file header. The email was again delivered, but interestingly enough, Word handled the corruption differently:

1. When the corruption is detected, it apologizes for not being able to open the document.
2. Clicking ‘OK’, we get an option to repair the file.
3. Clicking ‘Yes’, we get a brand new file called ‘Document1’.

However, when we click ‘Enable Content’, we don’t get the message box from our macro. Why? Well, it’s because Word has created a new “Document1” and our old macro, while still there, won’t be executed until next time we open the file. This is not very useful from an attack standpoint, but a simple macro change will get us execution, change the macro to:

Sub Document_New()
    MsgBox "Hello!"
End Sub

Now when we click through the prompts and enable macros, we are warmly greeted by some macro execution.

Conclusion

This was a relatively simple attack that came from simply questioning our assumptions about mail filters. While the addition of some user prompts, and the requirement for a docm extension are not ideal, this does represent an interesting proof of concept that has successfully bypassed mail filtering in the real world. A number of other scenarios involving extensions, original formats, and header tampering have since been attempted, but we feel the attempts above concisely convey the general process.

Here are the steps for the working attack:

1. Create a macro-enabled Word document
2. Add a Document_New macro as above and save the document
3. Open the document in a hex editor and null out the first byte, re-save the file
4. Email the document to your victim and wait patiently for profit

Vendor Response

• Mimecast: Fixed (2017)
• Barracuda: Fixed (2018)
• Microsoft: Non-issue citing “user action required” (2017)

Will Pearce