ADCS prüfen: ESC1 bis ESC17 – welche Fehlkonfiguration wo steckt und wie man sie findet

Eine falsch eingestellte Zertifikatvorlage reicht, und ein normaler Domänenbenutzer meldet sich als Domänen-Admin an. Die Active Directory Certificate Services sind in vielen Netzen der kürzeste Weg zur vollständigen Übernahme – und gleichzeitig der Bereich, den kaum jemand regelmäßig prüft. Dieser Beitrag ordnet die bekannten Angriffspfade ESC1 bis ESC17 ein und zeigt, wo man nachsehen muss.

Warum die PKI so oft das Einfallstor ist

Ein Zertifikat mit der erweiterten Schlüsselverwendung Client-Authentifizierung ist im Active Directory ein vollwertiger Anmeldeausweis. Wer sich ein Zertifikat auf den Namen eines anderen Kontos ausstellen lassen kann, meldet sich per PKINIT als dieses Konto an – ohne dessen Passwort, und auch nach einem Passwortwechsel noch so lange, wie das Zertifikat gültig ist. Genau darum geht es bei fast allen ESC-Pfaden: Irgendwo darf jemand mehr beantragen, genehmigen oder verändern, als er sollte.

Die Nummerierung geht auf die Veröffentlichung „Certified Pre-Owned“ von SpecterOps aus dem Jahr 2021 zurück (ESC1 bis ESC8). Seitdem kamen Jahr für Jahr neue Pfade hinzu, zuletzt ESC17, das 2026 vorgestellt wurde.

Die Angriffspfade im Überblick

Wo man nachsieht – ohne Zusatzsoftware

Einstellungen der Zertifizierungsstelle

Die wichtigsten CA-Flags lassen sich direkt auf der CA mit Bordmitteln auslesen:

# ESC6: steht EDITF_ATTRIBUTESUBJECTALTNAME2 in der Liste?
certutil -getreg policy\EditFlags

# ESC11: muss IF_ENFORCEENCRYPTICERTREQUEST enthalten
certutil -getreg CA\InterfaceFlags

# ESC16: darf 1.3.6.1.4.1.311.25.2 NICHT enthalten
certutil -getreg policy\DisableExtensionList

# ESC7: wer darf die CA verwalten?
certutil -getreg CA\Security

Ist EDITF_ATTRIBUTESUBJECTALTNAME2 gesetzt, entfernt man es mit certutil -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2 und startet den Dienst neu (net stop certsvc && net start certsvc). Vorher prüfen, ob eine Anwendung genau darauf angewiesen ist – das ist selten, kommt aber bei alten Webserver-Abläufen vor.

Veröffentlichte Vorlagen

Welche Vorlagen eine CA tatsächlich ausstellt, zeigt certutil -CATemplates. Für jede davon sind in der Konsole certtmpl.msc vier Stellen entscheidend:

1. Antragstellername: „Informationen werden in der Anforderung angegeben“ ist bei Vorlagen mit Client- oder Server-Authentifizierung ein Warnsignal (ESC1, ESC17).
2. Erweiterungen → Anwendungsrichtlinien: Client-Authentifizierung, Smartcard-Anmeldung, „Beliebiger Zweck“ oder leer (ESC2)?
3. Sicherheit: Haben „Domänen-Benutzer“, „Domänen-Computer“ oder „Authentifizierte Benutzer“ das Recht „Registrieren“ – oder gar „Schreiben“ (ESC4)?
4. Ausstellungsvoraussetzungen: Ist die Genehmigung durch einen Zertifikatverwalter aktiviert? Das entschärft ESC1 deutlich.

Vorlagen der Schemaversion 1 (etwa die alte Vorlage „Webserver“) sind wegen ESC15 besonders kritisch. Microsoft hat CVE-2024-49019 im November 2024 geschlossen; trotzdem sollte man solche Vorlagen durch eine duplizierte Fassung mit aktuellem Schema ersetzen.

Starke Zertifikatzuordnung am Domänencontroller

Mit KB5014754 hat Microsoft die starke Zuordnung von Zertifikaten zu Konten eingeführt. Seit dem Update vom 11. Februar 2025 laufen Domänencontroller im Enforcement-Modus, seit September 2025 wird der Kompatibilitätsmodus nicht mehr unterstützt. Wer den Registrierungswert StrongCertificateBindingEnforcement früher auf 0 gesetzt hat, sollte das prüfen – und die Kdcsvc-Ereignisse 39, 40 und 41 im System-Protokoll der Domänencontroller im Blick behalten. Genau hier setzt ESC16 an: Fehlt die SID-Erweiterung in den Zertifikaten, hilft die starke Zuordnung nicht.

Web-Registrierung

Die Web-Registrierung unter /certsrv wird heute kaum noch gebraucht. Ist sie installiert, dann nur über HTTPS mit Extended Protection for Authentication und ohne NTLM. Besser ist es, die Rolle zu entfernen, wenn niemand sie nutzt (ESC8).

Typische Fallstricke

• „Unsere CA ist doch nur intern.“ Für ESC1 genügt ein beliebiges Domänenkonto – genau das, was ein Angreifer nach einer Phishing-Mail hat.
• Vergessene Test-Vorlagen. Duplikate mit Namen wie „Kopie von Benutzer“ oder „Test-SAN“ sind in der Praxis die häufigste Ursache für ESC1.
• Zweite CA übersehen. Viele Umgebungen haben neben der produktiven noch eine alte CA aus einem früheren Projekt, die weiter Vorlagen ausstellt.
• Rechte über Gruppenverschachtelung. Wer nur auf die direkte Berechtigung schaut, übersieht ESC4 und ESC7 über verschachtelte Gruppen.
• Einmal geprüft ist nicht dauerhaft sicher. Jede neue Vorlage, jede neue Anwendung kann einen Pfad öffnen. Die Prüfung gehört in den regelmäßigen Betrieb.

Bezug zu BSI, NIS2 und CIS

Im BSI IT-Grundschutz betrifft das vor allem den Baustein APP.2.2 Active Directory sowie CON.1 Kryptokonzept mit den Anforderungen an Zertifikatsverwaltung. NIS2 (Art. 21 Abs. 2 lit. h, Kryptografie und Verschlüsselung, und lit. i, Zugriffskontrolle) verlangt nachvollziehbare Maßnahmen – eine dokumentierte, regelmäßige ADCS-Prüfung ist ein solcher Nachweis. In den CIS Controls passt das Thema zu Control 4 (sichere Konfiguration) und Control 6 (Zugriffskontrolle).

Fazit

Die meisten ESC-Pfade entstehen nicht durch Angriffe, sondern durch Bequemlichkeit: eine Vorlage, die „schnell mal“ den SAN erlaubt, ein Gruppenrecht, das nie zurückgenommen wurde. Wer CA-Flags, Vorlagen und Berechtigungen einmal sauber aufnimmt und die Prüfung danach regelmäßig wiederholt, nimmt Angreifern einen der bequemsten Wege zur Domänenübernahme.

Quellen: SpecterOps: Certified Pre-Owned · SpecterOps: ESC16 · Microsoft KB5014754 · TROOPERS26: ESC17 · Certipy