Disable LLMNR, NBT-NS, mDNS and WPAD in AD

When DNS cannot resolve a name, Windows asks the local network instead: over LLMNR (UDP 5355), NetBIOS Name Service (UDP 137) and, on current versions, multicast DNS (UDP 5353). Nothing authenticates the answer. Anyone on the segment running a poisoner such as Responder or Inveigh can reply "that's me", and the victim then connects and sends NTLM authentication, which is captured for cracking or relayed live. WPAD makes it worse: browsers and WinHTTP look up wpad automatically, so the victim does not even need to mistype anything.

This is LLMNR poisoning, and it appears in nearly every internal penetration test. The NTLM and legacy protocols pillar shows the LLMNR policy and a per-adapter NetBIOS script. This guide covers all four protocols, the options that survive new network adapters and non-domain devices, and how to prove the result from the network rather than from a registry key.

Measure: what is answering today

Before changing anything, get a baseline of how much fallback traffic you have. A packet capture on a few user VLANs (filter on UDP 5355, 137 and 5353) shows which hosts send queries and for which names. The names are the useful part: they reveal typos in mapped drives, stale shortcut targets and scripts that point at decommissioned servers. Fix those in DNS or in the configuration that references them, because each one is a guaranteed poisoning opportunity.

Check which hosts already have the protocols disabled:

$targets = (Get-ADComputer -Filter 'OperatingSystem -like "*Windows*"' -SearchBase 'OU=Workstations,DC=corp,DC=example,DC=com').DNSHostName
Invoke-Command -ComputerName $targets -ErrorAction SilentlyContinue -ScriptBlock {
    $llmnr = (Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient' -ErrorAction SilentlyContinue).EnableMulticast
    $mdns  = (Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters' -ErrorAction SilentlyContinue).EnableMDNS
    $nbt   = Get-CimInstance Win32_NetworkAdapterConfiguration -Filter 'IPEnabled=True' |
             Select-Object -ExpandProperty TcpipNetbiosOptions
    [PSCustomObject]@{ Host = $env:COMPUTERNAME; LLMNR = $llmnr; mDNS = $mdns; NetBIOS = ($nbt -join ',') }
} | Export-Csv .\name-resolution-posture.csv -NoTypeInformation

For TcpipNetbiosOptions, 0 means "use the DHCP setting", 1 enabled, 2 disabled. An empty LLMNR or mDNS value means the default, which is enabled.

Disable LLMNR

Group Policy:

Computer Configuration > Policies > Administrative Templates > Network > DNS Client
  Turn off multicast name resolution = Enabled

This writes EnableMulticast = 0 under HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient. Apply it to every OU containing Windows computers, servers included. Domain controllers and servers rarely need fallback name resolution at all.

Disable NetBIOS over TCP/IP

NetBIOS is configured per adapter, which is why scripts that run once miss docking stations, VPN adapters and new NICs. Use layered controls.

DHCP option for dynamic clients

On Windows DHCP servers, set the Microsoft vendor option on each scope or at server level:

# Vendor class "Microsoft Windows 2000 Options", option 001 "Microsoft Disable Netbios Option", value 2
Set-DhcpServerv4OptionValue -ComputerName dhcp01.corp.example.com -ScopeId 10.20.0.0 `
    -VendorClass 'Microsoft Windows 2000 Options' -OptionId 1 -Value 2

Clients with TcpipNetbiosOptions = 0 (the default) then disable NetBIOS on that adapter at the next lease renewal. Third-party DHCP servers can send the same vendor-specific option; check your vendor's documentation for the syntax.

Registry and GPO for static and VPN adapters

For adapters that do not use Windows DHCP, set NetbiosOptions = 2 on every interface under HKLM\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces\Tcpip_{GUID}. A startup script or Group Policy Preferences registry items with a collection covering all interface keys keeps it applied to new adapters:

Get-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces' |
    ForEach-Object { Set-ItemProperty -Path $_.PSPath -Name NetbiosOptions -Value 2 -Type DWord }

Newer Windows 11 ADMX files include a "Configure NetBIOS settings" policy under the DNS Client node. Where your whole fleet supports it, it is a cleaner option than scripts; check the policy's supported-on text against your oldest client builds.

As a further layer, setting NodeType = 2 (P-node) under HKLM\SYSTEM\CurrentControlSet\Services\NetBT\Parameters stops broadcast name queries even where NetBIOS remains enabled.

Disable mDNS

Set the DNS Client parameter directly, via Group Policy Preferences:

HKLM\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters
  EnableMDNS (DWORD) = 0

Recent Windows 11 ADMX templates also expose an mDNS policy under the DNS Client node. Pilot this one first: some printers, casting devices and peer discovery features rely on mDNS.

Block WPAD

WPAD lookups come from browsers set to "Automatically detect settings" and from the WinHTTP auto-proxy service. There are four ways a malicious answer can arrive, and each needs its own control:

1. Multicast fallback (LLMNR, NetBIOS, mDNS): handled by the sections above.
2. DNS: authenticated users can create records in AD-integrated zones by default, including wpad. The DNS Server global query block list prevents Microsoft DNS servers from answering wpad and isatap even if such a record exists. It is enabled by default, but it is regularly emptied to make a legitimate WPAD deployment work.
3. DHCP option 252: make sure no scope publishes it unless you run WPAD deliberately.
4. Client auto-detection itself: if you do not use WPAD, turn off automatic proxy detection for browsers through their policies and set the proxy explicitly or with a PAC URL.

# On each DNS server: confirm the block list is enabled and contains wpad
Get-DnsServerGlobalQueryBlockList -ComputerName dc01.corp.example.com

# Restore it if someone cleared it
Set-DnsServerGlobalQueryBlockList -ComputerName dc01.corp.example.com -Enable $true -List 'wpad','isatap'

# Look for wpad records that were created in AD-integrated zones
Get-DnsServerZone -ComputerName dc01.corp.example.com | Where-Object { $_.IsDsIntegrated -and -not $_.IsReverseLookupZone } |
    ForEach-Object { Get-DnsServerResourceRecord -ComputerName dc01.corp.example.com -ZoneName $_.ZoneName -Name 'wpad' -ErrorAction SilentlyContinue }

If you do rely on WPAD, publish a legitimate wpad record you control, remove only wpad from the block list, and keep isatap on it. Whoever can write that record controls your users' proxy, so lock down its ACL. The domain controller DNS side of this sits naturally with the rest of your domain controller hardening.

Devices you do not manage

Group Policy only reaches domain-joined Windows machines. The poisoner does not care who asks, and the victim that matters is whoever sends credentials in response, so unmanaged devices deserve a look:

• Non-domain Windows machines (contractor laptops, lab hosts, kiosk systems) keep all three protocols enabled. The DHCP NetBIOS option still reaches them, but LLMNR and mDNS do not. Network access control or a separate VLAN for unmanaged devices limits what they can reach and what a poisoner on their segment can collect.
• macOS and Linux rely on mDNS (Bonjour, Avahi) by design and some Linux distributions ship an LLMNR responder in systemd-resolved. They send NTLM less often than Windows, but domain-integrated Linux hosts and Macs with SMB mounts can. Configure LLMNR=no and MulticastDNS=no in systemd-resolved where you manage the hosts, and use your MDM for macOS.
• Servers in DMZs and management networks often sit outside the main GPO scope. Check that the same baseline is linked to their OUs, or applied locally with LGPO if they are not domain-joined.

Segmentation also matters on its own. Multicast name resolution is link-local: a poisoner has to be on the same broadcast domain as the victim. Small user VLANs, client isolation on Wi-Fi and private VLANs for servers shrink the audience of any poisoner that does get onto the network, which reduces the harm from devices you cannot configure.

Verify

Registry checks are necessary but not sufficient. Verify from the network:

• Re-run the posture script: LLMNR and mDNS should be 0, NetBIOS 2 on all adapters.
• Repeat the packet capture on the same VLANs. You should see no queries on UDP 5355 and 5353 from managed Windows hosts, and no NetBIOS name queries on UDP 137.
• From a managed client, Resolve-DnsName -Name doesnotexist01 -LlmnrNetbiosOnly should return an error rather than an answer.
• Resolve-DnsName wpad.corp.example.com should fail on every DNS server.
• Keep a detection in place for the machines you do not manage: a canary host that periodically queries a random, non-existent name over LLMNR and NetBIOS will receive an answer only if a poisoner is on the segment. Microsoft Defender for Identity and most NDR products also alert on these responses. Pair this with honeytokens to catch captured credentials being used.

What it breaks

• Short-name resolution for hosts without DNS records: old servers with static IPs that never registered, lab machines and devices on networks without the right DNS suffix search list. Fix the DNS side, not the policy.
• Legacy applications using NetBIOS names or the browser service (network neighbourhood browsing, some old line-of-business apps and license servers).
• mDNS discovery of printers, casting devices, some conference room equipment and peer-to-peer features, if they are used on corporate networks.
• WPAD-based proxy configuration: clients relying on automatic detection lose their proxy if the block list entry is enforced without an alternative; configure a PAC URL or explicit proxy first.
• Home and hotel networks for laptops: users occasionally reach consumer devices by name; this is a helpdesk note, not a reason to keep the protocols.

Related reading: the NTLM & Legacy Protocols topic, requiring SMB signing and LDAP signing and channel binding so that anything still captured cannot be relayed, and the NTLM relay glossary entry for the attack chain end to end.