Disable LLMNR and NBT-NS via Group Policy: 2026 Security Guide

LLMNR (Link-Local Multicast Name Resolution) and NBT-NS (NetBIOS Name Service) are legacy name resolution protocols that attackers exploit to capture credentials through poisoning attacks. When a Windows client can’t resolve a hostname via DNS, it falls back to broadcasting LLMNR and NBT-NS queries across the network — and attackers respond with malicious answers, capturing authentication attempts. Tools like Responder and Inveigh make this attack trivial, turning misconfigured name resolution into domain compromise. This guide shows how to disable LLMNR and NBT-NS via Group Policy, with registry paths, PowerShell verification, testing procedures, and complete rollback instructions for Windows 11 and Server 2025 environments.

These protocols serve no legitimate purpose in modern Active Directory environments where DNS provides comprehensive name resolution. LLMNR and NBT-NS exist for backward compatibility with legacy systems and workgroup environments, but in domain-joined networks they create unnecessary attack surface. Disabling them eliminates an entire class of network-based credential harvesting attacks without affecting normal domain operations.

TL;DR — disable LLMNR and NBT-NS in 3 steps

The complete configuration in under 5 minutes:

1. Create or edit a GPO linked to your target OUs
2. Computer Configuration → Administrative Templates → Network → DNS Client → Turn off multicast name resolution = Enabled
3. Computer Configuration → Windows Components → NetBT → Turn off NetBIOS over TCP/IP = Enabled

Apply with gpupdate /force, verify with Get-ItemProperty commands, test name resolution, and monitor for any application breakage during your pilot phase.

Why disable LLMNR and NBT-NS in 2026?

Three factors make this a high-priority hardening control:

LLMNR and NBT-NS poisoning is the #1 initial access vector in red team engagements. Every penetration test starts with running Responder on the network segment to capture NetNTLM hashes from name resolution fallbacks. The attack requires zero privileges and works against any domain-joined Windows host that attempts to access a non-existent hostname. Modern red team tooling has automated this to the point where hash capture happens within minutes of network access.

These protocols have no legitimate use in modern AD environments. DNS provides complete name resolution for domain-joined hosts. LLMNR was designed for link-local networks without DNS servers, and NBT-NS for pre-DNS Windows environments. In 2026, keeping them enabled is pure technical debt — they create attack surface without providing value.

Disabling them is risk-free in properly configured domains. Unlike disabling NTLM or SMBv1, turning off LLMNR and NBT-NS won’t break legitimate applications that follow modern naming conventions. The only impact is on misconfigured applications that rely on name resolution fallbacks — and those applications should be fixed anyway.

Understanding LLMNR and NBT-NS attacks

Both protocols work by broadcasting name resolution requests when DNS fails:

LLMNR (Link-Local Multicast Name Resolution) sends multicast UDP queries to 224.0.0.252:5355 when DNS lookup fails. Any host on the network can respond, claiming to be the requested hostname. Windows Vista+ enabled this by default.

NBT-NS (NetBIOS Name Service) broadcasts UDP queries to 255.255.255.255:137 for NetBIOS name resolution. Legacy protocol from Windows NT era, still enabled by default for compatibility.

The attack flow:

1. User/application tries to access \\fileserver\share but typos it as \\filserver\share
2. DNS lookup for filserver.domain.com fails
3. Windows falls back to LLMNR/NBT-NS broadcast: “Who has filserver?”
4. Attacker’s tool (Responder/Inveigh) responds: “I’m filserver, here’s my IP”
5. Client attempts authentication to attacker’s fake server
6. Attacker captures NetNTLM hash for offline cracking or relay

This attack requires no elevation, works from any network position, and captures real user credentials — not just reconnaissance data.

Pre-deployment checklist

Before implementing the policy:

1. Inventory legacy applications that might use NetBIOS names or depend on LLMNR fallback
2. Test in a pilot OU with a representative sample of workstations and servers
3. Document current name resolution behavior with nslookup, ping, and net use tests
4. Verify DNS infrastructure is healthy — check forward/reverse lookup zones, conditional forwarders, and suffix search lists
5. Plan monitoring for authentication failures and application errors during the transition
6. Prepare rollback procedure with exact GPO revert steps documented

Step-by-step: How to disable LLMNR and NBT-NS

The complete Group Policy configuration process:

Group Policy configuration details

LLMNR disable settings

Group Policy path:

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

Registry location:

HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient
Name: EnableMulticast
Type: DWORD
Value: 0 (Disabled)

PowerShell verification:

Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient" -Name EnableMulticast -ErrorAction SilentlyContinue

# Expected output when disabled:
# EnableMulticast : 0

NBT-NS disable settings

Group Policy path:

Computer Configuration
  └ Policies
    └ Administrative Templates  
      └ Windows Components
        └ Network
          └ NetBT
            └ Turn off NetBIOS over TCP/IP = Enabled

Registry location:

HKLM\SYSTEM\CurrentControlSet\Services\netbt\Parameters
Name: NodeType  
Type: DWORD
Value: 2 (P-node - point-to-point, no broadcasts)

PowerShell verification:

Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\netbt\Parameters" -Name NodeType -ErrorAction SilentlyContinue

# Expected output when disabled:
# NodeType : 2

# Alternative check - NetBIOS configuration per adapter
Get-WmiObject -Class Win32_NetworkAdapterConfiguration | Where-Object {$_.TcpipNetbiosOptions -ne $null} | Select-Object Description, TcpipNetbiosOptions

# TcpipNetbiosOptions values:
# 0 = Default (uses DHCP setting or enables NetBIOS)
# 1 = Enable NetBIOS over TCP/IP  
# 2 = Disable NetBIOS over TCP/IP

Alternative: Registry-based configuration

For environments that need direct registry configuration without Group Policy:

LLMNR registry disable

# Create the registry path if it doesn't exist
$regPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient"
if (!(Test-Path $regPath)) {
    New-Item -Path $regPath -Force
}

# Disable LLMNR
Set-ItemProperty -Path $regPath -Name "EnableMulticast" -Value 0 -Type DWord

# Verify setting
Get-ItemProperty -Path $regPath -Name "EnableMulticast"

NBT-NS registry disable

# Set NodeType to P-node (2) to disable broadcasts
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\netbt\Parameters" -Name "NodeType" -Value 2 -Type DWord

# Disable NetBIOS over TCP/IP on all adapters
$adapters = Get-WmiObject -Class Win32_NetworkAdapterConfiguration -Filter "IPEnabled=True"
foreach ($adapter in $adapters) {
    $adapter.SetTcpipNetbios(2)  # 2 = Disable
}

# Verify configuration
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\netbt\Parameters" -Name "NodeType"
Get-WmiObject -Class Win32_NetworkAdapterConfiguration | Where-Object {$_.TcpipNetbiosOptions -ne $null} | Select-Object Description, TcpipNetbiosOptions

Testing and verification procedures

Verify LLMNR is disabled

Test that LLMNR queries are not sent:

# This should fail quickly without network traffic on port 5355
ping nonexistent-llmnr-host

# Use Wireshark or netstat to confirm no LLMNR traffic:
# netstat -an | findstr :5355
# Should show no UDP connections on port 5355

Verify NBT-NS is disabled

Test that NetBIOS name service broadcasts are blocked:

# This should fail without broadcasts on port 137
net use * \\nonexistent-netbios-name\share

# Check NBT-NS service status
sc query netbt

# Verify no NetBIOS broadcasts with:
# netstat -an | findstr :137

Comprehensive verification script

PowerShell script to validate both settings:

function Test-LLMNRNBTDisabled {
    $results = @{}
    
    # Test LLMNR registry setting
    try {
        $llmnr = Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient" -Name EnableMulticast -ErrorAction Stop
        $results.LLMNR_Disabled = ($llmnr.EnableMulticast -eq 0)
    } catch {
        $results.LLMNR_Disabled = $false
        $results.LLMNR_Error = $_.Exception.Message
    }
    
    # Test NBT-NS NodeType setting
    try {
        $nbtns = Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\netbt\Parameters" -Name NodeType -ErrorAction Stop  
        $results.NBTNS_Disabled = ($nbtns.NodeType -eq 2)
    } catch {
        $results.NBTNS_Disabled = $false
        $results.NBTNS_Error = $_.Exception.Message
    }
    
    # Test NetBIOS over TCP/IP per adapter
    $adapters = Get-WmiObject -Class Win32_NetworkAdapterConfiguration -Filter "IPEnabled=True"
    $nbtDisabledAdapters = ($adapters | Where-Object {$_.TcpipNetbiosOptions -eq 2}).Count
    $results.NetBIOS_Adapters_Disabled = $nbtDisabledAdapters
    $results.Total_Adapters = $adapters.Count
    
    return $results
}

# Run the test
$testResults = Test-LLMNRNBTDisabled
$testResults | Format-Table -AutoSize

Common application compatibility issues

File server access using NetBIOS names

Symptom: UNC paths like \\SERVER\share fail after NBT-NS disable Solution: Use FQDN format: \\server.domain.com\share or configure DNS suffixes

Legacy printers using NetBIOS discovery

Symptom: Network printers become unreachable after NetBIOS disable Solution: Configure printers with IP addresses or FQDN, update print server DNS records

SQL Server named instances

Symptom: SQL Server browser service fails to respond to client discovery Solution: Use explicit connection strings with server FQDN and port numbers

Application-specific NetBIOS dependencies

Symptom: LOB applications report “network path not found” errors Solution: Update connection strings to use DNS names, configure application-specific DNS entries

Monitoring and troubleshooting

Monitor these event logs during deployment:

• System Log Event 4319: NetBIOS name resolution timeout
• DNS Client Event 1014: Name resolution policy table error
• Application-specific logs for connectivity failures

Rollback procedures

If issues arise and you need to restore LLMNR/NBT-NS:

Group Policy rollback

# Method 1: Set policies to Not Configured
1. Open GPMC, edit the GPO
2. Navigate to LLMNR setting: "Turn off multicast name resolution"
3. Set to "Not Configured"
4. Navigate to NBT-NS setting: "Turn off NetBIOS over TCP/IP" 
5. Set to "Not Configured"
6. Run gpupdate /force on affected systems

# Method 2: Disable the policy entirely (if dedicated GPO)
1. Unlink the GPO from all OUs
2. Run gpupdate /force to remove settings

Registry rollback

# Re-enable LLMNR
Remove-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient" -Name "EnableMulticast" -ErrorAction SilentlyContinue

# Re-enable NBT-NS (set to default/hybrid)
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\netbt\Parameters" -Name "NodeType" -Value 1

# Re-enable NetBIOS over TCP/IP on adapters
$adapters = Get-WmiObject -Class Win32_NetworkAdapterConfiguration -Filter "IPEnabled=True"
foreach ($adapter in $adapters) {
    $adapter.SetTcpipNetbios(0)  # 0 = Default (usually enables)
}

# Restart NetBT service to apply changes
Restart-Service netbt -Force

Advanced configuration options

Selective NetBIOS disabling

For environments that need NBT-NS on specific adapters only:

# Disable NetBIOS only on external-facing adapters
$externalAdapters = Get-WmiObject -Class Win32_NetworkAdapterConfiguration | Where-Object {$_.DefaultIPGateway -ne $null}

foreach ($adapter in $externalAdapters) {
    $adapter.SetTcpipNetbios(2)  # Disable
    Write-Output "Disabled NetBIOS on: $($adapter.Description)"
}

DHCP Option 43 and NetBIOS scope configuration

For environments using DHCP to manage NetBIOS settings:

DHCP Server → Scope Options → 001 Microsoft Disable Netbios Option
Value: 0x2 (Disable NetBIOS over TCP/IP)

Windows Defender Application Guard compatibility

WDAG requires special consideration for name resolution:

Computer Configuration → Administrative Templates → Windows Components → Windows Defender Application Guard
→ Allow files to download and save to the host operating system from Windows Defender Application Guard = Enabled

# Ensure DNS resolution works within WDAG containers
→ Network isolation settings → DNS suffixes = Configure domain suffixes

Security monitoring and validation

Detecting LLMNR/NBT-NS attack attempts

Even with protocols disabled, monitor for attack tools:

# Monitor for Responder-like tools attempting to bind to LLMNR/NBT-NS ports
Get-NetTCPConnection | Where-Object {$_.LocalPort -eq 5355 -or $_.LocalPort -eq 137}

# Check Windows Security log for unusual authentication patterns
Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4624,4625; StartTime=(Get-Date).AddDays(-1)} | 
  Where-Object {$_.Message -match "LLMNR|NetBIOS"}

Validation with network security tools

Use these tools to verify protocols are disabled:

• Wireshark: Filter for llmnr || nbns to confirm no broadcast traffic
• Nmap: nmap -sU -p 137,5355 target-host should show closed/filtered ports
• PowerShell: Test-NetConnection -ComputerName target -Port 5355 should fail

Frequently asked questions

Conclusion

Disabling LLMNR and NBT-NS via Group Policy eliminates a critical attack vector with minimal operational impact. These legacy protocols exist solely for backward compatibility and create unnecessary security exposure in modern Active Directory environments. The Group Policy configuration takes minutes to implement and provides immediate protection against credential harvesting attacks.

Your implementation roadmap:

1. This week: Test the Group Policy settings in a lab environment with representative applications
2. Next week: Deploy to a pilot OU with monitoring for 72 hours to catch any application dependencies
3. Within 30 days: Roll out organization-wide with documented exceptions for any legitimate dependencies discovered

Combine this hardening with NTLM disabling and SMB hardening to create a comprehensive defense against network-based credential attacks. The overlapping protections ensure that eliminating one attack vector doesn’t just push attackers to an equally viable alternative.

References

• Microsoft Learn: LLMNR and NetBIOS Name Service Overview
• MITRE ATT&CK T1557.001 — LLMNR/NBT-NS Poisoning and SMB Relay
• NIST SP 800-53 — Network Security Controls
• Group Policy Administrative Templates reference
• Responder tool documentation and attack methodology
• Windows DNS Client configuration reference