TL;DR

An Office XML (.xml) document can call a remote XSL stylesheet over SMB.  If this occurs against an attacker controlled server, the net-NTLM authentication hash (challenge/response) of that user is revealed.  Operationally, an attacker could crack this offline or leverage a relay technique for remote command execution (if privileged and on-net).  There are possible phishing implications due to organizational security gaps (such as with poor egress rules). In many cases, XML documents will likely pass through most mail gateway filtering mechanisms and/or other network security controls.  Defenders may want to consider changing the default XML file association to a text editor because most users will not have a valid requirement for opening raw Office XML documents.  Strong passwords, solid egress rules (e.g. disallowing SMB outbound) and user training can help mitigate these types of attacks.

---

Introduction

Methods for capturing netNTLM (version 1 or version 2) challenge/response hashes are well documented, and the use cases for exploiting/cracking netNTLM hashes can be accomplished with incredible tools like Impacket by CoreSecurity, Responder by Laurent Gaffie, Inveigh by @kevin_robertson, and Hashcat by Jens Steube.  For the most part, many of these capture techniques fall into the post-exploitation category and usually require LAN and/or host access for exploitation success.  Under the right circumstances, these techniques can be user driven (e.g. via Microsoft Office documents) and quite possibly an enabler for initial access.  In this post, we’ll discuss an unconventional technique for UNC path redirection and netNTLM capture with Microsoft Office (Word) 2016.  Topics include:

• A primer on Microsoft XML documents
• NetNTLM capture via XML stylesheet manipulation
• Use cases, notes, & caveats
• Defensive considerations

*Note: Before proceeding, I would highly recommend checking out the following resources for a background on Windows authentication protocols and related capture methods:

• LM, NTLM, Net-NTLMv2, oh my! by @petergombos
• Microsoft Office – NTLM Hashes via Frameset by @netbiosX
• SMB/HTTP Auth Capture via SCF File by @mubix
• Places of Interest in Stealing NetNTLM Hashes by @osandamalith
• Microsoft Word – UNC Path Injection with Image Linking by @thomas_elling

---

A Primer on Microsoft Office XML Documents

Since Office 2007, (most) file formats are based on Microsoft’s Office Open XML (OOXML) which is “a zipped, XML-based file format developed by Microsoft for representing spreadsheets, charts, presentations and word processing documents” (Wikipedia).   This is commonly represented in the “newer” office extensions, such as .docx for Microsoft Word and .xslx for Excel.

Quite interestingly, Office documents can also be represented as “flat” XML files that contain valid tags and attributes.  For instance, let’s create a Word XML document via the traditional sense by opening word and adding some text:

Instead of saving the file as a(n) .docx, let’s choose XML as the output:

Here is the (truncated) XML representation of that document:

Click the picture above to get a closer look.  Interestingly, there is a tag that contains the mso-application label:

<?mso-application progid="Word.Document"?>

The ProgID is actually a COM identifier. The Microsoft XML handler (MSOXMLED.EXE) processes the mso-application tag to load the appropriate Office application as identified by the ProgID.  MSOXMLED.EXE can be called directly to launch the respective XML file:

MSOXMLED.EXE /verb open "C:\Users\user\Desktop\word.xml"

Or, a user can launch the XML file directly (in Explorer) and rely on the default file association (handler).  If the default file association is not set (in Windows 10), Explorer will invoke runonce.exe to select an Office program.  The Office XML handler is the first (and preferred) choice, and this will become the default once selected:

The Office XML handler calls Word (winword.exe) to open the document:

*Note: Another option is to open the XML file from Word, or by using the command line directly.  These methods ‘bypass’ the handler.

---

NetNTLM Capture via XML Stylesheet Manipulation

From this 2004 blog post by Christian Nagel, I extracted and modified a simple Word XML document and stylesheet for this proof of concept.  Below, we have a local XML file (and a remotely hosted XSL file):

Our XML contains a reference (href) to the remote location within the xml-stylesheet tag.  Additionally, we added the mso-application tag to ensure that our XML doc is routed to the appropriate application by the handler.

Before attempting to open this file, let’s start the Impacket SMB server on our attack machine:

smbserver.py -smb2support test .

Let’s double click on our ‘malicious’ XML file to open it:

Now, let’s take a look at our SMB server log to examine the results:

Success – we can now attempt to crack this hash!

---

Use Cases, Notes, & Caveats

Phishing Implications

Depending on the circumstances, the XML file delivery method could be a viable phishing technique.  If an organization has weak egress filtering or VPN control for remote users, an attacker could email the Office XML document to “fly under the mail gateway and filter radar” by sending a seamlessly benign document like so –

Double-click and press Open.

Note: Depending on the circumstances, the user may have to step-through the default association prompt.

Word Opens in Protected View because the file originated from another location (e.g. the web).  Once we “enable editing”, the XSL doc is referenced and we collect the hash value on our attack machine:

This process took  a few steps, but it was not flagged.

Stylesheet Reference Tag

In our example above, we used an explicit UNC path to reference the stylesheet.  A file protocol handler designation would have worked as well:

file:///192.168.245.175/test/word.xsl

Other Microsoft Office Applications

This stylesheet fetch also works with other Office applications (e.g. Excel) and with other command line switches.  Word appears to be the most seamless.

WebDAV

Microsoft Word supports the WebDAV protocol.  If Word cannot fetch the remote reference via the SMB protocol, Word attempts to retrieve the remote file via HTTP WebDAV requests.  Didier Stevens (@DidierStevens) has a great write-up on this behavior in this blog post – Webdav Traffic to Malicious-Sites.

*Note: For a failed authentication attempt with NTLM WebDAV, a server would typically respond with a 401 unauthorized message.  Depending on the WebDAV client, the application may attempt to deal with this in several ways.  Explorer.exe prompts for credentials while Word seems to request the resource a few additional times (without prompt).  It is interesting behavior, but I could not force a pass-thru NTLM request to the server.  This is research topic for another day.

---

Defensive Considerations

• Strong Password Policies – Minimize the attackers chance of cracking collected hashes with strong and unique passwords.
• File Associations – Unless there is a viable business need, consider changing the default association for XML files to a test editor.  This Microsoft Docs article provides guidance for using GPO/GPP to configure a “file type preference.”
• Egress Rules – Outbound traffic, especially SMB (TCP 139/445) is dangerous for any organization (or home).  Enforce egress firewall rules and open only what is needed.
• (Remote) Users – Remote users that leverage webmail or VPNs that do not tunnel all traffic through it may be at risk for such an attack (and others like it).  Try to tighten up remote access controls and tunnel traffic through the VPN if possible.  Above all, train uses to be as diligent as possible about opening attachments.

---

Conclusion

Thank you for taking the time to read this post!  As always, feel free to send me a message if you have questions/feedback.

– @bohops