NTLM-Relay-Angriffe: Erkennung und Prävention

NTLM-Relay-Angriffe bleiben relevant, weil viele Active-Directory-Umgebungen weiterhin mindestens einen relayfähigen Pfad zulassen: unsignierte SMB-Kommunikation, unzureichende LDAP-Behandlung, exponierte AD-CS-Webregistrierung, Coercion-Pfade oder veraltetes Namensauflösungsverhalten, das Maschinen dazu bringt, sich dort zu authentifizieren, wo sie es nicht sollten.

Was ist NTLM Relay?

NTLM-Relay-Angriffe sind Netzwerkangriffstechniken, bei denen ein Angreifer einen NTLM-Authentifizierungsaustausch von einem System abfängt und in Echtzeit an einen anderen Dienst weiterleitet. Der Angreifer muss dafür den Passwort-Hash nicht knacken. Der Zieldienst akzeptiert die weitergeleitete Authentifizierung, weil der NTLM-Challenge-Response-Austausch für diese Sitzung noch gültig ist.

In der Praxis wird NTLM-Relay relevant, wenn drei Bedingungen zusammentreffen:

ein Opfer kann dazu gezwungen oder verleitet werden, sich über NTLM zu authentifizieren
der Angreifer kann das Opfer und den Zieldienst im Netzwerk erreichen
der Zieldienst akzeptiert NTLM weiterhin auf eine Weise, die nicht den Schutz erfordert, der den Relay-Pfad blockieren würde

Deshalb ist Relay kein einzelner Fehler. Es ist die Kombination aus NTLM-Nutzung, schwacher Namensauflösung oder Coercion-Pfaden sowie zu freizügigen Diensteinstellungen wie unsigniertem SMB oder unzureichender LDAP-Behandlung.

Wie es funktioniert

NTLM ist ein Challenge-Response-Protokoll:

der Client sendet eine Negotiate-Nachricht
der Server sendet eine Challenge
der Client sendet eine daraus abgeleitete Authenticate-Nachricht zurück

Bei einem Relay-Angriff leitet der Angreifer diese Nachrichten zwischen dem Opfer und dem Zieldienst weiter. Der Angreifer bricht das Protokoll dabei nicht kryptografisch. Der Angreifer missbraucht die Tatsache, dass der Zieldienst bereit ist, den weitergeleiteten Authentifizierungskontext zu akzeptieren.

Opfer werden häufig über schwache Namensauflösungspfade wie LLMNR oder NBT-NS oder über Coercion-Pfade in Anwendungen und Diensten, die eine ausgehende Authentifizierung auslösen, zur Authentifizierung gezwungen.

Microsofts Dokumentation zur SMB-Härtung besagt, dass SMB-Signierung dazu beiträgt, Relay-Angriffe zu verhindern, und dass das Erzwingen der Signierung dazu führt, dass Clients und Server unsignierte Pakete ablehnen. Deshalb ist SMB-Signierung eine Kontrolle gegen SMB-Relay-Ergebnisse und keine kosmetische Einstellung.

NTLM-Relay-Angriffe: Gängige Relay-Pfade und was sie blockiert

Relay-Pfad	Was der Angreifer erreichen will	Primäre Blockade
SMB-Relay	Lokale Administratorrechte oder Codeausführung auf einem Mitgliedsserver	Erforderliche SMB-Signierung auf dem Ziel
LDAP-Relay	Verzeichnisänderungen, wenn die weitergeleitete Identität über ausreichende Rechte verfügt und der Zielpfad dies zulässt	LDAP-Signierung und Härtung des Verzeichnispfads
AD-CS-Webregistrierungs-Relay	Zertifikatsausstellung, die für späteren Authentifizierungsmissbrauch nutzbar ist	Entfernung oder Härtung des verwundbaren Registrierungspfads

Eine sinnvolle Überprüfung sollte daher den Relay-Transport vom Ergebnis trennen. Das Blockieren von SMB-Relay entfernt nicht automatisch LDAP- oder AD-CS-Relay-Möglichkeiten.

Es lohnt sich außerdem, die Exposition von Arbeitsstationen von der von Servern zu trennen. Ein Relay-Pfad, der nur auf gering wertvollen Mitgliedshosts landet, ist immer noch ein Problem, aber die Priorität der Reaktion ändert sich sofort, wenn derselbe Pfad Domänencontroller, Verwaltungsserver, Zertifikatsdienste oder stark delegierte Dienstkonten erreichen kann.

Warum die Reduzierung von NTLM nicht dasselbe ist wie ein einzelner Registrierungswert

NTLM-Einschränkungen, SMB-Signierung, LDAP-Signierung, EPA/Channel-Binding, Härtung der Namensauflösung und Härtung der Zertifikatsdienste adressieren unterschiedliche Teile des Angriffs. Ein Tenant kann eine NTLM-bezogene Richtlinie setzen und trotzdem Relay exponieren, wenn ein Zieldienst den weitergeleiteten Austausch akzeptiert.

Betrachten Sie das Kontrollset als mehrschichtig:

unnötige NTLM-Nutzung dort reduzieren, wo der Anwendungspfad Kerberos oder eine stärkere Authentifizierung unterstützt
Signierung oder einen gleichwertigen Schutz für Dienste erzwingen, die NTLM weiterhin akzeptieren
Namensauflösungsverhalten entfernen, das einfache Möglichkeiten zum Abfangen von Authentifizierungen schafft
AD-CS- und LDAP-Pfade härten, die aus einem Relay eine Domäneneskalation machen
NTLM-Nutzung überwachen, damit Ausnahmen sichtbar bleiben

Die Angriffskette

Schritt 1 - Die Relay-Infrastruktur aufbauen

responder -I eth0 -rdw --no-HTTP-Server --no-SMB-Server
ntlmrelayx.py -tf targets.txt -smb2support -socks

Schritt 2 - Authentifizierung abfangen und weiterleiten

Wenn ein Opfersystem versucht, sich bei einem vom Angreifer kontrollierten Listener zu authentifizieren, leitet der Angreifer diesen NTLM-Austausch an das gewählte Ziel weiter.

# Beispielausgabe bei Erfolg
# [*] Authentifizierung gegen smb://10.10.0.50 als CORP/jsmith ERFOLGREICH

Schritt 3 - Die weitergeleitete Identität dort einsetzen, wo es zählt

# Beispiel für ein LDAP-Ziel
ntlmrelayx.py -t ldap://dc01.corp.local --escalate-user attacker

# Beispiel für ein SMB-Ziel
ntlmrelayx.py -tf targets.txt -smb2support -c 'whoami'

# Beispiel für einen AD-CS-Pfad
ntlmrelayx.py -t http://ca.corp.local/certsrv/certfnsh.asp --adcs --template Machine

Die weitergeleitete Sitzung ist nur so mächtig, wie es das Ziel und die weitergeleitete Identität zulassen. Die entscheidende Überprüfungsfrage ist nicht, ob ein Tool die Anfrage stellen kann. Sie lautet, ob die Umgebung noch ein Ziel exponiert, bei dem die Anfrage zu relevanten Berechtigungen führt.

Erkennung

Windows-Ereignis-IDs

Ereignis-ID	Quelle	Worauf zu achten ist
4624	Zielsystem	Typ-3-Netzwerkanmeldungen von einem ungewöhnlichen Quellhost
4776	DC	NTLM-Validierungsaktivität, die nicht zum normalen Pfad des Kontos passt
4625	Zielsystem	Wiederholte fehlgeschlagene Netzwerkanmeldungen im Umfeld von Relay-Tests oder fehlgeschlagener Weiterleitung

Microsoft dokumentiert Ereignis 4776 als NTLM-Anmeldedatenvalidierung. Für Domänenkonten ist der Domänencontroller maßgeblich und kann NTLM-Validierungsversuche für Domänenkonten anzeigen. Das ist nützlich, zeigt aber nicht jedes Detail des Zieldienstes, weshalb es mit den Anmelde- und Dienstprotokollen auf der Zielseite korreliert werden muss.

Praktische Erkennungshinweise

dasselbe Konto authentifiziert sich innerhalb eines kurzen Zeitfensters von einer Quelle aus bei mehreren Hosts
serverseitige NTLM-Aktivität geht von Arbeitsstationen aus, die diesen Datenverkehr normalerweise nicht initiieren
auf eine weitergeleitete Authentifizierung folgen unmittelbar Verzeichnisänderungen, lokale Administratoraktivität oder Zertifikatsregistrierungsverhalten
ein Computerkonto authentifiziert sich nach einem coercion-artigen Auslöser bei einem ungewöhnlichen Dienst
NTLM-Validierung tritt dort auf, wo normalerweise Kerberos verwendet werden sollte

SIEM-Erkennungsabfrage (Elastic KQL)

event.code: '4624' AND
winlog.event_data.LogonType: '3' AND
winlog.event_data.AuthenticationPackageName: 'NTLM'

Diese Abfrage ist für sich genommen nicht relay-spezifisch. Sie wird nützlich, wenn Sie sie um Hostrolle, erwartete Authentifizierungspfade und zeitliche Clusterbildung anreichern.

Bessere Erkennung durch Korrelation

Eine belastbare Relay-Erkennung benötigt in der Regel mindestens zwei der folgenden Signale:

NTLM-Validierung von einer unerwarteten Arbeitsstation oder einem unerwarteten Server
zielseitige Typ-3-Anmeldung unter Verwendung von NTLM
Zugriff auf coercion-relevante Dienste oder Named Pipes
unmittelbare Verzeichnis-, lokale Administrator- oder Zertifikatsregistrierungsaktion nach der Authentifizierung
ein Quellhost, von dem keine Authentifizierungsinitiierung gegenüber dem Ziel erwartet wird

Diese Korrelation ist deutlich belastbarer als eine Alarmierung bei jeglichem NTLM. Viele Umgebungen haben weiterhin legitime NTLM-Abhängigkeiten, sodass breit angelegte NTLM-Alarme Rauschen erzeugen, sofern das Team die Nutzung nicht bereits reduziert hat.

Behebung

Schneller Erfolg: Erzwingen Sie SMB-Signierung auf den Systemen, die weiterhin unsigniertes SMB akzeptieren. Das beseitigt das häufigste SMB-Relay-Ergebnis, ersetzt aber nicht die Härtung der LDAP- und Zertifikatspfade.

1. SMB-Signierung erzwingen

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

Set-SmbClientConfiguration -RequireSecuritySignature $true
Set-SmbServerConfiguration -RequireSecuritySignature $true

Überprüfen Sie sowohl Server als auch Clients. Ein teilweiser Rollout hinterlässt relayfähige Pfade. Microsoft dokumentiert, dass das Erzwingen der SMB-Signierung dazu führt, dass Client oder Server unsignierte Pakete ablehnen — genau das Verhalten, das nötig ist, um SMB-Relay-Ergebnisse zu stoppen.

2. Schwache Namensauflösungspfade deaktivieren

# GPO-Einstellung
# Computerkonfiguration > Administrative Vorlagen > Netzwerk > DNS-Client
# Multicast-Namensauflösung deaktivieren = Aktiviert

Microsofts Richtliniendokumentation für den DNS-Client besagt, dass das Aktivieren der Richtlinie LLMNR auf allen verfügbaren Netzwerkadaptern deaktiviert. Überprüfen Sie außerdem die veraltete NetBIOS-Namensauflösung dort, wo sie in der Umgebung noch existiert.

3. NTLM einschränken, wo der Geschäftspfad es zulässt

Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel -Value 5

Setzen Sie NTLM-Einschränkungen nicht blind um. Beginnen Sie mit dem Audit-Modus und der Ermittlung von Abhängigkeiten. Schränken Sie anschließend nach Server, Konto und Anwendungspfad dort ein, wo die geschäftliche Abhängigkeit verstanden ist.

4. Verzeichnis- und Zertifikatsziele härten

Wenn Domänencontroller oder Zertifikatsdienste weiterhin über relay-freundliche NTLM-Pfade erreichbar sind, ist die Behebung nicht abgeschlossen. Überprüfen Sie:

LDAP-Signierungsanforderungen auf Domänencontrollern
LDAP-Channel-Binding und Extended Protection, sofern zutreffend
AD-CS-Webregistrierung und Exposition von Zertifikatvorlagen
ob hochwertige Server weiterhin NTLM akzeptieren, obwohl stattdessen Kerberos oder stärkere Kontrollen eingesetzt werden sollten
ob Zertifikatsregistrierungspfade authentifizierungsfähige Zertifikate an weitergeleitete Computer- oder Benutzeridentitäten ausstellen können

5. Dienst für Dienst validieren, nicht Richtlinie für Richtlinie

Die Relay-Frage ist immer konkret: Kann diese abgefangene oder erzwungene Authentifizierung an dieses Ziel weitergeleitet werden und dieses Ergebnis erzeugen? Validieren Sie SMB-, LDAP-, AD-CS- und Verwaltungsserverpfade unabhängig voneinander. Ein grüner GPO-Bericht reicht nicht aus, wenn eine Ausnahme-OU, ein Legacy-Gerät oder ein Zertifikatsdienst-Endpunkt weiterhin relayfähig bleibt.

Validierung nach der Härtung

Die Erfolgsbedingung lautet nicht „die GPO existiert". Sie lautet, dass der Zieldienst den relevanten weitergeleiteten Pfad nicht mehr akzeptiert.

repräsentative SMB-Ziele erneut testen und bestätigen, dass sie Signierung erfordern
überprüfen, dass der Opferpfad, der zuvor LLMNR-, NBT-NS- oder anderen ausgehenden NTLM-Verkehr erzeugte, nicht mehr zum gleichen Ergebnis führt
bestätigen, dass die wichtigsten Verzeichnis- und Zertifikatsziele vom selben Ausgangspunkt aus nicht mehr relayfähig sind
aktuelle 4624- und 4776-Aktivität überprüfen, um sicherzustellen, dass die Umgebung für legitime Benutzer weiterhin funktioniert, während der missbräuchliche Pfad verschwunden ist
die SMB-Client- und -Server-Signierungskonfiguration von Endpunkten in jeder wichtigen OU oder Geräteverwaltungsgruppe überprüfen
überprüfen, dass die AD-CS-Webregistrierung und die Exposition von Zertifikatvorlagen behoben wurden, sofern sie Teil der Relay-Kette waren

Diese Validierung sollte an produktionsrelevanten Systemen durchgeführt werden, nicht nur an einer Labormaschine, die nie Teil des ursprünglichen Risikos war.

Wie EtcSec dies erkennt

EtcSec korreliert die Bedingungen, die Relay praktikabel machen: NTLM-Nutzung, relay-freundliche Ziele und angrenzende Konfigurationsschwächen wie unzureichendes SMB, LDAP oder exponierte Zertifikatsregistrierung. Das ist nützlicher als ein einzelnes isoliertes Flag, weil dasselbe Netzwerk sowohl harmlosen NTLM-Verkehr als auch eine kleine Anzahl tatsächlich ausnutzbarer Pfade enthalten kann.