NTLM is like that stubborn relic of the past that just won’t go away – a decades-old authentication protocol, seemingly deprecated but still lurking in the shadows of every Windows environment.  

Despite years of efforts to replace it with more secure alternatives like Kerberos, NTLM remains a critical fallback mechanism that Microsoft cannot fully deprecate. Why?

Because it’s embedded so deeply into the ecosystem, removing it would risk breaking countless legacy applications and workflows. This fallback dependency is what attackers exploit time and again, using techniques that leverage the protocol's inherent weaknesses. 

Introduction 

In recent years (2023-2024), a new trend has emerged where attackers focus on discovering and exploiting automatic NTLM (NT hash) leaks as a method of privilege escalation. The Microsoft Outlook application in particular has become a primary target for initial access due to its frequent and often silent network connections, which can trigger unintended NTLM authentication. 

Once attackers obtain a leaked NTLM hash, the impact can be devastating. Cracking the hash to retrieve the plaintext password isn’t always necessary; the NTLM hash itself can be used directly in pass-the-hash attacks. This allows attackers to authenticate as the user without knowing their password, leveraging the hash for remote PsExec, WMI, or RDP access, or even dumping additional credentials that were previously out of reach. If the NTLM hash belongs to a privileged user, attackers can perform DCSync attacks, request new Kerberos tickets, or escalate privileges within the domain. 

NTLM’s deprecation attempts are explored brilliantly in my favorite BlueHat presentation, which you can check out here. The presentation delves into the challenges of phasing out NTLM, highlighting how Microsoft's efforts to kill it off are often hampered by the need to maintain compatibility with legacy systems. 

The problem isn’t just that NTLM is an outdated protocol. The real issue lies in how file access requests can trigger NTLM fallback authentication, especially when connecting to a rogue SMB server. Although modern systems might prioritize Kerberos, they often revert to NTLM if Kerberos fails. This fallback can result in unintended credential leakage, especially since many applications initiate network connections without explicit user action. Despite Microsoft’s recommendations to limit NTLM usage, these settings are rarely enforced, leaving environments vulnerable. 

In the recent Defcon presentation, NTLM: The Last Ride, Jim Rush and Tomais Williamson highlighted how widespread these NTLM leaks are – and it’s not just a Microsoft problem. Yet, Microsoft’s own response to NTLM vulnerabilities has often been to classify them as “Moderate” or dismiss them as “By Design.” Even with the latest developments in Windows 11, where proactive blocks have been introduced, it’s clear that Microsoft is more focused on sidestepping the issue rather than fixing it outright. 

This is why we feel it’s crucial to bring awareness to these vulnerabilities. If Microsoft won’t take action, businesses must. We’re disclosing five significant NTLM vulnerabilities that impact widely used Microsoft products. These aren’t fringe issues; they affect applications that form the backbone of many enterprise environments. By sharing this, we aim to push companies to harden their own defenses instead of relying on patches that may never come. Perhaps this pressure will also drive Microsoft to address these issues more urgently. 

1. Microsoft Word - NTLM Leak via Malicious RTF Document Auto Link 

Imagine receiving a Word document named invoice.rtf. At first glance, the document opens in Protected View, with "Read-Only" mode enabled to safeguard against potential malicious content. 

Most users, however, are likely to enable editing, especially if the document appears legitimate and cannot be modified otherwise. The moment you click "Enable Editing," you’re presented with a popup warning that the document may contain malicious links, giving you the option to refuse these updates. 

Would you assume that rejecting the links in this prompt stops any external connections? If so, you’d be mistaken. Due to a logical flaw in the way Microsoft Word processes automatic OLE (Object Linking and Embedding) links, the "QueryHotLinks" function is bypassed, disregarding the user’s response. This results in the automatic access of a remote file, triggered by a call to std::filesystem::exists on the link, even if the user has declined it. 

As described earlier, this access attempt leads to a fallback NTLM authentication via SMB. In turn, your NT hash (NTLM hash) is sent to the remote server, resulting in a leak of NTLM credentials. 

The attack is initiated automatically by embedding a LINK property within the RTF file, using specific "a" and "p" properties to control the OLE link object. No further user interaction is required beyond enabling editing, making this vulnerability particularly dangerous. 

Microsoft’s Response: 

Microsoft classified this vulnerability as “Moderate,” with no specific timeline for a patch. Their reasoning is that the risk is mitigated by the presence of Protected View. While it’s understandable that Microsoft must prioritize more critical vulnerabilities, this issue still exposes users to significant risk, particularly if ‘Protected View’ is bypassed or disabled, as is common in many enterprise environments. 

Given the nature of this vulnerability, waiting for a patch is not advisable. Businesses should take immediate steps to mitigate exposure rather than relying on a fix that may not come soon. 

Official response: 

2. Microsoft Outlook – NTLM Leak via Remote Image Tag

Imagine receiving an email from an untrusted sender that includes an embedded image within the HTML body. The attacker uses a simple trick, inserting the image with an HTML tag like this:

At first glance, this may not seem like a sophisticated attack, and most users would likely ignore the image or avoid saving it. However, if you do try to save the image, your NTLM credentials are immediately leaked, as the image is hosted on a remote, malicious server. Outlook’s security mechanisms are designed to block automatic image rendering for untrusted emails, providing some protection in this scenario.

The Real Danger: Trusted Senders

The situation becomes far more dangerous when the email comes from a trusted sender, such as a colleague or a compromised company contact. In this case, the image is automatically rendered upon opening the email, without any user interaction required. As soon as Outlook tries to fetch the image, it sends an NTLM authentication request to the attacker’s SMB server, leaking your NTLM hash (NT hash).

Why This Happens:

This vulnerability arises because Outlook applies different security rules based on the trust level of the sender. When the email originates from a trusted source, Outlook does not block the automatic rendering of images. The HTML <img> tag with a src attribute pointing to a remote SMB server triggers an NTLM authentication request as soon as the email is opened. This leads to an immediate leak of the user’s NTLM credentials, without any explicit user action.

In some cases, this issue was even found to enable Remote Code Execution (RCE) through malicious image composite moniker rendering, although this specific vulnerability was patched. Nonetheless, the fundamental issue of automatic NTLM leaks remains, particularly when dealing with compromised trusted accounts.

Microsoft's Response:

3. Microsoft Access - NTLM Leak via Remote Table Refresh

Imagine receiving a report in the form of a Microsoft Access database file named report.accdb. Naturally, you open the file to view its contents. However, the first thing you encounter is a warning message stating: “The active content in this file is blocked.” Many users would likely disregard this message, assuming it’s a protective measure and feeling reassured that potentially dangerous content has been disabled.

After dismissing the warning, you gain access to the report, which displays a prominent yellow banner indicating that active content is disabled. This banner is meant to give you a sense of security, implying that as long as you don’t click "Enable Content," the file is safe to interact with. Unfortunately, this is a false sense of security – your NTLM hash (NT hash) has already been leaked before you even see this banner.

Why This Happens:

This issue arises due to the exploitation of built-in Microsoft Access features. In this case, the attacker uses a query object combined with an AutoExec macro. The AutoExec macro is configured to automatically execute a query on a remote table upon opening the Access file. This means that the application will attempt to connect to the remote table as soon as the file is opened, regardless of whether active content has been enabled.

If the remote table is hosted on a rogue SMB server, Microsoft Access will automatically try to authenticate using NTLM, resulting in an NTLM credential leak. This occurs before the user decides whether to enable active content, rendering the initial warning messages ineffective.

Microsoft’s Response:

Key Takeaway:

This vulnerability demonstrates the dangers of relying on built-in features and default security measures. The attack surface for NTLM-based leaks is significant, and these issues are unlikely to be addressed by Microsoft due to their classification as "features." Businesses should not wait for a patch and must instead focus on proactive hardening and monitoring to protect against this threat.

4. Microsoft Media Player - NTLM Leak via Legacy Player Files

Imagine receiving an email with an attached audio shortcut file named voicemail.wax. Curious to hear the message, you double-click the file. That’s all it takes – a single double-click – to silently compromise your NTLM credentials.

Receiving voicemails or video messages as email attachments is common and may already be exploited in the wild for harvesting NTLM purposes.

Why This Happens:

This vulnerability exploits a flaw in how Microsoft Windows Media Player handles certain media playlist files. An attacker can craft a malicious email with an attachment using a .wax, .wvx, or .wmx file extension. When the recipient double-clicks the attachment, it opens with the default media player application (typically wmplayer.exe). The playlist file then instructs Windows Media Player to retrieve and play a media stream from an attacker-controlled SMB server.

During this process, the media player inadvertently sends the user's NT hash as part of the authentication request to the remote server, resulting in an automatic NTLM credential leak. This happens transparently, with no further user interaction required.

"By-Design" Vulnerability:

Unsurprisingly, Microsoft classifies this issue as a feature. The logic is that users are expected to handle media files with caution. However, what’s more surprising is the inconsistency in how these files are treated by Outlook’s security filters. While Outlook blocks .asx playlist files as potentially dangerous attachments, it does not block .wax, .wvx, or .wmx files – even though all of these can be used to trigger the same behavior and leak NTLM credentials.

Microsoft’s Response:

Microsoft has made it clear that this is considered expected behavior and does not plan to release a patch to address this issue. Their stance is that the feature works as intended, and users are responsible for exercising caution when opening media files.

5. Microsoft Publisher - NTLM Leak via Remote Recipient List

Imagine receiving a stylish invitation to your company’s holiday party, cleverly disguised as a Publisher file named Christmas_Party.pub. Intrigued, you double-click the file to see the invite. Immediately, a prompt appears with a warning message stating: “Do you want to open the publication and access the external data?”

You and your colleagues have been trained to handle suspicious files, so you confidently click “No,” assuming you’ve prevented any risk. Unfortunately, you’re wrong – your NTLM credentials have already been leaked before the warning even appeared.

Why This Happens:

This vulnerability exploits a feature in Microsoft Publisher designed for Mail Merge functionality. Publisher can load a contact list from a remote data source, such as an external file on an SMB server. Here’s the problem: the validation of the remote file’s existence is performed automatically when the document is opened, even before the user is prompted to allow or deny access. This file check is conducted using NTLM authentication, causing your NTLM hash (NT hash) to be sent to the remote server without your consent.

In other words, while the actual retrieval of the contact list content requires user approval, the initial check to see if the file exists triggers an NTLM authentication request, leading to a leak of your NTLM credentials. The attacker doesn’t even need the remote contact list to exist – the mere attempt to verify it is enough to compromise your credentials.

Microsoft's Response:

Conclusion

In the face of Microsoft’s limited action on NTLM vulnerabilities, businesses must take steps to protect themselves. Here are several recommendations:

1. Restrict NTLM Usage: Use Group Policy to limit or disable NTLM authentication (Network security: Restrict NTLM). This will reduce the risk of fallback scenarios where NTLM is unintentionally used.
2. Enforce SMB Signing and Encryption: Enabling SMB signing and encryption can help prevent attackers from impersonating legitimate servers and triggering NTLM authentication.
3. Block Outbound SMB Traffic: Preventing outbound SMB connections to untrusted networks will reduce the risk of NTLM credential leakage to rogue servers.
4. Enable Kerberos-Only Authentication: Configure systems to prioritize Kerberos and disable fallback to NTLM wherever possible.
5. Monitor SMB Traffic for Anomalies: Implement network monitoring and alerting for unusual SMB traffic patterns, particularly outbound requests to unknown or untrusted IP addresses. This can help detect potential NTLM exploitation attempts early.
6. Audit NTLM Usage: Regularly review your environment for applications and services still using NTLM, especially legacy systems. Create a plan to migrate these to more secure authentication methods.
7. Educate End Users: Make sure users understand the risks of opening files or clicking on links from untrusted sources, even if no immediate action seems to follow.

Ultimately, this is about mitigating risk before an attacker can exploit these flaws. While we’re highlighting these five critical vulnerabilities, remember that NTLM leaks are not limited to the SMB protocol alone. Attackers will keep finding ways to exploit this legacy protocol until it is truly dead – and we can’t afford to wait for that day. 

To read more about vulnerabilities in Microsoft products, check out our articles on CVE-2024-38021, CVE-2024-30103, and CVE-2024-38173 to learn about these Microsoft Outlook vulnerabilities that Morphisec discovered.