Plug a laptop into a Windows network and within twenty minutes you will usually hold a set of domain credentials, without exploiting a single vulnerability. Windows machines that cannot resolve a name through DNS shout the question onto the local network, and anything on that network can answer. That is LLMNR poisoning, and it is still the opening move in most internal tests we run.
How the attack actually unfolds
The attack works because Windows falls back to broadcast name resolution when DNS returns nothing. A user types a share name with a typo, or a login script points at a server decommissioned last year, and the workstation asks the whole subnet who owns that name.
Read More: 4 Multi-Functional Bags to Carry Laptops Safely
A tester’s machine replies that it does, the workstation authenticates to it, and the tester now holds an NTLMv2 challenge and response for that user. Tools such as Responder automate all of it. From there the credential goes one of two ways: offline cracking, which succeeds against a surprising share of eight character passwords, or relaying it straight to another machine that does not enforce SMB signing.
Why it survives in well managed estates
This protocol is enabled by default, and defaults are exactly where these problems live. The NSA and CISA joint advisory on the top ten cybersecurity misconfigurations, published in October 2023, put default configurations of software at number one on the list, ahead of missing patches. Legacy name resolution fits that description precisely. Nobody chose to run it. It came with the operating system, it causes no visible problem, and it never appears on a vulnerability scan because there is no vulnerability to find. The setting is working exactly as designed.
“We have captured a domain administrator hash in the first hour of a test at a company that had just passed an external audit with no findings. The audit asked whether patching was current, and it was. Nobody asked whether a laptop in a meeting room could answer name lookups for the finance team, and that question is the one that matters once somebody is inside the building.”
William Fieldhouse, Director, Aardwolf Security Ltd
Turning it off without breaking anything
You should disable both LLMNR and NetBIOS name resolution through group policy, then watch for what breaks. LLMNR goes off with a single policy setting under DNS Client. NetBIOS over TCP/IP is disabled per adapter, which is more work, and DHCP option 001 can push it. Before you do either, run a short capture to see what is currently being requested on the wire, because a legacy application that depends on broadcast resolution will announce itself immediately. Most estates find nothing depends on it. Where something does, that application is usually old enough to deserve a separate conversation.
The second half of the fix
Disabling the protocol stops the capture, and SMB signing stops the relay. Enforce signing on servers and workstations, since without it a captured authentication can be forwarded to another machine and used directly, no cracking required. Then raise the cost of the credentials themselves by moving to longer passphrases and by keeping privileged accounts off ordinary workstations. An internal network penetration test will confirm whether the changes hold, and regular vulnerability scanning covers the patch level in between, though it will never surface this particular problem on its own.
Frequently asked questions about LLMNR poisoning
Two questions come up in every debrief where this finding appears.
Does this need an attacker inside the building?
It needs a presence on the internal network, which is not the same thing. A compromised laptop, a device on the guest network with a route inside, or contractor kit plugged into a meeting room port all provide it.
Read More: 4 Stylish Phone Cases Protecting Devices from Accidental Damage
