LLMNR and NBT-NS Explained: Name Poisoning Risk and How to Turn Them Off

LLMNR (Link-Local Multicast Name Resolution, RFC 4795, 2007) and NetBIOS Name Service (NBT-NS, RFC 1001 and RFC 1002, 1987) are older ways for a Windows machine to find another machine by name when DNS cannot answer. Both ask the whole local network, and neither checks who replies, so any host on the link can claim to be the name you asked for. In most enterprise networks the right state is off: disable LLMNR by Group Policy, disable NetBIOS over TCP/IP by DHCP option or adapter setting, require SMB signing, restrict NTLM, and fix the DNS gaps that made the fallback necessary.

This is a defensive explainer: how the protocols work, why an unauthenticated answer becomes a credential exposure problem, what Microsoft has said about retiring them, and an order of operations for switching them off without breaking the printers and old applications that still lean on them. Adversary behaviour is described only at the level of MITRE ATT&CK T1557.001.

Key takeaways

• LLMNR sends a name query to a link-scope multicast address (224.0.0.252 for IPv4, FF02:0:0:0:0:0:1:3 for IPv6) on UDP port 5355. Every LLMNR host on that link sees the question. RFC 4795 was published in January 2007 as an Informational document, not a standard, because the IETF did not reach consensus on the approach.
• NBT-NS is the name service half of NetBIOS over TCP/IP. Its broadcast ("B") nodes resolve names by broadcasting a NAME QUERY REQUEST to UDP port 137. RFC 1001 and RFC 1002 date from March 1987.
• The core weakness is trust. Neither protocol, as normally deployed, authenticates the responder. RFC 4795 notes that multicast queries reach every host on the link, so an on-link host can spoof a reply "without having to guess" the query ID.
• Why it matters: if a client accepts a false answer and then connects to a file share or web service that asks for Windows authentication, it can send an NTLM authentication exchange to the wrong machine. MITRE ATT&CK T1557.001 describes adversaries collecting or relaying that material.
• Microsoft's direction (Networking Blog, 22 April 2022) is that mDNS should be the only multicast name resolution protocol on by default, with NetBIOS name resolution and LLMNR "progress toward being turned off by default in all cases."
• How to turn them off: the Group Policy "Turn off multicast name resolution" disables LLMNR on all adapters; the DHCP Microsoft vendor option 001 with value 0x2, or the adapter WINS tab, or the SetTcpipNetbios WMI method with value 2 disables NetBIOS over TCP/IP; the "Configure NetBIOS settings" policy controls whether the DNS client uses NetBIOS name resolution at all.
• Compensating controls matter as much as the switch: SMB signing, NTLM auditing and restriction, SMB client NTLM blocking, and Extended Protection for Authentication.

What are LLMNR and NetBIOS Name Service?

Both protocols answer one question: "what is the IP address for this short name?" DNS answers that question by asking a server. LLMNR and NBT-NS answer it by asking the neighbours.

NetBIOS Name Service (RFC 1001 and RFC 1002, March 1987)

NetBIOS started as a programming interface for PC networking in the 1980s. RFC 1001 ("Concepts and Methods") and RFC 1002 ("Detailed Specifications"), both dated March 1987, define how to carry it over TCP/IP. The result is usually called NetBIOS over TCP/IP, NBT or, in Windows, NetBT.

NBT has three services, each on a fixed port. RFC 1002 lists them as constants:

NetBIOS names are flat. RFC 1001 describes "sixteen alphanumeric characters" and a client interface where each name is exactly 16 bytes long. There is no hierarchy, no domain suffix and no delegation, which is part of why NetBIOS names collide and why DNS replaced them for most purposes.

RFC 1001 defines three node types, and the node type decides how a machine resolves a name:

• B nodes (broadcast) "solicit name information by broadcasting a request." Every machine in the broadcast area receives it.
• P nodes (point to point) ask a NetBIOS Name Server (NBNS). On Windows networks, the NBNS role was historically filled by WINS, the Windows Internet Name Service.
• M nodes (mixed) broadcast first, and if that does not produce an answer, ask the NBNS.

Microsoft's [MS-NBTE] specification documents Windows extensions to NBT (name syntax, timers and multihomed hosts); the broadcast behaviour discussed here is the original 1987 design.

RFC 1001 is candid about security as a design choice for the server side. Section 15.1.6 contrasts a "secured" NBNS that monitors name activity for consistency with a "non-secured" NBNS that is "essentially a 'bulletin board' on which name information is posted." Broadcast resolution has no server at all; the answer comes from whoever replies.

LLMNR (RFC 4795, January 2007)

LLMNR came twenty years later. RFC 4795 was written by three Microsoft engineers and published in January 2007. Its IESG note is worth reading: the document "was originally intended for advancement as a Proposed Standard, but the IETF did not achieve consensus on the approach." It was published as Informational because early versions were already implemented and deployed.

LLMNR reuses the DNS message format. The RFC says it supports "all current and future DNS formats, types, and classes, while operating on a separate port from DNS, and with a distinct resolver cache." It is meant for the case where "conventional DNS name resolution is not possible," for example two laptops on a network with no DNS server.

Microsoft's implementation is documented as a profile in [MS-LLMNRP]. That profile differs from RFC 4795 mainly in transport: RFC 4795 requires TCP and EDNS0 support, while the Windows profile makes both optional and "does not send or respond to unicast queries in TCP."

What about mDNS and DNS?

Multicast DNS (mDNS, RFC 6762) does a similar job for names ending in .local and is the protocol Microsoft now wants as the default multicast resolver on Windows. We cover it in depth in mDNS and DNS-SD explained. MITRE's T1557.001 lists mDNS on UDP 5353 alongside LLMNR and NBT-NS, because an unauthenticated multicast answer has the same basic trust problem.

When does Windows fall back to LLMNR and NetBIOS after DNS fails?

The short answer: when DNS returns nothing useful for a name, Windows can try LLMNR, and then NetBIOS, depending on policy and on how many networks the machine is connected to. The longer answer comes from the DNS Client policy reference on Microsoft Learn (ADMX_DnsClient), which documents the knobs that control the order.

The default: parallel queries on multi-homed machines

The policy "Turn off smart multi-homed name resolution" describes the default optimisation. When the policy is not configured, Windows optimises name resolution "by issuing parallel DNS, link local multicast name resolution (LLMNR) and NetBIOS over TCP/IP (NetBT) queries across all networks." If more than one positive response comes back, "the network binding order is used to determine which response to accept."

If you enable that policy, Windows stops optimising: "DNS queries will be issued across all networks first. LLMNR queries will be issued if the DNS queries fail, followed by NetBT queries if LLMNR queries fail."

So "fallback" is not always strictly sequential. On a laptop with Wi Fi and a VPN adapter, link local protocols can be in flight at the same time as DNS.

Flat names and non-domain networks

Two other policies shape which answer wins:

• "Prefer link local responses over DNS when received over a network with higher precedence." If enabled, responses from LLMNR and NetBT on a higher binding order network are preferred over DNS responses from lower order networks.
• Flat name preference on non-domain networks. The policy reference says that when the relevant setting is disabled or not configured, "the DNS client will prefer link local responses for flat name queries on non-domain networks." If enabled, the client "will prefer DNS responses, followed by LLMNR, followed by NetBT for all networks."

Both of these only apply if smart multi-homed name resolution is left on.

Which names trigger the fallback?

RFC 4795 Section 3 says that "by default, an LLMNR sender SHOULD send LLMNR queries only for single-label names," and that stub resolvers supporting both DNS and LLMNR should avoid sending DNS queries for single-label names. In everyday terms, a single-label name is something like fileserver or printer01 with no dots.

For NetBIOS, the policy "Allow NetBT queries for fully qualified domain names" defaults to off. When it is off, "NetBT queries will only be issued for single-label names such as 'example' and not for multi-label and fully qualified domain names."

The most common real world trigger is therefore mundane: someone types a short name, a mistyped share path, or a host name that was retired years ago, DNS has no record, and the machine asks the neighbourhood instead.

You can see the difference with Resolve-DnsName

The Resolve-DnsName cmdlet on Microsoft Learn exposes the choice directly:

• -DnsOnly resolves with DNS only; per the documentation, "LLMNR and NetBIOS queries are not issued."
• -LlmnrOnly resolves using only LLMNR.
• -LlmnrNetbiosOnly resolves using only LLMNR or NetBIOS.
• -LlmnrFallback and -NetbiosFallback allow falling back to those protocols when DNS fails.

That makes it a safe before and after test.

How does each protocol work on the wire?

LLMNR on UDP 5355

RFC 4795 Section 2: "LLMNR queries are sent to and received on port 5355. The IPv4 link-scope multicast address ... is 224.0.0.252. The IPv6 link-scope multicast address ... is FF02:0:0:0:0:0:1:3."

The flow:

1. A sender with no DNS answer for printer01 builds a DNS style query and sends it to 224.0.0.252 (or the IPv6 group) on UDP 5355.
2. Every host on the link that runs an LLMNR responder receives it.
3. A responder that is authoritative for the name replies by unicast to the sender's source port.
4. The sender waits for LLMNR_TIMEOUT (1 second if set statically, 100 ms on IEEE 802 media including Wi Fi, per RFC 4795 Section 7) and takes the answer.

Other details in the RFC:

• Responders "MUST listen on UDP port 5355 on the link-scope multicast address(es)" and on TCP 5355 on their unicast addresses.
• A default record TTL of 30 seconds is recommended in answers.
• For TCP, the responder should set the IP TTL or IPv6 Hop Limit on its listening socket to 1, so an off-link sender never receives the SYN-ACK. For UDP, the RFC recommends 255 for compatibility with early link local addressing implementations.
• Hosts can detect name conflicts with the C (conflict) bit and are told to log conflicts, because conflicts can be "forensic evidence" of misuse (Section 5.1).

NBT-NS on UDP 137

RFC 1002 Section 4.2.12 defines the NAME QUERY REQUEST. A B node broadcasts it to the IP broadcast address on UDP 137. RFC 1002 states that a request packet is always sent to the well known name service port, and the destination is "either the IP broadcast address or the address of the NBNS." Any end node that owns the name answers.

The NBT header carries a B (broadcast) flag that is set when "packet was broadcast or multicast." NetBIOS also has name registration, refresh, release and conflict messages, including the NAME CONFLICT DEMAND (Section 4.2.8).

Why any host on the link gets to answer

This is the design decision that matters for security. Both protocols are peer to peer. There is no authoritative server whose identity the client checks. In LLMNR's case the RFC is explicit: LLMNR "is often deployed in situations where no trust model can be assumed" (Section 5.3).

RFC 4795 Section 5.2 spells out the consequence. With unicast DNS, an attacker on a switched network has a hard time seeing the query and guessing its ID. With LLMNR, "multicast LLMNR queries are propagated to all hosts on the link, making it possible for an on-link attacker to spoof LLMNR responses without having to guess the value of the ID field in the query." And if the query is for a name that does not exist at all, "spoofing a response in a timely way is not difficult, since a legitimate response will never be received."

That last sentence explains why typos and stale names are such a large part of the risk. A query for a name nobody owns is a question only a liar will answer.

RFC 4795 does define optional authentication: TSIG or SIG(0), IPsec ESP with NULL encryption and a group pre-shared key, or DNSSEC with configured trust anchors (Section 5.3). The RFC itself notes that group keys "do not protect against forgery by an attacker that is a member of the group." In ordinary enterprise Windows deployments these mechanisms are not what protects you; turning the protocol off is.

Why is that a credential exposure risk?

Here is the chain at concept level, as MITRE ATT&CK T1557.001 ("Adversary-in-the-Middle: Name Resolution Poisoning and SMB Relay") describes it. The sub-technique (created 11 February 2020, last modified 12 May 2026) maps to the Credential Access and Collection tactics on Windows.

1. A client cannot resolve a name in DNS and asks via LLMNR, NBT-NS or mDNS.
2. Another host on the same link answers, claiming the name. MITRE describes this as spoofing "an authoritative source for name resolution," "effectively poisoning the service."
3. The client connects to the address it was given. If the service it thinks it is reaching asks for Windows authentication, the client may start an NTLM exchange with that host.
4. MITRE notes that "the username and NTLMv2 hash will then be sent" to the adversary controlled system, where it can be attacked offline. In some cases the NTLM exchange can instead be relayed to another server, and MITRE adds that relay "may also be independent" of poisoning and can be carried into other protocols such as LDAP, MSSQL and HTTP.

First, poisoning is the delivery step; NTLM is the payload. Disabling LLMNR and NBT-NS removes one easy way to steer a client, but it does not fix NTLM's exposure to relay. That is why the compensating controls later in this article (SMB signing, NTLM restriction, EPA) are part of the fix, not optional extras. Our explainer on Kerberos vs NTLM covers how to find out which protocol your applications actually use.

Second, the attacker has to be on the link. RFC 4795 Section 5 notes that these threats "are most serious in wireless networks," since a wired attacker needs physical access while a wireless one can act from a distance. In an enterprise that means guest Wi Fi, shared office floors, conference rooms, VPN segments that bridge clients together and compromised internal hosts are where this matters.

MITRE's mitigation list is short and maps straight onto this article:

For the adversary view of the same technique, including detection data sources, see our MITRE ATT&CK T1557.001 explainer. For the layer below name resolution, the ARP and IPv6 neighbor discovery post covers the related address spoofing problem.

What has Microsoft said about ramping down LLMNR and NetBIOS?

On 22 April 2022 the Microsoft Networking Blog published "Aligning on mDNS: ramping down NetBIOS name resolution and LLMNR." The main points, in Microsoft's words where quoted:

• "The modern standard for multicast name discovery is mDNS." Windows supports the others "for historical reasons."
• NetBIOS name resolution and LLMNR "are rarely used today," so leaving them enabled "needlessly expands the attack surface."
• NetBIOS name resolution "has been turned off by default on cellular interfaces for some time."
• In Windows Insider builds of the time, NetBIOS was placed in a "learning mode" where it is used only as a fallback after mDNS and LLMNR queries fail.
• "The default LLMNR behavior has not been changed in Windows yet." The stated goal is "mDNS is the only multicast name resolution protocol on by default," with both legacy protocols progressing toward being off by default in all cases.

The same post documents the registry value behind the change: a REG_DWORD named EnableNetbios under HKLM\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters, with 0 for disabled, 1 for allowed, 2 for disabled on public networks and 3 for learning mode.

What the current Group Policy documentation says

The ADMX_DnsClient policy reference on Microsoft Learn now documents the matching policy, Configure NetBIOS settings (Computer Configuration > Administrative Templates > Network > DNS Client). It states that "by default, the DNS client will disable NetBIOS name resolution on public networks for security reasons," and offers four options:

For LLMNR, the policy remains Turn off multicast name resolution. Per the policy reference: if you enable it, "LLMNR will be disabled on all available network adapters"; if you disable it or leave it unconfigured, "LLMNR will be enabled on all available network adapters." The policy is stored in Software\Policies\Microsoft\Windows NT\DNSClient under the value name EnableMulticast.

Read those two facts together. On a stock Windows client with no policy applied, LLMNR is on, and NetBIOS name resolution is on except where the network is classified as public. If you want them off on domain and private networks, you have to say so.

Server side signals

Microsoft's Windows Server 2025 documentation points the same way:

• SMB signing "is now required by default for all SMB outbound connections."
• Creating an SMB share now configures a "File and Printer Sharing (Restrictive)" firewall group, which "no longer permits inbound NetBIOS ports 137-139."
• The SMB client supports blocking NTLM for remote outbound connections.
• The OSConfig security baseline for Windows Server 2025 "disables LLMNR and NetBIOS over TCP/IP, and the system relies exclusively on DNS," and requires SMB signing on clients and servers.

That baseline is a useful reference point: Microsoft's own hardened server configuration treats both protocols as off.

How do Linux, macOS, printers and appliances handle these?

Linux with systemd-resolved

On distributions that use systemd-resolved, LLMNR is a resolver setting. The resolved.conf manual documents LLMNR= as taking a boolean or resolve:

• true enables full LLMNR responder and resolver support.
• false disables both.
• resolve enables resolution only, with responding disabled.

The manual also notes that systemd-networkd "also maintains per-link LLMNR settings," and "LLMNR will be enabled on a link only if the per-link and the global setting is on." The setting has existed since systemd version 216. MulticastDNS= works the same way for mDNS.

A server that never needs to be found by a short name on the local link has no reason to run an LLMNR responder, so LLMNR=no is a sensible server setting. Because both the global and per-link settings must be on, disabling it globally is enough. Distributions ship different defaults, so check the running value rather than assuming.

Linux and Unix file servers, and macOS

Hosts that act as Windows compatible file and print servers may run a separate NetBIOS name service next to SMB. If every client reaches such a server by a DNS name over TCP 445, that name service is usually unnecessary; your file server package's documentation will say how to switch it off. For macOS and other platforms, verify behaviour with the packet capture method below rather than assuming a default.

Printers, scanners, NAS and appliances

This is where most of the surprises are. Network printers, multifunction scanners, small NAS units, building controllers and lab instruments may keep NetBIOS name service enabled so older clients can find them by a short name, and some may send NBT-NS queries of their own, for example a scan to folder feature that looks up a share by NetBIOS name. Windows only controls the Windows side. Your inventory should list, per device class:

• Does the device answer NBT-NS or LLMNR?
• Does the device itself query by NetBIOS name (scan to folder, SMB destinations)?
• Can it use a DNS name or IP address instead?
• Can NetBIOS be switched off in its admin interface?

The Microsoft SMB signing documentation is relevant here too: some third party SMB servers do not support signing, and Windows 11 24H2 clients that require signing will fail to connect to them with STATUS_INVALID_SIGNATURE. Microsoft says it does not recommend disabling SMB signing as a workaround. Treat a device that cannot sign as a device that needs an update, a replacement or isolation.

Comparison: DNS, mDNS, LLMNR and NBT-NS

Step by step: find, disable and test

Run this as a staged change, not a one-night switch. The order below is deliberate: measure first, fix DNS, change a pilot group, then widen.

Step 1: Find hosts that still use LLMNR and NBT-NS

Windows packet capture with Packet Monitor. Microsoft documents pktmon as an in-box tool on Windows 10 and Windows Server 2019 (version 1809) and later. A packet is reported if it matches at least one filter, and port filters match source or destination.

# Run in an elevated PowerShell window on a representative client or server
pktmon filter add -t udp -p 5355
pktmon filter add -t udp -p 137
pktmon filter add -t udp -p 138
pktmon start -c
# Leave it running through a normal working period, then:
pktmon counters
pktmon stop
# Convert the ETL file that pktmon stop reports into text
pktmon etl2txt <etl file>

Packet Monitor writes ETL files and can convert them to text or pcapng for analysis in a packet analyzer.

Linux packet capture. On a Linux host attached to the same segment (a mirrored switch port gives you more than one host's view):

# Capture only legacy name resolution traffic on all interfaces
sudo tcpdump -ni any 'udp port 5355 or udp port 137 or udp port 138' -w legacy-names.pcap

What to look for in either capture:

• Who is asking. Source addresses of queries on 5355 and 137 are the clients that still fall back. Group them by subnet and device type.
• What names they ask for. Repeated queries for the same short name usually mean a stale mapped drive, a hard coded path in a script, a typo in a configuration file or a missing DNS record.
• Who is answering. Legitimate answers should come from the machine that owns the name. Answers for names that do not exist in your inventory deserve investigation.

Windows configuration checks. On each Windows host, these read only commands show the current state.

# LLMNR: policy value (absent means the policy is not configured, so LLMNR is on)
Get-ItemProperty -Path 'HKLM:\Software\Policies\Microsoft\Windows NT\DNSClient' -Name EnableMulticast -ErrorAction SilentlyContinue

# NetBIOS name resolution policy in the DNS client (see the four options above)
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters' -Name EnableNetbios -ErrorAction SilentlyContinue

# NetBIOS over TCP/IP per adapter: 0 = via DHCP, 1 = enabled, 2 = disabled
Get-CimInstance Win32_NetworkAdapterConfiguration -Filter "IPEnabled = TRUE" |
  Select-Object Description, TcpipNetbiosOptions

# NetBT bindings for the workstation and server services
net config workstation
net config server

Microsoft's "Direct host SMB over TCP/IP" article explains how to read the net config output: NetbiosSmb is the global NetBIOS-less transport, and a NetBT_Tcpip_{GUID} line for an adapter means NetBIOS over TCP/IP is still bound to it.

Linux configuration checks.

# Global and per-link LLMNR and mDNS state as systemd-resolved sees it
resolvectl status

# Which processes listen on the legacy ports
sudo ss -lunp | grep -E ':(5355|137|138)\b'

Step 2: Fix the DNS gaps that cause fallback

Disabling the fallback without fixing the reason for it turns a quiet risk into a help desk queue. Using the names from your capture:

1. Add missing records for hosts that should be reachable by name.
2. Fix the DNS suffix and search list so fileserver becomes fileserver.corp.example on every network profile, including VPN. The ADMX_DnsClient reference documents a policy that sets the primary DNS suffix and "supersedes the primary DNS suffix configured in the DNS Suffix and NetBIOS Computer Name dialog."
3. Retire stale names. Old drive mappings, logon scripts, shortcuts, printer queues and application config files that point at decommissioned servers are a steady source of queries for names nobody owns. Those are the queries RFC 4795 says are easiest to spoof.
4. Replace short names with fully qualified names in scripts and configuration you control.
5. Check Resolve-DnsName -DnsOnly <name> for every name in your capture. If it returns an answer, DNS can carry that name and the fallback is unnecessary.

Step 3: Disable LLMNR by Group Policy

1. Open the Group Policy Management Console and edit (or create) a GPO linked to a pilot OU.
2. Go to Computer Configuration > Administrative Templates > Network > DNS Client.
3. Open Turn off multicast name resolution and select Enabled. (The setting name is a negative: enabling it turns LLMNR off.)
4. Apply to the pilot group, run gpupdate /force on a test machine, and confirm with the registry check above.
5. Repeat the packet capture on the pilot. LLMNR queries from those machines on UDP 5355 should stop.

For devices managed through MDM rather than Group Policy, the same setting is exposed in the Policy CSP as ./Device/Vendor/MSFT/Policy/Config/ADMX_DnsClient/Turn_Off_Multicast.

On Linux servers using systemd-resolved, the equivalent is a drop-in file:

# /etc/systemd/resolved.conf.d/90-no-llmnr.conf
[Resolve]
LLMNR=no

Then restart the service with sudo systemctl restart systemd-resolved and check resolvectl status.

Step 4: Disable NetBIOS over TCP/IP

NetBIOS over TCP/IP is a per-adapter setting. You have three supported ways to set it, and you can combine them.

Option A: DHCP option (best for managed client networks). Microsoft documents this in "How to disable NetBIOS over TCP/IP by using DHCP server options":

1. In the DHCP console, expand the server and scope, right-click Scope Options and choose Configure Options.
2. On the Advanced tab, choose Microsoft Options in the Vendor class list, with Default User Class selected.
3. Select 001 Microsoft Disable Netbios Option and enter 0x2 in the Long box.
4. On clients, the WINS tab of the IPv4 advanced properties must be set to Use NetBIOS setting from the DHCP server (value 0, the default per-adapter state) for the option to take effect.

If you run a different DHCP server, look for how it sends Microsoft vendor specific option 1 with value 2; Microsoft's direct hosting article describes the same option as "code 1, Disable NetBIOS over TCP/IP. Setting this option to a value of 2 disables NBT."

Option B: Adapter setting via WMI (best for servers and static addresses). The SetTcpipNetbios method of Win32_NetworkAdapterConfiguration accepts 0 (via DHCP), 1 (enable) or 2 (disable). It returns 0 for success with no reboot or 1 for success with a reboot required.

# Disable NetBIOS over TCP/IP on every IP-enabled adapter.
# Review the adapter list from Step 1 first, and pilot on one server.
Get-CimInstance Win32_NetworkAdapterConfiguration -Filter "IPEnabled = TRUE" |
  ForEach-Object {
    $r = Invoke-CimMethod -InputObject $_ -MethodName SetTcpipNetbios -Arguments @{ TcpipNetbiosOptions = [uint32]2 }
    [pscustomobject]@{ Adapter = $_.Description; ReturnValue = $r.ReturnValue }
  }

Option C: The adapter WINS tab. Select Disable NetBIOS over TCP/IP in IPv4 Advanced settings.

For new images, the Microsoft-Windows-NetBT unattend component has a per-interface NetbiosOptions setting.

Also set the DNS client policy. Separately from the adapter binding, use Configure NetBIOS settings under DNS Client and choose Disable NetBIOS name resolution for managed networks. This tells the DNS client not to use NetBIOS name resolution at all, which also covers adapters you missed.

Microsoft's warning applies: disabling NetBIOS over TCP/IP "forces all SMB traffic to be direct hosted SMB traffic" on TCP 445, and a machine with it disabled cannot talk SMB to systems that only support the NetBIOS transport. That is exactly why Step 1 and a pilot come first.

Step 5: Test name resolution afterwards

On each pilot machine:

# Every name from your capture should still resolve with DNS alone
Resolve-DnsName -DnsOnly fileserver
Resolve-DnsName -DnsOnly printer01.corp.example

# Confirm LLMNR no longer answers for a test name
Resolve-DnsName -LlmnrOnly fileserver

# Confirm NetBT is no longer bound
net config workstation

Then repeat the packet capture for a full working day. Success looks like: no queries on UDP 5355 or 137 from pilot machines, no new help desk tickets about mapped drives or printers, and line of business applications behaving normally. Widen the GPO and DHCP option in rings (IT, then a business unit, then everyone), keeping a rollback path: unlink the GPO and set the DHCP option back.

Step 6: Block what is left at the host firewall

MITRE's M1037 suggests host based filtering of LLMNR, NetBIOS and mDNS traffic. Once the protocols are off, inbound rules that drop UDP 5355, 137 and 138 and TCP 139 on client profiles add a second layer for machines that drift out of policy. Windows Server 2025 already moves new SMB shares to a restrictive firewall group without NetBIOS ports.

Compensating controls: SMB signing, NTLM restrictions and EPA

Turning the protocols off removes a delivery path. These controls reduce what a false answer or a relayed authentication can achieve, whatever the delivery path.

SMB signing

Microsoft Learn describes SMB signing as a signature over each message that "contains a hash of the entire message" and "the identities of the original sender and the intended recipient," which helps protect "from relay and spoofing attacks." Current defaults:

The policies live in Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options as "Microsoft network client: Digitally sign communications (always)" and "Microsoft network server: Digitally sign communications (always)," backed by RequireSecuritySignature under the LanManWorkstation and LanManServer parameters keys. Windows Server 2025 adds auditing for clients and servers that do not support signing (Set-SmbServerConfiguration -AuditClientDoesNotSupportSigning $true and Set-SmbClientConfiguration -AuditServerDoesNotSupportSigning $true), which is the right way to find devices that would break before you require signing on servers.

Microsoft adds three recommendations that also cut down on NTLM: use Kerberos instead of NTLMv2, do not connect to shares by IP address, and do not use DNS CNAME records for file servers, because those patterns push clients to NTLM.

NTLM auditing and restriction

The NTLM overview on Microsoft Learn says Kerberos version 5 "is the preferred authentication method for Active Directory environments," while NTLM remains for workgroups, local logon and applications that still request it. Restricting NTLM is a staged process:

1. Set Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers to Audit all. Each NTLM request to a remote server is logged, so you learn which servers still receive NTLM.
2. Review the events and fix applications that can use Kerberos.
3. Add servers that must keep NTLM to Add remote server exceptions for NTLM authentication.
4. Move to Deny all once the exception list is stable.

Microsoft's guidance is explicit that going straight to Deny all "could degrade productivity," so audit first.

Block NTLM in the SMB client

On Windows Server 2025 and Windows 11 24H2 or later, the SMB client can block NTLM for remote outbound connections. Microsoft says this "prevents bad actors from tricking clients into sending NTLM requests to malicious servers." Configure it under Computer Configuration > Administrative Templates > Network > Lanman Workstation > Block NTLM (LM, NTLM, NTLMv2), or:

Set-SmbClientConfiguration -BlockNTLM $true

An exception list (Block NTLM Server Exception List) lets you keep NTLM for named servers that cannot yet use Kerberos. This control speaks directly to the poisoning scenario: even if a client is pointed at the wrong SMB server, it will not offer NTLM.

Extended Protection for Authentication

Microsoft Security Advisory 973811 (published 11 August 2009) introduced Extended Protection for Authentication (EPA), which binds Integrated Windows Authentication requests to both the Service Principal Name of the intended server and the outer TLS channel. The advisory notes that the update "does not directly provide protection against specific attacks such as credential forwarding, but allows applications to opt-in." It also notes that applications using session signing and encryption, such as SMB with signing enabled, "are not affected by credential forwarding." In practice, enable EPA on the web services and directory services in your estate that accept Windows authentication, following each product's documentation.

Detection notes

MITRE's M1031 mitigation points to network intrusion detection. Useful concept level signals: one host answering LLMNR or NBT-NS for many different names, answers for names absent from DNS and inventory, LLMNR conflict log entries, and NTLM authentication from clients to machines that are not servers (Restrict NTLM audit mode makes these visible). Once the protocols are off, any UDP 5355 or 137 traffic from a managed client is itself a finding.

Common mistakes

• Disabling on workstations but not servers. Servers also query by short name (scheduled tasks, backup jobs, legacy integrations) and also answer. A server responding to NBT-NS keeps the protocol alive on the segment. Include servers, with their own pilot.
• Breaking legacy apps without a test window. Some line of business applications, older SMB clients and scan to folder workflows depend on NetBIOS names or the NetBIOS transport. Microsoft warns that disabling NetBIOS over TCP/IP stops SMB with systems that only support it. Capture first, pilot second.
• Forgetting VPN clients. VPN adapters have their own DNS settings and, with smart multi-homed name resolution, can issue link local queries in parallel. Check that the VPN pushes the right DNS suffix and that the DHCP option or adapter setting covers the virtual adapter.
• Forgetting guest and home networks. A laptop that is clean on the corporate LAN still sends LLMNR on hotel Wi Fi unless the policy applies everywhere. Group Policy and MDM settings follow the device; per-network DHCP options do not.
• Leaving systemd-resolved LLMNR on for servers. Linux servers that run systemd-resolved may answer LLMNR. Set LLMNR=no unless there is a reason.
• Relying only on the DHCP option. Machines with static addresses, and adapters set to "Enable NetBIOS over TCP/IP" explicitly, ignore it. Use the WMI method or the DNS client policy as well.
• Treating the switch as the whole fix. NTLM relay works with or without name poisoning. SMB signing and NTLM restriction are part of the same project.
• Disabling SMB signing to make an old device work. Microsoft recommends against it. Isolate or replace the device instead.

FAQ

Is LLMNR enabled by default in Windows 11?

Unless a policy says otherwise, yes. Microsoft's policy reference for "Turn off multicast name resolution" says that if the policy is disabled or not configured, "LLMNR will be enabled on all available network adapters." Microsoft's April 2022 blog said "the default LLMNR behavior has not been changed in Windows yet," with the goal of turning it off by default in future.

Is NetBIOS over TCP/IP still enabled by default?

The per-adapter default is "Use NetBIOS setting from the DHCP server," which means it is enabled unless DHCP sends the disable option. Separately, the DNS client "will disable NetBIOS name resolution on public networks" by default according to the DNS Client policy reference. On domain and private networks you need to turn it off yourself.

Will disabling LLMNR and NetBIOS break anything?

It can break anything that only finds a peer by short name without DNS, or only talks SMB over the NetBIOS transport. That usually means old devices, scan to folder features and scripts with hard coded short names. A packet capture before the change tells you which ones you have.

Is disabling LLMNR enough to stop NTLM relay?

No. MITRE notes that relay "may also be independent" of poisoning. Pair the change with SMB signing, NTLM auditing and restriction, SMB client NTLM blocking where available, and Extended Protection for Authentication on services that accept Windows authentication.

Should I disable mDNS too?

MITRE's mitigation lists mDNS with LLMNR and NetBIOS, to disable if not needed. Microsoft's direction is to keep mDNS as the one multicast resolver on by default. Whether you disable it depends on whether your networks rely on local service discovery; our mDNS and DNS-SD explainer walks through that decision.

How do I check if LLMNR is disabled?

Look for EnableMulticast under HKLM\Software\Policies\Microsoft\Windows NT\DNSClient after the policy applies, then confirm with a packet capture on UDP 5355 that the machine no longer sends queries. Resolve-DnsName -LlmnrOnly <name> should no longer return answers from the machine's perspective.

Do I need WINS anymore?

Microsoft's port reference says WINS servers are required unless all domains are on Active Directory and all computers run Windows 2000 or later. In a modern domain where every client resolves through DNS, WINS is a legacy dependency to retire on the same plan as NBT-NS.

Does disabling NetBIOS affect SMB file sharing?

Modern SMB uses TCP 445 directly ("direct hosted" SMB) and has done since Windows Vista and Windows Server 2008 with SMB 2.0.2, per Microsoft. Disabling NetBIOS over TCP/IP removes the older TCP 139 transport and broadcast name lookup, not SMB itself.

Where Safeguard fits

Safeguard's fit here is indirect. Safeguard does not configure Group Policy, DHCP options, network adapters or host firewalls, does not capture network traffic and is not an endpoint or network intrusion detection product. Those jobs belong to your directory, device management and network tooling.

Where Safeguard helps is the software around these systems. The internal scripts, management tools, provisioning images and service code that touch Windows authentication and name resolution are software you build, and they pull open source dependencies like anything else. Safeguard scans those repositories, container images and SBOM files for vulnerable components (safeguard scan --dir ., --image <name>, --sbom <file>), shows which projects contain a given component and version, and evaluates policies and gates against the results. Gate actions are Block, Warn and Notify, and teams approve exceptions through the platform rather than by switching a gate off. The coverage you get depends on the inventory you feed it.

Disabling LLMNR and NetBIOS is configuration hygiene; patching the code that runs your environment is dependency hygiene. Both remove easy paths for an attacker on your network.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The demos below show Safeguard on ordinary software projects, not on Windows name resolution settings.

The first demo is a real Safeguard CLI session. After install, safeguard opens the interactive terminal, you ask it to fix the lodash CVE in a repository, and it reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. It ends with /permissions, /model and /scan. The same review loop suits an infrastructure tooling repository, where every change should be seen by a person before it ships.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard local runner on your own machine, approves it with its device code and then runs a scan from the terminal. That suits an administrator's workstation or build host that holds image and provisioning repositories you want scanned without sending source anywhere else first.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which tools Claude can use. A security engineer working through a hardening project can then ask about findings in the repositories that build their management tooling, with Claude limited to the tools you allowed.

Click through it at your own pace, or open it full screen.

Safeguard's desktop and CLI downloads are at safeguard.sh/download, and the CLI documentation is at docs.safeguard.sh/docs/cli.

Quick check

Sources

• RFC 4795: Link-Local Multicast Name Resolution (LLMNR)
• RFC 1001: Protocol Standard for a NetBIOS Service on a TCP/UDP Transport: Concepts and Methods
• RFC 1002: Protocol Standard for a NetBIOS Service on a TCP/UDP Transport: Detailed Specifications
• MITRE ATT&CK T1557.001: Name Resolution Poisoning and SMB Relay
• Microsoft Networking Blog: Aligning on mDNS: ramping down NetBIOS name resolution and LLMNR (22 April 2022)
• Microsoft Learn: ADMX_DnsClient Policy CSP
• Microsoft Learn: [MS-LLMNRP] Overview
• Microsoft Learn: [MS-NBTE] Introduction
• Microsoft Learn: Disable NetBIOS over TCP/IP by using DHCP
• Microsoft Learn: Direct host SMB over TCP/IP
• Microsoft Learn: SetTcpipNetbios method of the Win32_NetworkAdapterConfiguration class
• Microsoft Learn: Win32_NetworkAdapterConfiguration class
• Microsoft Learn: Microsoft-Windows-NetBT unattend component
• Microsoft Learn: Resolve-DnsName
• Microsoft Learn: Pktmon command formatting
• Microsoft Learn: Overview of Server Message Block signing
• Microsoft Learn: Control SMB signing behavior
• Microsoft Learn: Block NTLM connections on SMB
• Microsoft Learn: NTLM overview
• Microsoft Learn: Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers
• Microsoft Learn: Security Advisory 973811, Extended Protection for Authentication
• Microsoft Learn: What's new in Windows Server 2025
• Microsoft Learn: Configure security baselines for Windows Server 2025
• Microsoft Learn: Service overview and network port requirements for Windows
• systemd: resolved.conf manual

Last reviewed: 25 October 2026.