Active Directory Certificate Services (AD CS): Angriffe jenseits der Klassiker (ESC9 bis ESC16)

Die meisten Übersichten zu Active Directory Certificate Services (AD CS) hören bei ESC8 auf. Das ist verständlich, denn ESC1 bis ESC8 stammen aus dem ursprünglichen „Certified Pre-Owned"-Paper von SpecterOps und decken die offensichtlichsten Fehlkonfigurationen ab: ausnutzbare Subject Alternative Names, gefährliche Enrollment-EKUs, schwache Template-ACLs, die EDITF-CA-Einstellung und den NTLM-Relay auf die Web-Enrollment-Schnittstelle. In realen internen Pentests entscheiden über Domain Admin aber oft die Techniken, die erst danach beschrieben wurden und genau deshalb in vielen Härtungs-Checklisten fehlen.

Exotisch sind diese Lücken nicht. Mehrere von ihnen sind direkte Nebenwirkungen der Microsoft-Härtung gegen Zertifikats-Spoofing aus dem Mai-2022-Update (KB5014754). Dieses Update führte die SID-Sicherheitserweiterung in Zertifikaten ein, um die schwache Zuordnung von Zertifikat zu Konto zu beenden. Wo die zugehörigen Schalter halb gesetzt oder bewusst zurückgedreht wurden, entsteht stattdessen eine neue Angriffsfläche. Statt acht Techniken stur durchzunummerieren, folgt dieser Artikel ihrem gemeinsamen Mechanismus, weil sich daraus auch die Verteidigung am schnellsten ableiten lässt.

Schwache Zertifikatszuordnung: ESC9, ESC10 und ESC16

Alles dreht sich hier um eine einzige Frage: Wie verknüpft ein Domain Controller ein vorgelegtes Zertifikat mit einem Konto? Seit KB5014754 trägt ein Zertifikat dafür die Erweiterung szOID_NTDS_CA_SECURITY_EXT (OID 1.3.6.1.4.1.311.25.2), die die SID des Kontos festschreibt. Wie streng der DC diese Bindung prüft, hängt am Schalter StrongCertificateBindingEnforcement: 0 schaltet die Prüfung ab, 1 ist der Kompatibilitätsmodus, und erst 2 erzwingt sie vollständig. Die folgenden drei Techniken leben alle davon, dass diese Bindung an irgendeiner Stelle bröckelt.

Bei ESC9 (No Security Extension) geschieht das auf Template-Ebene. Trägt ein Template das Flag CT_FLAG_NO_SECURITY_EXTENSION (0x80000 im msPKI-Enrollment-Flag), fehlt die SID-Erweiterung in jedem daraus ausgestellten Zertifikat. Wer Enrollment-Recht auf ein solches Template hat und zusätzlich das userPrincipalName-Attribut eines Opfers beschreiben darf, ändert die UPN auf die eines privilegierten Kontos, fordert das Zertifikat an und meldet sich als dieses Konto an, solange die DCs nicht im Modus 2 laufen. Hier hilft nur beides zusammen: das Flag aus dem Template nehmen und die strenge Bindung erzwingen.

ESC10 (Weak Certificate Mappings) erreicht dasselbe Ziel ganz ohne Template-Flag, indem es direkt an der DC-Konfiguration ansetzt. Mal steht StrongCertificateBindingEnforcement schlicht auf 0, sodass eine fehlende oder unpassende SID-Erweiterung niemanden stört. Mal enthält der Registry-Wert CertificateMappingMethods unter dem Schannel-Schlüssel das Bit 0x4, das die schwache, rein UPN-basierte Zuordnung wieder einschaltet. Beide Wege münden in denselben Trick mit der manipulierten userPrincipalName, und beide schließt man, indem man die Bindung auf 2 zieht und das 0x4-Bit entfernt.

Während ESC9 ein einzelnes Template betrifft, hebelt ESC16 den Schutz gleich für die ganze CA aus. Steht der OID 1.3.6.1.4.1.311.25.2 in der DisableExtensionList des Policy-Moduls, verlässt kein Zertifikat mehr die CA mit der SID-Erweiterung, egal aus welchem Template. Damit reicht plötzlich jedes beliebige Template mit Client-Authentication-EKU als Eskalationspfad, sobald die schwache Bindung greift. Der Eintrag muss aus der Liste verschwinden, und auch hier ist StrongCertificateBindingEnforcement = 2 die zweite Hälfte der Antwort.

Relay und Host-Kompromittierung: ESC11 und ESC12

ESC11 ist die RPC-Schwester von ESC8. Der NTLM-Relay läuft nicht über die HTTP-Web-Enrollment-Seite, sondern über die ICertPassage-RPC-Schnittstelle (ICPR). Den Türöffner liefert ein fehlendes IF_ENFORCEENCRYPTICERTREQUEST-Flag auf der CA, denn dann nimmt sie unverschlüsselte RPC-Anfragen an. Ein Angreifer zwingt ein Maschinenkonto zur Authentifizierung, relayt diese auf den RPC-Endpunkt und lässt sich in dessen Namen ein Zertifikat ausstellen. Wer die erzwungene Verschlüsselung aktiviert und Extended Protection for Authentication einschaltet, nimmt dem Angriff die Grundlage.

ESC12 fällt etwas aus der Reihe, weil es kein klassischer Konfigurationsfehler ist, sondern den Zugriff auf den privaten CA-Schlüssel über einen bereits kompromittierten CA-Host beschreibt. Liegt der Schlüssel auf einem YubiHSM, landet dessen Authentifizierungsschlüssel in der Registry. Wer mit ausreichenden Rechten eine Shell auf dem CA-Server hat, liest ihn aus, greift damit auf den CA-Schlüssel zu und stellt beliebige „goldene" Zertifikate aus. Praktisch ist das die Fortsetzung von ESC5 und vor allem eine Erinnerung daran, dass ein CA-Server denselben Schutz verdient wie ein Domain Controller: so wenige Administratoren wie möglich, konsequente Tier-0-Isolation und ein Auge auf jedem Backup.

Privilegien aus Zertifikatsmetadaten: ESC13 und ESC14

ESC13 dreht eine völlig legitime AD-Funktion gegen ihren Besitzer. Eine Ausstellungsrichtlinie (Issuance Policy) lässt sich über das Attribut msDS-OIDToGroupLink an eine AD-Sicherheitsgruppe koppeln. Trägt ein Template eine solche Policy, bekommt jeder, der sich mit dem daraus ausgestellten Zertifikat anmeldet, bei der Authentifizierung die Rechte der verknüpften Gruppe zugeschrieben, ohne je Mitglied gewesen zu sein. Zeigt der Link auf eine privilegierte Gruppe, genügt das bloße Enrollment-Recht auf dem Template für die Eskalation. Beim Audit lohnt sich deshalb der gezielte Blick auf alle msDS-OIDToGroupLink-Verknüpfungen und darauf, wer auf den betroffenen Templates überhaupt ausstellen darf.

ESC14 nutzt das Attribut altSecurityIdentities, das ein Zertifikat explizit einem Konto zuordnet, etwa über Aussteller und Seriennummer. Darf ein Angreifer dieses Attribut bei einem Opfer beschreiben, hinterlegt er dort eine Zuordnung zu einem Zertifikat, das er selbst in der Hand hat, und authentifiziert sich anschließend als das Opfer. Je schwächer das Mapping-Format, desto leichter die Fälschung: Eine Zuordnung allein über das Subject ist deutlich angreifbarer als eine starke über Issuer und Seriennummer oder den Key Identifier. Schreibrechte auf altSecurityIdentities gehören entsprechend eng gefasst, und nur starke Mapping-Typen sollten überhaupt akzeptiert werden.

EKUwu: ESC15 und CVE-2024-49019

ESC15 ist die jüngste der hier behandelten Techniken und besser bekannt unter dem Namen EKUwu, offiziell geführt als CVE-2024-49019. Sie betrifft Zertifikats-Templates der Schema-Version 1, die eine unangenehme Eigenschaft haben: Sie prüfen die im Certificate Signing Request mitgelieferten Application Policies nicht. Weil Application Policies bei der Authentifizierung Vorrang vor den im Template hinterlegten EKUs genießen, kann ein Angreifer mit Enrollment-Recht einfach eine beliebige Policy in den Request schreiben, etwa Client Authentication oder Certificate Request Agent, und dem Zertifikat damit einen Verwendungszweck aufzwingen, den das Template nie vorgesehen hat. Erlaubt das Template obendrein die freie Angabe des Subjects, ist die Identitätsübernahme nur noch ein Schritt.

Bei der Einordnung sind zwei Details wichtig. Standardmäßig sind alle v1-Templates anfällig, der Angreifer braucht aber ein Enrollment-Recht, und sobald jemand ein v1-Template klont, hebt Windows es automatisch auf Version 2 an, womit die Lücke verschwindet. Microsoft hat das Problem mit den Updates vom 12. November 2024 grundsätzlich behoben. Wer auf Nummer sicher gehen will, spielt diesen Patch ein, ersetzt verbliebene v1-Templates durch v2-Äquivalente und überprüft, wer auf den alten Vorlagen ausstellen darf.

Erkennung und Härtung in der Praxis

So unterschiedlich die acht Techniken im Detail sind, ihr gemeinsamer Nenner ist überschaubar: eine zu schwache Bindung zwischen Zertifikat und Konto und zu großzügig verteilte Enrollment- und Schreibrechte. Drei Stellschrauben nehmen einem Großteil der Angriffe die Luft. StrongCertificateBindingEnforcement gehört auf 2, sobald alle Zertifikate die SID-Erweiterung tragen. Das schwache 0x4-Bit in CertificateMappingMethods sollte verschwinden. Und sowohl das RPC- als auch das HTTP-Enrollment lassen sich durch erzwungene Verschlüsselung und EPA absichern.

Sichtbar werden die konkreten Fehlkonfigurationen mit denselben Werkzeugen, die auch Angreifer einsetzen. Certipy findet auf der offensiven Seite, was sich ausnutzen lässt; auf der Verteidigerseite leisten PSPKIAudit oder Locksmith dasselbe. Sie zeigen, welche Templates das CT_FLAG_NO_SECURITY_EXTENSION-Flag tragen, welche msDS-OIDToGroupLink-Verknüpfungen existieren, welche Vorlagen noch auf Schema-Version 1 stehen und wo die CA-Flags gefährliche Werte haben. Wichtig ist, dieses Audit nicht als Einmalaktion abzuhaken, denn jedes neue Template und jede frisch delegierte Berechtigung kann die Lage wieder verschieben.

Fazit

ESC9 bis ESC16 machen deutlich, dass AD CS auch jenseits der bekannten ESC1–ESC8-Klassiker eine ergiebige Angriffsfläche bleibt, gerade weil ein Teil dieser Techniken aus einer nur halb umgesetzten Härtung erwächst. Wer seine Zertifikatsinfrastruktur ernst nimmt, schaut deshalb nicht nur auf die Template-ACLs, sondern ebenso auf die Bindungs-Schalter der DCs, die CA-Flags, die OID-Gruppen-Links und die übrig gebliebenen v1-Templates. Im Rahmen eines internen Penetrationstests nehmen wir bei turingpoint die gesamte AD-CS-Kette samt dieser neueren Techniken unter die Lupe und liefern eine nach Risiko priorisierte Härtungsempfehlung, die offensive Befunde mit konkreten Defender-Maßnahmen verbindet.