ESC1 bis ESC8 und Golden-Certificate-Angriffe zeigen, warum ADCS-Konfiguration und ein einzelner CA-Private-Key strukturelle PKI-Risiken bleiben. Wie Threshold-MPC-Signierung und Echtzeit-Revocation das Modell ändern.
Active Directory Certificate Services (ADCS) bleibt in vielen Windows-Estates die Standard-Enterprise-PKI. Öffentliche Forschung hat gezeigt, dass mehrere der schwerwiegendsten Privilege-Pfade keine «ungepatchten CVEs, die auf Patch Tuesday warten» sind. Es sind Konfigurations- und Architektur-Outcomes: Zertifikat-Templates, die dem Requester vertrauen, Enrolment-Pfade, die NTLM-Relay akzeptieren, und ein CA-Private-Key, der an einem Ort lebt.
Diese Seite fasst die strukturellen Probleme zusammen, würdigt die öffentliche Forschung, die sie dokumentiert hat, und beschreibt, wie ein anderes CA-Signaturmodell (Threshold-MPC, kryptografische SAN-Enforcement, kein NTLM-Enrolment, Echtzeit-Revocation) die Fehlermodi adressiert, die Patching allein nicht lösen kann.
Forscher bei SpecterOps haben eine Familie von ADCS-Privilege-Escalation-Techniken dokumentiert, die üblicherweise als ESC1 bis ESC8 bezeichnet werden. Die Details unterscheiden sich nach Template und Enrolment-Pfad; das Muster nicht:
| Muster | Was schiefgeht |
|---|---|
| ESC1 | Fehlkonfigurierte Templates erlauben einem authentifizierten Benutzer, ein Zertifikat anzufordern, das effektiv einen anderen Principal impersoniert (zum Beispiel durch Kontrolle des Subject Alternative Name). Domain-Privilegien folgen dann dem Zertifikat, nicht dem ursprünglichen Konto. |
| ESC8 | Web-Enrolment, das NTLM akzeptiert, kann über Relay missbraucht werden: ein Angreifer erzwingt Authentifizierung und enrolt gegen die CA unter der relayten Identität. |
| ESC2–ESC7 (Familie) | Verwandte Fehlkonfigurationen bei Templates, Enrolment Agents und CA-Berechtigungen, die ADCS von einem Identitätsservice in einen Domain-Admin-Escalation-Pfad verwandeln. |
Der wichtige architektonische Punkt: Mehrere dieser Pfade gelingen, weil ADCS Konfigurationsflags und Active-Directory-ACLs vertraut, die Operatoren selten end-to-end auditieren. Eine Organisation kann «fully patched» sein und trotzdem exponiert bleiben.
Veröffentlichte CVEs haben über die Zeit spezifische ADCS- und verwandte Enrolment-Schwächen adressiert (zum Beispiel Issues unter Identifiers wie CVE-2022-26923 und nachfolgende ADCS-Advisories). Behandeln Sie CVE-IDs als Beleg, dass Vendoren und Forscher die Problemklasse anerkennen; behandeln Sie kein grünes Patch-Dashboard als Beweis, dass ESC-Klassen-Template-Risiko verschwunden ist.
Die Anerkennung für das systematische öffentliche Mapping von ESC1–ESC8 gebührt den ADCS-Forschungspublikationen von SpecterOps. Diese Seite listet keine offensive Tooling; die Forschungsakte reicht, um eine Design-Diskussion zu rechtfertigen.
Wenn ein Angreifer den CA-Private-Key erhält, kann er Zertifikate für beliebige Subjects fälschen, solange Relying Parties dieser CA vertrauen. Das ist das Golden-Certificate-Szenario: unbegrenzte Fälschung, bis jeder Trust Anchor, der die CA einbettet, ersetzt ist.
In einem klassischen ADCS-Deployment sitzt der CA-Private-Key typischerweise in einer HSM-Partition oder einem Software-Key-Store. Diese Konzentration ist genau das High-Value-Target. Enrolment-Bugs zu patchen ändert nicht die Tatsache, dass ein einziger erfolgreicher Diebstahl des CA-Keys die Trust-Story für diese Hierarchie beendet.
Issues der Klasse ESC1 bis ESC4 folgen weitgehend aus Template- und Permission-Design, nicht aus einem einzelnen Memory-Corruption-Bug, den Sie mit einem Cumulative Update schließen. Solange:
bleibt die Escalation-Surface ein Konfigurations- und Protokollproblem. Security-Teams, die nur CVEs tracken, unterschätzen das Residualrisiko.
Eine PKI, die diese Fehlermodi entfernt, sieht anders aus als «ADCS plus bessere Hardening-Guides»:
Nichts davon ersetzt Inventory, Monitoring oder Certificate-Lifecycle-Disziplin. Es ändert die Trust-Architektur darunter.
DuoKeys PKI- und Zertifikatsprodukt kombiniert Certificate Lifecycle (ausstellen, erneuern, zurückziehen, auditieren) mit MPC-gestütztem Key Protection, sodass CA- und High-Value-Signing-Material kein Single-Appliance-Secret sind. Dieselbe Control Plane, die Zertifikate steuert, bindet auch an agentic Identitäten für nicht-menschliche Principals, die Maschinenzertifikate brauchen, ohne ADCS-Template-Schuld zu erben.
Praktische Programmform:
Q: Können wir ADCS behalten, wenn wir Templates härten?
Sie können Risiko reduzieren. ESC-Klassen-Issues zeigen, dass Template- und ACL-Review Pflicht ist, wenn ADCS bleibt. Hardening allein gibt Ihnen keine Threshold-CA-Keys und entfernt die Golden-Certificate-Konzentration nicht von selbst.
Q: Ist das nur ein Windows-Problem?
ADCS ist der übliche Enterprise-Fall wegen der Active-Directory-Kopplung. Jede CA, die einen monolithischen Private Key speichert und schwacher Enrolment-Identitätsbindung vertraut, hat dieselben strukturellen Risiken.
Q: Warum hier keine Exploit-Tools nennen?
Öffentliche CVE-Identifier und SpecterOps-Forschung reichen, um das Problem auf einer öffentlichen Produktseite zu etablieren. Tooling-Details gehören in einen privaten technischen Workshop, nicht in Marketing-Copy.
ADCS-Ausfälle, die für Domain-Compromise am meisten zählen, sind oft Konfigurations- und Key-Custody-Ausfälle: ESC1-artige Impersonation über Templates, ESC8-artiges Relay gegen NTLM-Enrolment, und ein CA-Key, der bei Diebstahl zum Golden Certificate wird. Patching hilft, wo eine CVE existiert. Es schreibt Template-Trust nicht um und splittet keinen monolithischen CA-Key. Threshold-MPC-Signierung, kryptografische SAN-Bindung, NTLM-freies Enrolment und Echtzeit-Revocation sind die architektonischen Antworten.
Geschrieben von
Nagib Aouini
Verwandte Ressourcen
Sagen Sie uns, wo Kontrolle heute schwierig ist. Wir helfen Ihnen, den nächsten praktischen Schritt zu finden.
