All posts

Defending Against LLMNR and NBT-NS: The Responder Attack Every Windows Machine Invites

Your machine hardens its passwords, disables SMBv1, and locks down RDP - and then, the moment DNS hiccups, it shouts its credentials onto the local network. LLMNR, NBT-NS, mDNS and WPAD are the legacy name-resolution fallbacks that make the single most reliable attack on any Windows LAN work. Here's how they leak, and how WinSentinel checks they're off.

If you've ever watched a penetration tester get Domain Admin, there's a good chance the first move was almost embarrassingly simple: they plugged into the network, ran a tool called Responder, and waited. Within minutes, Windows machines started handing over authentication hashes - no exploit, no malware, no CVE. Just Windows doing exactly what it was designed to do. That design is broadcast name resolution, and it is the quietest own-goal in the whole platform.

How name resolution falls back to shouting

When a Windows machine needs to turn a name like fileserver into an IP address, it tries DNS first. But if DNS returns nothing - a typo, a decommissioned host, a stale mapped drive, an app probing for a server that doesn't exist - Windows doesn't give up. It falls back to asking the entire local network segment: "Does anyone here know who fileserver is?" Three separate legacy protocols carry that broadcast:

The fatal flaw: none of these are authenticated. Any device on the segment can answer. So an attacker's machine simply replies to every query: "Yes, fileserver is me." The victim believes it, connects, and - because it thinks it's talking to a legitimate Windows resource - automatically authenticates with the logged-in user's credentials.

What the attacker actually gets

The victim doesn't send a password. It sends a NetNTLMv2 response - a challenge/response derived from the user's password hash. That's still catastrophic, in two ways:

The uncomfortable part: this requires zero interaction from the victim. A background service probing for a name that no longer resolves is enough to trigger the leak. The user is doing nothing wrong and nothing unusual.

WPAD: the same trick, aimed at your web traffic

There's a fourth protocol that rides the exact same weakness. WPAD (Web Proxy Auto-Discovery) is the "Automatically detect settings" checkbox in Windows proxy configuration. When enabled, the machine asks the network for a host literally named wpad and downloads a proxy-configuration script from it. An attacker who answers the wpad query - via DNS, LLMNR, or NBT-NS - hands the victim a malicious proxy config and man-in-the-middles its web traffic, harvesting credentials and injecting content. Same root cause (unauthenticated name resolution), bigger blast radius.

The fix is to simply turn the fallbacks off

Here's the good news that makes this such a high-value hardening: in almost every modern environment, these fallbacks provide no legitimate value. Real hosts resolve through DNS. The only things relying on LLMNR/NBT-NS are typos, dead mappings, and attackers. So you can disable them outright:

Why this belongs in a scanner, not a one-time GPO

The trap with name-resolution hardening is that it's spread across four different mechanisms in three different registry hives, plus a per-interface NetBIOS setting that a single re-imaged laptop or freshly-added NIC quietly resets to the DHCP default. You can set the GPO and still have one adapter on one machine happily answering NBT-NS broadcasts - which is all an attacker needs. "We disabled LLMNR" is a claim; "no interface on this machine answers a broadcast name query" is a fact you have to re-verify.

That's exactly what WinSentinel's new Name Resolution module does. On every scan it reads the LLMNR policy, each interface's NetbiosOptions value, the mDNS setting, and the WPAD posture, and reports each as a plain pass or warning. A NetBIOS value it can't read is treated as still-exposed, never a silent pass - because the DHCP default is "on". If one interface out of six is still exposed, you see it.

Run it

The Name Resolution module ships in the free, open-source WinSentinel CLI - like every single-machine audit, it's unlimited and local-only:

dotnet tool install --global WinSentinel.Cli
winsentinel --audit

Look for the Name Resolution category in the report. Each warning comes with the exact PowerShell to close it. It's the difference between hoping the Responder attack won't work on your machines and knowing it can't.