ADCS Zertifikatangriffe: Wie ESC1 bis ESC8 die Domäne gefährden

Was sind ADCS Zertifikatangriffe?

ADCS Zertifikatangriffe missbrauchen Fehlkonfigurationen in Active Directory Certificate Services, um Zertifikate mit zu starker Aussagekraft auszustellen oder Enrollment-Wege zu kapern. Der eigentliche Wert eines Zertifikats liegt dabei nicht im Zertifikat selbst, sondern in der Identität, die sich damit gegenüber Kerberos, Schannel oder anderen Authentifizierungswegen ausweisen kann. Wenn ein wenig privilegierter Benutzer ein Zertifikat für ein fremdes oder zu starkes Ziel erhalten kann, wird aus einer PKI-Konfiguration schnell ein Tier-0-Problem.

SpecterOps hat diese Fehlkonfigurationsklassen unter den ESC-Bezeichnungen bekannt gemacht. In Enterprise-Umgebungen sind besonders ESC1, ESC4, ESC6 und ESC8 relevant, weil sie entweder über Templates, Template-ACLs, CA-Flags oder Web Enrollment direkte Missbrauchspfade schaffen.

ADCS Zertifikatangriffe: Welche Komponenten Sie verstehen müssen

Wie die wichtigsten ESC-Klassen praktisch funktionieren

ESC1: Missbrauch einer verwundbaren Vorlage

Eine Vorlage ist im Kern dann interessant, wenn sie drei Dinge verbindet:

• wenig privilegierte Enrollment-Rechte
• Möglichkeit, den Subject oder SAN selbst zu liefern
• EKUs, die Authentifizierung erlauben

Wenn diese Kombination vorliegt, kann ein Angreifer ein Zertifikat beantragen, das als fremde Identität nutzbar wird.

certipy find -u [email protected] -p 'Password123!' -dc-ip 10.10.0.1 -vulnerable -stdout
certipy req -u [email protected] -p 'Password123!' -ca CORP-CA -template VulnerableTemplate -upn [email protected]

ESC4: Missbrauch über Template-ACLs

Hier ist die Vorlage selbst zunächst nicht zwingend unsicher. Das Problem ist, dass ein Benutzer oder eine Gruppe die Vorlage verändern darf. Damit wird aus einer harmlosen Vorlage schnell eine ESC1-artige Vorlage.

ESC6: Missbrauch über CA-Flag EDITF_ATTRIBUTESUBJECTALTNAME2

Microsoft dokumentiert dieses Flag heute auch selbst als gefährliche Einstellung. Wenn es aktiv ist, kann die CA SAN-Angaben in Zertifikatsanforderungen breit akzeptieren. Zusammen mit authentifizierungsfähigen Templates kann das zur sofortigen Kompromittierung führen.

certutil -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2

Die Härtung besteht gerade darin, dieses Flag nicht aktiv zu lassen, wenn es keinen zwingenden und sauber abgesicherten Grund gibt.

ESC8: Relay gegen Web Enrollment

Wenn /certsrv oder vergleichbare Enrollment-Endpunkte NTLM über HTTP oder ohne ausreichenden Schutz akzeptieren, kann ein Angreifer Relay-Techniken mit ADCS verbinden. Genau deshalb sind HTTPS, EPA und saubere Endpoint-Härtung keine kosmetischen Details, sondern Teil der PKI-Sicherheit.

Was Sie zuerst prüfen sollten

Alle Templates mit Authentifizierungsbezug

Prüfen Sie Templates mit EKUs wie Client Authentication, Smart Card Logon oder verwandten Authentifizierungsnutzungen. Nicht jede Vorlage ist kritisch, aber jede authentifizierungsfähige Vorlage mit falschen Rechten oder zu freier SAN-Steuerung verdient hohe Priorität.

Template-ACLs und Enrollment-Rechte

Fragen Sie explizit:

• Wer darf das Template nutzen?
• Wer darf das Template verändern?
• Wer darf es veröffentlichen oder in der CA-Konfiguration wirksam machen?

CA-Flags und Enrollment-Endpunkte

Prüfen Sie, ob auf der CA problematische EditFlags aktiv sind und ob Web Enrollment noch auf historische Weise erreichbar ist.

Erkennung und Telemetrie

Relevante Events

• 4886 für Zertifikatsanforderungen
• 4887 für ausgestellte Zertifikate
• 4768 oder benachbarte Authentifizierungssignale, wenn Zertifikate anschließend für TGT-nahe Flows genutzt werden

Was in den Daten auffällt

• unerwartete Anforderer für starke Templates
• Zertifikate mit SAN- oder UPN-Werten, die nicht zur beantragenden Identität passen
• Änderungen an Templates kurz vor riskanten Zertifikatsanforderungen
• CA-Konfigurationsänderungen an EditFlags oder Web Enrollment

Remediation und Härtung

1. Entfernen Sie gefährliche SAN-Steuerung aus Templates

Templates für wenig privilegierte Benutzer sollten nicht frei erlauben, dass Antragsteller Identitäten im SAN definieren, wenn diese Zertifikate für Authentifizierung genutzt werden können.

2. Bereinigen Sie Template-ACLs

Wenn ein Benutzer eine Vorlage ändern kann, kontrolliert er indirekt später auch, was mit dieser Vorlage ausgestellt wird. Template-ACLs gehören deshalb in denselben Review wie Domain-ACLs oder GPO-Rechte.

3. Deaktivieren Sie gefährliche CA-Flags

Wo EDITF_ATTRIBUTESUBJECTALTNAME2 aktiv ist, muss das Team eine sehr belastbare Begründung liefern. In den meisten Umgebungen ist das Flag eher Altlast als legitime Notwendigkeit.

4. Härten Sie Web Enrollment

Erzwingen Sie HTTPS, aktivieren Sie Extended Protection for Authentication und prüfen Sie, ob der Web Enrollment-Endpunkt überhaupt noch benötigt wird. Nicht jede CA braucht diesen Weg in moderner Form.

Validierung nach dem Fix

• Templates erneut inventarisieren und auf Enrollment-Rechte, EKUs und SAN-Steuerung prüfen
• Template-ACLs mit dem alten Zustand vergleichen
• CA-Flags und Enrollment-Endpunkte erneut lesen
• Testanforderungen nur in kontrollierter Umgebung durchführen, um sicherzustellen, dass die gefährlichen Pfade wirklich verschwunden sind

Zusätzliche Priorisierung im Betrieb

Im Alltag sollten Sie ADCS nicht nur nach der Frage priorisieren, ob eine ESC-Klasse existiert, sondern auch danach, welche Vorlage oder welcher Endpunkt am nächsten an produktiven Administratorkonten oder breit nutzbaren Enrollment-Rechten liegt. Eine theoretisch verwundbare Vorlage mit engem Scope ist weniger dringlich als ein häufig genutztes Template mit Authentifizierungs-EKU, SAN-Steuerung und Domain-Users-Enroll-Rechten. Dieselbe Logik gilt für Web Enrollment: Entscheidend ist nicht nur, dass /certsrv existiert, sondern ob der Endpunkt mit NTLM, ohne ausreichenden Schutz und in der Praxis noch breit erreichbar ist.

Typische Fehlannahmen in Projekten

Viele Teams nehmen an, dass PKI nur ein Infrastrukturthema sei und nicht in denselben Tier-0-Review wie Gruppen, GPOs oder Replikationsrechte gehört. Genau das ist bei ADCS falsch. Sobald eine Vorlage oder ein Enrollment-Endpunkt Identitäten für Authentifizierung abbilden kann, ist das Thema identitätskritisch. Deshalb sollten Template-Änderungen, CA-Flags und Web-Enrollment-Härtung in denselben Change- und Ausnahmeprozess wie andere privilegierte Verzeichnisänderungen aufgenommen werden.

Zusätzlich lohnt sich eine einfache Prüffrage in jedem Review: Welche Vorlagen werden tatsächlich von vielen Systemen oder Benutzern genutzt, und welche davon erlauben irgendeine Form von Identitätssteuerung oder haben zu breite ACLs? Diese Sicht hilft, operative Priorität von theoretischer Verwundbarkeit zu trennen.

Welche Template-Eigenschaften gemeinsam bewertet werden sollten

Ein sauberer ADCS-Review liest eine Vorlage nicht nur auf eine einzelne ESC-Klasse hin. Entscheidend ist die Kombination aus Enrollment Rights, Issuance Requirements, Subject/SAN-Steuerung, EKUs und Template-ACLs. Eine Vorlage mit Client Authentication EKU und breiten Enrollment-Rechten ist nicht automatisch kritisch. Kritisch wird sie dann, wenn Antragsteller Identitäten selbst liefern können, ein Angreifer die Vorlage verändern darf oder eine CA-Einstellung wie EDITF_ATTRIBUTESUBJECTALTNAME2 die Schutzgrenze aufweicht. Genau deshalb sollten Template-Reviews immer als Matrix gelesen werden und nicht als isolierte Checkbox-Prüfung.

Warum Manager Approval allein kein Sicherheitsbeweis ist

Microsoft dokumentiert, dass sich auf Vorlagenebene CA certificate manager approval als Issuance Requirement erzwingen lässt. Diese Freigabe reduziert automatische Ausstellung, ersetzt aber keine Härtung der Vorlage selbst. Sie behebt weder zu breite Template-ACLs noch gefährliche EKU-Kombinationen noch unsaubere CA-Flags. In Projekten wird Manager Approval deshalb oft als Beruhigungssignal missverstanden: Die Vorlage gilt als „sicher“, obwohl sie technisch weiter in eine gefährliche Richtung konfiguriert ist und nur auf einen manuellen Freigabeschritt angewiesen bleibt. Für Tier-0-nahe Templates ist das zu wenig. Dort muss die Vorlage auch ohne freundliche Betriebsannahmen robust sein.

Welche Vorlagen zuerst in den Review gehören

Zuerst gehören Vorlagen mit Authentifizierungsbezug in den Review: Templates mit Client Authentication, Smart Card Logon oder vergleichbaren EKUs, veröffentlichte Vorlagen mit breiten Enrollment-Rechten und Vorlagen, die über Autoenrollment oder häufige Betriebsprozesse eine hohe Reichweite haben. Diese Kombination macht aus einer einzelnen Fehlkonfiguration ein strukturelles Problem. Ein selten genutztes Spezialtemplate mit engem Scope ist meist weniger dringend als ein breit ausgerolltes Template, das Tausende Benutzer oder Systeme ansprechen dürfen.

Web Enrollment und EPA praktisch validieren

Bei Web Enrollment reicht es nicht, nur auf „HTTPS aktiv“ zu prüfen. Entscheidend ist, ob die Anwendung Relay-resistent betrieben wird. Nach der Härtung sollten Teams daher validieren, dass /certsrv ausschließlich über TLS erreichbar ist, Extended Protection for Authentication auf den relevanten IIS-Endpunkten wirklich aktiv ist und keine Legacy-Automation mehr auf ungeschützten NTLM-Flows basiert. Gerade in älteren Umgebungen bleibt das Risiko bestehen, obwohl die CA selbst bereits bereinigt wurde, weil der Web-Enrollment-Pfad unverändert geblieben ist.

Review von Template-Lifecycle und Veröffentlichung

Neben den eigentlichen Template-Eigenschaften sollte jedes Team auch den Lifecycle prüfen: Welche Vorlagen sind noch veröffentlicht, obwohl sie kaum genutzt werden? Welche alten Templates wurden nie außer Betrieb genommen? Und welche Änderungen an EKUs, Enrollment Rights oder Issuance Requirements sind in den letzten Monaten erfolgt? Viele ADCS-Risiken entstehen nicht durch eine einmalige Fehlentscheidung, sondern durch Jahre unkontrollierter Änderungen an veröffentlichten Vorlagen.

Alte Enrollment-Pfade konsequent abbauen

Wenn Web Enrollment, CES oder andere historische Enrollment-Wege nicht mehr benötigt werden, sollten sie nicht nur „weniger sichtbar“, sondern wirklich entfernt oder isoliert werden. Ein veröffentlichter, aber kaum noch genutzter Endpoint bleibt Angriffsfläche. Deshalb gehört zu jeder ADCS-Härtung auch die Frage, welche Enrollment-Pfade betrieblich noch legitim sind und welche nur aus Kompatibilitätsgründen weiterlaufen. Genau diese Altpfade sind oft der Grund, warum Relay- oder Missbrauchsszenarien trotz sauberer Template-Reviews weiter bestehen.

Validierung veröffentlichter Vorlagen nach Änderungen

Nach jeder Template- oder CA-Änderung sollten Teams nicht nur die gewünschte Zielkonfiguration prüfen, sondern auch bestätigen, welche Vorlagen tatsächlich noch auf der Enterprise CA veröffentlicht sind. Gerade in gewachsenen Umgebungen bleibt ein altes Template häufig veröffentlicht, obwohl es fachlich bereits ersetzt wurde. Ein belastbarer Review fragt deshalb: Welche Vorlage ist in AD definiert, welche ist auf der CA veröffentlicht, welche darf autoenrollen und welche wird von produktiven Clients oder Diensten wirklich noch verwendet? Erst diese vier Perspektiven zusammen zeigen, ob eine gefährliche Kombination aus EKU, Enrollment-Recht und Freigabeweg wirklich beseitigt wurde.

Referenzen

• Microsoft Learn: certutil
• Microsoft Defender for Identity: vulnerable CA setting (ESC6)
• Microsoft Learn: certificate template issuance requirements
• SpecterOps Certified Pre-Owned whitepaper
• SpecterOps overview of ADCS ESC abuse paths

Verwandte Beiträge

• ACL-Missbrauch und DCSync: Wie stille Rechte Domain Admin öffnen
• AD-Angriffspfade: Wie Fehlkonfigurationen bis Domain Admin führen
• Golden Ticket Angriff: Die Schlüssel zu Ihrer Domain
• Kerberos-Delegationsangriffe: Unkontrolliert bis RBCD
• AD Sicherheitsüberwachung: Event IDs und SIEM
• AD Gruppenverschachtelung: Versteckte DA-Pfade

ADCS Zertifikatangriffe sollten nie nur als PKI-Thema betrachtet werden. Sobald Templates, CA-Settings und Enrollment-Endpunkte zu großzügig sind, wird aus PKI-Infrastruktur ein sehr direkter Domänenpfad.