NTLM The Last Ride

NTLM The Last Ride

Speakers: Jim Rush, Security Researcher; Tomais Williamson, Senior Security Consultant

Conference: DEF CON 32

YouTube: https://www.youtube.com/watch?v=7IrPkH7kK2I

Overview

In "NTLM The Last Ride" at DEF CON 32, security researchers Jim Rush and Tomais Williamson delivered a sobering assessment of the enduring vulnerability posed by NTLM (New Technology LAN Manager), a legacy authentication protocol within Windows environments. Despite Microsoft's long-standing recommendations against its use and ongoing deprecation efforts, NTLM continues to be a persistent and often underestimated security risk. The talk highlighted how NTLM bugs frequently serve as critical "gateway bugs," enabling attackers to escalate privileges or gain deeper access within networks, often leading to significant bounties or impactful compromises.

The speakers, both experienced security professionals from New Zealand, critically examined the protocol's history, its inherent design flaws, and the seemingly endless stream of vulnerabilities associated with it. They emphasized Windows' "overwhelming desire to authenticate to absolutely everything," a characteristic that, when combined with NTLM's weaknesses, creates a fertile ground for attackers to capture and exploit authentication hashes. This presentation serves as a stark reminder that even as newer, more secure protocols like Kerberos are prioritized, the "last ride" of NTLM is proving to be a remarkably long and dangerous journey for many organizations.

The relevance of this talk cannot be overstated. While Microsoft has declared NTLM "feature complete" and plans for its eventual removal in future Windows 11 releases and Server 2025, the reality on the ground is that many internal environments still support older NTLM versions. This creates a significant attack surface that continues to be exploited by threat actors. Rush and Williamson's research underscores the critical need for defenders to proactively address NTLM weaknesses, even as the industry collectively hopes for its final demise.

Background

▶ Watch: Introduction: NTLM's persistent brokenness in Windows (0:00)

The NTLM (New Technology LAN Manager) authentication protocol, developed in the 1990s, was designed to provide authentication, integrity, and confidentiality for Windows systems. It succeeded the even less secure LM (LAN Manager) protocol. Despite its initial intentions, NTLM has been a known source of security vulnerabilities for decades. Microsoft officially recommended against its use as early as 2010, and a 2011 DEF CON talk famously titled "Nail the Coffin Shut, NTLM is Dead" prematurely declared its demise. However, as Rush and Williamson pointedly noted, "It failed to die."

The persistence of NTLM stems from several factors. Primarily, the Windows operating system exhibits an "overwhelming desire to authenticate to absolutely everything that it can," often defaulting to NTLM if a more secure Kerberos negotiation fails. This fallback mechanism, while intended for compatibility, creates a significant attack vector. Even with Microsoft's recent efforts to prioritize Kerberos, the NTLM fallback remains a critical weak point. The speakers highlighted Microsoft's plans to disable NTLM in a future version of Windows 11 and its complete removal from Server 2025. However, they also cautioned that these changes often come with a "long tail" of legacy support, noting that many internal environments still support the even weaker NTLMv1. Furthermore, the option to re-enable NTLM, much like NTLMv1, means that its "feature complete" status does not equate to its immediate irrelevance.

At its core, NTLM operates as a challenge-response mechanism. When a client attempts to access a network resource (like a file share or website), it establishes a network path and sends a negotiate message. The server responds with a challenge message, and the client, using a hash of the user's password (an NTHash), generates an authenticate message in response. This process happens in different flavors, primarily NTLMv1 and Net NTLMv2. While NTLMv2 offers improvements over NTLMv1, both remain susceptible to various attacks, particularly when implemented in environments with less stringent security controls or when combined with other vulnerabilities. The inherent design of transmitting password hashes, even in a challenge-response format, leaves it vulnerable to offline cracking or relay attacks if an attacker can intercept the authentication flow.

The speakers noted that NTLM's problematic nature is often "by design" and that Microsoft's approach has been to deprecate and eventually disable it rather than fix its fundamental flaws. This long, drawn-out deprecation process ensures that NTLM will continue to haunt security professionals for the foreseeable future, making it a crucial topic for ongoing research and defensive strategies.

Key Findings

▶ Watch: NTLM protocol overview, history, and challenge-response mechanism (2:00)

The central finding presented by Rush and Williamson is that NTLM remains a critically persistent and dangerous attack vector within Windows environments, serving as a "gateway bug to something better" for attackers. Despite its age and Microsoft's official deprecation, NLM vulnerabilities consistently lead to significant compromises, often resulting in valuable bounties for researchers. This directly contradicts the notion that NTLM is a dead or irrelevant protocol.

Their research underscores several key observations:

1. Windows' Insatiable Authentication Desire: A core behavioral characteristic of Windows is its "overwhelming desire to authenticate to absolutely everything that it can," indiscriminately sending out authentication hashes. This inherent behavior, combined with NTLM's weaknesses, creates a pervasive risk across networks.
2. The "Long Tail" of Deprecation: While Microsoft has made strides in deprecating NTLM and prioritizing Kerberos, the process is protracted. The speakers noted that "half of the internal environments we've come across still support NTLMv1," indicating a significant legacy footprint that will persist for years, if not decades, despite official end-of-life announcements for Server 2025.
3. NTLM as an Enabler for Deeper Compromises: Rather than being an endpoint vulnerability, NTLM flaws frequently act as initial access points or stepping stones. Capturing NTLM hashes allows attackers to perform further actions like brute-forcing passwords, relaying authentication for impersonation, or leveraging them in more complex attack chains.
4. Microsoft's "Feature Complete" Stance vs. Reality: Microsoft has stated that NTLM is "feature complete" and that they are stopping work on it. However, the continued fallback to NTLM when Kerberos negotiation fails means the protocol remains active and exploitable. The ability to re-enable NTLM, even after it's disabled in future Windows 11 releases, further complicates its effective removal from enterprise networks.
5. A Constant Stream of CVEs: The speakers highlighted the "crap load of CVEs" associated with NTLM, pointing to a consistent pattern of discovery for new attack vectors. This ongoing stream of vulnerabilities, often by design, demonstrates that NTLM's inherent weaknesses are a continuous source of exploitation opportunities.

In essence, Rush and Williamson's key finding is that NTLM is not merely a legacy annoyance but an active and critical component of the modern attack landscape, frequently underestimated and persistently exploited.

Technical Deep Dive

▶ Watch: Long list of NTLM vulnerabilities and design flaws (4:00)

NTLM, or New Technology LAN Manager, is a suite of Microsoft security protocols that provide authentication, integrity, and confidentiality to users and systems. It operates fundamentally as a challenge-response authentication mechanism. When a client attempts to access a resource on a server, the interaction unfolds in three main steps:

1. Negotiate: The client initiates communication by sending a NEGOTIATE_MESSAGE to the server, indicating its intention to authenticate and its supported NTLM features.
2. Challenge: The server responds with a CHALLENGE_MESSAGE, which includes a randomly generated nonce (a unique, single-use number) called the server challenge.
3. Authenticate: The client takes its user's password hash (the NTHash), the server challenge, and other session data, and computes a response. This response is sent back to the server in an AUTHENTICATE_MESSAGE. The server then validates this response against its own knowledge of the user's password hash or by forwarding it to a domain controller.

The two primary flavors of NTLM discussed are NTLMv1 and Net NTLMv2. NTLMv2 is a significant improvement over NTLMv1, incorporating stronger cryptographic primitives and additional random data to mitigate certain attacks, but it is not impervious to compromise. Both versions rely on the client possessing the NTHash, which is a cryptographic hash of the user's password. This hash is derived from a one-way function, meaning it's computationally expensive to reverse it back into a plaintext password, much like "turning a cow into a hot dog" – it's hard to get the cow back.

Attackers primarily exploit NTLM by intercepting or coercing clients to send their NTLM hashes. Once an attacker obtains an NTHash or an NTLM challenge-response pair, there are three main avenues of attack:

1. Brute-Forcing/Cracking: The captured NTHash can be subjected to offline brute-force attacks using tools like Hashcat or John the Ripper. The faster the cracking hardware (e.g., GPUs), the quicker weak or common passwords can be recovered as plaintext. The speakers humorously referred to the "password cracking village" at DEF CON to illustrate the speed of modern cracking techniques.
2. Relay Attacks: In this scenario, the attacker acts as a man-in-the-middle. They intercept an NTLM authentication attempt from a client, relay the challenge to the legitimate server, and then relay the server's challenge back to the client. The client responds with its NTHash-derived authentication, which the attacker then relays to the server. The server, believing it's communicating directly with the client, grants access. This allows the attacker to impersonate the legitimate user. While more prevalent with NTLMv1, NTLMv2 is also susceptible to relay attacks under specific conditions, often for "fun" as the speakers put it, indicating less common but still viable vectors.
3. Reporting to MSRC: As a less direct but still impactful action, researchers can report newly discovered NTLM vulnerabilities to the Microsoft Security Response Center (MSRC), often leading to CVE assignments and sometimes bounties.

The talk highlighted a litany of past NTLM-related vulnerabilities, demonstrating its continuous exploitability:

• Moniker Link (2024): A recent bug that leveraged NTLM.
• Windows Themes File: Loading a malicious theme could trigger the sending of NTLM hashes.
• Outlook Sound Files: A notorious zero-click RCE (Remote Code Execution) vulnerability that allowed attackers to steal NTLM hashes just by playing a specially crafted sound file in Outlook. This bug saw multiple bypasses and subsequent fixes, indicating its criticality and the difficulty in fully patching NTLM-related issues.
• Petite Potam: A highly publicized vulnerability that allowed an attacker to coerce a Windows host to authenticate to a malicious NTLM relay server, potentially leading to domain controller compromise.
• Morphisec Talk: Another DEF CON talk that focused on NTLM vulnerabilities, underscoring the ongoing interest and discovery in this area.

These examples underscore that NTLM is not a static target but a constantly evolving attack surface, where new vectors are discovered that leverage its fundamental design and its integration within the vast Windows ecosystem. Understanding the protocol's mechanics and its historical vulnerabilities is crucial for effective defense.

Demo / Proof of Concept

▶ Watch: Microsoft's slow NTLM deprecation and continued fallback (6:00)

While the talk did not feature a live, step-by-step demonstration in the provided transcript, the speakers explicitly referenced and described the use of a widely recognized tool for NTLM hash collection: Responder.

Responder, developed by lgandx, is a rogue authentication server designed to answer specific network requests and capture authentication hashes. It's a staple in penetration testing toolkits for its ability to listen on multiple ports and protocols (including HTTP, SMB, LLMNR, NBT-NS, and more), mimicking legitimate services to trick clients into authenticating.

For the purpose of collecting NTLM hashes, the speakers highlighted Responder's activity on two critical ports: Port 80 (HTTP) and Port 445 (SMB). When a Windows client attempts to access a resource that an attacker has configured Responder to mimic (e.g., a non-existent file share via a Universal Naming Convention (UNC) path or a web resource), Responder can intercept the NTLM challenge-response sequence. It then captures the NTHash from the client's authentication message.

The speakers noted that Responder "provides authentication challenges on these ports and a lot of others. It does some other cool stuff. It's a very valuable pen testing tool. If you've never heard of it, go run it in an internal network and frighten your sock team." This statement encapsulates Responder's effectiveness as a proof-of-concept tool to demonstrate the ease with which NTLM hashes can be acquired in vulnerable environments. Its primary function in the context of this talk was to "collect hashes," thereby proving the viability of NTLM hash capture as the initial step in many attack chains. The simplicity and widespread availability of such tools mean that the threat of NTLM hash capture is not theoretical but a practical and easily executable attack.

Defensive Implications

▶ Watch: Introducing Responder, the rogue authentication server tool (6:35)

The enduring presence and exploitability of NTLM necessitate a proactive and multi-layered defensive strategy, despite Microsoft's deprecation efforts. Defenders should not rely solely on future Windows updates to eliminate the risk, given the "long tail" of legacy systems and the option to re-enable NTLM.

Here are the key defensive implications:

1. Prioritize Kerberos and Disable NTLM Wherever Possible: The most fundamental step is to configure systems and applications to exclusively use Kerberos for authentication. This involves ensuring that domain controllers are healthy, Service Principal Names (SPNs) are correctly registered, and applications are configured to request Kerberos tickets. Crucially, NTLM should be explicitly disabled via Group Policy Objects (GPOs) across the domain, particularly for sensitive servers and client machines. While Microsoft plans to disable it in future Windows 11 versions, manual enforcement is necessary for current and mixed environments. Organizations must also be aware that NTLM can often be re-enabled, requiring continuous monitoring and enforcement.
2. Block NTLM Traffic to External Networks: Windows' "overwhelming desire to authenticate to everything" means it will attempt NTLM authentication to external resources if not restricted. Firewall rules should be implemented to prevent NTLM traffic (especially on ports like 445/TCP and 139/TCP for SMB, and 80/TCP, 443/TCP for HTTP/S for relay attempts) from leaving the internal network. This mitigates the risk of NTLM hashes being leaked to malicious external servers.
3. Implement SMB Signing and Extended Protection for Authentication (EPA): For environments where NTLM must still be used, SMB Signing (Message Signing) should be enforced on all SMB communications. This prevents NTLM relay attacks against SMB by requiring cryptographic signatures on packets. Similarly, Extended Protection for Authentication (EPA), where supported, helps mitigate credential relay attacks by binding authentication to the TLS channel.
4. Monitor for NTLM Authentication Attempts: Security teams should actively monitor their networks for NTLM authentication events, especially those that fall back from Kerberos or originate from unexpected sources. Tools like Responder are easily detectable. Centralized logging and Security Information and Event Management (SIEM) systems can be configured to alert on NTLM authentications, particularly NTLMv1, which should be immediately investigated.
5. Educate Users and Enforce Strong Password Policies: While not a direct NTLM mitigation, strong, unique passwords and multi-factor authentication (MFA) make brute-forcing captured NTLM hashes significantly harder. User education about phishing and suspicious links that could coerce NTLM authentication is also vital.
6. Regular Vulnerability Scanning and Penetration Testing: Organizations should regularly scan their networks for NTLM-related misconfigurations and actively test for NTLM relay and hash capture vulnerabilities using tools like Responder. This helps identify and remediate weaknesses before attackers exploit them.
7. Isolate Legacy Systems: For systems that absolutely cannot function without NTLM (e.g., older applications or devices), they should be isolated into separate network segments with strict access controls, minimizing their attack surface and potential impact if compromised.

The speakers' emphasis on NTLM as a "gateway bug" means that mitigating it isn't just about patching a single vulnerability, but about removing a foundational primitive that enables more sophisticated and damaging attacks.

Key Takeaways

• NTLM's Persistent Threat: Despite being a decades-old protocol and Microsoft's ongoing deprecation efforts, NTLM remains an active and critical source of vulnerabilities, frequently serving as a "gateway bug" to deeper system compromises.
• Windows' Authentication Behavior: The Windows operating system's inherent "overwhelming desire to authenticate to absolutely everything" significantly contributes to NTLM's exploitability, as it readily sends authentication hashes across networks.
• The "Long Tail" of Legacy Support: Deprecation timelines, such as NTLM's planned removal in Server 2025 and future Windows 11 versions, are lengthy, and many internal environments still support older, weaker NTLMv1, prolonging the exposure window.
• Multiple Attack Vectors: Captured NTLM hashes enable various attacks, including brute-forcing passwords, NTLM relay for impersonation (especially NTLMv1, but sometimes NTLMv2), and leveraging in complex attack chains.
• Proactive Defense is Crucial: Defenders must actively configure systems to prioritize Kerberos, disable NTLM where possible, enforce SMB signing, and continuously monitor for NTLM authentication attempts, rather than waiting for Microsoft's full deprecation.
• Tools like Responder are Effective: Easily accessible tools like Responder demonstrate the practicality of NTLM hash capture, underscoring the ease with which these vulnerabilities can be exploited in unhardened environments.

About the Speaker(s)

Jim Rush is an experienced security researcher and former software developer. He has a history of discovering and reporting vulnerabilities, evidenced by his "few CVEs in various things" and his frequent interactions with CERT New Zealand, the national cybersecurity emergency response team. Prior to his career in cybersecurity, Jim had a unique background touring bands in New Zealand during the early 2000s, an experience he lightheartedly notes left him with "PTSD and a lot of debt." His diverse background provides him with a practical perspective on both software development and security.

Tomais Williamson is a senior security consultant and a security researcher. He is known for his involvement in CTF (Capture The Flag) competitions and has a track record of discovering vulnerabilities, including a "fun thing a few years ago in Kite Works" and contributions to "Microsoft stuff in this talk." Being "a little bit younger than Jim," Tomais represents a newer generation of cybersecurity professionals actively contributing to research and practical security consulting.