ADCS ESC9, ESC10, ESC11 Zertifikatseskalation

Was ist ADCS ESC9, ESC10, ESC11 Zertifikatseskalation

ADCS ESC9, ESC10, ESC11 Zertifikatseskalation bezeichnet die Gruppe von Active Directory Certificate Services (AD CS) Privilege-Escalation-Techniken, die nach der ursprünglichen „Certified Pre-Owned“-Forschung veröffentlicht wurden, die ESC1 bis ESC8 einführte. Während sich die ersten acht Pfade auf Template-Fehlkonfigurationen, gefährliche CA-Einstellungen und HTTP-Web-Enrollment konzentrieren, zielen ESC9, ESC10 und ESC11 auf die Ebene ab, die entscheidet, ob ein Zertifikat tatsächlich dem richtigen Konto zugeordnet wird: die im Zertifikat eingebettete Sicherheitserweiterung, die Zertifikatzuordnungskonfiguration des Domänencontrollers und die Verschlüsselungsdurchsetzung auf der RPC-Enrollment-Schnittstelle der CA.

ℹ️

ℹ️ Hinweis: Dieser Artikel setzt die ESC1-ESC8-Grundlagen voraus. Siehe ADCS Angriffspfade: wie Zertifikat-Fehlkonfigurationen zu Eskalationspfaden in Active Directory werden, falls Sie diese Grundlage zuerst benötigen — dieser Artikel deckt ausschließlich ESC1 bis ESC8 ab (das sagt bereits sein Slug), was genau die Lücke schließt, die dieser Beitrag hier füllt.

Alle drei Techniken existieren wegen derselben zugrunde liegenden Änderung: Microsofts Update vom Mai 2022 (KB5014754) führte die Sicherheitserweiterung szOID_NTDS_CA_SECURITY_EXT ein, die die SID des anfragenden Prinzipals in ein ausgestelltes Zertifikat einbettet, damit das KDC dieses Zertifikat stark an ein Konto binden kann. ESC9, ESC10 und ESC11 sind drei verschiedene Wege, auf denen diese Bindung eine Umgebung nicht schützen kann — einer auf Template-Ebene, einer auf Domänencontroller-/Schannel-Ebene und einer auf RPC-Transportebene.

Wie es funktioniert

ESC9 — Keine Sicherheitserweiterung

ESC9 tritt auf, wenn das msPKI-Enrollment-Flag eines Zertifikatstemplates das Bit CT_FLAG_NO_SECURITY_EXTENSION (0x80000) enthält. Die Certify-Dokumentation von SpecterOps beschreibt dies als Unterdrückung der szOID_NTDS_CA_SECURITY_EXT-Erweiterung bei jedem Zertifikat, das aus diesem Template ausgestellt wird. Der Effekt ist, dass sich der Zertifikatzuordnungsprozess so verhält, als wäre StrongCertificateBindingEnforcement auf 0 gesetzt, unabhängig vom tatsächlichen Registrierungswert auf dem Domänencontroller, weil keine SID im Zertifikat vorhanden ist, gegen die geprüft werden könnte.

Für sich allein ist dieses Flag nicht ausnutzbar. Es wird zu ESC9, wenn es mit einer zweiten Bedingung kombiniert wird, nach der Angreifer bei ESC1-ESC8-nahen Templates ohnehin suchen: ein niedrig privilegierter Prinzipal mit GenericWrite (oder gleichwertig) auf ein anderes Konto. Ein Angreifer mit GenericWrite auf ein Opferkonto kann dessen userPrincipalName so ändern, dass er einem privilegierten Ziel entspricht (zum Beispiel dem sAMAccountName eines Administrators), ein Zertifikat aus dem ESC9-markierten Template als das Opferkonto beantragen und sich als das imitierte Ziel authentifizieren — weil das resultierende Zertifikat keine SID-Erweiterung trägt, die dem gefälschten UPN widersprechen würde.

ESC10 — Schwache Zertifikatzuordnung (domänenweit)

ESC10 erzeugt dasselbe praktische Ergebnis wie ESC9 — eine Authentifizierung, die dem falschen Konto zugeordnet wird —, aber die Fehlkonfiguration liegt auf dem Domänencontroller oder in Schannel, nicht bei einem einzelnen Zertifikatstemplate. SpecterOps und die Community-Forschung (einschließlich des Certify-Wikis und unabhängiger AD-CS-Analysen) beschreiben zwei Varianten:

Fall A — Der Registrierungswert CertificateMappingMethods von Schannel auf dem Domänencontroller schließt UPN-Mapping ein. Ein Angreifer, der auf userPrincipalName eines Opferkontos schreiben kann (wiederum über GenericWrite oder ähnliches), setzt diesen so, dass er einem Zielprinzipal entspricht, und authentifiziert sich anschließend über Schannel (Client-TLS-Authentifizierung) mit einem beliebigen Zertifikat, dessen Subject oder SAN den gefälschten UPN widerspiegelt.
Fall B — StrongCertificateBindingEnforcement ist auf dem Domänencontroller explizit auf 0 (Kompatibilitätsmodus) gesetzt statt auf den erzwungenen Standardwert, sodass eine fehlende oder nicht übereinstimmende SID-Erweiterung akzeptiert statt abgelehnt wird — für jedes Template und jeden Prinzipal, nicht nur für ein markiertes Template wie bei ESC9.

Der entscheidende operative Unterschied zu ESC9: ESC10 ist nicht auf ein einzelnes Zertifikatstemplate begrenzt und erweitert damit typischerweise den Pool ausnutzbarer Konten auf die gesamte Domäne.

⚠️

⚠️ Achtung: ESC10 teilt seine Grundursache mit einem breiteren Härtungsthema — der Stärke der Zertifikatzuordnung auf dem Domänencontroller. Für die vollständige Mechanik von schwacher gegenüber starker Zuordnung, KDC-Ereignisse und Schannel-Sanierung siehe Schwaches Zertifikatmapping in AD CS: Warum starke Bindung zählt.

ESC11 — NTLM-Relay auf die RPC-Schnittstelle der CA

ESC11 ist das RPC-Transport-Pendant zu ESC8 (NTLM-Relay auf HTTP-Web-Enrollment). Zertifizierungsstellen stellen die ICertPassage-Schnittstelle (MS-ICPR) für Zertifikatanfragen über RPC bereit. Laut der Certify-Dokumentation von SpecterOps und unabhängiger Forschung von Compass Security wird durch das Interface-Flag IF_ENFORCEENCRYPTICERTREQUEST auf der CA gesteuert, ob diese Schnittstelle eine Verschlüsselung auf Paketebene erzwingt. Dieses Flag ist standardmäßig aktiviert, wird aber häufig deaktiviert, um Kompatibilität mit älteren Clients zu gewährleisten, die RPC_C_AUTHN_LEVEL_PKT_PRIVACY nicht aushandeln können.

Ist das Flag deaktiviert, kann ein Angreifer, der ein Opfer (zum Beispiel ein Domänencontroller-Maschinenkonto) zur NTLM-Authentifizierung zwingt, diese Authentifizierung zur RPC-Schnittstelle der CA relayen — und damit dieselben Schutzmaßnahmen umgehen, die ESC8 für Web-Enrollment abdeckt, jedoch über RPC statt über HTTP und unabhängig davon, ob Web-Enrollment überhaupt installiert ist.

Die Angriffskette

Technik	Voraussetzung	Missbrauchspfad	Auswirkung
ESC9	`GenericWrite` auf ein Opferkonto + ein Template mit `CT_FLAG_NO_SECURITY_EXTENSION`	UPN des Opfers auf den `sAMAccountName` eines Ziels umschreiben, Zertifikat beantragen, als Ziel authentifizieren	Imitation eines bestimmten Zielkontos
ESC10 (Fall A)	`GenericWrite` auf ein Opferkonto + DC-Schannel-`CertificateMappingMethods` erlaubt UPN-Mapping	UPN des Opfers umschreiben, über Schannel-Client-Zertifikat authentifizieren	Imitation jedes Kontos mit passendem UPN, domänenweit
ESC10 (Fall B)	`StrongCertificateBindingEnforcement` = 0 auf dem Domänencontroller	Jedes Zertifikat ohne SID-Erweiterung wird für die Zuordnung akzeptiert	Domänenweite Akzeptanz schwacher Zuordnung
ESC11	`IF_ENFORCEENCRYPTICERTREQUEST` der CA nicht gesetzt	NTLM-Authentifizierung eines Ziels erzwingen, zum RPC-Endpunkt (ICPR) der CA relayen, Zertifikat als Ziel beantragen	Zertifikat für die relayte Identität erhalten, oft ein Domänencontroller

🚨 Gefahr: Alle drei Techniken können im selben Ergebnis enden wie ESC1-ESC8 — ein Zertifikat, das für Kerberos-PKINIT-Authentifizierung als Domain Admin oder als Domänencontroller nutzbar ist. Die Eskalation über GenericWrite führt direkt in ACL-Missbrauch und DCSync: Wie stille Rechte Domain Admin öffnen. Der Relay-Schritt von ESC11 nutzt dieselben Coercion-/Relay-Primitiven, die in NTLM-Relay-Angriffe: Erkennung und Prävention behandelt werden.

Erkennung

Indikator	Event ID / Quelle	Worauf zu achten ist
Schwache oder fehlgeschlagene Zertifikatzuordnung bei der Anmeldung	Systemprotokoll des Domänencontrollers, Event ID 39 (keine starke Zuordnung), 40 (Zertifikat älter als Konto), 41 (SID-Mismatch)	Auditereignisse von KB5014754, die für privilegierte Konten, Admin-Arbeitsstationen oder Domänencontroller auslösen — nicht nur Legacy-Kompatibilitätsrauschen
Template ohne Sicherheitserweiterung	AD-CS-Template-Inventar	`msPKI-Enrollment-Flag` enthält `CT_FLAG_NO_SECURITY_EXTENSION` (0x80000) bei einem Template mit Authentifizierungs-EKU
Domänenweites Mapping-Downgrade	Registrierung des Domänencontrollers	`HKLM\SYSTEM\CurrentControlSet\Services\Kdc\StrongCertificateBindingEnforcement` = 0 (Kompatibilität) statt des erzwungenen Werts; `CertificateMappingMethods` (Schannel, `HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL`) reaktiviert UPN-/Subject-Issuer-Mapping
UPN-Änderungen vor Zertifikatanfragen	AD-CS-CA-Ausstellungsprotokoll + Verzeichnisänderungs-Auditing (Event ID 4738 auf dem DC)	Eine `userPrincipalName`-Änderung, unmittelbar gefolgt von einer Zertifikatregistrierung (Event ID 4886/4887 auf der CA) aus derselben Sitzung
RPC-Schnittstellenverschlüsselung nicht erzwungen	CA-Registrierung via `certutil -config "<CA>" -getreg CA\InterfaceFlags`	Der zurückgegebene Wert enthält nicht `IF_ENFORCEENCRYPTICERTREQUEST` (0x200) — deutet darauf hin, dass der ICPR-RPC-Endpunkt unverschlüsselte/unsignierte Anfragen akzeptiert und relay-fähig ist
Anomale Zertifikatanfragen über RPC	Netzwerk / CA-Server	Unerwartete eingehende RPC/DCOM-Verbindungen zum CA-Server von anderen Hosts als bekannten Enrollment-Clients, korreliert mit NTLM-Authentifizierungs-Coercion-Versuchen

💡

💡 Tipp: Microsoft Defender for Identity bietet eine eigene Sicherheitslagebewertung „Verschlüsselung für die RPC-Zertifikatregistrierungsschnittstelle erzwingen“, die ESC11-anfällige CAs direkt markiert — nutzen Sie diese, wenn Defender for Identity bereitgestellt ist, statt sich ausschließlich auf manuelle certutil-Prüfungen zu verlassen.

Sanierung

CT_FLAG_NO_SECURITY_EXTENSION von Templates entfernen (ESC9). Prüfen Sie das msPKI-Enrollment-Flag jedes Zertifikatstemplates. Bei jedem authentifizierungsfähigen Template mit gesetztem Flag sollte dieses entfernt werden, sofern kein dokumentierter, geprüfter Grund vorliegt — und dieser Grund sollte keine unprivilegierten Enrollment-Rechte einschließen.
Domänencontroller auf Full Enforcement umstellen (ESC10 Fall B). Bestätigen Sie, dass StrongCertificateBindingEnforcement nicht fest auf 0 gesetzt ist. Laut Microsofts KB5014754-Zeitplan wechselten Domänencontroller ohne expliziten Registrierungswert mit dem Update vom Februar 2025 in den Full-Enforcement-Modus, und der Registrierungsschlüssel selbst wurde nach dem Update vom September 2025 nicht mehr berücksichtigt — eine explizit belassene 0 ist also ein bewusstes Downgrade, das gefunden und begründet werden sollte.
Schwache Schannel-Zuordnungsmethoden deaktivieren (ESC10 Fall A). Überprüfen Sie CertificateMappingMethods auf jedem Domänencontroller und jedem Server, der Client-Zertifikat-TLS terminiert. Schwache Methoden (Subject/Issuer, nur Issuer, UPN) sollten deaktiviert bleiben; nur starke Methoden (S4U2Self, S4U2Self explizit) sollten zugelassen werden, sofern keine spezifische, dokumentierte Legacy-Anwendung etwas anderes erfordert.
RPC-Verschlüsselung auf jeder CA erzwingen (ESC11). Führen Sie certutil -setreg CA\InterfaceFlags +IF_ENFORCEENCRYPTICERTREQUEST auf jeder CA aus und starten Sie anschließend den Certificate-Services-Dienst neu (net stop certsvc && net start certsvc). Validieren Sie danach mit certutil -config "<CA>" -getreg CA\InterfaceFlags und bestätigen Sie, dass 0x200 vorhanden ist.
Die zugrunde liegende GenericWrite-Exposition schließen. Sowohl ESC9 als auch ESC10 Fall A erfordern, dass ein Angreifer bereits Schreibzugriff auf userPrincipalName eines Opferkontos besitzt. Überprüfen Sie ACLs auf übermäßig breite Vergaben von GenericWrite, GenericAll, WriteProperty oder gleichwertigen Rechten auf Benutzerobjekte, insbesondere von Helpdesk- oder Provisioning-Gruppen, als Teil derselben Sanierungsrunde.
Nach jeder Änderung erneut testen. Änderungen an Zertifikatzuordnung und RPC-Verschlüsselung können Legacy-Clients beeinträchtigen (ältere Windows-Versionen, Nicht-Windows-RPC-Clients, ältere Smartcard-Middleware). Rollen Sie Änderungen über eine repräsentative Pilotgruppe aus, bevor Sie domänenweit durchsetzen, und lassen Sie die KDC-/Schannel-Ereignisprüfung aus dem Erkennungsabschnitt während des Rollouts weiterlaufen, um zu bestätigen, dass keine legitime Authentifizierung zu scheitern beginnt.

✅ Schnellgewinn: Wenn die Zeit nur für eine Maßnahme heute reicht, führen Sie die Prüfung certutil -config "<CA>" -getreg CA\InterfaceFlags auf jeder CA aus. ESC11 erfordert keine Verzeichnisrechte zur Ausnutzung — nur Netzwerkzugriff und eine Coercion-Primitive —, was ihn zum niedrigschwelligsten der drei Pfade macht.

Wie EtcSec das erkennt

Die AD-Audit-Checks von EtcSec bilden jede Technik direkt ab: ESC9_NO_SECURITY_EXTENSION markiert Zertifikatstemplates mit CT_FLAG_NO_SECURITY_EXTENSION auf einem authentifizierungsfähigen Template, ESC10_WEAK_CERTIFICATE_MAPPING überprüft die Zertifikatzuordnungskonfiguration von Domänencontroller und Schannel auf Kompatibilitätsmodus-Einstellungen, und ESC11_ICERT_REQUEST_ENFORCEMENT verifiziert die RPC-Verschlüsselungsdurchsetzung auf jeder entdeckten CA. Da ESC9 und ESC10 Fall A beide von einer GenericWrite-artigen Voraussetzung abhängen, korreliert EtcSec diese Befunde außerdem mit der breiteren ACL-Expositionsfläche, sodass ein Template-Flag oder eine Registrierungseinstellung danach priorisiert wird, ob ein Angreifer tatsächlich einen Ausnutzungsweg hat — statt isoliert markiert zu werden.

Wenn Sie eine vollständige AD-CS-Prüfung statt einer Prüfung einzelner Techniken aufbauen, kombinieren Sie diesen Artikel mit Active Directory Sicherheit auditieren: Praktische Checkliste für interne Teams für die vollständige Tier-0-Checkliste, in die diese Pfade gehören.

ℹ️

ℹ️ Hinweis: EtcSec prüft bei jedem AD-Audit automatisch auf ESC9-, ESC10- und ESC11-Exposition. Führen Sie ein kostenloses Audit durch, um Ihre Umgebung zu überprüfen.

ADCS ESC9, ESC10, ESC11: Zertifikatseskalationspfade jenseits von ESC1-ESC8