NetNTLMv2 Hash Cracking and the Case Against Legacy Authentication

From network port to cracked credential in under five minutes.

The tester plugs a laptop into a network port in a meeting room. They run a single tool — Responder — and wait. Within ninety seconds, a workstation on the same subnet broadcasts an LLMNR query for a hostname that doesn't exist in DNS. Responder answers the query, pretending to be the requested host. The workstation, trusting the response, sends its authentication attempt — including the logged-in user's NetNTLMv2 hash.

The tester copies the captured hash into hashcat. The password — Summer2025! — cracks in under four minutes against a standard wordlist with common mutations. The tester now has a valid domain credential. They authenticate to the network, enumerate Active Directory, and begin the escalation path that, in 85% of our internal engagements, ends at Domain Admin.

No vulnerability was exploited. No software was compromised. No zero-day was required. The attack worked because the network uses authentication protocols and broadcast resolution mechanisms that were designed decades ago — and never disabled.

How NTLM authentication actually works.

Understanding why NetNTLMv2 hashes are vulnerable requires understanding the protocol they come from. NTLM is a challenge-response authentication protocol — the server issues a challenge, the client responds with a cryptographic proof derived from the user's password, and the server validates the proof. The password itself never crosses the network.

That sounds secure. The problem isn't in the concept — it's in the implementation details and the ecosystem of protocols that trigger NTLM authentication in the first place.

The NetNTLMv2 hash — the response in Step 3 — is not a static password hash like NTLM. It's challenge-specific, so it can't be used directly for pass-the-hash attacks. But it can be cracked offline to recover the plaintext password, and it can be relayed in real time to authenticate to other services. Both attacks are trivially executed with standard tools.

How attackers harvest hashes without touching a single machine.

The most common method for capturing NetNTLMv2 hashes on an internal network doesn't require compromising a machine, exploiting a vulnerability, or even having valid credentials. It exploits broadcast name resolution protocols — LLMNR, NBT-NS, and mDNS — that exist for backwards compatibility and are enabled by default in virtually every Windows enterprise environment.

The attack is entirely passive from the target's perspective. No process is injected, no service is exploited, no file is created. The victim machine broadcasts a query, the attacker answers it, and the machine voluntarily sends its credentials. This is not a sophisticated attack — it's a fundamental design consequence of protocols that assume every device on the local network is trustworthy.

Fifteen minutes. Fourteen credentials. Two service accounts — one of which, as the engagement would later reveal, had Backup Operator privileges sufficient to extract the entire Active Directory database from the domain controller.

Why NetNTLMv2 hashes don't survive modern hardware.

A captured NetNTLMv2 hash is a cryptographic proof derived from the user's password. To recover the password, the attacker must try candidate passwords until one produces the same hash. This sounds computationally expensive — and it was, in 2003. In 2025, consumer-grade GPUs crack NetNTLMv2 hashes at rates that make all but the strongest passwords trivially recoverable.

Those numbers are for exhaustive brute-force of every possible 8-character combination. In practice, attackers don't brute-force randomly. They use wordlists compiled from billions of breached passwords, combined with rule sets that apply common mutations: Summer → Summer2025! → $umm3r2025!. A password that meets your complexity policy — uppercase, lowercase, number, special character, 10+ characters — often cracks in seconds because it follows a human-predictable pattern.

Eleven of fourteen hashes cracked. Seven in under 12 seconds. Two service accounts — both with passwords that hadn't changed in years, both following the pattern [Function][Year][Symbol]. A 79% crack rate is not unusual; across our internal engagement portfolio, we typically crack between 60% and 85% of captured NetNTLMv2 hashes within the first hour.

When cracking isn't even necessary.

Cracking recovers the plaintext password. But there's an even faster attack: relaying. Instead of capturing the hash and cracking it offline, the attacker forwards the authentication in real time to a different server — authenticating as the victim without ever knowing their password.

Relay attacks are instant — no cracking time, no GPU cost, no password complexity consideration. A 40-character randomly-generated password is equally vulnerable to relay as a 6-character dictionary word. The defence against relay is not stronger passwords — it's protocol-level controls: SMB signing, LDAP signing, EPA, and ultimately, eliminating NTLM entirely.

The legacy that enterprises can't seem to kill.

Microsoft has recommended against NTLM authentication for over a decade. Kerberos — the preferred authentication protocol in Active Directory since Windows 2000 — is stronger in every meaningful dimension. So why does NTLM remain enabled in virtually every enterprise we assess?

Every one of these reasons is understandable. None of them is a justification for continuing to expose the organisation to an attack technique that succeeds in under five minutes in the majority of internal pen tests. The reasons explain why NTLM persists. They don't explain why it should.

What the replacement looks like.

The path away from NTLM isn't a single switch — it's a layered strategy that addresses the protocol itself, the broadcast resolution mechanisms that enable capture, the signing controls that prevent relay, and the password policies that determine cracking resistance.

A phased approach to eliminating NTLM.

Disabling NTLM overnight in a production environment is not realistic. But a phased, audited, tested approach is entirely achievable — and the hardening that happens at each phase delivers measurable risk reduction long before the final goal of full NTLM elimination is reached.

Phase 1 alone — achievable in a fortnight with minimal operational risk — eliminates approximately 70% of the hash capture and relay attack surface. It's the highest-return security investment most enterprises can make, and it costs nothing beyond a few hours of Group Policy configuration.

NTLM deprecation is coming — whether you're ready or not.

Microsoft has signalled increasingly clearly that NTLM's days are numbered. In 2023, Microsoft announced that NTLM would be deprecated in future versions of Windows. Windows 11 24H2 introduced Kerberos IAKerb and Local KDC extensions specifically to cover scenarios that previously forced NTLM fallback — non-domain-joined devices, IP-based access, and local account authentication.

The trajectory is unmistakable: Microsoft is systematically removing the technical reasons for NTLM's existence. When NTLM is finally disabled by default in a future Windows release, organisations that haven't prepared will face a choice between emergency remediation and disabling the security control — the same pattern that has kept NTLM alive for decades.

The bottom line.

NetNTLMv2 hash capture and cracking is not a sophisticated attack. It requires no vulnerabilities, no exploits, and no special access — just a laptop on the network and a few minutes of patience. It works because enterprises run broadcast name resolution protocols that trust every device on the subnet, authentication protocols that expose crackable credentials to anyone listening, and password policies that produce predictable, human-patterned passwords that modern GPUs defeat in seconds.

The defences are available, well-documented, and free: disable LLMNR and NBT-NS, enforce SMB signing, enforce LDAP signing and channel binding, audit NTLM usage, restrict NTLM with exceptions, and ultimately disable it entirely. Phase 1 takes a fortnight and eliminates the majority of the attack surface. The full roadmap takes 6–12 months and removes NTLM entirely.

Microsoft is deprecating NTLM. The replacement protocols are ready. The only question is whether your organisation eliminates the risk proactively — on your timeline, with proper testing and controlled rollout — or reactively, when a pen test demonstrates Domain Admin in 90 minutes, or worse, when an attacker demonstrates it for real.