Remediation Guides

How to Disable LLMNR and NetBIOS over TCP/IP on Windows

26 September 2026 9 min read

LLMNR (UDP 5355) and NetBIOS over TCP/IP (UDP 137) are fallback name resolution protocols Windows uses when DNS fails, and an attacker on the same subnet can answer them to capture NTLM hashes. To disable LLMNR, enable the “Turn off multicast name resolution” GPO; to disable NetBIOS, set each adapter to Disabled, then rescan.

Both protocols are on by default, which is why this finding is common on Windows networks the first time someone runs an internal scan. The fix is small. The work is making sure DNS already resolves every name these protocols were quietly covering for.

What the scanner is actually detecting

Nessus reports this as four separate informational plugins, and pentest reports usually add “LLMNR/NBT-NS poisoning” demonstrated with Responder.

Plugin ID Title What triggers it
53513 Link-Local Multicast Name Resolution (LLMNR) Detection Remote check: the device answered an LLMNR request.
160301 Link-Local Multicast Name Resolution (LLMNR) Service Detection Local check (Nessus Agent or credentialed scan) of the LLMNR service status on Windows.
10150 Windows NetBIOS / SMB Remote Host Information Disclosure The host listens on UDP 137 or TCP 445 and replies to NetBIOS nbtscan or SMB requests.
92372 Microsoft Windows NetBIOS over TCP/IP Info Local check (credentialed or agent). It collects NetBT settings per adapter into a CSV attachment and stays in the results after the fix.

All four are rated Info by Tenable, and none has remediation text beyond confirming the service fits your security policy. 160301 and 92372 report status, so they stay listed after the fix with different output. Teams act on them anyway because of the attack described next.

Real-world risk, stated honestly

When a Windows host cannot resolve a name through DNS (a typo in a UNC path, a stale mapped drive), it falls back to LLMNR multicast and then NetBIOS broadcast. Anyone on the same segment can reply “that’s me”, and if the service asks for authentication, the victim sends the attacker an NTLMv2 challenge response. MITRE ATT&CK tracks this as T1557.001, Name Resolution Poisoning and SMB Relay.

What the attacker gets depends on your other controls:

  • Offline cracking: the captured hash is only as strong as the user’s password.
  • Relay: the authentication can be forwarded to another server that does not require signing. Requiring SMB signing blocks the SMB relay path.

The limits matter too: the attacker needs a foothold on the same broadcast domain, the victim must query a name DNS cannot answer, and nothing here gives code execution by itself. It is a routine internal-pentest finding, and reducing NTLM usage is the longer-term companion fix.

How to confirm it on the host

Run these in an elevated PowerShell session:

# LLMNR policy: no value means LLMNR is on, 0 means it is off
Get-ItemProperty -Path 'HKLM:SOFTWAREPoliciesMicrosoftWindows NTDNSClient' -Name EnableMulticast -ErrorAction SilentlyContinue

# Anything bound to the LLMNR (5355) or NetBIOS name (137) ports?
Get-NetUDPEndpoint -LocalPort 5355,137 -ErrorAction SilentlyContinue |
    Select-Object LocalAddress, LocalPort, OwningProcess

# NetBIOS mode per adapter: 0 = use DHCP setting, 1 = enabled, 2 = disabled
Get-CimInstance -ClassName Win32_NetworkAdapterConfiguration -Filter "IPEnabled = TRUE" |
    Select-Object Description, TcpipNetbiosOptions

ipconfig /all also prints a “NetBIOS over Tcpip” line for each adapter.

Before you change anything, find out what still depends on these protocols. From any Linux box on the same VLAN, capture the fallback queries for a few business days:

tcpdump -ni <interface> 'udp port 5355 or udp port 137'

Replace <interface> with the capture interface (ip -br link lists them). Most LLMNR and NBNS name queries in the capture are lookups DNS did not answer; ignore hosts querying their own name, and expect some parallel queries from multi-homed machines. IPv6 LLMNR may not reach the capture host if the switch does MLD snooping. Skip NetBIOS registrations, refreshes and node-status traffic on UDP 137. Create DNS records for legitimate names (printers, NAS devices, short names in scripts) and fix typos and stale references at the source.

How to fix it

Disable LLMNR with Group Policy (domain-joined hosts)

Set Computer Configuration > Administrative Templates > Network > DNS Client > Turn off multicast name resolution to Enabled. Microsoft documents that enabling it disables LLMNR on all network adapters. The policy writes:

HKLMSOFTWAREPoliciesMicrosoftWindows NTDNSClient
    EnableMulticast    REG_DWORD    0

Link the GPO to the OUs holding workstations and member servers, then run gpupdate /force on a pilot machine. For Intune-managed devices, the same setting is exposed as the policy CSP ./Device/Vendor/MSFT/Policy/Config/ADMX_DnsClient/Turn_Off_Multicast.

Disable LLMNR through the registry (standalone hosts)

$p = 'HKLM:SOFTWAREPoliciesMicrosoftWindows NTDNSClient'
if (-not (Test-Path $p)) { New-Item -Path $p -Force | Out-Null }
New-ItemProperty -Path $p -Name EnableMulticast -PropertyType DWord -Value 0 -Force

Run gpupdate /force or reboot, since a direct registry write does not always close the LLMNR socket straight away. Then run Get-NetUDPEndpoint -LocalPort 5355 -ErrorAction SilentlyContinue: no output (or, without the switch, a “No MSFT_NetUDPEndpoint objects found” error) means nothing is listening.

Disable NetBIOS over TCP/IP, option 1: DHCP

This covers every DHCP client in a scope. In the DHCP console, right-click the scope’s Scope Options, choose Configure Options, and on the Advanced tab pick Microsoft Options as the Vendor class and Default User Class as the User class. Tick 001 Microsoft Disable Netbios Option and enter 0x2. Clients must stay on the default “Use NetBIOS setting from the DHCP server” and pick it up on lease renewal (ipconfig /renew). Static-IP servers are not covered, because that default enables NetBIOS when the address is static.

Option 2: the adapter’s WINS tab

Open ncpa.cpl, then adapter Properties > Internet Protocol Version 4 (TCP/IPv4) > Properties > Advanced > WINS, and select Disable NetBIOS over TCP/IP. Fine for a handful of servers, impractical at scale.

Option 3: PowerShell or registry (static-IP servers, scripted rollout)

First export the current per-adapter values, so a rollback restores them exactly, including adapters (cluster heartbeat, iSCSI, backup NICs) that already had NetBIOS disabled on purpose:

reg export HKLMSYSTEMCurrentControlSetServicesNetBTParametersInterfaces netbt-before.reg

The WMI method below sets every IP-enabled adapter to Disabled. A ReturnValue of 0 means done, 1 means a reboot is required.

Get-CimInstance -ClassName Win32_NetworkAdapterConfiguration -Filter "IPEnabled = TRUE" |
    Invoke-CimMethod -MethodName SetTcpipNetbios -Arguments @{ TcpipNetbiosOptions = [uint32]2 }

To also cover adapters that are currently disconnected, set the value directly on every Tcpip_{GUID} interface key:

$base = 'HKLM:SYSTEMCurrentControlSetServicesNetBTParametersInterfaces'
Get-ChildItem -Path $base | ForEach-Object {
    Set-ItemProperty -Path $_.PSPath -Name NetbiosOptions -Value 2
}

New adapters (VPN clients, docking stations, Hyper-V virtual switches) get a fresh interface key, so run this as a startup script rather than once.

How to verify the fix and rescan

  1. On the host, rerun the three checks: EnableMulticast reads 0, nothing is bound to UDP 5355 or 137, and every adapter shows TcpipNetbiosOptions 2 (static or scripted method), or 0 if you used the DHCP option, in which case ipconfig /all must show NetBIOS over Tcpip as Disabled for that adapter. Reboot if a listener remains.
  2. From a same-subnet machine outside both the LLMNR GPO and the DHCP scope, with NetBIOS enabled on its own adapter, run Clear-DnsClientCache, then Resolve-DnsName -Name TARGET-HOST -LlmnrOnly and nbtstat -A 10.0.0.25 (the target’s IP). Both should fail. A tester with these protocols disabled fails regardless of the target; from Linux, nmblookup -A 10.0.0.25 avoids that problem.
  3. Rescan with the same Nessus policy, credentialed or with the agent, from the same subnet as the target. The finding that should disappear is 53513. Plugins 160301 and 92372 are status checks and will still be listed: confirm the 160301 output reports LLMNR as disabled, and open the 92372 CSV attachment to confirm every adapter shows NetBIOS disabled.

A clean remote result proves little if a firewall drops UDP 5355 or the scanner sits in another subnet or VLAN. LLMNR is link-local by design (RFC 4795), so trust 53513 only from the target’s subnet; for routed scanners, rely on the disabled status that 160301 and 92372 report. The on-host checks are the real proof.

What can break and how to roll back

  • Short-name lookups without DNS records: printers, NAS appliances, workgroup machines and scripts using single-label names. Add DNS records and check the DNS suffix search list.
  • WINS: if you still run WINS, clients with NetBIOS disabled stop registering and resolving through it.
  • Legacy SMB over TCP 139: very old clients and devices that only speak NetBIOS session service lose access. Modern SMB uses TCP 445 and is unaffected.

Roll out in rings (IT pilot, one department, everyone) and keep the rollback ready:

# LLMNR: set the GPO to Not Configured, or on a standalone host:
Remove-ItemProperty -Path 'HKLM:SOFTWAREPoliciesMicrosoftWindows NTDNSClient' -Name EnableMulticast
gpupdate /force

# NetBIOS: restore the per-adapter values exported before the change, then reboot
reg import netbt-before.reg

If you deployed the registry loop as a startup script, remove it first, or it sets the value back to 2 at the next boot. For the DHCP method, remove option 001 from the scope and let clients renew.

Common false positive reasons

  • Plugin 10150 still fires after NetBIOS is off. It also triggers on TCP 445, so any host running SMB keeps reporting it; the plugin output shows which port answered.
  • New or hidden adapters. A VPN or virtual switch adapter added after your script ran starts with NetbiosOptions 0.
  • Failover cluster virtual IPs. Each cluster IP Address resource has its own EnableNetBIOS property (default 1, enabled) that the adapter setting does not control, so a cluster IP can keep answering on UDP 137. Run Get-ClusterResource ‘<IP resource>’ | Set-ClusterParameter EnableNetBIOS 0 (or 2, which uses the NIC’s NetBIOS setting), then take the resource offline and online again in a maintenance window: cycling it also takes its dependent network name and clustered role offline.
  • Stale scan data. The scan ran before the GPO applied or before the reboot.
  • It is not a Windows box. Plugins 53513 and 10150 are remote checks against whatever answers on that IP, such as systemd-resolved (the LLMNR= setting in resolved.conf) or Samba’s nmbd on UDP 137. Fix those in their own configuration.

FAQ

Will disabling LLMNR and NetBIOS break Active Directory?

Not in a healthy environment. Domain members find domain controllers through DNS. What breaks is anything resolved only by short name without a DNS record, which the capture step above finds.

Is blocking UDP 5355 and 137 in the host firewall enough?

No. The risk is the host’s own outgoing queries being answered by an attacker. An inbound block hides the listener from the scanner but does not stop the host from sending queries and trusting replies.

Does the GPO also turn off mDNS?

The policy text only covers LLMNR. Treat mDNS on UDP 5353 as a separate item; MITRE’s mitigation guidance recommends disabling LLMNR, mDNS and NetBIOS where they are not needed.

Is disabling NetBIOS over TCP/IP the same as closing port 445?

No. It removes the NetBIOS name, datagram and session services (UDP 137, UDP 138, TCP 139). SMB over TCP 445 keeps working, so harden that separately as part of your Windows Server hardening checklist.

Tracking this finding across many hosts

On a large estate the hard part is proving that every host actually stopped answering. If you use SITEY, you can import the .nessus export, have its AI draft a host-specific script for its agents to run on Windows endpoints (in the default approval mode, only after a human approves it), and then re-test the individual Nessus finding. Closure means 53513 is absent and 160301 and 92372 show the disabled state, not that every plugin disappears. Duplicates are merged per scanner, not across scanners, so the same finding on a host can appear once for each scanner that reported it.

Sources

SITEY closes the loop, not just the report.Discover, validate, fix and verify in your own infrastructure.

See pricing
← All articles