ADCS Angriffspfade verständlich erklärt

ADCS Angriffspfade: Was ist ein echter Pfad?

Wenn Sie nach einer praxisnahen Erklärung für ADCS Angriffspfade suchen, müssen Sie bei der Kette beginnen und nicht beim Label. Ein AD-CS-Angriffspfad ist nicht nur ein schwaches Zertifikatstemplate. Es ist die Kombination aus Ausstellungsregeln, Enrollment-Rechten, Kontrolle über Template- oder CA-Konfiguration, erreichbaren Enrollment-Endpunkten und zertifikatbasierter Authentifizierung, durch die eine niedrig privilegierte Identität zu einer höher privilegierten werden oder denselben Pfad später wieder öffnen kann.

Deshalb darf eine AD-CS-Prüfung nicht bei einem einzelnen Screenshot aus Certificate Templates enden. Fünf Fragen müssen zusammen beantwortet werden:

Welche Enterprise CAs existieren in der Gesamtstruktur?
Welche Templates sind veröffentlicht und für Authentifizierung nutzbar?
Wer kann enroll, auto-enroll oder diese Templates ändern?
Welche CA-weiten Einstellungen erweitern Missbrauch von Subject oder SAN?
Welche Enrollment-Endpunkte und Authentifizierungspfade machen diese Zertifikate in der Produktion tatsächlich nutzbar?

In der SpecterOps-Forschung Certified Pre-Owned bezeichnen die ESC-Labels wiederkehrende Missbrauchsmuster. In einer realen Prüfung sind es Angriffspfade, weil sie PKI-Konfiguration direkt mit Identitätseskalation verbinden.

Warum ADCS Angriffspfade in Active Directory weiter relevant sind

Microsoft beschreibt AD CS als Windows-Server-Rolle für PKI-Zertifikate, die für Authentifizierung, Verschlüsselung, Smartcard-Anmeldung, TLS, VPN und weitere Sicherheitsabläufe genutzt werden. Dieselbe Rolle wird zu einer hochwirksamen Identitätsoberfläche, wenn Zertifikatausstellung und zertifikatbasierte Authentifizierung nicht mehr durch Least Privilege begrenzt sind.

AD-CS-Pfade bleiben relevant, weil sie nicht alle wie klassischer Admin-Missbrauch aussehen. Manche Pfade erlauben einem Angreifer, ein Zertifikat anzufordern, das als andere Identität authentifiziert. Manche erlauben zuerst die Änderung der Kontroll-Ebene und erst danach das Herstellen gefährlicher Template-Bedingungen. Andere beruhen auf Relay gegen Enrollment-Endpunkte statt auf direkter Template-Manipulation. Und wieder andere sind Teil größerer Eskalationsketten mit AD-Angriffspfaden oder ACL-Missbrauch und DCSync, statt allein zu wirken.

Ein zweiter Grund sind operative Blindstellen. Sicherheitsteams überwachen Passwort-Resets, Gruppenänderungen und Kerberos-Delegation oft genauer als Zertifikatausstellung. Wenn CA-Auditing, Sichtbarkeit auf Template-Änderungen oder Baselines für Zertifikatauthentifizierung schwach sind, kann ein verwundbarer PKI-Pfad lange aktiv bleiben, obwohl andere Eskalationswege bereits geprüft wurden.

Minimales Evidence Pack

Evidence	Warum sie wichtig ist
Enterprise-CA-Inventar	Bestätigt, welche CAs und Rollendienste tatsächlich in der Gesamtstruktur existieren
Veröffentlichtе Templates	Ein nicht veröffentlichtes Template kann von dieser CA nicht angefordert werden
Enrollment- und Auto-Enrollment-Rechte	Zeigt, ob niedrig privilegierte Identitäten Zertifikate erhalten können
Template-ACLs	Bestimmt, wer das Template manipulieren kann
Subject- und SAN-Kontrollen	Identifiziert, ob Antragsteller gefährliche Identitätswerte selbst liefern können
CA-Edit-Flags	Zeigt globale Einstellungen wie `EDITF_ATTRIBUTESUBJECTALTNAME2`
Status von Web Enrollment, HTTPS und EPA	Bestimmt, ob relaybare Endpunkte weiter offen sind
Ausstellungs- und Zertifikatauthentifizierungs-Telemetrie	Belegt, ob Monitoring Anfragen, Ausstellung und Zertifikatauthentifizierung wirklich sieht

Template-Missbrauchspfade: ESC1 und veröffentlichte Authentifizierungs-Templates

ESC1 ist das klarste Beispiel für einen Template-Missbrauchspfad. Microsoft Defender for Identity beschreibt die gefährliche Bedingung so: Wenn ein Zertifikatstemplate Supply in the request aktiviert hat und das Zertifikat außerdem für Authentifizierung gültig ist, könnten Angreifer ein Zertifikat anfordern, das für beliebige Benutzer gültig ist.

Praktisch entsteht ein ESC1-Pfad meist aus diesen Bedingungen:

das Template ist auf einer CA veröffentlicht
niedrig privilegierte Identitäten können darin enrollen
das Template erlaubt antragstellergesteuerte Subject- oder SAN-Werte
das Zertifikat ist für Authentifizierung nutzbar, zum Beispiel mit einem EKU für Client Authentication
kein stärkerer Mechanismus wie Manager Approval oder Required Authorized Signatures verhindert die Ausstellung

Entscheidend ist nicht nur das Flag. Ein Template kann riskantes Naming-Verhalten haben und trotzdem kein aktiver Pfad sein, wenn es nicht veröffentlicht ist oder nur für eng kontrollierte Enrollment-Gruppen gilt. Umgekehrt ist ein veröffentlichtes Authentifizierungs-Template mit schwachem Scope und schwachen Ausstellungsregeln bereits ein Identitätspfad und nicht bloß ein Hygieneproblem.

Deshalb sollte die Prüfung von veröffentlichten Authentifizierungs-Templates sprechen und nicht nur abstrakt von „verwundbaren Templates“. Die Veröffentlichung bestimmt die Ausnutzbarkeit.

Kontroll-Ebenen-Pfade: ESC4 und ESC6

ESC4 und ESC6 sind Pfade auf der Kontroll-Ebene. Sie sind gefährlich, weil sie es einem Angreifer erlauben, ausnutzbares Ausstellungsverhalten zu erzeugen oder auszuweiten, selbst wenn das Template nicht von Anfang an offensichtlich unsicher war.

Bei ESC4 liegt das Problem in der ACL des Template-Objekts. Zertifikatstemplates sind Active-Directory-Objekte, und ihre ACLs steuern nicht nur Enrollment, sondern auch, wer das Objekt verändern darf. Microsoft Defender for Identity weist ausdrücklich auf das Risiko hin, wenn unprivilegierte Gruppen Rechte wie Full Control oder WriteDACL erhalten und dadurch Template-Einstellungen ändern können. Der Angreifer braucht das Template also nicht bereits als ESC1; er kann es in diesen Zustand bringen.

Bei ESC6 verlagert sich das Problem vom Template zur CA. Wenn auf der CA das Flag EDITF_ATTRIBUTESUBJECTALTNAME2 aktiv ist, können Benutzer laut Microsoft Defender for Identity SAN-Werte in Zertifikatanfragen angeben, und dies wirkt sich auf Templates aus, unabhängig davon, ob diese individuell Supply in the request aktiviert haben. Das bedeutet nicht, dass jedes Template automatisch ein direkter Domain-Admin-Knopf wird. Es bedeutet, dass die CA die Subject-Kontrollfläche verbreitert hat und dadurch jedes veröffentlichte, authentifizierungsrelevante Template mit falschem Scope deutlich gefährlicher wird.

Diese beiden Pfade gehören in dieselbe Prüfung wie Berechtigungsmissbrauch und Replikationsrechte, weil es im Kern Governance-Probleme auf der PKI-Kontroll-Ebene sind.

Relay-Pfade: ESC8 und Enrollment-Endpunkte

ESC8 unterscheidet sich von Template-Missbrauch. Der Pfad hängt von relaybaren Enrollment-Endpunkten ab und nicht nur von Template-Flags.

Microsoft dokumentiert AD CS Web Enrollment und Certificate Enrollment Web Services als HTTP-basierte Enrollment-Oberflächen. Microsoft Support KB5005413 erklärt, warum das wichtig ist: Wenn Angreifer NTLM-Authentifizierung an verwundbare AD-CS-Enrollment-Endpunkte relayen können, können sie Zertifikate erhalten, die anschließend für weitere Kompromittierung genutzt werden. Die ESC8-Bewertung in Microsoft Defender for Identity fasst die Bedingung noch enger, indem sie IIS-Endpunkte hervorhebt, die NTLM ohne erzwungenes HTTPS oder ohne Extended Protection for Authentication (EPA) akzeptieren.

Damit ist ESC8 ebenso ein Endpunkt- und Protokollproblem wie ein PKI-Problem. Die Prüfung sollte deshalb einschließen:

ob CA Web Enrollment oder verwandte Enrollment-Webdienste installiert sind
ob sie weiterhin über HTTP erreichbar sind
ob EPA tatsächlich erzwungen wird
ob NTLM dort noch akzeptiert wird, wo Microsoft dessen Abschaltung oder Begrenzung empfiehlt

Dieser Pfad gehört auch neben allgemeine Relay-Härtung wie NTLM-Relay-Angriffe und deaktivierte SMB-Signierung, weil der Zertifikatsendpunkt oft nur ein Schritt in der Kette ist.

Wo weak certificate mapping einzuordnen ist

Weak certificate mapping ist wichtig, aber nicht dasselbe Problem wie ESC1, ESC4, ESC6 oder ESC8.

Der Kern der oben genannten AD-CS-Pfade betrifft wie ein Zertifikat ausgestellt wird oder wie der Ausstellungspfad wieder geöffnet wird. KB5014754 behandelt eine andere Ebene: wie Domänencontroller zertifikatbasierte Authentifizierung zu Konten abbilden und wie sie zu stärkerer Bindung übergehen. Deshalb sollte weak mapping als benachbarte Kontrolle behandelt und auf den eigenen Beitrag Weak Certificate Mapping in AD CS: Why Strong Binding Matters verwiesen werden, statt es hier so einzubauen, als ob es schon durch die vier ADCS-Vuln-Tags des Artikels abgedeckt wäre.

In der Praxis muss eine gute AD-CS-Prüfung zwei Fragen trennen:

kann ein Angreifer ein gefährliches Zertifikat erhalten?
wenn ein gefährliches Zertifikat existiert, wie binden Domänencontroller es an ein Konto?

Beides hängt zusammen, aber es ist nicht derselbe Angriffspfad.

Erkennung

Die Erkennung muss Ausstellung, Änderungen an der Kontroll-Ebene und Authentifizierungstelemetrie korrelieren. Kein einzelnes Ereignis beweist AD-CS-Missbrauch.

Telemetrie für CA-Ausstellung und CA-Konfiguration

Microsofts Guidance zu Advanced Audit Policy und PKI-Monitoring stellt CA-Auditing in den Mittelpunkt. Mindestens sollte das Sicherheitsteam wissen, ob die CA Antrags- und Ausstellungstelemetrie wie die folgenden Events erzeugt:

4886 für Zertifikatanforderungen
4887 für Zertifikatausstellung
4882 für Änderungen an Certificate-Services-Sicherheitsberechtigungen
4890, 4891 oder 4892 für Verwaltungs- und Konfigurationsänderungen in Certificate Services

Diese Events sind nützlich, weil sie zeigen, dass eine Anforderung, eine Ausstellung oder eine Konfigurationsänderung stattgefunden hat. Sie beweisen aber nicht allein, dass die Anforderung bösartig war. Dafür müssen Antragsteller, Template, beabsichtigtes Subject und erwarteter Geschäftsablauf korreliert werden.

Telemetrie für Änderungen an Active-Directory-Objekten

Templates sind AD-Objekte, daher ist 5136 relevant, wenn Auditing konfiguriert ist und die passenden SACLs existieren. Microsoft dokumentiert 5136 als Event für Änderungen an Active-Directory-Objekten. In einer AD-CS-Prüfung ist es wichtig für Template-ACL-Änderungen, Änderungen des Veröffentlichungsstatus und andere Objektmodifikationen, die ein normales Template in einen Angriffspfad verwandeln.

Authentifizierungstelemetrie

Auf dem Domänencontroller erfasst 4768 TGT-Anforderungen. Das macht das Event nützlich, um Zertifikatausstellung mit späteren Authentifizierungsmustern zu korrelieren, insbesondere für Konten oder Maschinen, die normalerweise keine Zertifikatauthentifizierung verwenden. Aber 4768 ist kein AD-CS-Detektor. Es ist eine Korrelationsquelle unter mehreren und wird viel wertvoller, wenn es mit CA-Ausstellungsereignissen und einer Baseline für erwartetes Zertifikatauthentifizierungsverhalten kombiniert wird.

Konfigurations- und Expositionsbeweise

Nicht jede sinnvolle Erkennung ist eventgesteuert. Einige der wichtigsten AD-CS-Feststellungen sind Zustandsbefunde:

ein veröffentlichtes Authentifizierungs-Template ist weiterhin von niedrig privilegierten Benutzern enrollbar
eine Template-ACL gewährt weiterhin gefährliche Schreibrechte
EDITF_ATTRIBUTESUBJECTALTNAME2 ist weiterhin aktiv
ein Enrollment-Endpunkt akzeptiert weiterhin relaybare NTLM-Bedingungen über HTTP oder ohne EPA

Das ist einer der Gründe, warum AD-Sicherheitsüberwachung und wichtige Event IDs mit einer wiederholbaren Konfigurationsprüfung kombiniert werden sollten, statt als alleinige Antwort zu gelten.

Prioritäten bei der Remediation

Die richtige Reihenfolge ist: zuerst aktive Ausstellungspfade brechen, dann die Kontroll-Ebene härten, dann Endpunktlücken schließen und schließlich die Mapping-Posture separat validieren.

1. Aktive Ausstellungspfade brechen

Beginnen Sie damit, die Templates zu depublizieren oder einzuschränken, die aktuell den Pfad erzeugen. Microsoft Defender for Identity empfiehlt ausdrücklich, ein gefährliches Template aus der Veröffentlichung zu nehmen, wenn es nicht anforderbar sein sollte. Wenn ein Template verfügbar bleiben muss, reduzieren Sie zuerst den Enrollment-Scope, bevor Sie kosmetische Bereinigung betreiben.

Entfernen oder begrenzen Sie anschließend antragstellergesteuertes Subject- und SAN-Verhalten überall dort, wo es nicht strikt erforderlich ist. Müssen Templates spezielle Workflows weiter unterstützen, sollten stärkere Ausstellungssteuerungen wie Approval oder Authorized Signatures eingesetzt werden, anstatt breites Enrollment mit niedrigen Privilegien zu belassen.

2. Missbrauchsbedingungen auf der Kontroll-Ebene entfernen

Für ESC4 müssen Template-ACLs so gehärtet werden, dass unprivilegierte Gruppen weder Berechtigungen noch Template-Einstellungen verändern können. Für ESC6 sollte EDITF_ATTRIBUTESUBJECTALTNAME2 entfernt werden, sofern keine begründete und geprüfte betriebliche Abhängigkeit besteht.

Prüfen Sie außerdem, wer CA-Einstellungen verwalten, Templates veröffentlichen oder PKI-Administration delegieren darf. Eine Template-Korrektur ist nicht dauerhaft, wenn ein anderer Operator oder eine delegierte Gruppe den gefährlichen Zustand später unbemerkt wiederherstellen kann.

3. Relaybare Enrollment-Oberflächen schließen

Für ESC8 sollten die Microsoft-Mitigations aus KB5005413 umgesetzt werden:

ungenutzte Enrollment-Webrollen deaktivieren, wo möglich
HTTPS erzwingen
EPA aktivieren
NTLM-Exposition auf IIS-Enrollment-Endpunkten reduzieren oder deaktivieren, wo Microsoft dies empfiehlt

Wenn Web Enrollment betrieblich nicht erforderlich ist, ist das Entfernen oft die bessere Risikoreduktion als der Versuch, die Funktion mit Teilkontrollen dauerhaft zu erhalten.

4. Weak certificate mapping als benachbarte Härtung behandeln

Verwechseln Sie Template-Härtung nicht mit Mapping-Härtung. Wenn die Umgebung noch auf schwachen Zertifikatabbildungen beruht, sollte KB5014754 als eigener Remediation-Stream verfolgt und explizit auf DC-Seite validiert werden.

Validierung nach der Remediation

AD-CS-Remediation ist erst dann abgeschlossen, wenn nachweisbar ist, dass der Angriffspfad aus derselben Perspektive gebrochen wurde, aus der auch die Sicherheitsprüfung erfolgte.

Die Validierung sollte enthalten:

Nachweis, dass verwundbare Templates nicht mehr veröffentlicht sind oder nicht mehr durch niedrig privilegierte Identitäten enrollt werden können
Nachweis, dass gefährliche ACL-Einträge entfernt wurden
Nachweis, dass die CA EDITF_ATTRIBUTESUBJECTALTNAME2 nicht mehr exponiert
Nachweis, dass Enrollment-Endpunkte nicht mehr über HTTP oder ohne EPA offen sind, wenn der Pfad davon abhing
Nachweis, dass CA-Auditing nun Zertifikatanforderungen und -ausstellungen erfasst
Nachweis, dass AD-seitiges Monitoring Template-Objektänderungen dort sieht, wo es relevant ist
Nachweis, dass zuvor über riskante Pfade ausgestellte Zertifikate geprüft und bei Bedarf widerrufen wurden

Hier wird ein breiterer Workflow wie Active Directory-Sicherheit auditieren wichtig. AD-CS-Validierung dreht sich nicht um ein einzelnes Flag, sondern darum, nachzuweisen, dass Ausstellungspfad, Kontroll-Ebene und Monitoring-Pfad in der Produktion wirklich verändert wurden.

Wie EtcSec ADCS-Angriffspfade abbildet

EtcSec sollte hier bewusst eng bleiben: Das Produkt misst die Bedingungen, die den Pfad erzeugen.

Für die Kernpfade bedeutet das die Abbildung von Findings wie:

ESC1_VULNERABLE_TEMPLATE
ESC4_VULNERABLE_TEMPLATE_ACL
ESC6_EDITF_FLAG
ESC8_HTTP_ENROLLMENT

Dieselbe Prüfung kann außerdem benachbarte Findings sichtbar machen, die erklären, warum der Pfad existiert oder wie er sich weiter verketten lässt:

ADCS_WEAK_PERMISSIONS
PATH_CERTIFICATE_ESC

Der wichtige Punkt ist nicht, magische Angriffserkennung zu versprechen. Der Wert liegt darin, Template-Scope, Template-ACLs, CA-Flags und die Exposition von Enrollment-Endpunkten wiederholt zu messen, damit PKI-Drift sichtbar wird, bevor daraus erneut eine Eskalationskette entsteht.

ADCS Angriffspfade: wie Zertifikat-Fehlkonfigurationen zu Eskalationspfaden in Active Directory werden