Skip to main content

​
NetNTLMv1 Is Now Cryptographically Dead

Critical Security Notice: NetNTLMv1 should now be considered functionally equivalent to plaintext authentication. If your environment still permits NetNTLMv1, you are exposed to trivial credential compromise.

​
Overview

In 2025, Google/Mandiant released 8.6 TB of pre-computed rainbow tables targeting the NetNTLMv1 authentication protocol. The dataset covers over 1.1 quadrillion password permutations, reducing NetNTLMv1 credential recovery to a commodity operation achievable in under 12 hours on consumer-grade hardware.
This release was explicitly intended to accelerate protocol deprecation by eliminating the remaining cost and complexity barriers to exploitation.

​
What Changed

​
Before the Release

Prior to this release, NetNTLMv1 was widely acknowledged as weak but often tolerated due to:
Organizations maintained NetNTLMv1 support for:
  • Windows XP/Vista systems
  • Legacy printers and multifunction devices
  • Industrial control systems (ICS/SCADA)
  • Embedded devices with fixed firmware
  • Third-party software requiring NTLM
Common justification: “We need it for backwards compatibility.”
Pre-computed rainbow tables existed but:
  • Required significant storage (multiple TB)
  • Needed substantial compute resources
  • Were not widely distributed
  • Represented a barrier to entry for attackers
Security teams reasoned: “Exploitation is still difficult and expensive.”
NetNTLMv1 attacks required:
  • Specialized knowledge of the protocol
  • Custom tooling for capture and cracking
  • Access to computing clusters or expensive hardware
  • Time investment (days to weeks for cracking)
Result: Organizations prioritized other risks over NTLM deprecation.

​
After the Release

The public release of these tables removes all assumptions about attacker cost and complexity.
NetNTLMv1 exploitation is now:

Passive Capture

Attackers can passively capture NetNTLMv1 handshakes from network traffic without any interaction with targets.

Offline Cracking

Captured handshakes can be cracked offline in <12 hours, with no rate limits, lockouts, or detection.

Minimal Expertise

Pre-built tools and rainbow tables reduce the skill level required to near-zero. Script kiddies can exploit NetNTLMv1.

Consumer Hardware

Cracking runs on commodity hardware. No expensive GPU clusters or specialized equipment needed.
This shifts NetNTLMv1 from a legacy risk to a clear security liability.

​
Technical Background

​
NetNTLMv1 Protocol

NetNTLMv1 is a challenge-response authentication protocol:The critical weakness: the challenge-response can be precomputed for all possible passwords.

​
Attack Scenario

1

Network Capture

Attacker captures NetNTLMv1 traffic:
# Using Responder or similar tools
sudo responder -I eth0 -rdwv

# Or passive network sniffing
sudo tcpdump -i eth0 -w capture.pcap 'port 445'
Required: Network access (WiFi, VPN, compromised switch)
2

Extract Handshake

Parse captured traffic to extract challenge-response:
# Extract from packet capture
def parse_netntlmv1(pcap_file):
    packets = rdpcap(pcap_file)
    for packet in packets:
        if packet.haslayer(SMB):
            challenge = packet[SMB].SecurityBlob.Challenge
            response = packet[SMB].SecurityBlob.Response
            username = packet[SMB].SecurityBlob.UserName
            domain = packet[SMB].SecurityBlob.Domain
            return (challenge, response, username, domain)
3

Query Rainbow Tables

Look up captured handshake in rainbow tables:
# Download Google's rainbow tables (8.6 TB)
gsutil -m cp -r gs://net-ntlmv1-tables/tables ./

# Query for password
./ntlmv1-lookup --challenge 0123456789abcdef \
                 --response [captured_response] \
                 --tables ./tables/

# Result: Password recovered in <12 hours
4

Credential Reuse

Use recovered credentials for:
  • Lateral movement within network
  • Access to additional systems
  • Privilege escalation
  • Data exfiltration
  • Persistent access establishment

​
Security Impact

Any environment that still permits NetNTLMv1 is exposed to:

​
Credential Compromise via Captured Handshakes

  • Passive attack: No active exploitation required
  • Undetectable: Network capture leaves no logs
  • Offline cracking: No failed authentication attempts
  • High success rate: Rainbow tables cover common passwords

​
Lateral Movement Using Recovered Hashes

Once credentials are recovered:
  1. Authenticate to additional systems
  2. Access file shares and databases
  3. Compromise domain-joined workstations
  4. Escalate privileges if admin credentials captured
Service accounts are particularly vulnerable:
  • Often use NetNTLMv1 for legacy compatibility
  • Frequently have elevated privileges
  • Passwords rarely changed
  • May have access to multiple systems
  • Compromise can grant domain-wide access

​
High-Risk Scenarios

Flat Networks

Networks without segmentation allow:
  • Attacker to capture traffic across all VLANs
  • Lateral movement to any system
  • Single compromise leads to full breach

Legacy SMB Configurations

SMB shares configured for NetNTLMv1:
  • File server authentication compromised
  • Shared folder access stolen
  • Data exfiltration enabled

Shared Service Accounts

Service accounts used by multiple systems:
  • Compromising one grants access to many
  • Often have domain admin privileges
  • Difficult to detect misuse

No SMB Signing

Environments without enforced SMB signing:
  • Man-in-the-middle attacks trivial
  • Traffic easily intercepted
  • Relay attacks possible
Devices that silently negotiate NTLM fallback are particularly dangerous. Even if you think you’ve disabled NetNTLMv1, misconfigured devices may still use it.

​
Defensive Actions

​
Immediate Actions

1

Disable NTLMv1 Entirely

Windows Group Policy:
Computer Configuration
→ Windows Settings
→ Security Settings
→ Local Policies
→ Security Options
→ Network security: LAN Manager authentication level
→ Set to: "Send NTLMv2 response only. Refuse LM & NTLM"
Registry Key:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
"LmCompatibilityLevel"=dword:00000005
Test in a staging environment first! Disabling NTLMv1 may break legacy applications.
2

Enforce NTLMv2 Only

Configure all Windows systems to use NTLMv2:PowerShell Script:
# Enforce NTLMv2 on all domain systems
Set-GPRegistryValue -Name "Default Domain Policy" `
    -Key "HKLM\System\CurrentControlSet\Control\Lsa" `
    -ValueName "LmCompatibilityLevel" `
    -Type DWord `
    -Value 5

# Force GPO update
Invoke-GPUpdate -Force
3

Enable and Enforce SMB Signing

Prevent man-in-the-middle and relay attacks:Group Policy:
Computer Configuration
→ Windows Settings
→ Security Settings
→ Local Policies
→ Security Options
→ Microsoft network server: Digitally sign communications (always)
→ Enable
Registry:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters]
"RequireSecuritySignature"=dword:00000001
4

Audit NTLM Authentication Usage

Identify systems still using NTLM:Enable Logging:
# Enable NTLM auditing
auditpol /set /subcategory:"Logon" /success:enable /failure:enable

# Monitor Event IDs:
# 4624: Successful logon
# 4625: Failed logon
# Check for authentication package: "NTLM"
Analyze Logs:
# Find NTLM usage
Get-WinEvent -FilterHashtable @{
    LogName='Security'
    ID=4624
} | Where-Object {
    $_.Properties[8].Value -eq 'NTLM'
} | Select-Object TimeCreated, @{N='Username';E={$_.Properties[5].Value}}, @{N='Source';E={$_.Properties[18].Value}}

​
Short-Term Actions

Network Scanning:
# Use Nmap to detect NTLM support
nmap -p 445 --script smb-security-mode 192.168.1.0/24

# Look for output:
# Message signing disabled
# LM: Enabled (weak)
Active Directory Query:
# Find computers with old OS versions
Get-ADComputer -Filter {OperatingSystem -like "*XP*" -or 
                        OperatingSystem -like "*2003*" -or
                        OperatingSystem -like "*Vista*"} |
    Select-Object Name, OperatingSystem
Options for legacy systems:
  1. Network Isolation:
    • Move to separate VLAN
    • Restrict access with ACLs
    • No communication with production network
  2. Firmware Updates:
    • Check for manufacturer updates adding NTLMv2 support
    • Apply patches if available
  3. Replacement:
    • Budget for new hardware supporting modern protocols
    • Prioritize business-critical systems first
  4. Protocol Gateway:
    • Deploy intermediary supporting both protocols
    • Translate between legacy and modern auth
Priority for rotation:
  1. Service accounts with elevated privileges
  2. Domain administrator accounts
  3. Accounts used by multiple systems
  4. Long-lived credentials (>1 year old)
PowerShell Script:
# Find service accounts using NTLM
$ntlmAccounts = Get-WinEvent -FilterHashtable @{
    LogName='Security'
    ID=4624
} | Where-Object {
    $_.Properties[8].Value -eq 'NTLM' -and
    $_.Properties[5].Value -like '*svc*'
} | Select-Object -ExpandProperty Properties[5].Value -Unique

# Rotate passwords
foreach ($account in $ntlmAccounts) {
    $newPassword = Generate-SecurePassword -Length 32
    Set-ADAccountPassword -Identity $account `
        -NewPassword (ConvertTo-SecureString $newPassword -AsPlainText -Force) `
        -Reset
    Write-Host "Rotated password for $account"
}

​
Long-Term Actions

1

Remove NTLM Where Kerberos is Viable

Kerberos Advantages:
  • Mutual authentication (prevents spoofing)
  • Ticket-based (no passwords on wire)
  • Time-limited tickets (reduces replay risk)
  • Industry standard protocol
Migration Path:
# Configure Kerberos-only authentication
Set-GPRegistryValue -Name "Security Policy" `
    -Key "HKLM\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters" `
    -ValueName "AllowNTLM" `
    -Type DWord `
    -Value 0
2

Migrate to Certificate-Based Authentication

PKI Benefits:
  • No password vulnerabilities
  • Strong cryptographic authentication
  • Supports smart cards and hardware tokens
  • Centralized certificate management
Implementation:
  • Deploy Active Directory Certificate Services
  • Issue user and computer certificates
  • Configure smart card logon
  • Enable certificate authentication for services
3

Treat NTLM as Deprecated

Organizational Policy:
“NTLM is a deprecated protocol and will not be supported for new applications or services. Existing NTLM usage must be justified and remediated.”
Enforcement:
  • No new applications may use NTLM
  • Existing NTLM usage requires exception approval
  • Annual review of NTLM exceptions
  • Quarterly progress reports on NTLM deprecation

​
Governance & Compliance Relevance

Allowing NetNTLMv1 in 2025+ environments should be considered a policy failure, not a technical limitation.

​
Frameworks and Standards

Relevant Controls:
  • IA-2: Identification and Authentication
    • NetNTLMv1 fails to provide adequate authentication strength
    • Recommendation: IA-2(1) Multi-factor authentication
  • IA-5: Authenticator Management
    • NetNTLMv1 hashes are equivalent to plaintext
    • Violates authenticator protection requirements
  • SC-8: Transmission Confidentiality
    • NetNTLMv1 exposes credentials in transit
    • Fails to meet confidentiality objectives
  • AC-17: Remote Access
    • Remote access using NetNTLMv1 is high risk
    • Recommendation: Certificate-based authentication

​
Detection and Monitoring

​
Identifying NetNTLMv1 Usage

Key Event IDs:
# Monitor for NTLM authentication
Get-WinEvent -FilterHashtable @{
    LogName='Security'
    ID=4624  # Successful logon
} | Where-Object {
    $_.Properties[8].Value -match 'NTLM|LM'
} | ForEach-Object {
    [PSCustomObject]@{
        Time = $_.TimeCreated
        User = $_.Properties[5].Value
        Source = $_.Properties[18].Value
        AuthPackage = $_.Properties[8].Value
    }
}
Alert Triggers:
  • Any NTLMv1 authentication event
  • Multiple failed NTLM attempts
  • NTLM usage from unexpected sources
Packet Inspection:
# Detect NetNTLMv1 in network traffic
from scapy.all import *

def detect_netntlmv1(packet):
    if packet.haslayer(SMB):
        auth_blob = bytes(packet[SMB].SecurityBlob)
        # NTLMv1 signature: NTLMSSP + specific offsets
        if b'NTLMSSP' in auth_blob:
            # Check for NTLMv1 response (24 bytes)
            if len(auth_blob) == 24:
                log_alert(f"NetNTLMv1 detected from {packet[IP].src}")
                return True
    return False

# Monitor network in real-time
sniff(filter="port 445", prn=detect_netntlmv1)
Splunk Query:
index=windows EventCode=4624 OR EventCode=4625
| search Authentication_Package IN ("NTLM", "LM")
| stats count by Authentication_Package, Account_Name, Source_Network_Address
| where Authentication_Package="NTLM"
| sort -count
ELK Query:
{
  "query": {
    "bool": {
      "must": [
        {"match": {"event.code": "4624"}},
        {"match": {"winlog.event_data.AuthenticationPackageName": "NTLM"}}
      ]
    }
  },
  "aggs": {
    "by_user": {
      "terms": {"field": "winlog.event_data.TargetUserName"}
    }
  }
}

​
Reference

Google Cloud Storage - NetNTLMv1 Rainbow Tables

Access the 8.6 TB public dataset of pre-computed NetNTLMv1 rainbow tables
The rainbow tables are intentionally made public to force organizations to deprecate NetNTLMv1. This is not a theoretical vulnerability—it’s a practical, commodity attack.

​
Summary

Bottom Line: NetNTLMv1 is cryptographically dead. Disable it immediately.
Key Points:
  1. 8.6 TB of rainbow tables covering 1.1+ quadrillion passwords are publicly available
  2. Cracking takes <12 hours on consumer hardware
  3. Any NetNTLMv1 usage is a critical security vulnerability
  4. Immediate action required: Disable NTLMv1, enforce NTLMv2, enable SMB signing
  5. Long-term goal: Migrate to Kerberos or certificate-based authentication

Disable Now

Turn off NetNTLMv1 in Group Policy immediately

Audit Usage

Identify all systems still using NTLM authentication

Migrate Away

Plan migration to Kerberos or PKI-based auth
Author: Zepher Ashe
License: CC BY-NC-SA 4.0
Last Updated: 2025

Build docs developers (and LLMs) love

Get started for freeTalk to us