Ausgehendes NTLM auf Tier 0 Domain Controllern blockieren: Coercion-Relay-Angriffe auf GPO-Ebene stoppen

Was "ausgehendes NTLM" für einen Domain Controller bedeutet

Diese Anleitung zeigt, wie Sie ausgehendes NTLM auf Tier 0 Domain Controllern blockieren — Coercion-Relay-Ketten wie PetitPotam und die Techniken, die ihm folgten, hängen vollständig davon ab, dass diese ausgehende Authentifizierung überhaupt existiert; verweigert man sie, bleibt ihnen nichts mehr zum Weiterleiten. Domain Controller authentifizieren fast alles, was sie untereinander und gegenüber anderen Active Directory-integrierten Diensten tun, mit Kerberos, doch NTLM existiert darunter weiterhin als Fallback — und standardmäßig authentifiziert sich jedes Windows-System bereitwillig ausgehend über NTLM gegenüber jedem Server, der danach fragt.

ANSSI, die französische nationale Cybersicherheitsbehörde, dokumentiert dieses Muster direkt in ihrem Leitfaden zur Active Directory-Administration. Die NTLMv2-Authentifizierung ist eine Netzwerkanmeldung — im Unterschied zu den interaktiven Anmeldungen, die wiederverwendbare Hashes im Speicher hinterlassen — und ihre Challenge-Response kann im Flug abgefangen und an ein zweites Ziel weitergeleitet werden, ohne dass der Angreifer das zugrunde liegende Geheimnis jemals erfährt: Er leiht sich die Zugriffsrechte des Opfers, anstatt dessen Passwort zu stehlen (ANSSI-PA-099, §4.15.2). Handelt es sich beim erzwungenen System um einen Domain Controller, sind die weitergeleiteten Zugriffsrechte Tier 0.

Wie Coercion-and-Relay-Angriffe ausgehendes NTLM missbrauchen

Das am besten dokumentierte Mitglied dieser Klasse ist PetitPotam. Das Advisory von CERT/CC zu dieser Technik erklärt, dass sie das Encrypting File System Remote Protocol missbraucht: Ein Aufruf von EfsRpcOpenFileRaw veranlasst das Zielsystem, "use NTLM to authenticate with the host that is specified within the path", und ein Angreifer kann diesen Pfad auf eine von ihm kontrollierte Infrastruktur richten — wodurch ein NTLM-Authentifizierungsversuch vom Computerkonto des Domain Controllers selbst ausgelöst wird, ohne dass für den Start der Kette Anmeldeinformationen nötig wären (CERT/CC VU#405600).

Diese abgefangene NTLM-Authentifizierung ist nur deshalb gefährlich, weil sie an anderer Stelle akzeptiert wird. CERT/CC beschreibt die vollständige Kette gegen Active Directory Certificate Services in drei Schritten:

Schritt 1 — Erzwingen

Der Angreifer ruft EfsRpcOpenFileRaw (oder eine äquivalente RPC-Methode mit demselben authentifizierungsauslösenden Verhalten) gegen den Domain Controller auf und richtet ihn auf eine von ihm kontrollierte Infrastruktur. Das Computerkonto des DC eröffnet eine ausgehende NTLM-Authentifizierung — dies ist eine Netzwerkanmeldung, wie der ANSSI-Leitfaden anmerkt, nicht die interaktive Variante, die wiederverwendbare Hashes im Speicher hinterlässt.

Schritt 2 — Weiterleiten

Der Angreifer fängt die NTLMv2-Challenge-Response ab — den "Net-NTLMv2"-Hash — und leitet sie unverändert und sofort an den HTTP-Endpunkt der AD CS-Webregistrierung weiter, bevor sie abläuft.

Schritt 3 — Umwandeln

AD CS stellt ein Zertifikat für das Computerkonto des Domain Controllers aus. CERT/CC weist darauf hin, dass dieses Zertifikat "can be used to obtain a Ticket Granting Ticket" — was ausreicht, um die gesamte Domain zu kompromittieren, ohne dass jemals ein Passwort oder ein Hash geknackt werden musste.

Jeder Schritt dieser Kette hängt davon ab, dass Schritt 1 gelingt: Der Domain Controller muss überhaupt bereit sein, NTLM-Authentifizierung nach außen zu senden. Nimmt man das weg, haben Schritt 2 und 3 keine Grundlage mehr.

Microsofts Korrektur, geführt als CVE-2021-36942 ("Windows LSA Spoofing Vulnerability"), schloss nur die unauthentifizierte Variante des EfsRpcOpenFileRaw-Aufrufs. Das zugrunde liegende Muster beseitigte sie nicht — ein Tier 0-System kann über andere RPC-Schnittstellen mit demselben Verhalten weiterhin zu einer ausgehenden NTLM-Authentifizierung gedrängt werden. Genau deshalb geht Microsofts eigene Empfehlung für diese Angriffsfamilie über einen einzelnen Patch hinaus. KB5005413 empfiehlt, Extended Protection for Authentication auf AD CS-Endpunkten zu aktivieren und — als stärkere Option auf Protokollebene — "disable NTLM Authentication on your Windows domain controller" (Microsoft KB5005413). Genau diese zweite Option setzt die ANSSI-Empfehlung R73 als eine einzige Gruppenrichtlinieneinstellung um.

Ausgehendes NTLM auf Tier 0 Domain Controllern blockieren (ANSSI R73)

Die ANSSI-Empfehlung R73 ist eindeutig: "outbound NTLM authentications from all Tier 0 systems must be blocked" — umgesetzt über eine einzige Gruppenrichtlinieneinstellung. Der Pfad der Gruppenrichtlinie, dem Leitfaden entnommen, lautet:

Computer Configuration\Windows Settings\Security Settings\Local Policies\
Security Options\Network Security: Restrict NTLM: Outgoing NTLM traffic
to remote servers → Deny all

Microsofts eigene Referenz zu dieser Einstellung bestätigt dieselben drei Zustände — Allow all (keine Einschränkung), Audit all (protokolliert jeden ausgehenden NTLM-Versuch, ohne ihn zu blockieren) und Deny all (das Gerät "can't authenticate any identities to a remote server by using NTLM authentication") — und weist darauf hin, dass die Einstellung auf jedem Domain Controller und Mitgliedsserver standardmäßig Not Configured ist (Microsoft Learn — Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers). Bleibt sie unkonfiguriert, hat die Coercion-and-Relay-Klasse genau den ausgehenden Pfad, den sie braucht.

Die ANSSI stellt ausdrücklich klar, dass Audit all für R73 nicht ausreicht — die Empfehlung schreibt Deny vor, nicht Protokollierung. Der Audit-Modus ist der Schritt vor der Einführung: lange genug laufen lassen, um zu bestätigen, dass es keinen legitimen ausgehenden NTLM-Verkehr aus Tier 0 gibt (normalerweise sollte es keinen geben, da DC-zu-DC- und DC-zu-AD-Dienst-Verkehr Kerberos nativ unterstützt), dann auf Deny all umstellen. Der Leitfaden fügt eine betriebliche Einschränkung hinzu, die man ernst nehmen sollte: Das Blockieren ausgehenden NTLMs setzt voraus, dass Tier 0-Systeme andere AD-Dienste über den FQDN und nicht über die rohe IP-Adresse erreichen, da Kerberos auf Namensauflösung angewiesen ist, um das richtige Serviceticket auszuwählen — eine Fehlkonfiguration, die die Audit-Phase aufdeckt, bevor sie zum Ausfall wird.

Die begleitende Maßnahme: einschränken, was Tier 0 nach unten sendet (ANSSI R82/R83)

Das Blockieren ausgehenden NTLMs schließt die netzwerkseitige Authentifizierungsflanke der Tier 0-Exposition. Die Grundposition der ANSSI lautet, dass Tier 0-Administrationsarbeitsplätze von vornherein keine Konnektivität nach unten haben sollten — physisch dediziert, mit ausgehendem Verkehr ausschließlich zu Tier 0-Ressourcen (R80). R82 und R83 greifen ausdrücklich nur dann, wenn eine Organisation stattdessen die zweite alternative Architektur der ANSSI übernimmt: die Bündelung des Tier 0-Fernzugriffs auf Umgebungen mit geringerem Vertrauensniveau als übergangsweisen Rückfall gegenüber einer vollständigen Trennung. Innerhalb dieses Modells schränkt R82 ein, welche Methoden der Fernverbindung aus Tier 0 heraus in weniger vertrauenswürdige Zonen erlaubt sind — RPC/MMC, PowerShell WinRM mit seiner standardmäßigen Kerberos-oder-NTLM-Netzwerkauthentifizierung oder natives RDP entweder im RestrictedAdmin-Modus oder mit einem Konto, dessen Geltungsbereich auf das Ziel-Tier beschränkt ist. R83 geht weiter: Das Konto, das für eine interaktive Sitzung auf diesem weniger vertrauenswürdigen Ziel verwendet wird, muss der eigenen Vertrauenszone dieses Ziels angehören, niemals eine Tier 0- oder Tier 1-Anmeldeinformation, damit ein kompromittiertes System einer niedrigeren Ebene nie wiederverwendbare Tier 0-Geheimnisse in den Händen hält. Die vollständige Anleitung zu Tier-bezogenen Anmeldeeinschränkungen finden Sie unter Active Directory Authentifizierungsrichtlinien und Silos für Tier 0.

Ausgehendes NTLM vor und nach der Blockade erkennen

Beide Event IDs sind direkt in ANSSI-PA-099 §4.15.2.1 bestätigt, und Microsofts eigene Referenz zur Richtlinieneinstellung verweist auf denselben Betriebsprotokollpfad. Zwei Dinge, die nach Aktivierung der Blockade überwacht werden sollten:

• Jede Häufung von Event ID 4001 nach dem Rollout verdient eine Untersuchung — entweder wurde in der Audit-Phase eine legitime Abhängigkeit übersehen, oder es versucht gerade etwas aktiv, eine ausgehende Authentifizierung zu erzwingen, und wird dabei gestoppt.
• Event ID 8001 während der Audit-Phase ist Ihre Abhängigkeitskarte. Jedes darin aufgeführte Quelle/Ziel-Paar ist etwas, das zu klären ist — beheben, ausnehmen oder auf Kerberos migrieren — bevor auf Deny all umgestellt wird.

Verwandte Erkennungsabdeckung — LDAP- und SMB-Relay-Abwehr, die unabhängig davon zählt, ob ausgehendes NTLM blockiert ist — behandeln LDAP Channel Binding auf Domain Controllern und SMB-Signierung und NTLM-Relay.

Remediation

1. Bestätigen Sie zuerst den Tier 0-Geltungsbereich. R73 funktioniert nur, wenn Ihre Tier 0-OU tatsächlich jeden Domain Controller und jeden Tier 0-sensiblen Server enthält — gleichen Sie das mit Ihrem Tier-Verwaltungsmodell ab, bevor Sie irgendeine Gruppenrichtlinie verknüpfen.
2. Führen Sie Audit all ein, über eine mit der Tier 0-OU verknüpfte Gruppenrichtlinie. Lassen Sie es lange genug laufen, um Ihren Patch-Zyklus, Backup-Jobs und alle monatlichen oder vierteljährlichen Administrationsaufgaben zu erfassen — kurze Audit-Fenster übersehen wiederkehrende Abhängigkeiten.
3. Prüfen Sie die Einträge zu Event ID 8001 und klären Sie jeden legitimen Fall: Richten Sie die Quelle auf Kerberos aus (meist eine DNS- oder SPN-Korrektur), nehmen Sie sie in die NTLM-Serverausnahmeliste auf, wenn sie wirklich nicht von NTLM wegkommt, oder setzen Sie die Abhängigkeit außer Betrieb.
4. Stellen Sie dieselbe Gruppenrichtlinie auf Deny all um. Achten Sie in den Tagen danach auf Event ID 4001 — alles Unerwartete ist entweder eine übersehene Abhängigkeit oder ein aktiver Erzwingungsversuch.
5. Erweitern Sie auf R74+, sobald Tier 0 saubere Ergebnisse liefert: Verknüpfen Sie eine gleichwertige Gruppenrichtlinie auf Domänenebene für den Rest der Umgebung, mit WMI-gefilterten Ausnahmen dort, wo NTLM wirklich noch nicht entfernt werden kann.
6. Ergänzen Sie R82/R83 für Tier 0-Administratoren, die sich nach unten verbinden müssen — beschränken Sie die Methode der Fernverbindung und verlangen Sie ein Konto des Ziel-Tiers, wie im vorherigen Abschnitt beschrieben, sodass diese Maßnahme und die Blockade auf Netzwerkebene beide Richtungen des Risikos abdecken.
7. Kombinieren Sie das mit Härtung auf der Relay-Seite. Das Blockieren ausgehenden NTLMs entfernt die Quelle weitergeleiteter Authentifizierungen aus Tier 0, aber jedes System im Informationssystem, das weiterhin unsignierte oder ungeschützte Ziele für NTLM-Relay akzeptiert (LDAP ohne Channel Binding, SMB ohne Signierung, AD CS-Webregistrierung ohne Extended Protection), bleibt gegenüber Opfern außerhalb von Tier 0 angreifbar. Behandeln Sie diese Gruppenrichtlinie als eine Schicht, nicht als die gesamte Verteidigung.

Wie EtcSec das erkennt

Das Active Directory-Audit von EtcSec prüft genau diese Konfigurationslücke. ANSSI_R73_NTLM_OUTBOUND_TIER0 meldet das Fehlen jeder Gruppenrichtlinieneinstellung, die RestrictSendingNTLMTraffic über Tier 0-Systeme hinweg auf Deny all setzt — der reine Audit-Modus wird korrekt als Nichterfüllung der Maßnahme gewertet. ANSSI_R74_NTLM_OUTBOUND_DOMAIN verfolgt separat, ob dieselbe Deny-Richtlinie auf eine auf Domänenebene verknüpfte Gruppenrichtlinie ausgeweitet wurde. ANSSI_R82_R83_ADMIN_ARCHITECTURE meldet Tier 0-Systeme, denen die von R82 und R83 geforderten Schutzmaßnahmen der Administrationsarchitektur fehlen, und NTLM_RELAY_OPPORTUNITY meldet die breitere Relay-Exposition in der Umgebung, wann immer NTLM ohne die oben beschriebenen kompensierenden Schutzmaßnahmen erreichbar bleibt.