LLMNR, NBT-NS, mDNS und WPAD in AD deaktivieren

Kann DNS einen Namen nicht auflösen, fragt Windows stattdessen das lokale Netzwerk: über LLMNR (UDP 5355), den NetBIOS-Namensdienst (UDP 137) und in aktuellen Versionen über Multicast-DNS (UDP 5353). Die Antwort wird von nichts authentifiziert. Jeder im Segment, der einen Poisoner wie Responder oder Inveigh betreibt, kann „das bin ich“ antworten; das Opfer verbindet sich daraufhin und sendet eine NTLM-Authentifizierung, die zum Knacken abgefangen oder live weitergeleitet wird. WPAD verschärft das Problem: Browser und WinHTTP fragen wpad automatisch ab, das Opfer muss sich also nicht einmal vertippen.

Das ist LLMNR poisoning, und es taucht in fast jedem internen Penetrationstest auf. Der Leitfaden zu NTLM und Legacy-Protokollen zeigt die LLMNR-Richtlinie und ein NetBIOS-Skript pro Adapter. Dieser Leitfaden behandelt alle vier Protokolle, die Optionen, die auch neue Netzwerkadapter und Nicht-Domänengeräte abdecken, und wie Sie das Ergebnis im Netzwerk nachweisen statt anhand eines Registrierungsschlüssels.

Messen: was heute antwortet

Ermitteln Sie vor jeder Änderung eine Ausgangsbasis, wie viel Fallback-Verkehr Sie haben. Ein Paketmitschnitt in einigen Benutzer-VLANs (Filter auf UDP 5355, 137 und 5353) zeigt, welche Hosts Abfragen senden und für welche Namen. Die Namen sind der nützliche Teil: Sie offenbaren Tippfehler in Laufwerkszuordnungen, veraltete Verknüpfungsziele und Skripte, die auf stillgelegte Server verweisen. Beheben Sie diese im DNS oder in der Konfiguration, die sie referenziert, denn jeder einzelne ist eine garantierte Poisoning-Gelegenheit.

Prüfen Sie, auf welchen Hosts die Protokolle bereits deaktiviert sind:

$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

Bei TcpipNetbiosOptions bedeutet 0 „DHCP-Einstellung verwenden“, 1 aktiviert, 2 deaktiviert. Ein leerer LLMNR- oder mDNS-Wert bedeutet den Standard, also aktiviert.

LLMNR deaktivieren

Gruppenrichtlinie:

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

Das schreibt EnableMulticast = 0 unter HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient. Wenden Sie die Richtlinie auf jede OU mit Windows-Computern an, Server eingeschlossen. Domänencontroller und Server benötigen Fallback-Namensauflösung so gut wie nie.

NetBIOS über TCP/IP deaktivieren

NetBIOS wird pro Adapter konfiguriert — deshalb verpassen einmalig ausgeführte Skripte Dockingstationen, VPN-Adapter und neue Netzwerkkarten. Setzen Sie auf mehrere Ebenen von Maßnahmen.

DHCP-Option für dynamische Clients

Setzen Sie auf Windows-DHCP-Servern die Microsoft-Herstelleroption pro Bereich oder auf Serverebene:

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

Clients mit TcpipNetbiosOptions = 0 (Standard) deaktivieren NetBIOS auf diesem Adapter dann bei der nächsten Leaseverlängerung. DHCP-Server von Drittanbietern können dieselbe herstellerspezifische Option senden; die Syntax finden Sie in der Dokumentation Ihres Herstellers.

Registrierung und GPO für statische und VPN-Adapter

Für Adapter, die kein Windows-DHCP verwenden, setzen Sie NetbiosOptions = 2 auf jeder Schnittstelle unter HKLM\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces\Tcpip_{GUID}. Ein Startskript oder Registrierungselemente der Gruppenrichtlinieneinstellungen mit einer Sammlung, die alle Schnittstellenschlüssel abdeckt, halten die Einstellung auch für neue Adapter aktuell:

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

Neuere ADMX-Dateien für Windows 11 enthalten unter dem Knoten DNS Client eine Richtlinie „Configure NetBIOS settings“. Unterstützt Ihre gesamte Flotte sie, ist sie eine sauberere Option als Skripte; gleichen Sie den „Supported on“-Text der Richtlinie mit Ihren ältesten Client-Builds ab.

Als zusätzliche Ebene verhindert NodeType = 2 (P-Knoten) unter HKLM\SYSTEM\CurrentControlSet\Services\NetBT\Parameters Broadcast-Namensabfragen, selbst wenn NetBIOS aktiviert bleibt.

mDNS deaktivieren

Setzen Sie den DNS-Client-Parameter direkt, über die Gruppenrichtlinieneinstellungen:

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

Aktuelle ADMX-Vorlagen für Windows 11 bieten unter dem Knoten DNS Client ebenfalls eine mDNS-Richtlinie. Führen Sie diese Änderung zuerst in einer Pilotgruppe ein: Manche Drucker, Casting-Geräte und Peer-Erkennungsfunktionen sind auf mDNS angewiesen.

WPAD blockieren

WPAD-Abfragen stammen von Browsern mit „Einstellungen automatisch erkennen“ und vom WinHTTP-Dienst für die automatische Proxyerkennung. Eine bösartige Antwort kann auf vier Wegen eintreffen, und jeder benötigt eine eigene Maßnahme:

1. Multicast-Fallback (LLMNR, NetBIOS, mDNS): durch die obigen Abschnitte abgedeckt.
2. DNS: Authentifizierte Benutzer können standardmäßig Einträge in AD-integrierten Zonen anlegen, auch wpad. Die Global Query Block List des DNS-Servers verhindert, dass Microsoft-DNS-Server auf wpad und isatap antworten, selbst wenn ein solcher Eintrag existiert. Sie ist standardmäßig aktiviert, wird aber regelmäßig geleert, damit eine legitime WPAD-Bereitstellung funktioniert.
3. DHCP-Option 252: Stellen Sie sicher, dass kein Bereich sie veröffentlicht, sofern Sie WPAD nicht bewusst einsetzen.
4. Die automatische Erkennung auf dem Client selbst: Wenn Sie WPAD nicht nutzen, deaktivieren Sie die automatische Proxyerkennung in den Browsern über deren Richtlinien und legen Sie den Proxy explizit oder über eine PAC-URL fest.

# Auf jedem DNS-Server: prüfen, dass die Sperrliste aktiv ist und wpad enthält
Get-DnsServerGlobalQueryBlockList -ComputerName dc01.corp.example.com

# Wiederherstellen, falls jemand sie geleert hat
Set-DnsServerGlobalQueryBlockList -ComputerName dc01.corp.example.com -Enable $true -List 'wpad','isatap'

# Nach wpad-Einträgen suchen, die in AD-integrierten Zonen angelegt wurden
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 }

Wenn Sie auf WPAD angewiesen sind, veröffentlichen Sie einen legitimen wpad-Eintrag unter Ihrer Kontrolle, entfernen Sie nur wpad aus der Sperrliste und belassen Sie isatap darin. Wer diesen Eintrag schreiben kann, kontrolliert den Proxy Ihrer Benutzer — sichern Sie seine ACL daher ab. Die DNS-Seite der Domänencontroller gehört hier naturgemäß zur übrigen Härtung der Domänencontroller.

Geräte, die Sie nicht verwalten

Gruppenrichtlinien erreichen nur in die Domäne eingebundene Windows-Rechner. Dem Poisoner ist egal, wer fragt, und entscheidend ist das Opfer, das als Antwort Anmeldeinformationen sendet — nicht verwaltete Geräte verdienen daher Aufmerksamkeit:

• Windows-Rechner außerhalb der Domäne (Laptops von Dienstleistern, Laborhosts, Kiosksysteme) behalten alle drei Protokolle aktiviert. Die DHCP-Option für NetBIOS erreicht sie dennoch, LLMNR und mDNS jedoch nicht. Netzwerkzugangskontrolle oder ein separates VLAN für nicht verwaltete Geräte begrenzen, was diese erreichen und was ein Poisoner in ihrem Segment abgreifen kann.
• macOS und Linux setzen konstruktionsbedingt auf mDNS (Bonjour, Avahi), und manche Linux-Distributionen liefern in systemd-resolved einen LLMNR-Responder aus. Sie senden seltener NTLM als Windows, domänenintegrierte Linux-Hosts und Macs mit SMB-Einbindungen können es jedoch. Konfigurieren Sie LLMNR=no und MulticastDNS=no in systemd-resolved, wo Sie die Hosts verwalten, und nutzen Sie für macOS Ihre MDM-Lösung.
• Server in DMZs und Verwaltungsnetzen liegen oft außerhalb des Hauptgeltungsbereichs der GPOs. Prüfen Sie, dass dieselbe Baseline mit ihren OUs verknüpft ist oder — wenn sie nicht in der Domäne sind — lokal mit LGPO angewendet wird.

Auch Segmentierung zählt für sich genommen. Multicast-Namensauflösung ist Link-lokal: Ein Poisoner muss sich in derselben Broadcast-Domäne wie das Opfer befinden. Kleine Benutzer-VLANs, Client-Isolation im WLAN und private VLANs für Server verkleinern das Publikum jedes Poisoners, der doch ins Netzwerk gelangt, und reduzieren so den Schaden durch Geräte, die Sie nicht konfigurieren können.

Überprüfen

Registrierungsprüfungen sind notwendig, aber nicht ausreichend. Überprüfen Sie vom Netzwerk aus:

• Führen Sie das Bestandsskript erneut aus: LLMNR und mDNS sollten 0 sein, NetBIOS auf allen Adaptern 2.
• Wiederholen Sie den Paketmitschnitt in denselben VLANs. Von verwalteten Windows-Hosts sollten keine Abfragen auf UDP 5355 und 5353 und keine NetBIOS-Namensabfragen auf UDP 137 mehr zu sehen sein.
• Auf einem verwalteten Client sollte Resolve-DnsName -Name doesnotexist01 -LlmnrNetbiosOnly einen Fehler statt einer Antwort liefern.
• Resolve-DnsName wpad.corp.example.com sollte auf jedem DNS-Server fehlschlagen.
• Behalten Sie eine Erkennung für die Rechner bei, die Sie nicht verwalten: Ein Canary-Host, der regelmäßig einen zufälligen, nicht existierenden Namen über LLMNR und NetBIOS abfragt, erhält nur dann eine Antwort, wenn sich ein Poisoner im Segment befindet. Microsoft Defender for Identity und die meisten NDR-Produkte melden solche Antworten ebenfalls. Kombinieren Sie das mit Honeytokens, um die Verwendung abgefangener Anmeldeinformationen zu erkennen.

Was dabei ausfallen kann

• Kurznamenauflösung für Hosts ohne DNS-Einträge: alte Server mit statischen IPs, die sich nie registriert haben, Laborrechner und Geräte in Netzen ohne die richtige DNS-Suffix-Suchliste. Beheben Sie das auf der DNS-Seite, nicht in der Richtlinie.
• Legacy-Anwendungen, die NetBIOS-Namen oder den Computerbrowserdienst nutzen (Durchsuchen der Netzwerkumgebung, manche alte Fachanwendungen und Lizenzserver).
• mDNS-Erkennung von Druckern, Casting-Geräten, manchen Konferenzraumsystemen und Peer-to-Peer-Funktionen, sofern diese in Unternehmensnetzen genutzt werden.
• WPAD-basierte Proxykonfiguration: Clients, die auf automatische Erkennung angewiesen sind, verlieren ihren Proxy, wenn der Sperrlisteneintrag ohne Alternative durchgesetzt wird; konfigurieren Sie zuerst eine PAC-URL oder einen expliziten Proxy.
• Heim- und Hotelnetze für Laptops: Benutzer erreichen Verbrauchergeräte gelegentlich per Namen; das ist ein Hinweis für den Helpdesk, kein Grund, die Protokolle beizubehalten.

Weiterführend: das Thema NTLM & Legacy-Protokolle, SMB-Signierung erzwingen und LDAP-Signierung und Channel Binding, damit alles, was dennoch abgefangen wird, nicht weitergeleitet werden kann, sowie der Glossareintrag NTLM relay zur Angriffskette von Anfang bis Ende.