Unlike modern protocols, NTLM does not rely on ticketing systems or third-party identity providers during the initial exchange. It utilizes a Challenge-Response mechanism.
When a client (e.g., a workstation) attempts to access a resource on a target server (e.g., an SMB file share), the following sequence occurs:
ntds.dit), performs the exact same mathematical encryption on the Challenge, and compares its result with the client’s Response.
NTLMv2 was introduced to patch catastrophic cryptographic weaknesses in NTLMv1.
| Feature | NTLMv1 (Critically Weak) | NTLMv2 (Modern Standard) |
|---|---|---|
| Challenge Handling | Uses only the Server Challenge. | Combines the Server Challenge with a Client-generated Challenge. |
| Replay Attack Resistance | Highly vulnerable. | Incorporates a Timestamp into the response, making replay attacks significantly harder. |
| Cryptographic Strength | Uses weak DES encryption, easily cracked by Rainbow Tables (e.g., L0phtCrack). | Uses HMAC-MD5, providing much stronger cryptographic integrity. |
The Fundamental Flaw: While NTLMv2’s client challenge and timestamp successfully mitigate simple replay attacks, it does not fix the protocol’s core architectural sin: it still relies on the user’s NT Hash as the ultimate cryptographic secret.
Because of its architecture, NTLM exposes networks to two devastating attack vectors.
Pass-the-Hash (PtH)
If an attacker compromises a machine and dumps the LSASS memory, they extract the user’s NT Hash. Because NTLM only requires the NT Hash to encrypt the challenge (Step 3), the attacker never needs to crack the plaintext password. They simply pass the stolen hash into their own authentication request to move laterally.
NTLM Relaying
Unlike Kerberos, NTLM lacks Mutual Authentication. The client authenticates to the server, but the server does not prove its identity to the client. An attacker can position themselves as a Man-in-the-Middle (MitM). When a victim attempts to authenticate, the attacker intercepts the Type 1 message, relays it to a target server, receives the Type 2 Challenge, sends it back to the victim, and relays the victim’s valid Type 3 Response to compromise the target server.
If Kerberos is superior, why does NTLM traffic still exist on corporate networks? The protocol serves as an automatic fallback mechanism:
\\192.168.1.50\C$), the system automatically downgrades to NTLM.From a Blue Team perspective, tracking NTLM usage is a dual-purpose activity: discovering legacy technical debt and hunting for active lateral movement.
As covered in our Event 4624 & 4625 Analysis, an analyst can identify NTLM authentications on a target server by filtering successful network logons.
Domain Controllers log Event ID 4776 (“The computer attempted to validate the credentials for an account”) for every NTLM Netlogon validation request. A sudden spike in 4776 failure events is a massive red flag for a Password Spraying or Brute Force campaign.
// Detects successful NTLM Network Logons by Administrative accounts// Highly indicative of Pass-the-Hash lateral movement.SecurityEvent| where EventID == 4624| where LogonType == 3| where AuthenticationPackageName == "NTLM"// Filter for sensitive administrative accounts| where TargetUserName has_any ("admin", "svc_", "administrator")// Filter out expected legacy servers if applicable| where IpAddress != "192.168.10.100"| project TimeGenerated, Computer, TargetUserName, IpAddress, LogonProcessName| sort by TimeGenerated desc# Identify systems still utilizing NTLM to prepare for deprecationindex=windows sourcetype="WinEventLog:Security" EventCode=4624 Logon_Type=3 Authentication_Package="NTLM"| stats count by Target_User_Name, Source_Network_Address, host| sort - countUnderstanding NTLM’s flaws is the first step in Active Directory security. To understand how modern networks secure authentication and prevent NTLM Relaying, we must dive into its successor.
👉 Read the next architectural deep-dive: Kerberos Authentication