If you think you blocked NTLMv1 in your org, think again

Silverfort discovers an Active Directory Group Policy designed to disable NTLMv1 is easily bypassed due to a simple misconfiguration, allowing NTLMv1 authentications to persist.  

TL;DR 

  • News: Silverfort’s research team discovered a new way for attackers to use NTLMv1 in attacks, despite efforts to disable it. Using a misconfiguration in on-prem applications, attackers can bypass the Group Policy designed to stop NTLMv1 authentications. 
  • Why it matters: 64% of Active Directory user accounts regularly authenticate with NTLM, despite its known weaknesses and being deprecated by Microsoft. Many organizations attempted to solve the NTLMv1 problem with an Active Directory Group Policy. However, we discovered that this policy is flawed and allows NLTMv1 authentications to persist, creating a false sense of security and leaving organizations vulnerable. Attackers know NTLMv1 is a weak authentication protocol and actively seek it out as a method to move laterally or escalate privileges. 
  • Who’s affected: Any organization who uses third-party or home-grown on-prem applications and those who do not strictly use Windows machines. For example, if a Mac computer connects to a bank application, they could be compromised.  
  • Impact to organizations: An attacker sitting on a network can see the NTLMv1 traffic and crack the users’ credentials offline, leading to lateral movement and privilege escalation. Our POC emulates an application bypassing the fencing, validating this misconfiguration works to an attacker’s advantage. 
  • Result of disclosure: While Microsoft Security Response Center (MSRC) indicated the NTLMv1 bypass is not a vulnerability, they took proactive measures to enhance security by announcing the complete removal of NTLMv1 within two months of our disclosure, starting with Windows 11 version 24H2 and Windows Server 2025. 

We will be hosting a conversation on Thursday, February 6, 2025, where I’ll be taking people through the research in more detail and showing how to mitigate NTLMv1 authentications in the absence of a patch. You can register here.

Summary & Mitigations 

Despite its historical significance, NTLM represents a considerable security liability. Its outdated cryptographic methods, well-documented weaknesses and lack of modern security features (such as MFA and server identity validation) make it an attractive target for attackers. NTLMv1 hashes can be intercepted and used for authentication relay attacks or even dictionary attacks, granting attackers unauthorized access to sensitive systems. New NTLM vulnerabilities have been disclosed over the last few months, including a zero-day. More recently, CyberSky discovered an NTLM vulnerability exploited by Russian threat actors as part of an attack chain that delivers the open-source Spark RAT malware.    

Many organizations proactively use Microsoft’s Group Policy mechanism to stop NTLMv1, believing this will protect them from insecure NTLMv1 authentications. However, our research shows on-prem applications can be configured to enable NTLMv1, negating the Group Policy LAN Manager’s highest authentication level set in Active Directory. Organizations think they are doing the right thing by setting this group policy, but it’s still being bypassed by the misconfigured application. Until applications cannot be configured to authenticate with NTLMv1, the problem will persist.    

At Silverfort, we’ve seen many attempts to authenticate via NTLMv1 across our customer base. We work closely with our customers to map and detect NTLMv1 usage and apply risk-based fencing to reduce the risk of compromise. Without a patch for NLTMv1, businesses that used NTLMv1 in the past should consider the following:  

  1. Enable audit logs for all NTLM authentications in the domain. 
  2. Map all applications that use NTLM authentications in the first instance or as a fall back. 
  3. Detect vulnerable applications that request clients use NTLMv1 messages. 
  4. Fence all NTLM with a modern authentication method. 

Technical deep dive: NTLMv1 bypass in Active Directory 

NTLM (NT LAN Manager) is an old but widely used authentication mechanism commonly seen in Windows-based environments. Developed by Microsoft in the early 1990s, it was once the standard for authenticating users across a network, especially Microsoft’s Active Directory. However, despite being largely replaced by more secure protocols like Kerberos, NTLM continues to linger in legacy systems due to backward compatibility requirements. Measures were taken over the years to encourage the use of newer, more secure forms of authentication, such as blocking legacy NTLMv1 across the entire domain. In December of 2024, Microsoft announced the deprecation of NTLM active development. Even with these changes, questions remain. Do these actions create a more secure environment? Are we really getting closer to a complete removal of NTLMv1? Let’s dive into the technical details. 

NTLM 101 

NTLM is an authentication mechanism used to verify a user’s identity in Windows-based systems. NTLM consists of three messages: Negotiate, Challenge and Authenticate. The process begins with the client sending a Negotiate message to the server, indicating its intent to use NTLM for authentication and providing information about supported authentication options. The server then responds with a Challenge message, which includes a random number (the challenge) for the client to hash using its credentials. The client then sends the hashed response back to the server in the Authenticate message, which also includes the client’s username, domain and session information. The server validates the response and, if successful, grants access to the requested resource.  

NTLM is often used as the underlying authentication mechanism in higher-level protocols like SMB (Server Message Block) or HTTP. While NTLM is a standalone authentication protocol, it is often referred to as a “mechanism” because it is frequently implemented as part of other protocols or systems to provide authentication.  

Figure 1: Simple NTLM Authentication 

NTLMv1 vs NTLMv2 

NTLMv1 was first introduced in 1993. Security awareness at this time was low and NTLM was designed accordingly. Encryption, the first security mechanism, was in its infancy and only DES was supported. The second mechanism, the challenge, only consisted of an 8-byte server challenge. This number of random bytes was easier to guess in terms of breaking the cipher and discovering the user’s credentials. The last mechanism missing in the first version of NTLM was specifying the source and destination of the NTLM authentication. This very quickly led to the infamous attack method NTLM Relay, which positioned the adversary between the client and the server. If an NTLMv1 message was caught, it could be then used to reauthenticate the adversary to the application and even reuse it with a different protocol. For example, by transitioning NTLM authentication over SMB to NTLM over LDAP.  

The second version of NTLM – NTLMv2 – introduced mitigations for many of the security weaknesses detailed above. The first was the upgrade of the encryption method with the use of RC4, which strengthened the cipher and made it harder to brute-force. The second was the addition of the Client Challenge, which added another source of entropy to the computation of the cipher. The last and biggest modification to NTLM was the AV_PAIRS. This added extra fields to the NTLM Authenticate message, such as source client, destination server, domain and even SPN, which are a few of the fields that create a unique session key for every authentication. This protection made it difficult to perform relay attacks. 

Netlogon to evaluate NTLM 

The last piece of the puzzle is that the application server in Active Directory cannot evaluate the NTLM message on its own, simply because it does not have the user’s credentials stored. Instead, Microsoft uses the RPC Netlogon interface to evaluate the NTLM message remotely. The server must attach the NTLM message to the NetrLogonSamLogonEx function alongside the NTLM challenges. If the Domain Controller successfully recreates the message using the user’s stored credentials, then it will return success and follow the user’s Privilege Access Certificate (PAC) to perform authorization and a matching session key. If the evaluation failed, it would respond with the corresponding error. 

Figure 2: NTLM Authentication in Active Directory 

NTLMv1 disclosure 

The Group Policy mechanism is Microsoft’s solution to disable NTLMv1 across the network. The LMCompatibilityLevel registry key prevents the Domain Controllers from evaluating NTLMv1 messages and returns a wrong password error (0xC000006A) when authenticating with NTLMv1. This should eliminate NTLMv1 completely and require all application servers to provide NTLMv2. Does this eliminate NTLMv1? Let’s take a look.  

Figure 3: Reject NTLMv1 with GP enabled 

NTLMv1 bypass 

MS-NRPC is the specification of the Netlogon remote interface which describes all of its structures and functions. The NetrLogonSamLogon and its variants (NetrLogonSamLogonEx and NetrLogonSamLogonWithFlags) oversee passing the NTLM message from the server to the Domain Controller securely for evaluation. The function structure requires identity information to be passed alongside the NTLM message. As defined in section 2.2.1.4.15, the NETLOGON_LOGON_IDENTITY_INFO contains many fields such as domain name, username, workstation, and others. One interesting field is the ParameterControl. If we look at its flags, we can see that in the O value, it states, “Allow NTLMv1 authentication (MS-NLMP) when only NTLMv2 (NTLM) is allowed.”

Figure 4: A Screenshot of MS-NRPC documentation ParameterControl Flag Page 65. 

I wondered whether Microsoft really allows applications to use NTLMv1 when it is disabled. After building the data structure and simulating a malicious application, I discovered this flag bypasses the Group Policy that prevents using NTLMv1 authentication across the network. 

Figure 5: Bypass the NTLMv1 Group Policy.  

So how does this impact the elimination of NTLMv1? 

Applications that request clients to generate NTLMv1 will still be able to do so, even if the Group Policy is activated. It is important to note that Windows clients with LMCompatibilityLevel 3 and above will not generate NTLMv1 if requested. However, non-Windows clients are not protected. If an application requests an NTLMv1 message from a non-Windows client, the Domain Controller may approve the authentication and generate a session key. We use applications in our customer networks that attempt to use NTLMv1 even if the relevant Group Policy is activated. Because of this bypass, you cannot tell if a vulnerable application is fully mitigated. While many organizations attempt to discover all NTLMv1 use, they may not even be aware that some applications are still using NTLMv1. 

What should I do to fully mitigate? 

  1. Enable audit logs for all NTLM authentications in the domain. 
  2. Map all applications that use NTLM authentications in the first instance or as a fall back. 
  3. Detect vulnerable applications that request clients to use NTLMv1 messages. 
  4. Fence all NTLM with a modern authentication method. 

Silverfort’s Unified Identity Security Platform detects and protects all NTLM authentications. Our ITDR module can detect NTLMv1 applications and perform risk-based modern fencing to all vulnerable applications.  

Disclosure Process 

While MSRC indicated that the NTLMv1 bypass was not classified as a vulnerability, they took proactive measures by announcing the complete removal of NTLMv1 starting with Windows 11 version 24H2 and Windows Server 2025. The issue was reported on September 30th, 2024, and their response aligned with the official removal announcement in November 2024. By addressing legacy risks and phasing out outdated protocols, Microsoft demonstrates a strong commitment to enhancing security with a forward-thinking approach. This step underscores the importance of safeguarding systems with modern, secure alternatives like SSO or Kerberos and showcases how responsible reporting can contribute to meaningful improvements. 

Don’t forget to register for our technical webinar here!

Stop Identity Threats Now