AD Certificate Services (AD CS) — ESC1 bis ESC15 & Zertifikats-Missbrauch

ESC-Angriffskatalog — die 15 Schwachstellenklassen von AD CS

Die ESC-Klassifikation (Escalation) wurde von Will Schroeder und Lee Christensen (SpecterOps) eingeführt und seitdem von der Security-Community erweitert. Jede ESC-Klasse beschreibt eine spezifische Fehlkonfiguration in AD CS, die zur Privilege Escalation führt. Die gefährlichsten: ESC1 — Ein Zertifikatstemplate erlaubt dem Antragsteller, den Subject Alternative Name (SAN) frei zu wählen. Ein normaler Benutzer fordert ein Zertifikat an und trägt als SAN [email protected] ein — das resultierende Zertifikat authentifiziert ihn als Domain Admin. Voraussetzungen: Template erlaubt „Enrollee Supplies Subject“, der Benutzer hat Enrollment-Rechte, und Extended Key Usage (EKU) enthält Client Authentication oder Smart Card Logon.

ESC2 — Wie ESC1, aber das Template hat die EKU „Any Purpose“ oder gar keine EKU (SubCA-Zertifikate). ESC3 — Ein Template mit „Certificate Request Agent“ EKU erlaubt es, Zertifikate im Namen anderer Benutzer anzufordern. ESC4 — Schwache ACLs auf dem Template-Objekt im AD: Ein Benutzer mit WriteDacl oder WriteProperty auf dem Template kann die Konfiguration ändern und ESC1-Bedingungen selbst herstellen. ESC5 — Schwache ACLs auf dem CA-Server-Objekt selbst (z. B. ManageCA-Berechtigung für nicht-privilegierte Benutzer). ESC6 — Die CA hat das Flag EDITF_ATTRIBUTESUBJECTALTNAME2 gesetzt — jeder Antragsteller kann den SAN über Request-Attribute ändern, unabhängig von der Template-Konfiguration.

• ESC7 — ManageCA + ManageCertificates: Wenn ein Benutzer ManageCA-Berechtigung auf der CA hat, kann er sich selbst die ManageCertificates-Berechtigung geben. Damit kann er: Ausstehende Zertifikatsanforderungen genehmigen („Officer Approval“ umgehen), das EDITF_ATTRIBUTESUBJECTALTNAME2-Flag aktivieren (ESC6 herstellen), und fehlgeschlagene Anforderungen erneut ausstellen. Kombination: ManageCA → ManageCertificates → ESC6 aktivieren → beliebiges Zertifikat mit beliebigem SAN anfordern.
• ESC8 — NTLM Relay zu AD CS Web Enrollment: Wenn die CA einen HTTP-basierten Enrollment-Endpoint hat (Certificate Enrollment Web Service — CES, oder Web Enrollment — certsrv), und dieser NTLM-Authentifizierung akzeptiert, kann ein Angreifer eine NTLM-Relay-Attacke durchführen: PetitPotam/PrinterBug gegen einen Domain Controller → NTLM-Hash des DC-Computerkontos → Relay zu http://ca/certsrv/ → Zertifikat für den DC anfordern → als DC authentifizieren → DCSync. Dies war 2021–2023 der meistgenutzte AD-CS-Angriffsvektor in Ransomware-Kampagnen.
• ESC9–ESC11 (neuere Entdeckungen): ESC9 (CT_FLAG_NO_SECURITY_EXTENSION): Template setzt msPKI-Enrollment-Flag mit dem „No Security Extension“-Flag — die SID des Antragstellers wird nicht im Zertifikat gespeichert, StrongCertificateBindingEnforcement wird umgangen. ESC10: Schwache Zertifikatszuordnung (Certificate Mapping) — wenn der DC das Zertifikat nur über den UPN (nicht die SID) dem Konto zuordnet, kann ein Angreifer mit ESC9-Zertifikat sich als beliebiger Benutzer authentifizieren. ESC11: NTLM-Relay zum RPC-Enrollment-Interface (MS-ICPR/MS-WCCE) — ähnlich wie ESC8, aber über RPC statt HTTP. Erfordert, dass die CA IF_ENFORCEENCRYPTICERTREQUEST nicht gesetzt hat.
• ESC13–ESC15 (2024-Entdeckungen): ESC13: Templates mit issuance policy OID, die über eine OID-Gruppe einer AD-Gruppe zugeordnet sind — ein Angreifer kann durch Zertifikatsanforderung Gruppenmitgliedschaften erlangen. ESC14: Schwache Berechtigungen auf den AD-Objekten, die für Certificate Mapping verwendet werden (z. B. altSecurityIdentities-Attribut). Ein Angreifer, der dieses Attribut auf einem privilegierten Konto ändern kann, ordnet sein eigenes Zertifikat diesem Konto zu. ESC15 („EKUwu“): Templates mit Application Policy (Schema Version 1) anstelle von EKU — die Application Policy wird beim Enrollment nicht vom CA validiert, der Antragsteller kann beliebige EKUs einsetzen.

Golden Certificates & Persistenz — das Zertifikats-Äquivalent zum Golden Ticket

Wenn ein Angreifer den privaten Schlüssel der Certificate Authority stiehlt, kann er beliebige Zertifikate fälschen — für jeden Benutzer, jedes Computerkonto, jeden Dienst. Dies ist ein Golden Certificate: äquivalent zum Golden Ticket, aber mit entscheidenden Vorteilen für den Angreifer: Zertifikate haben typischerweise eine Gültigkeit von 1–5 Jahren (vs. 10 Stunden für ein TGT), ein KRBTGT-Passwort-Reset invalidiert keine Zertifikate, und Zertifikate erscheinen in keinen Kerberos-Logs — die Authentifizierung über PKINIT hinterlässt andere Spuren als Standard-Kerberos. Tool: ForgeCert (SpecterOps) fälscht Zertifikate mit dem gestohlenen CA-Schlüssel.

• CA-Schlüssel stehlen — die Techniken: Der CA-Privatschlüssel wird typischerweise im Windows Certificate Store gespeichert, geschützt durch DPAPI und (hoffentlich) ein HSM (Hardware Security Module). Ohne HSM: SharpDPAPI kann den DPAPI-Masterkey des CA-Servers extrahieren und den privaten Schlüssel entschlüsseln. Mimikatz (crypto::capi oder crypto::cng) exportiert den Schlüssel direkt. Certipy hat einen integrierten ca-Befehl zum Backup des CA-Schlüssels (erfordert Admin auf dem CA-Server). Verteidigung: HSM ist Pflicht — der Schlüssel verlässt das HSM nie in Softwareform.
• DVWA — Domain Escalation via Vulnerable ACLs: Selbst ohne direkte ESC-Schwachstellen können ACL-Ketten (Delegation Chains) zur CA führen: Ein Benutzer hat GenericAll auf einen Gruppenobjekt → die Gruppe hat Enrollment-Rechte auf einem verwundbaren Template → ESC1. Tools: BloodHound (v4.3+ hat AD-CS-Support — zeigt ESC-Pfade in der Graph-Datenbank) und Certipy find (enumeriert alle Templates und identifiziert ESC1–ESC15 automatisch). Empfehlung: Regelmäßig Certipy-Audits durchführen und BloodHound-Pfade zur CA analysieren.
• Shadow Credentials via AD CS: Kombination aus AD-CS-Angriff und Key Trust: Ein Angreifer mit Schreibrechten auf das msDS-KeyCredentialLink-Attribut eines Benutzers oder Computers kann einen eigenen Public Key hinterlegen. Anschließend kann er sich über PKINIT (Kerberos mit Zertifikat) als dieses Konto authentifizieren — ohne das Passwort zu kennen oder zu ändern. Tool: Whisker (setzt den Key), Rubeus (führt PKINIT durch und erhält ein TGT). Erkennung: Überwachung von Änderungen am msDS-KeyCredentialLink-Attribut (Event 5136 — Directory Service Changes).
• PKINIT & Certificate-based Authentication: PKINIT ist die Kerberos-Erweiterung für zertifikatsbasierte Authentifizierung (RFC 4556). Der Client präsentiert sein Zertifikat während der AS-REQ-Phase (statt Passwort). Der KDC validiert das Zertifikat und stellt ein TGT aus. UnPAC-the-Hash: Nach erfolgreicher PKINIT-Authentifizierung enthält das TGT den PAC (Privilege Attribute Certificate) mit dem NTLM-Hash des Benutzers — der Angreifer hat damit auch den Hash für Pass-the-Hash-Angriffe. Tool: Certipy auth führt PKINIT durch und extrahiert den NTLM-Hash.

AD CS Härtung & Monitoring — die Verteidigung

Die Härtung von AD CS erfordert einen systematischen Ansatz, da die meisten Schwachstellen aus Default-Konfigurationen und historischen Template-Einstellungen resultieren. Schritt 1: Vollständiger Audit aller Zertifikatstemplates mit Certipy (certipy find -u user@domain -p pass -dc-ip DC_IP -vulnerable) oder PSPKIAudit (PowerShell-Modul). Schritt 2: Enrollee Supplies Subject auf allen Templates deaktivieren, es sei denn, es ist absolut notwendig (z. B. für Webserver-Zertifikate — dann mit CA Certificate Manager Approval kombinieren). Schritt 3: Enrollment-Berechtigungen auf das Minimum reduzieren — „Authenticated Users“ sollte NIEMALS Enrollment-Rechte haben. Schritt 4: HTTP-basierte Enrollment-Endpoints absichern oder deaktivieren (→ ESC8-Prävention).

• Template-Härtungs-Checkliste: 1) Enrollee Supplies Subject = Disabled (außer mit CA Manager Approval). 2) EKU explizit setzen — nie „Any Purpose“ oder leere EKU. 3) Enrollment nur für benötigte Gruppen — keine „Domain Users“ oder „Authenticated Users“. 4) Manager Approval für sensitive Templates aktivieren. 5) Authorized Signatures Required ≥ 1 für Enrollment Agents. 6) Validity Period minimieren (1 Jahr statt 5). 7) CT_FLAG_NO_SECURITY_EXTENSION nicht setzen (→ ESC9). 8) Ungenutztes Templates deaktivieren (nicht löschen — löschen verhindert Audit-Trail).
• CA-Server absichern: 1) CA-Server als Tier 0 behandeln — gleiche Sicherheitsstufe wie Domain Controller. 2) HSM für den CA-Privatschlüssel verwenden (Thales Luna, Entrust nShield, Azure Managed HSM). 3) EDITF_ATTRIBUTESUBJECTALTNAME2 deaktivieren (certutil -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2). 4) HTTP Enrollment deaktivieren oder auf HTTPS mit Extended Protection for Authentication (EPA) umstellen. 5) IF_ENFORCEENCRYPTICERTREQUEST aktivieren (→ ESC11-Prävention). 6) ManageCA-Berechtigung auf CA-Admins beschränken.
• StrongCertificateBindingEnforcement: Microsoft hat mit KB5014754 (Mai 2022) die Zertifikatszuordnung verschärft: Zertifikate müssen über die SID (nicht nur UPN) dem AD-Konto zugeordnet werden. Registry: HKLM\SYSTEM\CurrentControlSet\Services\Kdc\StrongCertificateBindingEnforcement: 0 = Disabled (unsicher), 1 = Compatibility Mode (Default — warnt, blockiert nicht), 2 = Full Enforcement (sicher — empfohlen). Microsoft hat den Enforcement-Termin mehrfach verschoben — 2026 ist Full Enforcement noch immer nicht Default. Empfehlung: Sofort auf 2 setzen und Zertifikate ohne SID-Mapping erneuern.
• Monitoring — AD-CS-Angriffe erkennen: Kritische Event-IDs: 4886 (Certificate Services received a certificate request), 4887 (Certificate Services approved/issued a certificate), 4899 (Certificate template updated). Sigma-Regeln: win_security_ad_cs_certificate_request_with_san.yml — Erkennung von Zertifikatsanforderungen mit SAN (ESC1-Indikator). Certipy-Erkennung: Anomale Zertifikatsanforderungen von Benutzern, die normalerweise keine Zertifikate anfordern. PKINIT-Monitoring: Event 4768 (TGT issued) mit Pre-Authentication Type 16 (PKINIT) — wenn Benutzer plötzlich PKINIT verwenden, die es vorher nicht taten.