Everyone says turn off LLMNR and NBT-NS and the finding goes away. Do it. But that's the half of the attack that hurts less.
The half that hurts is the relay, and the setting that stops it lives somewhere else.
This is the finding I keep seeing at the top of internal pentest reports, year after year.
It's also the one that gets fixed last, because it's "just a GPO" and nobody on the team owns the GPO.
Why a typo asks the whole subnet
Windows tries the hosts file and DNS first. When DNS comes back empty, it falls back to LLMNR on UDP 5355, multicast to 224.0.0.252, and then to NBT-NS, broadcast on UDP 137.
So every mistyped share path is a question shouted at everyone on the segment. So is every mapped drive pointing at a file server that got decommissioned in 2019, and every app still hardcoded to a hostname nobody remembers.
Nobody on that subnet is supposed to answer unless they own the name.
Nothing enforces that.
What Responder does with the question
Responder answers every one of those questions with "yes, that's me." The victim believes it, tries to authenticate, and hands over an NTLMv2 challenge-response.
Inveigh does the same job in PowerShell or .NET when you can't drop a Python tool on the box. (Responder came out of Trustwave SpiderLabs over a decade ago. A lot of internal testers still run it before their coffee's done.)
From there it goes one of two ways. ATT&CK files both under T1557.001.
- Crack it offline. Hashcat mode 5600 takes NetNTLMv2. A strong password survives this. A Summer2026! does not.
- Relay it. Impacket's ntlmrelayx forwards the authentication live to a host that doesn't require SMB signing. No cracking, so password strength doesn't matter at all. If the victim is a local admin on the target, the attacker is too.
That second path is why I won't let anyone rate this as a medium. I've argued that one more times than I can count.
Watch 5355 and 137 before you touch a GPO
If you can't switch it off tomorrow because someone is worried about a line-of-business app, detect it first.
Pull flow data for UDP 5355 and UDP 137 and look at the responses, not the queries.
Queries are noise. A healthy network has very few LLMNR responses, and they come from the host that owns the name. One machine answering for dozens of different names it has no business owning is Responder, or something just as bad.
The cheap trick is a canary.
Have a box ask LLMNR for a name that doesn't exist on a schedule, and alert if anything answers. Respounder is an open-source tool built for exactly this.
In CIS v8 terms the flow logging is Safeguard 13.6 and the sensor is 13.3. Both are IG2.
The two settings, in the words the console uses
Neither of these is findable by guessing, so here they are verbatim.
- LLMNR: Computer Configuration, Administrative Templates, Network, DNS Client, Turn off multicast name resolution, set to Enabled. That writes EnableMulticast = 0 under HKLM\Software\Policies\Microsoft\Windows NT\DNSClient.
- NBT-NS: there's no clean GPO. It's per adapter, under IPv4, Advanced, the WINS tab, Disable NetBIOS over TCP/IP. At scale, push DHCP option 001 in the Microsoft vendor class with a value of 0x2. The other route is a startup script that sets NetbiosOptions to 2 on every Tcpip_{GUID} key under HKLM\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces.
I don't care which NBT-NS route you take.
DHCP misses anything with a static IP, and the script misses anything that isn't domain joined. Pick the one that covers more of your fleet and clean up the rest by hand.
I'd test on one OU for a week first. The thing that breaks is almost always a printer or an old app resolving a short name that DNS never had.
Where I disagree with the usual fix
Here's my hill. SMB signing matters more than either of those settings.
Turn off LLMNR and NBT-NS and Responder still has mDNS on UDP 5353, which it poisons just as happily. An attacker on the segment has other ways to coerce authentication anyway. Require signing and the relay half breaks no matter how the hash got captured. The GPO you want is Microsoft network server: Digitally sign communications (always), alongside the client-side twin.
Windows 11 24H2 shipped in late 2024 with signing required by default. Your Server 2016 file server didn't get that memo.
If you're the admin with a pentest readout on Friday, that file server is what to fix this week.
CIS puts disabling unnecessary services at Safeguard 4.8, and that's IG2, which surprises people. In IG1 it only shows up through 4.1, the secure configuration process. I'd treat it as IG1 anyway. You can check where you stand with the CIS IG1 assessment and the CIS Controls overview.
What I don't know is Microsoft's timeline. In April 2022 they said they were ramping down both protocols in favor of mDNS.
It's October 2026 and LLMNR is still on by default, and I can't tell you when that flips.
Don't wait for it. Turn the two protocols off, but if you only get one change through the change board this quarter, make it signing.