ADCS ESC2, ESC3, ESC5, ESC7: Zertifikatseskalationspfade zwischen den bekannten Techniken

Was sind ADCS ESC2 ESC3 ESC5 ESC7 Zertifikatseskalationspfade

Die ADCS-Zertifikatseskalationspfade ESC2, ESC3, ESC5 und ESC7 liegen in der Lücke zwischen zwei bereits gut abgedeckten Enden der Angriffsfläche von Active Directory Certificate Services (AD CS). Die Forschung Certified Pre-Owned von SpecterOps benannte acht Techniken, ESC1 bis ESC8, und spätere Forschung fügte ESC9, ESC10 und ESC11 hinzu. Dieser Corpus deckt bereits beide Enden ab: ADCS-Angriffspfade erklärt behandelt ESC1, ESC4, ESC6 und ESC8, und ADCS ESC9, ESC10, ESC11: Zertifikatseskalationspfade jenseits von ESC1-ESC8 behandelt die nach KB5014754 veröffentlichten Techniken der Bindungsebene. ESC2, ESC3, ESC5 und ESC7 sind die vier Techniken aus der ursprünglichen SpecterOps-Nummerierung, die keiner der beiden Artikel abdeckt.

Diese Lücke ist relevant, weil diese vier Techniken kein zufälliger Restposten sind, sondern sich in dieselben Active-Directory-Angriffspfade einreihen, die BloodHound-artige Analysen für jede andere Tier-0-Technik abbilden. ESC2 und ESC3 sind, wie ESC1, Techniken auf Template-Ebene — aber statt eines Templates, das preisgibt, als wer sich ein Zertifikat authentifizieren kann, geben sie preis, wofür ein einmal ausgestelltes Zertifikat verwendet werden kann — entweder für jeden beliebigen Zweck oder für den spezifischen Zweck, Zertifikate im Namen einer anderen Person anzufordern. ESC5 und ESC7 sind, wie ESC4, Zugriffskontroll-Techniken — aber statt einer ACL auf einem einzelnen Zertifikatstemplate betreffen sie die Objekte und Berechtigungen, die jedes Template und jedes von der CA jemals ausgestellte Zertifikat kontrollieren: die Zugriffskontrolle der CA selbst sowie die PKI-Container in Active Directory, die die Templates, die CA-Registrierungen und die Liste der von Domänencontrollern für die Authentifizierung vertrauten CAs enthalten.

Eine Umgebung, die bereits jeden ESC1-, ESC4-, ESC6- und ESC8-Befund sowie jeden ESC9-, ESC10- und ESC11-Befund behoben hat, kann über diese vier Techniken weiterhin einen aktiven Pfad zum Domain Admin haben — weil keine der anderen Prüfungen den EKU-Umfang, die Delegation von Enrollment Agents oder die Zugriffskontrolle auf PKI-Objekt- und CA-Ebene betrachtet.

Funktionsweise

ESC2 — Templates mit „Any Purpose" oder ohne EKU

ESC2 ist ein Zertifikatstemplate, dessen Extended Key Usage (EKU) entweder die Any-Purpose-OID (2.5.29.37.0) ist oder gar keine EKUs definiert — was Windows wie ein einer untergeordneten CA gleichwertiges Template behandelt, das für jeden Zweck verwendbar ist. Laut der Certify-Dokumentation von SpecterOps erfordert die Ausnutzung, dass alle folgenden Bedingungen gleichzeitig zutreffen: Das Angreifer-Principal besitzt Enrollment-Rechte auf CA-Ebene, dasselbe Principal besitzt Enrollment-Rechte auf dem konkreten Template, das Template erfordert keine Manager-Genehmigung, das Template erfordert keine autorisierten (gegengezeichneten) Signaturen, und die EKU des Templates ist Any Purpose oder vollständig fehlend.

Sind diese Bedingungen erfüllt, registriert der Angreifer ein Zertifikat aus dem Template und erhält damit eine Anmeldeinformation, die Windows für jeden zertifikatsnutzenden Zweck akzeptiert — laut SpecterOps-Dokumentation einschließlich derselben Rolle „Certificate Request Agent", von der ESC3 abhängt. Mit anderen Worten: Ein ESC2-Template kann genutzt werden, um einen ESC3-artigen Enrollment-Agent-Angriff zu starten, obwohl es die EKU Certificate Request Agent nie explizit deklariert. Genau deshalb sollten ESC2-Befunde immer gegen die übrigen veröffentlichten Templates der CA geprüft werden, bevor man sie als geringfügig einstuft: Ein Any-Purpose-Zertifikat ist nur so gefährlich wie das, wofür die CA es sonst noch einlösen lässt.

ESC3 — Enrollment-Agent-Templates (Kette aus zwei Templates)

ESC3 ist eine Kette aus zwei Templates, keine einzelne Fehlkonfiguration. Das erste Template muss die EKU Certificate Request Agent (OID 1.3.6.1.4.1.311.20.2.1) tragen — dieselbe OID, die Microsoft als Application-Policy-Erweiterung für Enrollment Agents dokumentiert, die bei der Ausstellung von Smartcards verwendet wird. Laut SpecterOps-Dokumentation benötigt das Template der ersten Stufe dieselben Enrollment-Voraussetzungen wie ESC2 (Enrollment-Rechte auf CA- und Template-Ebene, keine Manager-Genehmigung, keine autorisierten Signaturen) plus diese spezifische EKU.

Sobald der Angreifer dieses Enrollment-Agent-Zertifikat besitzt, benötigt er ein zweites Template: eines, das nicht einschränkt, wer als Enrollment Agent auftreten darf, in das sich der Angreifer registrieren kann, das keine Manager-Genehmigung erfordert und dessen EKU mit der Agent-Rolle kompatibel ist — Client-Authentifizierung, PKINIT, Smartcard-Anmeldung, Any Purpose oder gar keine EKU. Sind beide Teile vorhanden, fordert der Angreifer ein Zertifikat aus dem zweiten Template im Namen einer Zielidentität an, etwa eines Domain Admin, und signiert die Anfrage mit dem Enrollment-Agent-Zertifikat. Das resultierende Zertifikat authentifiziert sich als das Ziel, nicht als der Angreifer.

Microsofts eigene Dokumentation zur mit Windows Server 2008 Enterprise eingeführten Funktion Restricted Enrollment Agent beschreibt genau, warum dies standardmäßig gefährlich ist: Vor dieser Funktion war es „nicht möglich, einem Enrollment Agent zu gestatten, nur eine bestimmte Gruppe von Benutzern zu registrieren", sodass jedes gültige Enrollment-Agent-Zertifikat verwendet werden konnte, um im Namen jedes Benutzers der Organisation ein Zertifikat anzufordern, einschließlich Domain Admins. Restricted Enrollment Agent erlaubt es einem CA-Administrator, festzulegen, für welche Templates und welche Ziel-Sicherheitsgruppen jedes Enrollment-Agent-Zertifikat verwendet werden darf — allerdings nur auf einer Enterprise-Edition-CA und nur, wenn es tatsächlich konfiguriert wurde.

ESC5 — Verwundbare Zugriffskontrolle auf PKI-Objekte

ESC5 ist überhaupt kein Template-Problem. Es ist ein Active-Directory-ACL-Problem auf den Objekten, die die gesamte PKI vertrauenswürdig machen. Laut SpecterOps-Dokumentation gehören folgende Objekte zum betroffenen Bereich:

• das eigene AD-Computerobjekt des CA-Servers
• der RPC/DCOM-Server des CA-Servers
• der Container-Baum Public Key Services im Configuration-Namenskontext (CN=Public Key Services,CN=Services,CN=Configuration,DC=...), einschließlich seiner Unter-Container Certificate Templates, Certification Authorities und Enrollment Services
• das Objekt NTAuthCertificates innerhalb dieses Containers

Laut Microsofts eigener [MS-WCCE]-Protokolldokumentation enthält das Objekt NTAuthCertificates ein mehrwertiges Attribut mit DER-kodierten CA-Signaturzertifikaten — in der Praxis die Liste der CAs, denen Domänencontroller für die zertifikatsbasierte Authentifizierung (einschließlich Smartcard-Anmeldung) vertrauen. Kann ein Angreifer auf dieses Objekt schreiben, kann er eine betrügerische CA in die Vertrauensliste aufnehmen; jedes Zertifikat, das diese betrügerische CA anschließend signiert, wird für die Domänenauthentifizierung vertrauenswürdig. Die SpecterOps-Dokumentation nennt ein konkretes Beispiel für das allgemeine Risiko: Domain Users mit GenericAll auf dem Certificate-Templates-Container und dessen untergeordneten Objekten — volle Kontrolle über jede Zertifikatstemplate-Definition in der Gesamtstruktur, ausgehend von einer standardmäßig weit gefassten Gruppe.

Wie schwerwiegend ein ESC5-Befund ist, hängt vollständig davon ab, welches Objekt gegenüber wem offenliegt. Schreibzugriff auf den Certificate-Templates-Container erlaubt es einem Angreifer, Templates von Grund auf in eine ESC1-/ESC2-/ESC3-taugliche Form zu bringen oder zu verändern und dabei jede bereits durchgeführte Härtung der bestehenden Templates zu umgehen. Schreibzugriff auf das Computerobjekt der CA oder deren RPC/DCOM-Server kann zur Kompromittierung des CA-Hosts selbst führen und damit zum privaten Schlüssel der CA — dieselbe Auswirkungsklasse, die in Certighost CVE-2026-54121 dokumentiert ist, wo eine andere AD-CS-Schwachstelle einem niedrig privilegierten Benutzer erlaubte, sich als Domänencontroller auszugeben.

ESC7 — Verwundbare Zugriffskontrolle der Zertifizierungsstelle

ESC7 sitzt im Security-Descriptor des CA-Objekts selbst, überhaupt nicht auf AD-Objekten — und ist, anders als ESC6, kein Registry-Flag. Windows-CAs unterstützen Rollentrennung über zwei Zugriffsrechte, die im Security-Tab der Zertifizierungsstellenkonsole konfigurierbar sind: ManageCA (die Rolle CA-Administrator) und ManageCertificates (die Rolle Zertifikatmanager/-verantwortlicher).

Laut SpecterOps-Dokumentation erlaubt der Besitz von ManageCA einem Principal, die CA-weite Konfiguration zu ändern — einschließlich des Umschaltens des Flags EDITF_ATTRIBUTESUBJECTALTNAME2, von dem ESC6 abhängt, des erneuten Aktivierens zuvor deaktivierter verwundbarer Templates sowie des Herstellens der Bedingungen, auf die sich ESC11 und ESC16 stützen. Das bedeutet: Ein Angreifer, der nur ManageCA besitzt — ohne jede Template-Fehlkonfiguration in Sicht —, kann ESC6- oder ESC11-Bedingungen nach Belieben herstellen. Die SpecterOps-Dokumentation beschreibt zudem einen direkteren ManageCA-Missbrauch: ein Zertifikat aus einem Template anfordern, das eine Manager-Genehmigung erfordert, die Anfrage fehlschlagen und in der Warteschlange hängen lassen, und anschließend ManageCA zusammen mit ManageCertificates nutzen, um diese ausstehende Anfrage zwangsweise auszustellen — unabhängig von der Genehmigungspflicht, die dies eigentlich verhindern sollte.

ManageCertificates allein erlaubt einem Principal, Zertifikate zu verwalten und auszustellen, die auf Genehmigung warten. Laut SpecterOps-Dokumentation ermöglicht dies eine ESC1-artige Umgehung über gruppengebundene Ausstellungsrichtlinien: ein Zertifikat aus einem genehmigungspflichtigen Template anfordern, mit ManageCertificates eine gruppengebundene Issuance-Policy-OID in die ausstehende Anfrage einschleusen und diese dann ausstellen — wodurch man ein Zertifikat erhält, dessen Ausstellungsrichtlinie auf eine privilegierte Gruppe verweist, ohne jemals die Manager-Genehmigungskontrolle zu erfüllen, die das Template eigentlich durchsetzen sollte.

Die Angriffskette

Das Muster zieht sich durch alle vier Techniken: ESC2 und ESC3 missbrauchen, wozu ein Template berechtigt, sobald ein Zertifikat daraus hervorgeht; ESC5 und ESC7 missbrauchen, wer überhaupt befugt ist, die Templates und die CA zu kontrollieren. Diese zweite Kategorie ist der Grund, warum das Beheben jedes einzelnen durch ESC1, ESC2, ESC3, ESC4 oder ESC6 markierten Templates die Tür nicht schließt — ein Angreifer mit ESC5- oder ESC7-Zugriff kann den verwundbaren Zustand nach Abschluss der Überprüfung einfach wiederherstellen.

🚨 Gefahr: ESC3 und die Schreibzugriffs-Varianten von ESC5 enden beide im selben Ergebnis wie ESC1 — einem Zertifikat, das sich als Zielidentität authentifiziert und in ein Kerberos-TGT umgewandelt werden kann, um diese Identität zu imitieren, einschließlich eines Domain Admin. Die Eskalation in die ACL eines PKI-Objekts beginnt häufig als gewöhnliche ACL-Missbrauch-und-DCSync-Aufklärung und nicht als AD-CS-spezifische Technik.

Erkennung

Abhilfemaßnahmen

1. Any-Purpose- und EKU-lose Authentifizierungstemplates entfernen (ESC2). Beschränken Sie die EKU-Liste jedes veröffentlichten Templates auf das, was tatsächlich benötigt wird. Muss ein Template wirklich für mehrere Zwecke wiederverwendbar sein, behalten Sie die Manager-Genehmigung und die Anforderung autorisierter Signaturen bei, statt sich allein auf eine enge EKU zu verlassen.
2. Enrollment-Agent-Templates einschränken (ESC3). Konfigurieren Sie Restricted Enrollment Agent auf jeder Enterprise-Edition-CA, die Certificate-Request-Agent-Zertifikate ausstellt, und grenzen Sie jeden Enrollment Agent auf bestimmte Templates und bestimmte Ziel-Sicherheitsgruppen ein, statt ihn uneingeschränkt zu lassen. Steht Restricted Enrollment Agent nicht zur Verfügung, beschränken Sie die Registrierung im Enrollment-Agent-Template auf die kleinstmögliche, eng verwaltete Gruppe.
3. ACLs von PKI-Objekten härten (ESC5). Überprüfen Sie die ACLs der Container Certificate Templates, Certification Authorities und Enrollment Services, des Objekts NTAuthCertificates sowie des AD-Computerobjekts jedes CA-Servers. Entfernen Sie GenericAll, WriteDacl, WriteOwner und gleichwertige Rechte von jedem Principal außerhalb der vorgesehenen Tier-0-PKI-Administrationsgruppe.
4. Rollentrennung der CA verschärfen (ESC7). Überprüfen Sie den Security-Tab jeder CA und stellen Sie sicher, dass Manage CA und Issue and Manage Certificates nur von den Konten gehalten werden, die sie benötigen. Behandeln Sie beide als Tier-0-äquivalente Berechtigungen, nicht als allgemeine IT-Admin-Standardrechte — siehe Active Directory härten dazu, wie sich dies in eine breitere Tier-0-Berechtigungsüberprüfung einfügt.
5. Umgang mit ausstehenden Anfragen überprüfen. Stellen Sie sicher, dass das zwangsweise Ausstellen einer abgelehnten oder ausstehenden Zertifikatsanfrage nicht routinemäßig denselben Principals zur Verfügung steht, die auch Zertifikate anfordern können — genau diese Kombination macht die ESC7-Genehmigungsumgehung erst möglich.
6. Nach jeder Änderung erneut testen. Einschränkungen bei Enrollment Agents und Änderungen an PKI-ACLs können legitime Smartcard-Ausstellung und delegierte Administrationsworkflows beeinträchtigen. Validieren Sie Änderungen mit einer repräsentativen Pilotgruppe, bevor Sie sie CA-weit erzwingen, und führen Sie die CA-Audit-Log-Überprüfung aus dem Erkennungsabschnitt während des gesamten Rollouts fort.

Einordnung: ANSSI R36, R37 und der Rest des ADCS-Corpus

ANSSIs Leitfaden zur sicheren Administration von Active Directory (ANSSI-PA-099) behandelt das PKI-Risiko für Tier 0 als eigene, nummerierte Empfehlung, unabhängig von allgemeiner Zertifikatshygiene. R36 besagt, dass eine PKI, die Zertifikate erzeugen kann, die zur Authentifizierung in Tier 0 verwendbar sind, „keine Angriffspfade zu Tier 0 aus niedriger vertrauenswürdigen Ebenen bieten darf, weder über die Administration der sie hostenden Systeme noch über die Delegation von Rechten über Zertifikatserzeugungsfähigkeiten noch über veröffentlichte Zertifikatstemplates" — eine nahezu exakte Beschreibung dessen, was ESC5 und ESC7 missbrauchen (delegierte Kontrolle über die Fähigkeit zur Zertifikatserzeugung, also die CA und ihre PKI-Objekte) und was ESC2 missbraucht (veröffentlichte Templates, die mehr Fähigkeiten gewähren als beabsichtigt). Derselbe Leitfaden führt separat R37 an, das die kryptografische Stärke von Zertifikaten behandelt (Verbot von DSA-Signaturen, Pflicht zu SHA-2-/SHA-3-Hashes und Mindestgrößen für RSA-Schlüssel) — ein reales, aber eigenständiges Anliegen gegenüber den hier behandelten EKU- und ACL-Fehlkonfigurationen, das es wert ist, zusätzlich zu diesen vier Techniken geprüft zu werden, nicht an deren Stelle.

Dieser Artikel wiederholt bewusst nicht ESC1, ESC4, ESC6 oder ESC8 — siehe dazu ADCS-Angriffspfade erklärt — oder ESC9, ESC10, ESC11, die in der Zertifikatszuordnungs- und RPC-Verschlüsselungsebene angesiedelt sind, die in ADCS ESC9, ESC10, ESC11 und dem zugehörigen Artikel zum schwachen Zertifikatmapping behandelt werden. Eine vollständige AD-CS-Überprüfung benötigt alle drei Artikel sowie die breitere Tier-0-Checkliste in Active-Directory-Sicherheit auditieren, denn keine der elf Techniken ersetzt eine andere.

Wie EtcSec dies erkennt

Die AD-Audit-Prüfungen von EtcSec bilden jede hier behandelte Technik direkt ab: ESC2_ANY_PURPOSE markiert authentifizierungsfähige Templates mit Any-Purpose- oder leerer EKU und ohne Genehmigungsschranke, ESC3_ENROLLMENT_AGENT markiert Certificate-Request-Agent-Templates und deren uneingeschränkte nachgelagerte Ziele, ESC5_PKI_OBJECT_ACL überprüft die ACLs des Public-Key-Services-Container-Baums, von NTAuthCertificates und der CA-Computerobjekte, und ESC7_CA_VULNERABLE_ACL überprüft die Rollentrennung auf CA-Ebene auf zu weit gefasste ManageCA- und ManageCertificates-Vergaben. Befunde aus allen vier Techniken fließen in PATH_CERTIFICATE_ESC zusammen, wenn sie einen aktiven Pfad zum Domain Admin bilden — ein Template-Flag oder ein ACL-Eintrag wird also danach priorisiert, ob er tatsächlich erreichbar ist, nicht isoliert markiert.

Primärquellen

• SpecterOps / Certify — Escalation Techniques Overview
• SpecterOps / Certify — ESC2: Misconfigured Any Purpose
• SpecterOps / Certify — ESC3: Misconfigured Certificate Request Agent
• SpecterOps / Certify — ESC5: Vulnerable PKI Object Access Control
• SpecterOps / Certify — ESC7: Vulnerable Certificate Authority Access Control
• Certified Pre-Owned: Abusing Active Directory Certificate Services
• Microsoft: AD CS Restricted Enrollment Agent
• Microsoft: [MS-WCCE] NTAuthCertificates Object
• ANSSI-PA-099: Recommandations relatives à l'administration sécurisée des systèmes d'information reposant sur Microsoft Active Directory