NTLM-Relay stoppen: LDAP, SMB-Signierung und LLMNR

NTLM-Relay bleibt einer der zuverlässigsten Wege zur Domänenkompromittierung, weil viele AD-Umgebungen noch immer unsignierte LDAP-Bindungen, unsigniertes SMB und veraltete Namensauflösungsprotokolle zulassen, die Anmeldeinformationen an jeden preisgeben, der im lokalen Segment mithört. Keine der hier beschriebenen Maßnahmen erfordert neue Infrastruktur — es handelt sich um Registrierungswerte, Gruppenrichtlinieneinstellungen und Überwachungsprotokollierung, die Sie noch diese Woche aktivieren können. Dieser Leitfaden behandelt das Absichern von LDAP- und SMB-Signierung, das Abschalten von LLMNR/NBT-NS und die Ablösung von NTLMv1 — mit Prüfschritten und einer klaren Liste dessen, was dabei ausfallen kann.

Warum LLMNR und NBT-NS NTLM-Relay ermöglichen

LLMNR (Link-Local Multicast Name Resolution) und NBT-NS (NetBIOS Name Service) ermöglichen Windows-Hosts die Namensauflösung, wenn DNS fehlschlägt, indem sie eine Anfrage per Broadcast ins lokale Subnetz senden. Jeder Host in diesem Segment kann antworten — die Antwort wird nicht authentifiziert. Ein Angreifer, der auf diese Broadcasts antwortet, bringt das Opfer dazu, sich per NTLM bei ihm zu authentifizieren, und erbeutet so einen Hash oder leitet den laufenden Authentifizierungsversuch an einen Zieldienst wie LDAP oder SMB weiter. Das Abschalten beider Protokolle beseitigt in den meisten internen Penetrationstests den einfachsten Einstiegspunkt zum Abgreifen von Anmeldeinformationen.

LLMNR deaktivieren

Gruppenrichtlinienpfad:

Computer Configuration > Policies > Administrative Templates > Network > DNS Client
  Turn Off Multicast Name Resolution: Enabled

Entsprechender Registrierungswert:

HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient
  EnableMulticast (DWORD) = 0

NBT-NS deaktivieren

Für NBT-NS gibt es keinen nativen GPO-Schalter; deaktivieren Sie es pro Netzwerkadapter über WMI, idealerweise verteilt per Startskript oder geplanter Aufgabe, damit die Einstellung auch für neue Netzwerkkarten gilt:

# NetBIOS über TCP/IP auf allen Adaptern deaktivieren (0 = Standard/per DHCP aktivieren, 1 = aktivieren, 2 = deaktivieren)
Get-WmiObject Win32_NetworkAdapterConfiguration -Filter "IPEnabled=True" |
    ForEach-Object { $_.SetTcpipNetbios(2) }

Überprüfung:

Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient" -Name EnableMulticast
Get-WmiObject Win32_NetworkAdapterConfiguration -Filter "IPEnabled=True" |
    Select-Object Description, TcpipNetbiosOptions

LDAP-Signierung und LDAP Channel Binding

Unsignierte LDAP-Bindungen erlauben es einem Angreifer, eine abgefangene NTLM-Authentifizierung direkt in eine LDAP-Sitzung auf einem Domänencontroller weiterzuleiten — oft genug, um sich selbst einer privilegierten Gruppe hinzuzufügen oder vertrauliche Attribute zu lesen. Zwei voneinander unabhängige Einstellungen schließen diese Lücke: LDAP-Serversignierung (LDAPServerIntegrity) und LDAP Channel Binding (LdapEnforceChannelBinding); Letzteres schließt den LDAPS/TLS-spezifischen Relay-Pfad, den die Signierung allein nicht abdeckt.

Auf jedem Domänencontroller festlegen:

HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
  LDAPServerIntegrity (DWORD) = 2   ; 1 = None, 2 = Require signing

HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
  LdapEnforceChannelBinding (DWORD) = 2   ; 0 = Never, 1 = When supported, 2 = Always

Beide Werte lassen sich über eine GPO-Registrierungseinstellung verteilen, die auf die OU Domain Controllers zielt, oder direkt setzen:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" -Name LDAPServerIntegrity -Value 2
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" -Name LdapEnforceChannelBinding -Value 2

Nicht konforme Clients vor dem Erzwingen finden

Bevor Sie LDAPServerIntegrity auf erzwungene Signierung setzen, aktivieren Sie die Diagnoseprotokollierung auf dem DC und werten das Ereignisprotokoll „Directory Service“ über ein Rollout-Fenster aus (üblich sind zwei bis vier Wochen):

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics" -Name "16 LDAP Interface Events" -Value 2

Achten Sie auf diese Directory-Service-Ereignis-IDs, die genau zeigen, welche Clients und Dienste sich ohne Signierung oder Channel Binding binden:

Get-WinEvent -LogName "Directory Service" | Where-Object { $_.Id -in 2887,2889,3039 } |
    Select-Object TimeCreated, Id, Message | Format-List

Setzen Sie LDAPServerIntegrity und LdapEnforceChannelBinding erst dann auf ihre erzwingenden Werte (2), wenn die Ereignisse 2889 und 3039 nicht mehr auftreten oder die verbleibenden Quellen akzeptierte Ausnahmen sind. Unter LDAP Channel Binding wird erläutert, wie das Binding die LDAP-Sitzung an den TLS-Kanal koppelt.

SMB-Signierung

SMB-Relay funktioniert genauso wie LDAP-Relay: Eine abgefangene NTLM-Authentifizierung wird gegen einen Dateiserver oder, schlimmer noch, gegen den SMB-Stack eines Domänencontrollers wiedergegeben. Ist SMB-Signierung erforderlich, besteht eine weitergeleitete Sitzung die Integritätsprüfung nicht und wird verworfen.

Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options
  Microsoft network server: Digitally sign communications (always): Enabled
  Microsoft network client: Digitally sign communications (always): Enabled

Entsprechende Registrierungswerte:

HKLM\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters
  RequireSecuritySignature (DWORD) = 1

HKLM\SYSTEM\CurrentControlSet\Services\LanManWorkstation\Parameters
  RequireSecuritySignature (DWORD) = 1

Wenden Sie die Einstellung zuerst auf Domänencontroller an (sie sind das wertvollste Relay-Ziel), danach in einem gestaffelten Rollout auf Arbeitsstationen und Dateiserver. Überprüfung:

Get-SmbServerConfiguration | Select-Object RequireSecuritySignature
Get-SmbClientConfiguration | Select-Object RequireSecuritySignature

NTLM auditieren und einschränken

Statt NTLM komplett zu deaktivieren — was alles lahmlegt, was noch nicht auf Kerberos migriert ist — nutzen Sie den Restrict NTLM-Ablauf: erst auditieren, dann erzwingen.

Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options
  Network security: Restrict NTLM: Audit NTLM authentication in this domain: Enable all
  Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers: Audit all

Die Überwachungsereignisse (IDs 8001–8004) landen im Protokoll Microsoft-Windows-NTLM/Operational, nicht im Systemprotokoll. Werten Sie sie über einen vollständigen Geschäftszyklus aus, erstellen Sie eine Positivliste der Dienste, die NTLM berechtigterweise noch benötigen, und stellen Sie dann für alles andere von Audit auf Deny um:

Network security: Restrict NTLM: NTLM authentication in this domain: Deny all
Network security: Restrict NTLM: Add server exceptions in this domain: <legacy app servers>

NTLMv1 deaktivieren

NTLMv1 ist kryptografisch schwach und sollte vollständig deaktiviert werden; nur NTLMv2 muss als Fallback für Geräte verfügbar bleiben, die Kerberos noch nicht nutzen können.

Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options
  Network security: LAN Manager authentication level: Send NTLMv2 response only. Refuse LM & NTLM

Registrierung:

HKLM\SYSTEM\CurrentControlSet\Control\Lsa
  LmCompatibilityLevel (DWORD) = 5

Überprüfung:

Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name LmCompatibilityLevel

Was dabei ausfallen kann

• LDAP-Signierung/Channel Binding: ältere Netzwerkscanner, Drucker/Multifunktionsgeräte mit eingebetteten LDAP-Adressbuchabfragen, manche Backup- und Monitoring-Appliances sowie Identitäts-Bridges von Drittanbietern, die sich ohne Signierung binden. Die Ereignisse 2886–2889 identifizieren diese vor dem Erzwingen.
• SMB-Signierung: sehr alte NAS-Geräte, die nur SMBv1 beherrschen, sowie manche Industrie-/Embedded-Systeme; zudem kostet die Signierung bei großvolumigen Dateiübertragungen über langsame Verbindungen etwas Durchsatz.
• Deaktivierung von LLMNR/NBT-NS: Umgebungen, die für Legacy-Abfragen nach einfachen Namen (Anwendungen aus der Zeit vor DNS, manche Fachanwendungen) noch auf NetBIOS-Namensauflösung angewiesen sind, können sporadische Fehler bei der Namensauflösung sehen — prüfen Sie zuerst die DNS-Abdeckung.
• LmCompatibilityLevel = 5: jedes Gerät und jede Anwendung mit fest codiertem NTLMv1, typischerweise sehr alte Kopierer, manche SCADA/ICS-Komponenten und ungepatchte SMB-Clients außerhalb von Windows.

Verwandte Härtungsmaßnahmen finden Sie unter Kerberos-Härtung und Härtung der Domänencontroller. Hintergründe zur Relay-Technik selbst finden Sie unter NTLM relay.