NTLM v1, once a staple for securing Windows networks, is now a vestige of past security protocols, overshadowed by its significant vulnerabilities. In an Active Directory environment where NTLM v1 authentication is still allowed on the domain controller, it is possible to obtain Domain Admin privileges within a few hours or days.
How can I check whether my AD environment is at risk?
Check the following registry key for each domain controller in your environment:
HKLM\System\CurrentControlSet\Control\Lsa\LmCompatibilityLevel
This registry key should be on a domain controller at registry security level 5. All other options are not secure.
| Setting | Description | Registry security level |
|---|---|---|
| Send LM & NTLM responses | Client devices use LM and NTLM authentication, and they never use NTLMv2 session security. Domain controllers accept LM, NTLM, and NTLMv2 authentication. | 0 |
| Send LM & NTLM – use NTLMv2 session security if negotiated | Client devices use LM and NTLM authentication, and they use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication. | 1 |
| Send NTLM response only | Client devices use NTLMv1 authentication, and they use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication. | 2 |
| Send NTLMv2 response only | Client devices use NTLMv2 authentication, and they use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication. | 3 |
| Send NTLMv2 response only. Refuse LM | Client devices use NTLMv2 authentication, and they use NTLMv2 session security if the server supports it. Domain controllers refuse to accept LM authentication, and they’ll accept only NTLM and NTLMv2 authentication. | 4 |
| Send NTLMv2 response only. Refuse LM & NTLM | Client devices use NTLMv2 authentication, and they use NTLMv2 session security if the server supports it. Domain controllers refuse to accept LM and NTLM authentication, and they’ll accept only NTLMv2 authentication. | 5 |
Potential impact by changing the setting to security level 5:
Client devices that don’t support NTLMv2 authentication can’t authenticate in the domain and access domain resources by using LM and NTLM.
Attack Paths
Brute-force Vulnerability:
NTLM v1’s use of weak hashing (MD4) and encryption methods are easily compromised by today’s powerful computers. Attackers can quickly brute-force the hashes to reveal user passwords.
Relay Attacks:
NTLM v1 does not inherently protect against man-in-the-middle (MITM) attacks. Attackers can intercept the authentication process and relay credentials to access unauthorized resources, often without detection.
No Server Authentication:
The protocol lacks mutual authentication. While it confirms the client’s identity to the server, it does not verify the server’s identity to the client, leaving the door open to impersonation attacks.
Pass-the-Hash Technique:
Attackers who obtain the hashed version of a user’s password can authenticate to a server or service as the user, bypassing the need for the actual password. This exploit is particularly dangerous because hashes can be captured with relative ease and used indefinitely.
Rainbow Table Attacks :
NTLM v1 hashes do not use salting, making them susceptible to precomputed rainbow table attacks, where attackers use a large database of precalculated hashes to reverse-engineer passwords.
How to check whether legacy systems authenticate with NTLM v1
To find applications that use NTLMv1, enable Logon Success Auditing on the domain controller as first step.
The NTLM audit logs will look similar to this log (source Microsoft):
Sample Event ID: 4624
Source: Microsoft-Windows-Security-Auditing
Event ID: 4624
Task Category: Logon
Level: Information
Keywords: Audit Success
Description:
An account was successfully logged on.
Subject:
Security ID: NULL SID
Account Name: -
Account Domain: -
Logon ID: 0x0
Logon Type: 3
New Logon:
Security ID: ANONYMOUS LOGON
Account Name: ANONYMOUS LOGON
Account Domain: NT AUTHORITY
Logon ID: 0xa2226a
Logon GUID: {00000000-0000-0000-0000-000000000000}
Process Information:
Process ID: 0x0
Process Name: -
Network Information:
Workstation Name: Workstation1
Source Network Address:\<ip address>
Source Port: 49194
Detailed Authentication Information:
Logon Process: NtLmSsp
Authentication Package: NTLM
Transited Services: -
Package Name (NTLM only): NTLM V1
Key Length: 128In this example, the event is logged as ANONYMOUS LOGON and can therefore be ignored. See Microsoft recommendation:
“The logic of the NTLM Auditing is that it will log NTLMv2-level authentication when it finds NTLMv2 key material on the logon session. It logs NTLMv1 in all other cases, which include anonymous sessions. Therefore, our general recommendation is to ignore the event for security protocol usage information when the event is logged for ANONYMOUS LOGON.”
Ideally, you should use a SIEM to analyze the logs. However, especially smaller companies or dedicated OT environments do not have SIEM integration, which means that filtering the logs directly on the domain controller will be necessary. This event log filter can be imported as an .xml file and filters out the NTLM v1 logs directly. It is important that you check each individual domain controller.
<ViewerConfig>
<QueryConfig>
<QueryParams>
<UserQuery />
</QueryParams>
<QueryNode>
<Name>NTLMv1 Authentications</Name>
<Description>NTLMv1 Authentications</Description>
<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">
*[System[Provider[@Name='Microsoft-Windows-Security-Auditing'] and (EventID=4624)]] and
*[EventData[Data[@Name="TargetUserName"]!="ANONYMOUS LOGON"]] and
*[EventData[Data[@Name="LmPackageName"]="NTLM V1"]]
</Select>
</Query>
</QueryList>
</QueryNode>
</QueryConfig>
</ViewerConfig>The filter will mainly filter the following logs:
– Security logs with Event ID 4624
– TargetUserName not equals ANONYMOUS LOGON (Microsoft recommends to filter those logs out)
– LmPackageName equals NTLM V1
How to block NTLM v1
The best way to block NTLMv1 is via a group policy that is applied to all domain controllers.
Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “Network security: LAN Manager authentication level” –> change to “Send NTLMv2 response only. Refuse LM & NTLM”
Restart is not required after applying the group policies.
If you need support in this topic you are welcome to contact us!
For reference:
Audit use of NTLMv1 on a domain controller – Windows Server | Microsoft Learn
Network security LAN Manager authentication level – Windows 10 | Microsoft Learn
Leave a Reply