ESC1 bis ESC15 erklärt – mit Erkennung und Gegenmaßnahmen

Kurzfassung vorab: Die ESC-Reihe beschreibt die typischen Fehlkonfigurationen, mit denen sich eine ADCS-Umgebung in einen Generalschlüssel für das gesamte Active Directory verwandelt. Wer ESC1 und ESC8 nicht abgestellt hat, hat keine PKI, sondern eine offene Hintertür mit Zertifikatssiegel. Die gute Nachricht: Fast alle Pfade lassen sich mit Bordmitteln und einem halben Tag Arbeit pro Issuing CA schließen — wenn man weiß, wonach man sucht. Genau das liefert dieser Artikel: Erkennung, Bewertung und konkrete Gegenmaßnahme für jede einzelne ESC.

Abb. 1: ADCS als Pfad zur Domänenübernahme — vom niedrig privilegierten Konto zur Domain-Admin-Identität über eine verwundbare Issuing CA.

1. Warum ADCS-Fehlkonfigurationen so gefährlich sind

Kurz vorweg, damit klar ist, worüber wir hier reden: Die Issuing CA ist kein gewöhnlicher Server. Sie stellt Zertifikate aus, mit denen sich Maschinen und Nutzer gegenüber dem Domain Controller authentifizieren — über PKINIT (Kerberos) oder Schannel (TLS). Wer die CA dazu bringt, ihm ein Zertifikat für „Administrator" auszustellen, der meldet sich anschließend als Administrator an. Kein Passwort-Cracking, kein Mimikatz, keine Kerberoasting-Geduldsprobe. Ein Zertifikat, eine Anmeldung, fertig.

Die Forscher von SpecterOps haben dieses Feld 2021 im Whitepaper „Certified Pre-Owned" systematisiert und acht Eskalationspfade durchnummeriert: ESC1 bis ESC8. Seitdem ist die Reihe gewachsen — ESC9 bis ESC15 kamen über die Jahre dazu, ESC15 ist sogar eine echte CVE (CVE-2024-49019). Die Nummerierung ist keine Rangfolge der Gefährlichkeit, sondern schlicht die Reihenfolge der Entdeckung. Für die Praxis sortiere ich anders: nach der Frage, wie leicht sich der Pfad ohne Vorbedingungen ausnutzen lässt.

Und genau hier liegt der Punkt, den viele Admins unterschätzen: Die meisten ESCs setzen kein hohes Privileg voraus. ESC1 funktioniert mit einem stinknormalen Domänennutzer. Das ist kein theoretisches Risiko für irgendeinen verschachtelten Sonderfall, sondern der Standardbefund in fast jedem Audit, das ich begleite.

Warnung · Der Klassiker im Erstaudit Ich habe noch keine gewachsene ADCS-Umgebung gesehen, die im ersten Scan komplett sauber war. Die Default-Templates sind harmlos, aber sobald jemand „mal eben" eine Web-Server-Vorlage geklont und das Häkchen bei „Subject im Request angeben" gesetzt hat, steht ESC1 offen. Wer eine Audit-Phase ohne ESC-Check abschließt, hat keinen Audit gemacht, sondern eine Beruhigungstablette geschluckt.

2. ESC1 — der Königsweg über die Zertifikatsvorlage

ESC1 ist der Pfad, den du zuerst verstehen musst, weil die meisten anderen Varianten darauf aufbauen. Die Bedingungen klingen technisch, sind aber im Alltag erschreckend oft erfüllt: Eine Zertifikatsvorlage erlaubt Client-Authentifizierung als Verwendungszweck (EKU), lässt den Antragsteller den Subject Alternative Name (SAN) selbst angeben, und ein niedrig privilegierter Nutzer hat Enrollment-Recht darauf. Wenn alle drei zusammenkommen, ist die Domäne offen.

Der Angriff selbst ist trivial. Der Angreifer fordert ein Zertifikat aus der verwundbaren Vorlage an — und trägt als SAN nicht seinen eigenen Namen ein, sondern „Administrator@deinedomain.local". Die CA prüft nicht, ob das stimmt, weil die Vorlage das Subject explizit dem Request überlässt. Das Zertifikat kommt zurück, lautet auf den Domain Admin, und der DC akzeptiert es bei der PKINIT-Anmeldung anstandslos.

Abb. 2: ESC1 im Ablauf — SAN-Spoofing in fünf Schritten bis zur Domain-Admin-Anmeldung.

Die drei Zutaten im Klartext, damit du beim Prüfen genau weißt, worauf du schaust:

Bedingung	Was konkret gesetzt ist	Wo du es findest
EKU erlaubt Auth	Client Authentication, Smart Card Logon, PKINIT oder „Any Purpose"	Vorlage → Reiter „Erweiterungen" → Anwendungsrichtlinien
SAN aus Request	Flag CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT gesetzt	Vorlage → Reiter „Antragstellername" → „In der Anforderung angeben"
Enrollment für viele	Authenticated Users / Domain Users haben Enroll	Vorlage → Reiter „Sicherheit" → Berechtigung „Registrieren"

 

So findest du ESC1 in deiner Umgebung. Das Werkzeug der Wahl ist Certify (Windows) oder Certipy (Linux). Beide kennen die Schwachstellenmuster und markieren verwundbare Vorlagen direkt:

PowerShell

# — ESC1-Erkennung mit Certify (vom Angreifer-Standpunkt) — # Listet alle Vorlagen und markiert verwundbare automatisch Certify.exe find /vulnerable   # — Gegenprobe mit Bordmitteln: Welche Vorlagen erlauben SAN im Request? — # Flag-Wert 1 in msPKI-Certificate-Name-Flag = ENROLLEE_SUPPLIES_SUBJECT Get-ADObject -SearchBase ("CN=Certificate Templates,CN=Public Key Services," + "CN=Services," + (Get-ADRootDSE).configurationNamingContext) ` -LDAPFilter "(objectClass=pKICertificateTemplate)" ` -Properties msPKI-Certificate-Name-Flag, pKIExtendedKeyUsage | Where-Object { $_."msPKI-Certificate-Name-Flag" -band 1 } | Select-Object Name, pKIExtendedKeyUsage | Format-Table -AutoSize

 

Die Gegenmaßnahme ist unspektakulär und genau deshalb so wirksam: Entferne das Häkchen „Subject im Request angeben" überall dort, wo es nicht zwingend gebraucht wird. Für die ganz wenigen Vorlagen, die es wirklich brauchen (manche Web-Server- oder SCEP-Szenarien), setzt du stattdessen die Manager-Genehmigung („CA Certificate Manager Approval"), damit kein Request ohne menschliche Freigabe durchläuft.

Praxis-Tipp · Reihenfolge beim Aufräumen Fang nicht bei der ältesten Vorlage an, sondern bei der mit den meisten Enroll-Berechtigten. Eine ESC1-Vorlage, auf die nur drei Server-Admins zugreifen dürfen, ist ein anderes Risiko als eine, auf die „Domain Users" Enroll hat. Sortiere nach Angriffsfläche, nicht nach Alphabet — dann hast du das echte Risiko in der ersten Stunde erschlagen.

3. ESC2 bis ESC4 — Varianten desselben Themas

ESC2, ESC3 und ESC4 sind enge Verwandte von ESC1. Sie nutzen denselben Mechanismus — verwundbare Vorlagen — nur über etwas andere Hebel. Wer ESC1 verstanden hat, hat diese drei in zehn Minuten mit dazu.

ESC2 — der Any-Purpose-Joker

Bei ESC2 ist der Verwendungszweck der Vorlage entweder „Any Purpose" (EKU 2.5.29.37.0) oder ganz leer. Ein Zertifikat ohne EKU-Einschränkung lässt sich für alles verwenden — auch für Client-Authentifizierung. Damit wird ESC2 faktisch zu ESC1, sobald zusätzlich SAN aus dem Request erlaubt ist. Die Gegenmaßnahme: Jede Vorlage bekommt einen konkreten, minimalen EKU. „Any Purpose" gehört auf keine ausstellende Vorlage, Punkt.

ESC3 — Missbrauch des Enrollment Agents

ESC3 dreht sich um die EKU „Certificate Request Agent". Wer ein Zertifikat mit diesem Zweck bekommt, darf im Namen anderer Nutzer Zertifikate beantragen — das ist das Enrollment-Agent-Prinzip, das eigentlich für Smartcard-Ausgabestellen gedacht ist. Ist die Agent-Vorlage zu großzügig vergeben und gibt es zusätzlich eine Zielvorlage, die Enrollment-Agent-Requests akzeptiert, kann der Angreifer sich erst zum Agent machen und dann im Namen des Domain Admins ein Auth-Zertifikat ziehen.

ESC4 — Schreibrecht auf die Vorlage selbst

ESC4 ist subtiler und damit gefährlicher: Hier ist nicht die Konfiguration der Vorlage das Problem, sondern wer sie ändern darf. Hat ein niedrig privilegierter Nutzer Schreibrecht (Write, WriteDacl, WriteOwner) auf das Vorlagenobjekt im AD, dann macht er sich die Vorlage mit zwei Klicks selbst zu einer ESC1-Vorlage, nutzt sie aus und dreht die Änderung wieder zurück. Im Audit-Log bleibt — wenn überhaupt — eine kurze Konfigurationsänderung übrig, die niemand mit einer Kompromittierung verbindet.

ESC	Auslöser	Gegenmaßnahme in einem Satz
ESC2	Any-Purpose- oder leerer EKU	Konkreten, minimalen EKU pro Vorlage setzen
ESC3	Enrollment-Agent zu großzügig vergeben	Agent-Vorlagen stark einschränken, Zielvorlagen auf Agents prüfen
ESC4	Schreibrecht auf Vorlagenobjekt im AD	Template-ACLs härten, nur PKI-Admins dürfen schreiben

 

Für die ACL-Prüfung bei ESC4 brauchst du keinen Spezial-Scanner — der PSPKI-Modul-Befehl reicht, um auffällige Berechtigungen sichtbar zu machen:

PowerShell

# — ESC4-Erkennung: Schreibrechte auf Zertifikatsvorlagen prüfen — # Benötigt das PSPKI-Modul (Install-Module PSPKI) Import-Module PSPKI   Get-CertificateTemplate | ForEach-Object { $tpl = $_ $tpl | Get-CertificateTemplateAcl | Select-Object -ExpandProperty Access | Where-Object { $_.Rights -match "Write" -and $_.IdentityReference -notmatch "Domain Admins|Enterprise Admins|SYSTEM" } | Select-Object @{n="Template";e={$tpl.Name}}, IdentityReference, Rights } | Format-Table -AutoSize

4. ESC5 bis ESC8 — wenn die CA selbst das Problem ist

Die nächste Gruppe verlässt die Vorlagen-Ebene und greift die CA-Konfiguration und ihre Umgebung an. Hier sitzt mit ESC6 der Klassiker und mit ESC8 der mit Abstand häufigste „echte" Angriffspfad in modernen Umgebungen.

ESC5 — schwache ACLs auf CA-Objekten

ESC5 ist der Sammelbegriff für zu großzügige Berechtigungen auf den AD-Objekten rund um die PKI: das CA-Computerkonto, das CA-Objekt unter „Public Key Services", die NTAuthCertificates-Liste. Wer hier Schreibrecht hat, kann auf vielfältige Weise eskalieren — etwa indem er ein eigenes CA-Zertifikat in den NTAuth-Store schiebt. Selten, aber wenn vorhanden, brandgefährlich.

ESC6 — das EDITF-Flag, das alles aushebelt

ESC6 ist der Klassiker mit dem höchsten „Wie konnte das so lange unentdeckt bleiben"-Faktor. Ist auf der CA das Flag EDITF_ATTRIBUTESUBJECTALTNAME2 gesetzt, darf jeder Antragsteller bei jeder Vorlage einen beliebigen SAN mitschicken — auch bei Vorlagen, die das eigentlich gar nicht erlauben. Das Flag hebelt also die saubere Vorlagen-Konfiguration global aus. Eine einzige falsch gesetzte CA-Einstellung macht die ganze Mühe bei den Templates zunichte.

PowerShell
# — ESC6-Erkennung: Ist das gefährliche EDITF-Flag gesetzt? — # Auf dem CA-Server ausführen certutil -getreg policy\EditFlags   # In der Ausgabe nach EDITF_ATTRIBUTESUBJECTALTNAME2 suchen. # Taucht es auf, ist ESC6 aktiv. Entfernen mit: certutil -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2   # Danach den Zertifizierungsstellendienst neu starten: Restart-Service certsvc

 

ESC7 — schwache CA-Verwaltungsrechte

Bei ESC7 hat ein nicht vertrauenswürdiger Nutzer die CA-Rollen „ManageCA" oder „ManageCertificates". Mit ManageCA lässt sich unter anderem das ESC6-Flag selbst setzen — der Angreifer macht sich die Lücke also bei Bedarf selbst auf. ManageCertificates erlaubt das Freigeben zurückgehaltener Requests, was sich mit ESC1-Vorlagen kombinieren lässt, die auf Manager-Approval stehen.

ESC8 — NTLM-Relay auf das Webenrollment

ESC8 ist in der Praxis der wichtigste Pfad überhaupt, weil er auf eine Komponente zielt, die in vielen Umgebungen läuft, ohne dass jemand sie bewusst betreibt: das Web-Enrollment (certsrv) und der Certificate Enrollment Web Service. Akzeptieren diese HTTP-Endpunkte NTLM-Authentifizierung ohne HTTPS und ohne Extended Protection for Authentication, kann ein Angreifer eine Maschinen-Authentifizierung (etwa von einem Domain Controller, erzwungen per PetitPotam) auf die CA umleiten und sich in deren Namen ein Zertifikat ausstellen lassen. Ergebnis: ein Zertifikat für das DC-Konto, das anschließend zur vollständigen Übernahme reicht.

Warnung · ESC8 ist oft unsichtbar aktiv Das Web-Enrollment wird häufig „nur für den Notfall" installiert und dann vergessen. Es läuft, niemand nutzt es, niemand patcht es, niemand hat HTTPS erzwungen. Genau das ist der gefundene Fressen für ein Relay. Wenn du eine Sache aus diesem Artikel mitnimmst: Prüfe als Erstes, ob certsrv oder der CES-Endpunkt erreichbar ist — und ob er HTTP zulässt.

ESC	Wo es sitzt	Sofortmaßnahme
ESC5	ACLs auf CA-Objekten im AD	Schreibrechte auf PKI-Admins reduzieren
ESC6	EDITF-Flag auf der CA	Flag entfernen, certsvc neu starten
ESC7	CA-Rollen ManageCA / ManageCertificates	Rollen nur an vertrauenswürdige Konten
ESC8	Webenrollment ohne HTTPS / EPA	EPA erzwingen, HTTPS-Pflicht, ungenutzte Endpunkte abschalten

5. ESC9 bis ESC15 — die jüngere Garde

Die höheren Nummern sind weniger bekannt, aber nicht weniger relevant — besonders ESC15 als echte CVE solltest du auf dem Schirm haben. Hier die Kurzfassung jeder Variante, damit du im Scan-Ergebnis weißt, was dich erwartet.

Abb. 3: ESC1–ESC15 im Überblick — Schweregrad (Auswirkung bei Ausnutzung) gegen Audit-Häufigkeit aus der Beratungspraxis.

ESC9 und ESC10 drehen sich um das Zusammenspiel von Zertifikats-Mapping und dem StrongCertificateBindingEnforcement, das Microsoft nach den Mai-2022-Patches (KB5014754) eingeführt hat. Kurz gesagt: Wenn die starke Bindung zwischen Zertifikat und Konto nicht durchgesetzt wird und eine Vorlage das SID-Mapping nicht erzwingt, lassen sich Zertifikate auf falsche Konten mappen. ESC11 überträgt das Relay-Prinzip von ESC8 auf den RPC-Enrollment-Endpunkt (ICertPassage / IF_ENFORCEENCRYPTICERTREQUEST), wenn dort keine Paket-Verschlüsselung erzwungen wird.

ESC12 ist ein Sonderfall: Hat ein Angreifer Shell-Zugriff auf den CA-Server und ist der private Schlüssel auf einem YubiHSM gespeichert, dessen Auth-Key im Klartext in der Registry liegt, kann er den CA-Schlüssel exportieren. Selten, weil es bereits Shell-Zugriff voraussetzt — aber ein gutes Argument für ordentliches HSM-Key-Management. ESC13 nutzt Zertifikatsvorlagen mit einer Issuance Policy, die per OID-Gruppen-Link an eine AD-Gruppe gekoppelt ist: Das ausgestellte Zertifikat verleiht dann implizit die Gruppenmitgliedschaft.

ESC14 betrifft schwach konfigurierte explizite Zertifikats-Mappings über das Attribut altSecurityIdentities — wenn dort ein schwaches Mapping (etwa nur über den Subject-Namen) eingetragen ist, lässt sich ein passendes Zertifikat fälschen. Und ESC15 ist die einzige echte Sicherheitslücke im klassischen Sinn: CVE-2024-49019, auch „EKUwu" genannt. Sie betrifft alte Vorlagen der Schema-Version 1 und erlaubt es, über manipulierte Anwendungsrichtlinien einen beliebigen EKU in das ausgestellte Zertifikat zu schmuggeln — Microsoft hat sie im November 2024 gepatcht.

Info · Verweis auf die Migration ESC15 betrifft ausschließlich v1-Vorlagen. Wenn du noch Schema-Version-1-Templates im Bestand hast, ist das nicht nur ein ESC15-Thema, sondern generell ein Modernisierungsfall. Wie du Vorlagen sauber auf v2/v3/v4 hebst, zeigt der Spoke „Zertifikatsvorlagen v2 vs. v3 vs. v4 – wann was?". Den vollständigen ADCS-Kontext liefert die Pillar-Seite zum ADCS-Leitfaden.

6. Erkennung in der Praxis — vom Scan zum Maßnahmenplan

Einzelne ESCs zu kennen ist die eine Hälfte. Die andere ist ein wiederholbarer Prozess, mit dem du eine Umgebung systematisch abklopfst — und am Ende eine priorisierte Liste hast statt eines diffusen „da ist bestimmt was". So gehe ich in jedem ADCS-Health-Check vor:

Abb. 4: Erkennungs-Workflow — von der Inventur über Konfigurations- und Relay-Prüfung zum priorisierten Maßnahmenplan.

Inventur ziehen. Certify (find /vulnerable) oder Certipy (find -vulnerable -stdout) liefern in Minuten eine Liste aller Vorlagen, CAs und auffälligen Berechtigungen. Das ist dein Startpunkt — und gleichzeitig genau das, was ein Angreifer als Erstes tun würde.

CA-Konfiguration prüfen. Das EDITF-Flag (ESC6), die CA-Rollen (ESC7) und die ACLs auf den CA-Objekten (ESC5) prüfst du direkt auf dem Server mit certutil und PSPKI.

Relay-Pfade testen. Ist das Web-Enrollment (ESC8) erreichbar? Erzwingt der RPC-Endpunkt Verschlüsselung (ESC11)? Hier lohnt ein gezielter Test mit Certipy relay oder ntlmrelayx in einer kontrollierten Umgebung.

Maßnahmenplan mit Priorität. Jeder Befund bekommt einen Schweregrad, einen Verantwortlichen und einen Termin. ESC1 und ESC8 zuerst, dann der Rest. Dokumentiert, terminiert, nachprüfbar — sonst ist es kein Audit.

Praxis-Tipp · Die Werkzeuge gehören in deine Hand Certify, Certipy und PSPKIAudit sind die Tools, mit denen auch Angreifer arbeiten. Genau deshalb sollten sie in deiner Hand sein, bevor sie in fremder sind. Plane für die Erstanalyse einen halben bis ganzen Tag pro Issuing CA ein — das klingt viel, ist aber gegenüber dem Aufräumen nach einem Vorfall ein Schnäppchen.

7. Härtung — was du in welcher Reihenfolge abstellst

Wenn der Scan steht, kommt die Gretchenfrage: Womit anfangen? Nicht alphabetisch, nicht nach ESC-Nummer, sondern nach der Frage, welcher Pfad ohne Vorbedingungen sofort zur Domänenübernahme führt. Der folgende Entscheidungsbaum ist meine Standard-Reihenfolge im Redesign.

Abb. 5: Härtungs-Entscheidungsbaum — die Pfade ohne Vorbedingung (ESC8, ESC1) zuerst, dann ACLs und Monitoring.

Die wichtigsten Stellschrauben auf einen Blick, inklusive der konkreten Einstellung:

Maßnahme	Adressiert	Aufwand
Webenrollment abschalten oder EPA + HTTPS erzwingen	ESC8, ESC11	niedrig
„SAN im Request" überall entfernen, wo nicht nötig	ESC1, ESC2	niedrig
EDITF_ATTRIBUTESUBJECTALTNAME2 entfernen	ESC6	sehr niedrig
Template-ACLs und CA-Rollen härten	ESC4, ESC5, ESC7	mittel
StrongCertificateBindingEnforcement auf 2 (Full)	ESC9, ESC10, ESC14	mittel
v1-Vorlagen ausmustern, KB von Nov 2024 einspielen	ESC15	mittel
Manager-Approval für sensible Vorlagen	ESC1, ESC3	niedrig

 

Eine Maßnahme verdient besondere Erwähnung, weil sie gleich drei ESCs adressiert und trotzdem oft vergessen wird: das StrongCertificateBindingEnforcement. Nach den KB5014754-Patches kannst du erzwingen, dass Zertifikate fest an die SID des Kontos gebunden sein müssen. Auf den Vollmodus (Wert 2) solltest du, sobald deine Umgebung kompatibel ist:

PowerShell

# — StrongCertificateBindingEnforcement auf Vollmodus setzen — # Auf allen Domain Controllern ausführen (oder per GPO verteilen) # Wert 0 = deaktiviert, 1 = Kompatibilität (Standard), 2 = volle Durchsetzung   $path = "HKLM:\SYSTEM\CurrentControlSet\Services\Kdc" Set-ItemProperty -Path $path -Name "StrongCertificateBindingEnforcement" ` -Value 2 -Type DWord   # Vorsicht: Vorher prüfen, dass alle aktiven Zertifikate ein SID-Mapping # tragen. Sonst sperrst du dir legitime Anmeldungen aus. Get-WinEvent -LogName "System" -FilterXPath "*[System[EventID=39 or EventID=41]]" ` -MaxEvents 50 | Select-Object TimeCreated, Id, Message | Format-List

Warnung · Den Vollmodus nicht blind scharfschalten Wer StrongCertificateBindingEnforcement ohne Vorprüfung auf 2 stellt, riskiert, dass plötzlich legitime Smartcard- oder VPN-Anmeldungen scheitern, weil deren Zertifikate kein SID-Mapping tragen. Erst die Events 39 und 41 im System-Log auswerten (Kompatibilitätsmodus liefert sie), die Lücken schließen, dann durchsetzen. Reihenfolge ist hier wirklich kein Luxus, sondern Selbstschutz.

8. Praxis-Beispiel — die Trendforge Digital GmbH

Die Trendforge Digital GmbH, ein cloud-affines Tech-Scaleup mit rund 400 Mitarbeitern, kam mit einem klassischen Auftrag: „Vor der nächsten Finanzierungsrunde will der Investor ein Security-Assessment, und unsere PKI ist seit Jahren nicht angefasst worden." Die ADCS-Umgebung war einstufig gewachsen — eine einzelne Issuing CA, über die Jahre mit Vorlagen vollgestopft, die niemand mehr richtig kannte.

Der Certify-Scan brauchte keine zwei Minuten und meldete vier ESC1-Vorlagen, davon zwei mit Enroll-Recht für „Authenticated Users". Eine davon — ironischerweise eine geklonte Web-Server-Vorlage namens „TF-WebSSL-v2" — hatte SAN aus dem Request aktiviert und Client-Authentifizierung im EKU. Mit einem Standard-Entwicklerkonto ließ sich daraus in der Testumgebung ein Zertifikat für das Domain-Admin-Konto ziehen. Zusätzlich lief das Web-Enrollment auf der CA, erreichbar per HTTP, ohne EPA — ESC8 stand offen.

Die Maßnahme: An einem einzigen Vormittag haben wir das Web-Enrollment abgeschaltet (es wurde nachweislich nicht genutzt), bei allen vier Vorlagen das SAN-Flag entfernt und für die zwei wirklich benötigten Web-Server-Vorlagen Manager-Approval gesetzt. Das Ergebnis: Der nächste Scan war sauber, das Assessment ging glatt durch, und Trendforge hat als Folgeauftrag gleich die Migration auf eine saubere zweistufige Hierarchie beauftragt — diesmal mit dokumentierten Vorlagen und einem festen Review-Zyklus. Der gesamte ESC-Teil des Erstaudits: ein halber Tag.

Verwandte Themen

Pillar-Seite: Active Directory Certificate Services – der komplette Leitfaden

ADCS-Härtung nach BSI IT-Grundschutz — wie sich die ESC-Gegenmaßnahmen in ein anerkanntes Härtungsframework einordnen → /adcs-haertung-bsi/

TameMyCerts als Policy-Modul – wann sinnvoll, wann übertrieben — wie ein Policy-Modul SAN-Missbrauch (ESC1/ESC6) auf Ausstellungsebene technisch unterbindet → /adcs-tamemycerts/

Audit-Logging für ADCS – was protokolliert werden muss — damit Konfigurationsänderungen wie bei ESC4 nicht unbemerkt bleiben → /adcs-audit-logging/

Häufige Fragen (FAQ)

Was bedeutet ESC bei ADCS?

ESC steht für „Enterprise Security Configuration" und bezeichnet eine Reihe typischer Fehlkonfigurationen in Active Directory Certificate Services, die SpecterOps 2021 systematisiert hat. Jede ESC beschreibt einen konkreten Pfad, über den sich Angreifer Privilegien verschaffen — von ESC1 (SAN-Spoofing über Vorlagen) bis ESC15 (CVE-2024-49019). Die Nummerierung ist die Reihenfolge der Entdeckung, keine Rangfolge der Gefährlichkeit.

Welche ESC-Schwachstelle ist am gefährlichsten?

In der Praxis sind ESC1 und ESC8 die wichtigsten, weil sie ohne hohe Vorbedingungen auskommen und direkt zur Domänenübernahme führen. ESC1 funktioniert mit einem normalen Domänennutzer, ESC8 setzt nur ein erreichbares Web-Enrollment ohne HTTPS voraus. Wer diese beiden abgestellt hat, hat den Großteil des realen Risikos beseitigt.

Wie erkenne ich ESC-Schwachstellen in meiner Umgebung?

Mit den Werkzeugen Certify (Windows) oder Certipy (Linux), die verwundbare Vorlagen und CA-Konfigurationen automatisch markieren — ergänzt durch certutil und das PSPKI-Modul für die CA-seitigen Prüfungen. Plane einen halben bis ganzen Tag pro Issuing CA ein. Wichtig ist ein wiederholbarer Prozess von der Inventur über die Konfigurationsprüfung bis zum priorisierten Maßnahmenplan.

Reicht es, nur ESC1 abzustellen?

Nein. ESC1 ist der häufigste Befund, aber ESC6 hebelt saubere Vorlagen global aus, und ESC8 öffnet einen ganz anderen Angriffspfad über NTLM-Relay. Eine ESC-Härtung muss alle relevanten Varianten abdecken — andernfalls schließt du die Vordertür und lässt die Terrassentür offen.

Was ist EDITF_ATTRIBUTESUBJECTALTNAME2?

Das ist die CA-Einstellung hinter ESC6. Ist sie gesetzt, darf jeder Antragsteller bei jeder Vorlage einen beliebigen Subject Alternative Name mitschicken — auch bei Vorlagen, die das eigentlich nicht erlauben. Damit wird die saubere Vorlagen-Konfiguration global ausgehebelt. Prüfen lässt sich das mit „certutil -getreg policy\EditFlags", entfernen mit dem entsprechenden -setreg-Befehl und einem Neustart von certsvc.

Wie schütze ich mich vor ESC8 (NTLM-Relay)?

Schalte ungenutzte Web-Enrollment-Endpunkte ab — in vielen Umgebungen laufen sie ohnehin nur „für den Notfall". Wo das Web-Enrollment gebraucht wird, erzwingst du HTTPS und Extended Protection for Authentication (EPA) und deaktivierst NTLM zugunsten von Kerberos. Zusätzlich helfen die Maßnahmen gegen Authentifizierungs-Zwang wie PetitPotam, etwa aktuelle Patches und SMB-Signierung.

Nächste Schritte mit boddenberg.de

ESC-Befunde sind selten ein Einzelproblem — meist sind sie das Symptom einer Umgebung, die nie ein sauberes Härtungs-Review gesehen hat. Drei Wege, das anzugehen:

ADCS-Health-Check · Standortbestimmung deiner bestehenden PKI — Architektur, Härtung und Audit-Readiness. Genau hier läuft der vollständige ESC1–ESC15-Scan mit priorisiertem Maßnahmenplan.

Architektur- oder Redesign-Workshop · Vom Ist-Zustand zur Zielarchitektur — auf Wunsch fokussiert auf Härtung und das saubere Aufräumen gewachsener Vorlagenlandschaften.

Implementierungs- oder Migrationsbegleitung · Beratung und technische Unterstützung beim Umsetzen der Gegenmaßnahmen, von der Vorlagen-Bereinigung bis zur Bindungs-Durchsetzung auf den DCs.

 

Kontakt: Uli Boddenberg · boddenberg.de · Dortmund