AD CS absichern: Angriffe von ESC1 bis ESC16 und starke Zuordnung

Eine Zertifizierungsstelle in Active Directory ist ein mächtiges Werkzeug, auch für Angreifer. Im Juni 2021 zeigten Will Schroeder und Lee Christensen von SpecterOps im Bericht „Certified Pre-Owned“, wie falsch eingestellte Active Directory Certificate Services (AD CS) einen normalen Benutzer in Minuten zum Domänen-Administrator machen. Sie nannten die Schwachstellen ESC1 bis ESC8; inzwischen zählt die Fachwelt bis ESC16. Dieser Artikel erklärt die wichtigsten Muster, Microsofts starke Zertifikatszuordnung (KB5014754) und eine Liste, mit der man die eigene PKI absichert.

Warum Zertifikate in AD so wertvoll sind

Ein Zertifikat mit dem Zweck Client-Authentifizierung ist in Active Directory ein Ausweis: Mit ihm kann man sich per Kerberos (PKINIT) oder Schannel anmelden, ohne Passwort. Wer ein Zertifikat auf den Namen eines Administrators bekommt, ist dieser Administrator, und zwar so lange, bis das Zertifikat abläuft oder gesperrt wird. Passwortwechsel helfen nicht. Deshalb gehört eine Unternehmens-CA zur höchsten Schutzstufe, genau wie ein Domänencontroller. Wie Vorlagen und automatische Registrierung funktionieren, erklärt Windows-Autoenrollment einfach erklärt.

Die klassischen Angriffe ESC1 bis ESC8

ESC1: Eine Vorlage erlaubt Client-Authentifizierung, normale Benutzer dürfen registrieren, und der Antragsteller darf den Namen selbst angeben. Der Angreifer beantragt ein Zertifikat mit dem Namen des Domänen-Administrators im Feld Subject Alternative Name.
ESC2: Eine Vorlage erlaubt jeden Zweck (Any Purpose) oder gar keinen festen Zweck.
ESC3: Eine Vorlage für Registrierungsagenten ist für normale Benutzer offen. Damit darf man Zertifikate im Namen anderer beantragen.
ESC4: Falsche Rechte auf einer Vorlage. Wer sie ändern darf, macht sie zu ESC1.
ESC5: Falsche Rechte auf anderen PKI-Objekten, etwa dem CA-Server oder Containern in AD.
ESC6: Die CA hat das Flag EDITF_ATTRIBUTESUBJECTALTNAME2 gesetzt und übernimmt damit Namen aus jedem Antrag.
ESC7: Falsche Rechte auf der CA selbst, etwa „Zertifizierungsstelle verwalten“ für normale Benutzer.
ESC8: NTLM-Relay auf die Web-Registrierung der CA. Ein Angreifer zwingt einen Domänencontroller zur Anmeldung bei sich und leitet sie an die Weboberfläche der CA weiter, die bekannte Kette hinter dem Angriff PetitPotam.

Vier rote Kästen: Eine Vorlage erlaubt freie Namen, der Angreifer beantragt ein Zertifikat für den Domänen-Administrator, die CA stellt es aus, und er meldet sich per PKINIT als Administrator an. — Der klassische Angriff ESC1 in vier Schritten.

Neuere Varianten bis ESC16

Seit 2022 kamen weitere Muster hinzu, vor allem rund um die Zuordnung von Zertifikaten zu Konten:

ESC9 und ESC10: Vorlagen ohne Sicherheitserweiterung oder Domänencontroller mit schwacher Zuordnung. Wer den Anmeldenamen (UPN) eines Kontos ändern darf, bekommt ein Zertifikat, das auf ein anderes Konto passt.
ESC11: NTLM-Relay auf die RPC-Schnittstelle der CA, wenn diese keine verschlüsselten Anträge verlangt.
ESC13 und ESC14: Ausstellungsrichtlinien, die mit Gruppen verknüpft sind, und schwache explizite Zuordnungen im Attribut altSecurityIdentities.
ESC15 (EKUwu, CVE-2024-49019): Bei Vorlagen der Schema-Version 1 konnte ein Antragsteller zusätzliche Anwendungsrichtlinien in den Antrag schreiben. Microsoft hat das am 12. November 2024 gepatcht.
ESC16: Die CA lässt die Sicherheitserweiterung mit der Konto-SID für alle Zertifikate weg; das öffnet dieselbe Tür wie ESC9, nur für die ganze CA.

KB5014754: die starke Zertifikatszuordnung

Microsoft reagierte im Mai 2022 mit dem Update KB5014754. Seitdem schreibt eine Unternehmens-CA die SID des Kontos in eine eigene Erweiterung jedes Zertifikats (OID 1.3.6.1.4.1.311.25.2). Domänencontroller prüfen bei der Anmeldung, ob die SID zum Konto passt. Der Zeitplan:

Mai 2022: Kompatibilitätsmodus, schwache Zuordnungen erzeugen nur Warnungen im Ereignisprotokoll.
11. Februar 2025: Domänencontroller wechseln standardmäßig in den vollen Erzwingungsmodus.
9. September 2025: Mit dem Sicherheitsupdate entfällt die Möglichkeit, per Registry in den Kompatibilitätsmodus zurückzukehren.

Als stark gelten die SID-Erweiterung, eine URI mit der SID im Feld Subject Alternative Name und explizite Zuordnungen über Aussteller und Seriennummer, den Schlüsselbezeichner (SKI) oder den SHA-1-Hash des öffentlichen Schlüssels. Schwach sind Zuordnungen nur über Aussteller und Subject, nur über Subject oder über die E-Mail-Adresse. Zertifikate von Fremd-CAs oder aus Geräteverwaltungen brauchen deshalb oft eine Anpassung.

Drei Schritte: Mai 2022 Update KB5014754 mit SID-Erweiterung, 11. Februar 2025 volle Erzwingung als Standard, 9. September 2025 Ende des Kompatibilitätsmodus. — Der Zeitplan der starken Zertifikatszuordnung.

So prüfen und härten Sie Ihre PKI

Für die Bestandsaufnahme gibt es freie Werkzeuge: Locksmith und PSPKIAudit (PowerShell) sowie Certipy und Certify, die auch Angreifer nutzen. Ein Prüflauf mit Certipy aus Sicht eines normalen Benutzers sieht so aus (Domäne und Konto als Beispiel):

certipy find -u pruefer@firma.local -p 'Passwort' -dc-ip 10.0.0.10 -vulnerable -stdout

Die wichtigsten Gegenmaßnahmen:

Namen aus AD: Bei Vorlagen mit Client-Authentifizierung den Namen nie vom Antragsteller übernehmen. Wo es nicht anders geht, Freigabe durch einen Zertifikatsverwalter verlangen.
Rechte knapp halten: Registrieren nur für die Gruppen, die das Zertifikat brauchen; Schreibrechte auf Vorlagen und CA nur für Tier-0-Administratoren.
Ungenutzte Vorlagen von der CA zurückziehen, vor allem alte Vorlagen der Version 1.
Web-Registrierung abschalten oder nur per TLS verschlüsselte Verbindung. Erkennbar am Schloss-Symbol im Browser.">HTTPS mit Extended Protection betreiben; NTLM wo möglich deaktivieren.
Flags prüfen: EDITF_ATTRIBUTESUBJECTALTNAME2 aus, Sicherheitserweiterung an, verschlüsselte RPC-Anträge erzwingen.
Updates einspielen und starke Zuordnung erzwingen.
Protokollieren: Die Überwachung der Zertifikatsdienste aktivieren. Ereignis 4886 meldet einen Antrag, 4887 eine Ausstellung; ungewöhnliche Namen in Anträgen sind ein Alarmzeichen.

Auch der Schlüssel der CA selbst gehört geschützt, am besten in einem HSM; siehe HSM und TPM.

Zwei Spalten: starke Zuordnungen über SID-Erweiterung, SID im SAN, Aussteller und Seriennummer oder Schlüsselkennung; schwache über Subject, E-Mail-Adresse oder nur den UPN. — Welche Zuordnungen Domänencontroller seit 2025 akzeptieren.

Häufige Fragen

Bin ich betroffen, wenn ich nur die Standardvorlagen nutze? Die eingebauten Vorlagen sind meist unkritisch, aber Rechte und CA-Einstellungen können trotzdem falsch sein. Eine Prüfung mit Locksmith oder PSPKIAudit zeigt das in wenigen Minuten.

Hilft es, ein kompromittiertes Konto zurückzusetzen? Nicht gegen ein gestohlenes Zertifikat. Das Zertifikat muss gesperrt werden; siehe Zertifikatssperrung.

Funktionieren alte Zertifikate nach der Erzwingung noch? Nur, wenn sie die SID-Erweiterung tragen oder stark zugeordnet sind. Ältere Zertifikate ohne Erweiterung müssen neu ausgestellt werden.

Ist AD CS damit veraltet? Nein, aber es braucht Pflege wie jede Tier-0-Komponente. Viele Firmen ergänzen es um Geräteverwaltung und Cloud-PKI.

Fazit

AD CS-Angriffe nutzen fast immer Konfigurationsfehler: frei wählbare Namen, zu weite Rechte, gefährliche Flags und NTLM-Relay. Mit Namen aus Active Directory, knappen Rechten, abgeschalteter Web-Registrierung, aktueller Zuordnung nach KB5014754 und regelmäßigen Prüfläufen ist die eigene PKI gut geschützt. Mehr in der Übersicht Verschlüsselung und IT-Sicherheit.