Capturing NetNTLMv2 with Responder and cracking it offline

The fastest way into an Active Directory environment is often to let the network hand you a hash. You do not phish anyone, you do not exploit a CVE. You sit on the wire, answer a name-resolution query that nobody should be sending, and a domain user authenticates to you.

That authentication is a NetNTLMv2 response, and capturing it is the bread and butter of internal pentesting.

Why the hash lands in your lap

Windows resolves names in a specific order. DNS first. When DNS fails, the host falls back to broadcast protocols: LLMNR (UDP 5355), NBT-NS (UDP 137), and on newer stacks mDNS. These protocols trust whoever answers first. There is no authentication on the response.

So when a user fat-fingers a share path, mistypes a hostname, or some service blindly looks up wpad, the request misses DNS and gets shouted across the broadcast domain. Responder answers it. It claims to be the host the victim wanted, the victim tries to authenticate over SMB or HTTP, and Responder collects the NetNTLMv2 exchange.

responder -I eth0 -wv

-I picks the interface. -w starts the rogue WPAD proxy, -v is verbose so you watch the captures roll in. By default it poisons LLMNR, NBT-NS and MDNS and stands up SMB and HTTP listeners to harvest the response. Leave it running on a quiet engagement and the captures accumulate on their own.

mitm6 is the IPv6 sibling. Most networks run dual-stack but never configured DHCPv6, so mitm6 becomes the rogue IPv6 DNS server, and now you are poisoning actual DNS lookups instead of waiting for fallback. Pair it with ntlmrelayx and the capture turns into a relay.

What a NetNTLMv2 actually is

The line Responder drops looks like this:

jdoe::CONTOSO:1122334455667788:6E0C...A1:0101000000000000...

That is the NetNTLMv2 hash format, and the shape matters:

user::DOMAIN:serverchallenge:HMAC:blob

The serverchallenge is the 8-byte random the server (you, the rogue listener) sent. The HMAC is an HMAC-MD5 keyed on the NT hash of the user's password, computed over the challenge and the blob. The blob carries the client challenge, a timestamp, and target info.

The cleartext password never crosses the wire. What you have is a response that proves the user knows the password, bound to one challenge you chose. That binding is the whole point and it is why this is not a reusable credential.

NetNTLMv2 is not pass-the-hash material

This trips people up constantly. You captured a hash, so you want to pass it. You cannot.

Pass-the-hash replays the static NT hash, the 16 bytes stored in the SAM or NTDS. NetNTLMv2 is not that. It is HMAC output computed live against a one-time challenge. Replaying it gets you nothing because the next authentication uses a different server challenge, and your old HMAC will not validate.

You have exactly two moves. Crack it to recover the password, or relay it before the session dies.

Cracking it

Drop the full line into a file and point hashcat at mode 5600:

hashcat -m 5600 capture.txt rockyou.txt -r /usr/share/hashcat/rules/best64.rule

NetNTLMv2 is HMAC-MD5, which is fast. A single modern GPU chews through it at billions per second, so this behaves like cracking NTLM directly: a wordlist plus a rule set clears the weak passwords in minutes. John does the same job:

john --format=netntlmv2 --wordlist=rockyou.txt capture.txt

The catch is the same catch as always. Fast hash, weak password, you win fast. Fast hash, fourteen random characters, you win never. Cracking recovers the cleartext, which is worth more than a relay because you can reuse a password across the domain. A relay gets you one session on one box.

When to relay instead

If the password is strong enough that cracking is hopeless, you do not need it. Relay the authentication straight to another host while the session is live.

ntlmrelayx.py -tf targets.txt -smb2support

The hard requirement: SMB signing must not be enforced on the target. Signing binds the authenticated session to the channel, so a relayed response fails the integrity check. Domain controllers enforce signing by default. Member servers and workstations very often do not, and those are your relay targets. Relay to SMB for command execution or to LDAP for tricks like RBCD, and you get access without ever knowing the password.

A relay also bypasses the strong-password problem entirely. The user could have a sixty-character passphrase and you would not care, because you never crack it. You just borrow the authentication.

The defender's side

Kill the poisoning surface first. Disable LLMNR and NBT-NS through Group Policy and the DHCP scope respectively, because almost nothing legitimate needs them once DNS is healthy. That alone removes most of Responder's catch. Disable mDNS where you can, and if you do not use IPv6, turn it off or pin DHCPv6 so mitm6 has nothing to hijack.

Then enforce SMB signing everywhere, not just on the DCs. Required signing is what turns a successful capture into a dead end, because the attacker can capture all day and never relay. Combine it with channel binding (EPA) on HTTP and LDAP endpoints to close the relay paths that do not run over SMB.

And the structural fix that survives everything: passwords long enough that the capture, even when it happens, never cracks. If signing is on and the password is strong, the attacker is left holding a hash that is good for nothing. That is the state you want every workstation in.