LLMNR and NBT-NS Poisoning: Capturing Hashes on a LAN

LLMNR poisoning is the trick that turns a mistyped hostname on a Windows network into a pile of captured credentials, and it works because of how Windows looks up names when its first choice comes back empty. A workstation asks for a share that does not exist, DNS has no answer, and Windows quietly shouts the same question to the whole subnet. Anyone listening can shout back "that is me", and the moment the workstation believes it, it tries to authenticate to the attacker. This guide walks the full chain in a lab: why the fallback exists, how the poisoning happens, what you actually capture, and how a defender closes the hole for good.

Read it top to bottom the first time to build the model, then keep it open as a reference. Every command here is for a subnet you own or are explicitly authorized to test, such as the internal range 10.10.10.0/24 used in the worked example.

01What you need in the lab

You need very little to reproduce LLMNR poisoning, which is part of why it stays so common. A single attack host on the same broadcast domain as the Windows clients is enough, because the fallback protocols are link-local and never cross a router. If you can see the victims' subnet with a layer-two broadcast, you are in range.

A practical lab is one Linux box with Responder installed, two or three Windows clients joined to a domain, and a file server. Put the attacker at 10.10.10.5, a victim workstation at 10.10.10.25, and a second server at 10.10.10.30. Nothing else is required. The clients do not need to be unpatched or misconfigured, because the behavior you are abusing is on by default.

02How Windows name resolution falls back to LLMNR, NBT-NS and mDNS

Windows name resolution falls back to LLMNR, NBT-NS and mDNS whenever DNS cannot answer, and that fallback is exactly what LLMNR poisoning abuses. When a host needs to turn a name like fileserver01 into an address, it works down a fixed order: the local hosts file and DNS cache first, then the configured DNS servers, and only if those come back with nothing does it ask the local link directly.

Those link-local protocols are the fallback. They were built for small networks with no DNS at all, and all three ask the same question by shouting it to neighbors instead of a trusted server.

The problem is trust. A DNS answer comes from a server the host was told to trust. A multicast answer comes from whoever replies first, with no authentication at all. On a quiet subnet the only replies are from real hosts, so nobody notices. Add one attacker who answers everything, and the fallback becomes a credential funnel.

03How a failed lookup becomes an attacker-answered one

A failed lookup becomes an attacker-answered one the instant the attacker replies to the multicast question faster than nobody, which is a low bar when the real host does not exist. The classic trigger is a typo. A user opens \\fileserver1 when the share is really \\fileserver01, or clicks a stale shortcut, or an application probes for a print server that was decommissioned. DNS returns nothing because the name is wrong, so Windows falls through to LLMNR and NBT-NS.

The attacker's tool has been listening on UDP 5355 and 137 the whole time. It sees the query for the bad name, crafts a reply claiming the attacker's own IP is that host, and sends it. The victim has no way to tell a forged answer from a real one, because these protocols carry no signature or server identity. The victim now believes the attacker is fileserver1.

What happens next is the part that matters. The victim wanted a file share, so it opens an SMB connection to that address and, because it is a domain machine reaching what it thinks is a domain resource, it offers to authenticate automatically with the logged-on user's account. That automatic Windows authentication, handed to an attacker who never asked for it, is the whole prize.

04What you actually capture: a NetNTLM challenge, not the NT hash

What you capture from LLMNR poisoning is a NetNTLM challenge-response, and it is worth being precise about that, because the name confuses people. You do not get the user's NT hash, the fixed value stored on the domain controller. You get the output of a one-time handshake where the server sends a random challenge and the client proves it knows the NT hash by computing a response over that challenge.

The distinction has two practical consequences. First, you cannot pass a NetNTLMv2 capture the way you pass an NT hash, because it is tied to a single challenge and is useless for a fresh login. Second, because the response was computed from the NT hash and a known challenge, you can test password guesses offline until one reproduces the response, or you can forward the live handshake to another server before it expires. Those two paths, cracking and relaying, are the rest of the attack.

There are two generations of this response. NetNTLMv1 is older, weak, and increasingly rare because it can be reduced to a form that cracks almost instantly. NetNTLMv2 is what you will see on any current domain, and it resists cracking far better, so a strong password genuinely protects it.

05Running Responder to answer and capture in a lab

Responder is the tool that answers the poisoned queries and records the handshakes, and it does the whole job with one command. It listens on the LLMNR, NBT-NS and mDNS ports, replies to queries with your interface address, and stands up fake SMB and HTTP servers that collect whatever authenticates to them. By default it writes every capture to a log directory and to a local database.

# 0xpriv.dev/network  -  answer and capture on the lab interface
# listen on eth0, poison LLMNR/NBT-NS/mDNS, serve the fake SMB/HTTP endpoints
sudo responder -I eth0

# passive first: watch what names are being requested without answering any
sudo responder -I eth0 -A

Start in analyze mode with -A on a real assessment. It poisons nothing and only reports the queries flying past, which tells you which names are being asked for and how noisy the subnet is before you decide to answer. When you switch to the active command, Responder begins replying and the first captures usually arrive within minutes on a busy network.

# sudo responder -I eth0
[+] Listening for events...
[*] [LLMNR]  Poisoned answer sent to 10.10.10.25 for name fileserver1
[SMB] NTLMv2-SSP Client   : 10.10.10.25
[SMB] NTLMv2-SSP Username : CORP\jmorris
[SMB] NTLMv2-SSP Hash     : jmorris::CORP:1122334455667788:9A3C...truncated...:0101000000000000...

That single line with the username and the long colon-separated value is a full NetNTLMv2 capture. Copy it, or pull it from the log directory, into a file for the next step. Responder also saves each capture under its own logs folder so you do not have to scrape the console.

06Cracking NetNTLMv2 offline with hashcat

Cracking NetNTLMv2 offline is the first thing to try with a capture, and hashcat does it with mode 5600. That mode number is specific to NetNTLMv2, so it is worth memorizing: 5600 is NetNTLMv2 and 5500 is the older NetNTLMv1. Save the captured line to a file exactly as Responder printed it, point hashcat at a wordlist, and let it test guesses against the challenge until one matches.

# crack a NetNTLMv2 capture: mode 5600 is NetNTLMv2 (5500 is NetNTLMv1)
hashcat -m 5600 captured.txt /usr/share/wordlists/rockyou.txt

# add rules to stretch the wordlist against predictable passwords
hashcat -m 5600 captured.txt rockyou.txt -r rules/best64.rule

$ hashcat -m 5600 captured.txt rockyou.txt
JMORRIS::CORP:1122334455667788:9a3c...:0101...:Autumn2026!
Session..........: hashcat
Status...........: Cracked
Hash.Mode........: 5600 (NetNTLMv2)

If the password is in the wordlist or close to it, you have cleartext credentials for a domain user in seconds. If it is long and random, hashcat will grind and get nothing, which is the honest outcome and exactly why password policy is a real defense here rather than a checkbox.

07Relaying the handshake instead of cracking it

Relaying the handshake is the move when the password is too strong to crack, because it sidesteps cracking entirely. Instead of recording the authentication and attacking it later, you forward it live to a second server that accepts it, logging you in as the victim without ever learning the password. The catch is SMB signing: if the target server requires signing, the relayed session fails its integrity check and the attack stops. So the first step is finding servers where signing is not enforced.

netexec enumerates that for you and writes a ready-made target list of hosts without required signing.

# find hosts on the lab subnet that do NOT require SMB signing
netexec smb 10.10.10.0/24 --gen-relay-list targets.txt

# turn off Responder's own SMB/HTTP servers first so the relay tool can bind,
# then relay captured auth to the unsigned targets with impacket
impacket-ntlmrelayx -tf targets.txt -smb2support

$ netexec smb 10.10.10.0/24 --gen-relay-list targets.txt
SMB  10.10.10.25  445  WS-25   [*] Windows 10 (signing:True)  (not relayable)
SMB  10.10.10.30  445  SRV-30   [*] Windows Server (signing:False)
[*] wrote 1 host to targets.txt

When a poisoned victim authenticates, ntlmrelayx passes that handshake to 10.10.10.30, and because that server does not require signing it accepts the session. From there the relayed access is only as powerful as the victim account, so a captured local admin reused across machines is where relaying turns into real movement. Note that you must stop Responder's built-in SMB and HTTP servers (or disable them in its config) before relaying, because both tools want the same ports.

08A worked walkthrough on 10.10.10.0/24

This worked walkthrough on 10.10.10.0/24 ties the pieces into one clean run from a standing start. The attacker sits at 10.10.10.5, the victim workstation is 10.10.10.25, and the relay target is the unsigned server at 10.10.10.30.

The total setup is two commands and a wait. No exploit, no payload, nothing unpatched. The attack rides entirely on a protocol that is on by default and a user who typed a name that does not resolve.

09Detecting LLMNR poisoning on your network

Detecting LLMNR poisoning is realistic because the attack has a clear tell: something on the subnet is answering name queries that it has no business answering. A legitimate network has a small, stable set of hosts that respond to LLMNR and NBT-NS. A poisoner answers for names that do not exist and for hosts it is not, so an unexpected responder to a known-bad name is the strongest single signal.

The cleanest detection is a honeytoken. Have a monitoring host periodically request a hostname that is guaranteed not to exist, with no DNS record anywhere. On a healthy network that query gets no answer. On a poisoned one, the attacker's tool helpfully replies, and that reply is your alarm. The tool Respounder does exactly this, sending a crafted LLMNR query for a fake name and flagging whoever answers.

# detection honeytoken: ask for a name that must never resolve, alert on any answer
# a legitimate subnet returns nothing; a poisoner replies and gives itself away
nslookup totally-not-a-real-host-0xpriv 2>/dev/null

# passive view of who is answering multicast name queries on the wire
sudo tcpdump -ni eth0 'udp port 5355 or udp port 137'

Beyond honeytokens, watch for the behavioral pattern in logs: a host that suddenly serves SMB and HTTP to clients it never served before, bursts of NTLM authentication to an address that is not a known server, and the default service fingerprints that capture tools expose. Alert on the answering behavior rather than a payload string, because there is no malicious payload to match here, only an answer that should not exist.

10Shutting down LLMNR poisoning for good

Shutting down LLMNR poisoning is a configuration job, not a patch, because nothing here is a bug to fix. The fallback protocols are features that most networks never actually need, so the real defense is turning them off and making the authentication they leak useless to relay. These controls stack, and the first two alone remove the attack surface on a properly run domain.

If you can only do one thing today, disable multicast name resolution by GPO and verify it with a Responder analyze-mode run from the lab. If the queries dry up, the surface is gone.

11FAQ

12Wrapping up

LLMNR poisoning is not a clever exploit, it is a default setting doing exactly what it was designed to do for the wrong audience. A name fails to resolve, Windows asks the whole subnet, and an attacker answers. The fix is just as plain: turn off the multicast fallback, require SMB signing so leaked handshakes cannot be relayed, and keep passwords strong enough that the ones you do leak never crack. Run Responder in analyze mode against your own network, see how much is being asked for, and you will understand both the attack and the one-line policy that ends it.