LLMNR and NBT-NS ship enabled on every Windows machine. Most environments never turn them off. That's not a criticism. There's no alert telling you they're open, no obvious breakage if you leave them running, and the official documentation buries the fix under three layers of DNS settings.

The problem is that Responder has been public since 2012 and this is still the first thing any pentester runs on day one of an internal engagement. It works because Windows, when DNS fails to resolve a hostname, quietly multicasts the query across the local subnet. Any host can answer can answer to these multicast queries. An attacker answers, intercepts the authentication attempt, and leaves with an NTLM hash.

If your environment has a flat internal network like most SMB environments do, that hash can come from anywhere.

Before you roll this out, one thing worth knowing: disabling these protocols at the OS level stops Windows from using them. It does not stop applications. A conference room unit or a legacy print server may keep broadcasting regardless. Test on a pilot group first. Use GPO security filtering to exclude specific machines if something breaks rather than pulling the whole policy back like you should always do.

If this is the kind of thing you deal with weekly, The Hardening Brief covers one fix like this every week. Free.

If you've tried the Microsoft-documented GPO for disabling NetBIOS domain wide and it didn't take — you're not missing something. The GPO is broken. It doesn't reliably do what it's supposed to. Here's what actually works:

DHCP environments: Disable it at the DHCP server level. In Windows DHCP, set Microsoft option 001 to 0x2 on your scope. Pushes to all DHCP clients automatically without touching individual machines.

Static IP machines: Has to be done at the NIC. Either manually through:

Or push it via PowerShell startup script scoped to machines with static IPs.

The registry method that gets copy-pasted everywhere doesn't reliably apply across all environments. Don't trust it without verifying.

After either method, confirm it's actually off:

No output means NBT-NS is gone. If port 137 still shows up, it's still running regardless of what your settings say.

Takes effect after reboot.

After rollout, confirm nothing is still listening:

No output on any of those means you're clean. If you see a PID on port 137 after applying the DHCP option or NIC setting, something at the application layer is still using NBT-NS. Track down the process before assuming the config worked.

Most environments see nothing break. The ones that do usually have one of these:

Older network printers that rely on NetBIOS for discovery. They'll stop showing up in browsing but still work if accessed by IP or DNS name directly.

Applications with hardcoded NetBIOS name resolution. Rare but they exist in legacy environments. Your pilot group rollout will surface these before they become a domain-wide problem.

mDNS is used by some Apple devices and Bonjour-dependent software. If you have Macs or AirPrint in the environment, test those specifically before enforcing domain wide.

None of these are reasons not to disable. They're reasons to test first and use GPO security filtering to exclude specific machines rather than rolling back the whole policy.