The End of an Era: Understanding the Security Risks of NTLM

In October 2023, Microsoft made a pivotal announcement that signaled the beginning of the end for NTLM, including all its versions. This decision, reiterated in June 2024, underscores Microsoft’s commitment to transitioning developers to more secure protocols, such as Kerberos via the Negotiate mechanism. With the deprecation process set to commence in early 2025 and complete by 2027, NTLM’s long-standing reign is ending.

Despite its historical significance, NTLM now represents a considerable security liability. This blog explores the critical weaknesses inherent to NTLM, the reasons behind its prolonged use, and the imperative transition to more secure authentication protocols. Understanding these elements is essential for organizations to safeguard their systems and data in an evolving digital landscape. 

Microsoft Announcement

Microsoft announced in October 2023 its intention to deprecate all versions of NTLM, including LANMAN, NTLMv1, and NTLMv2. This decision was reaffirmed in June 2024, emphasizing that NTLM is no longer under active development and urging developers to transition to more secure protocols like Kerberos via the Negotiate mechanism​​.

The deprecation process is set to begin in early 2025, with phased reductions in support throughout the year. By mid-2026, NTLM will no longer be available in new installations of Microsoft’s operating systems (the possibility of enabling it in some advanced settings is unverified, however). Full deprecation, including the removal of legacy support, is expected to be complete by the end of 2027.

NTLM is a Security Risk

Today, NTLM poses significant security risks due to outdated cryptographic methods and well-documented weaknesses. Also, NTLM lacks modern security features such as multi-factor authentication (MFA) and server identity validation. Because of these weaknesses, attackers can exploit NTLM and gain unauthorized access to sensitive resources like databases and internal applications, making it a major liability.

An older version of NTLM used a shared secret (password) to authenticate over an unencrypted channel. For a new user, there is no initialization protocol; it is as simple as “please log in user X with password Y”.

This means that the protocol exchanges all the information necessary for an attacker to potentially crack the password with a brute force attack within the messages themselves.

To improve the shortcomings of NTLM, salting was incorporated into the challenge-response mechanism of NTLMv2. As a result, NTLMv2 can be viewed as “partially salted” or “nonce-enhanced”, improving security during authentication, but not fully addressing the storage security of password hashes or reusability of hashes, as in relay attacks. Overall, NTLMv2 does not provide protection from relay attacks due to its ability to reuse hashed passwords.

The Prevalence of NTLM: A Legacy’s Last Stand

Despite its many known vulnerabilities, NTLM has held its ground like an old warrior who refuses to retire. NTLM persistence is not random. In the late 1990s and early 2000s, a wave of legacy applications was born. These applications were often tailored to fit their organizations’ unique needs. However, as time marched on, many of these applications were abandoned by their creators. They were left without updates or support, yet they remained essential to countless enterprises.

NTLM, with its simple yet robust authentication mechanism, became the lifeline for these legacy systems. It provided the compatibility they needed to function in a modern world that had long moved on to newer, more secure protocols like Kerberos.

For many organizations, replacing these critical systems was daunting. The migration to modern authentication protocols was not just a technical challenge but a costly and complex endeavor. This required extensive reworking of infrastructure and application code. As the enterprise landscape evolved, so did its IT infrastructure.

New systems were introduced, and with them came the necessity to maintain trust relationships in a multi-domain environment. NTLM, despite its age, proved to be a reliable bridge, ensuring operational continuity and administrative convenience. Gradual upgrades became the norm, and NTLM was often kept as a fallback – a safety net for when new protocols stumbled.

Yet, security analysts knew that NTLM’s weaknesses made it a prime target for attackers. This was because pass-the-hash attacks, relay attacks and brute-force attempts are all too familiar in NTLM. This reliance on NTLM is a tale of survival in a rapidly changing digital world, a delicate dance between innovation and legacy.

However, it is worth mentioning that NTLM is not strictly a protocol for authentication, but rather a conceptual model for designing authentication mechanisms. Its versatility allows it to integrate with various complementary protocols, such as SMB or CIFS for file sharing and RPC for RDP access, making it a robust and adaptable model for authentication.

Why NTLM Still Reigns: Legacy Compatibility, Operational Necessities, and Security Considerations

There are high costs and complexities associated with upgrading or rewriting legacy systems, which account for the persistence of NTLM. Furthermore, NTLM continues to be used despite the availability of more modern authentication protocols due to the gradual nature of infrastructure upgrades and the reliance on non-Windows systems and third parties.
Following is a list of some of the key elements:

Compatibility and legacy systems:

• Legacy systems and applications were designed to work with NTLM.
• Rewriting or upgrading these systems can be costly and complex.
• Some non-Windows systems and applications still rely on NTLM.
• Organizations often upgrade their IT infrastructure incrementally.

Security Controls and Vendor Support:

• Certain third-party vendors may only support NTLM.
• Organizations enhance NTLM with security controls like MFA and monitoring.
• NTLM is used in specific cases such as remote access.
• Maintaining operational continuity often prevails over adopting new tech.

Understanding Password Syncing challenges and SaaS Risks

On the server side, password hashes are securely stored in the NTDS.dit file on each domain controller (DC). However, these hashes are susceptible to DCSync attacks, a sophisticated technique where malicious software masquerades as a legitimate DC.
By exploiting this technique, attackers can trick the DC into syncing its database of password hashes with rogue software such as Mimikatz.
This allows the attacker to harvest a complete set of credential hashes from the domain controller, which can then be used for domain takeover.

This is particularly dangerous for SaaS environments synchronized with on-premises Active Directory (AD) via cloud Identity Providers (IdPs) like Azure AD. Stolen hashes can be used to authenticate to SaaS applications without cracking passwords by leveraging synced AD integration. This grants unauthorized access to critical business data and services in the cloud.

Attackers can move laterally within the cloud environment, compromising additional accounts and accessing sensitive information. If administrative credentials are obtained, they can trigger backdoor creation, alter security settings, and maintain persistent access. This highlights the need for MFA, continuous monitoring and adherence to the principle of least privilege.

Exposing NTLM Vulnerabilities: Initial Access, Lateral Movement, and Threat Exposure

This section delves into the critical phases of exposure, including how attackers often leverage NTLM weaknesses during initial access and post-exploitation stages, enabling them to establish a foothold, escalate privileges, and move laterally, thereby amplifying the potential for widespread network compromise.

Initial Access: Attackers often gain initial access through methods such as phishing or exploiting software vulnerabilities. Once inside, they exploit NTLM vulnerabilities to establish network foothold.

Post-Exploitation Exposure: Post-exploitation, NTLM vulnerabilities allow attackers to maintain and expand their access. This could involve further escalating privileges and moving laterally within the network, increasing damage.

Malicious Access: Lateral Movement

Lateral Movement: With NTLM, you can reuse or replay the hash on other, more privileged machines until you gain domain dominance. Out of the (hacker) box, Kali Linux, onboarded with Metasploit exploits, can be used to accomplish this.

For instance, in the Target data breach of 2013, attackers used stolen credentials to move laterally within the network, accessing sensitive systems and customer data. This breach exposed millions of credit card and personal information records, highlighting the dangers of pass-the-hash attacks. Attackers used captured NTLM hashes to authenticate and move across systems within the network, evading detection and accessing sensitive resources. Another example is the infamous WannaCry ransomware attack.

Attackers used a known vulnerability in the SMB protocol to spread the malware. This included exploiting NTLM authentication weaknesses to move laterally across affected networks. This allowed them to rapidly propagate the ransomware, causing widespread disruption.

NTLM Threat Exposure Unveiled

The next section delves into the threat exposure posed by NTLM, highlighting how attackers can exploit stored and transmitted hashes, leading to significant security breaches across networks.

NTLM Hashes Stored in Memory

The vulnerabilities of NTLM are particularly evident in how it handles and transmits hashes, making it a prime target for attackers seeking to compromise network security through memory extraction, network interception, and pass-the-hash attacks.

NTLM hashes are stored in the memory of authenticated machines. Attackers can use tools like Mimikatz to extract these hashes from machine memory, allowing them to impersonate users without needing their actual passwords. Once attackers have extracted the NTLM hashes, they can perform a pass-the-hash attack.

This involves using the hash to authenticate against other systems in the network, effectively granting them the same access as the original user. This can lead to a large-scale compromise of the network if higher-privileged accounts are targeted.

NTLM Hashes Sent Over the Network

NTLM authentication sends hashes over the network, making them susceptible to interception. By using network sniffing tools, attackers can capture these hashes and perform man-in-the-middle attacks to gain access to them. If attackers successfully intercept these hashes, they can use them to escalate their privileges by authenticating to additional machines and using tools like LSADUMP to extract further credentials.

NTLS has Multiple Authentications Compared to Kerberos

NTLM Authentication: Each time a user accesses a different resource, NTLM sends the hashed credentials over the network. This repeated transmission of hashes provides more opportunities for attackers to intercept and misuse them.

As hashes are stored on each machine, they are dispersed throughout the network by design.

Imagine a user named Alice who needs to access multiple network resources such as a file server, an email server, and a printer. For each access request, Alice’s workstation sends her hashed credentials over the network to the respective server. An attacker using a network sniffing tool can intercept these hashes during transmission. With enough intercepted hashes, the attacker can perform a pass-the-hash attack to gain unauthorized access to other systems by replaying the captured hashes.

Kerberos Authentication: Kerberos, in contrast, uses a ticket-based authentication mechanism that minimizes repeated authentication requests and significantly reduces credential interception risk. In Kerberos, the user authenticates once to the Key Distribution Center (KDC) and receives a Ticket Granting Ticket (TGT). This TGT is then used to request service tickets for accessing different resources without resending the user’s credentials over the network.

Combating NTLM Attacks: Common Strategies and Proactive Measures

The purpose of the following section is to examine techniques that relate to credential access, beginning with dumping the hashes stored in memory.

When a user logs in or authenticates with a service, their credentials are hashed, and these hashes are stored in the system’s memory. Attackers frequently use tools like Mimikatz to extract NTLM hashes from a machine’s memory. Once obtained, these hashes can be leveraged in pass-the-hash attacks to gain unauthorized access to other systems within the network.

Attackers typically begin by compromising a system with sufficient privileges to access the Local Security Authority Subsystem Service (LSASS) memory, where NTLM hashes are stored. Example of extracted NTLM and SHA1 hashes using Mimikatz.

From Network Traffic: Responder

In a network where NTLM authentication is used, tools like Responder pose a significant threat because they can capture NTLM hashes from network traffic through spoofing network service responses. Imagine a scenario where an attacker, Bob, infiltrates the same network segment as Alice, a network administrator. Bob sets up Responder on his laptop to listen on the network interface and spoof responses to NetBIOS Name Service (NBT-NS), LLMNR, and mDNS requests.

As Alice’s workstation sends out network requests to resolve hostnames, Responder intercepts these requests and pretends to be the legitimate network service. When Alice’s machine authenticates to the spoofed service, it sends her NTLM hash, which Responder captures. For example, Responder might display an intercepted NTLMv2 hash such as alice::CONTOSO:1122334455667788:9988776655443322:0101000000000000800000….

Armed with this hash, Bob can perform an offline brute-force attack using tools like Hashcat to crack Alice’s password. However, more efficiently, he can use the captured hash directly in a pass-the-hash attack to gain unauthorized access to other systems on the network by authenticating as Alice.

The purpose of the following section is to examine techniques that relate to lateral movement:

Lateral movement leveraging captured hashes

Pass-the-Hash: PtH attacks exploit inherent weaknesses in NTLM authentication. Attackers use captured NTLM hashes to authenticate to other machines without needing the plaintext password.

From previous scenario, by executing a command like pth-winexe -U ‘CONTOSO\alice%1122334455667788:9988776655443322’ //target-server cmd – using PTH tool kit, Bob can open a command prompt on a target server as Alice, bypassing the need for the plaintext password. This can be done using various tools that support NTLM hash authentication, such as pth-winexe or pth-smbclient.

NTLM Relay: An NTLM relay attack involves intercepting an NTLM authentication request from a user and relaying it to a target server to gain unauthorized access. The attacker captures the NTLM hash and uses it to authenticate to another system as the legitimate user, exploiting trust relationships within the network.
He uses a tool like ntlmrelayx to relay the captured NTLM hash to another server on the network that trusts NTLM authentication. This server, not aware of the interception, processes the authentication as if it were genuinely from the original user.

Using Decrypted Password

Direct Login –> On-Premises: Decrypted NTLM passwords allow attackers to bypass security measures and gain direct access to on-prem systems. Attackers can extract and decrypt NTLM hashes from compromised machines using tools like Mimikatz.

Passwords decrypted in this way can be used for direct logins via remote desktop protocol (RDP) or secure shell (SSH), enabling lateral movement across the network with legitimate credentials, effectively circumventing MFA – assuming it is only enabled during initial login.

Direct Login –> SaaS: In environments where NTLM passwords are synchronized between on-prem systems and SaaS applications, decrypted passwords pose a significant threat. Cloud services such as Office 365, Salesforce, and Google Workspace can be accessed using these credentials. This expands the attack surface beyond the corporate network to include cloud resources, increasing the potential impact of the breach. For example, decrypting an admin’s NTLM password from the on-premises environment allows attackers to access the organization’s cloud services with the same level of privilege.
This emphasizes the need for robust encryption practices, strict access controls, and MFA across all services to protect against NTLM credential compromise.

Due to the one-way nature of NTLM hashes, it is not possible to directly decrypt plaintext passwords from NTLM hashes. It is possible to exploit these hashes using techniques like rainbow tables or brute-force attacks using tools like Hashcat.

From Capturing Credential Access to Lateral Movement

Imagine the following scenario: Bob, an experienced attacker, decides to exploit a company’s reliance on NTLM for network authentication. He sets up his laptop on the same network segment and configures Responder to capture NTLM authentication requests by listening on the network interface. As employees like Alice attempt to access network resources, Responder intercepts these requests and captures their NTLM hashes.

With these hashes in hand, Bob uses ntlmrelayx to relay them to a high-value target server at IP address 192.168.1.10. By running ntlmrelayx.py -t smb://192.168.1.10, Bob effectively forwards Alice’s captured hash to the server, which naively accepts the authentication and grants him access as if he were Alice. This allows Bob to explore the server’s file shares and potentially extract sensitive information, demonstrating the severe risk posed by NTLM relay attacks in an unprotected network environment.

---

Gaining Visibility into NTLM Usage

To protect themselves from all the ways attackers can leverage NTLM, organizations first need to gain visibility into where and how NTLM is used within their networks. This involves identifying all systems and applications that rely on NTLM for authentication. Regular network audits and monitoring tools can help achieve this visibility.

Silverfort enhances NTLM visibility by integrating its platform to monitor and protect all authentications within an organization’s environment. By doing so, Silverfort provides real-time visibility and risk analysis of NTLM authentication, allowing organizations to detect and mitigate potential threats effectively. Silverfort’s AI-driven risk analysis engine continuously monitors access attempts, creating detailed behavioral baselines for each user. This helps in identifying anomalous activities and potential risks associated with NTLM authentications.

Reducing NTLM Reliance efforts should be made to reduce the usage of NTLM to the bare minimum. Transitioning to more secure authentication protocols, such as Kerberos or modern cloud-based authentication mechanisms, can mitigate NTLM-related risks. Microsoft recommends using the Negotiate protocol, which prioritizes Kerberos and falls back to NTLM only when necessary.

Improve your organization’s security by gaining clear visibility into NTLM usage while identifying where NTLM is being used and take steps to minimize its reliance by transitioning to more secure authentication protocols.

Is NTLM an attack surface you want to address? Schedule a meeting with one of our experts here.