LLMNR & NBT-NS Poisoning

When DNS resolution fails, Windows falls back to LLMNR and NBT-NS — broadcasting “who has this name?” to the whole LAN. An attacker running a responder simply answers “that’s me,” the victim authenticates against it, and the attacker captures the NetNTLM hash to crack offline or relay onward. It’s a man-in-the-middle technique and one of the fastest ways to bootstrap Active Directory access, whether through pass-the-hash or NTLM relay into SMB on port 445.

How It Works

Tools like Responder listen for LLMNR/NBT-NS (and WPAD) broadcasts and poison them, capturing NetNTLMv2 hashes as victims authenticate. Captured hashes can be cracked offline with hashcat -m 5600, or — where SMB signing is disabled — relayed live with ntlmrelayx straight into a domain-joined host. Attackers often pair this with ARP spoofing to force traffic through a position where broadcasts are visible.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

How to Detect It

• Watch for unexpected LLMNR/NBT-NS answers on the LAN, especially from a single host answering many different name queries.
• Seed honeypot lookups for non-existent hostnames and alert on any response.
• Monitor for a spike in NTLM authentication attempts against one internal IP.

How to Defend Against It

• Disable LLMNR and NBT-NS via Group Policy and DHCP options — the fix that removes the attack surface entirely.
• Enforce SMB signing and LDAP channel binding so captured or relayed hashes can’t be used to authenticate.
• Segment the network so broadcast domains are small, and fix DNS so the fallback is never triggered in the first place.

Validating Your Defenses

An authorized internal test shows whether Responder-style poisoning still captures usable hashes on your LAN, and whether relay paths into AD are actually closed. Log every captured hash and relay path so the evidence lands in the pentest report instead of a scratch terminal.