LLMNR and NBT-NS Poisoning: How One Misconfiguration Hands Over Your Credentials

Some of the most reliable attacks on a Windows network don't involve a single exploit. No CVE, no payload that EDR has to miss, no patch that would have saved you. The attacker just plugs into the same LAN as your users, runs a tool that has existed for over a decade, and waits for Windows to volunteer credentials. That is LLMNR and NBT-NS poisoning, and it remains one of the first things any internal pentester reaches for — because it still works almost everywhere.

What LLMNR and NBT-NS actually do

When Windows needs to resolve a name like fileserver01 and DNS comes back empty — a typo, a decommissioned share, a mapped drive that no longer exists — it does not give up. It falls back to two legacy broadcast protocols: Link-Local Multicast Name Resolution (LLMNR) and NetBIOS Name Service (NBT-NS). Both shout the same question to the entire local subnet: "Who is fileserver01?"

The fatal flaw is that these protocols are unauthenticated. There is no check on who answers. Any machine on the segment can reply "That's me," and the asking host believes it. On a healthy network nobody answers, and the lookup simply fails. On a compromised one, the attacker's machine answers every single time.

From a typo to your password hash

Here is the chain an attacker runs, end to end:

1. A user's machine broadcasts a failed name lookup — often something completely mundane the user never typed, generated by a stale Group Policy drive map or a misconfigured printer.
2. The attacker's tool (Responder is the classic) answers the broadcast, claiming to be the requested host.
3. The victim then tries to authenticate to the attacker, because it thinks it found the real server. Windows helpfully sends an NTLMv2 challenge-response — effectively the user's password hash.
4. The attacker either cracks that hash offline (weak passwords fall in minutes) or, far worse, relays it live to another machine where that user has rights.

The dangerous version isn't cracking — it's the relay. If SMB signing isn't enforced on the target, the attacker forwards the captured authentication straight to a server and gets a session as the victim, no password ever needed.

String those together and a single unattended laptop on a guest VLAN becomes a foothold to administer file servers, all from protocols Windows enabled for you.

Shutting it down on a machine

The good news: none of this is load-bearing on a modern network with working DNS. You can disable both protocols and enforce signing with no real loss of function.

1. Disable LLMNR

Turn off multicast name resolution entirely. Via Group Policy it lives under Computer Configuration → Administrative Templates → Network → DNS Client → Turn off multicast name resolution. The equivalent registry value:

Set-ItemProperty "HKLM:\Software\Policies\Microsoft\Windows NT\DNSClient" `
  -Name EnableMulticast -Value 0

2. Disable NBT-NS

LLMNR is only half the problem; NetBIOS over TCP/IP must go too, per interface. Set it to disabled (value 2) across every adapter:

$key = "HKLM:\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces"
Get-ChildItem $key | ForEach-Object {
  Set-ItemProperty -Path $_.PSPath -Name NetbiosOptions -Value 2
}

3. Enforce SMB signing

This is the control that neutralizes the relay, which is the dangerous part. When SMB signing is required, a relayed authentication can't be replayed against the target. Require it on both client and server roles:

Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters" `
  -Name RequireSecuritySignature -Value 1
Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters" `
  -Name RequireSecuritySignature -Value 1

4. Restrict NTLM where you can

The strongest endgame is to stop accepting NTLM authentication on servers that don't need it and move to Kerberos. That is a bigger project, but auditing outbound NTLM usage (Restrict NTLM: Outgoing NTLM traffic to remote servers) is a sane first step toward knowing who would even be affected.

Auditing it once is easy; keeping it true is the hard part

Every one of those settings is a registry value, which means every one of them can silently drift. A re-imaged machine ships with defaults. A new network adapter comes up with NetBIOS re-enabled. A "temporary" troubleshooting change to fix a flaky share never gets reverted. The hardening you applied last quarter is only as good as your ability to prove it is still in place today.

On a single machine you don't need a subscription to stay honest. WinSentinel is free and runs at full power on one box — all modules, no caps — so one command tells you whether LLMNR is off, whether NBT-NS is disabled on every interface, whether SMB signing is actually required, and how that rolls into your overall posture score:

winsentinel audit
winsentinel score

The network-posture checks flag a host still answering broadcast name resolution or accepting unsigned SMB exactly the way a reviewer would — but on every run, not once a year. Change something and re-run, and the score moves the moment you regress.

When one machine becomes fifty

The relay attack only needs one machine on the subnet that still has NBT-NS enabled or SMB signing off. Manually confirming the state of these four settings on every endpoint, forever, is exactly where good intentions collapse. That continuous, centralized assurance is what WinSentinel Pro is for: lightweight agents report each machine's posture to a central node, so a single host that drifts back to answering LLMNR or drops its signing requirement surfaces as a drift alert instead of a post-incident finding. The depth of each machine's audit is identical to the free single-machine scan — Pro adds the fleet rollup, history, and alerting you need to trust dozens of machines at once.

The takeaway

LLMNR and NBT-NS poisoning survives not because it is sophisticated, but because the defaults favor the attacker and the fixes are unglamorous toggles nobody re-checks. Disable both legacy protocols, require SMB signing so captured authentication can't be relayed, and start measuring your NTLM exposure. Then make the verification continuous — free on the machine in front of you, fleet-wide with Pro when one machine becomes many. The protocols that hand over your credentials are trivial to turn off. The discipline is in proving, every day, that they stayed off.