ISW ADCS Auditor v1.0 – der ESC-Vektor-Scanner für Ihre Microsoft-PKI
Wenn ein Pentester mit Certipy oder BloodHound in eine Active-Directory-Umgebung kommt, gehört Active Directory Certificate Services (ADCS) zu den ersten drei Dingen, die er sich anschaut. Der Grund ist einfach: ADCS ist Tier-0-Infrastruktur, ist aber in den meisten Umgebungen einmal eingerichtet und seitdem nicht mehr ernsthaft auditiert worden. Und ADCS hat eine besondere Eigenschaft, die es zum dankbaren Angriffsziel macht: wer ein Zertifikat für einen anderen Benutzer ausstellen lassen kann, kann sich auch als dieser Benutzer authentifizieren.
Die Forschungsgruppe von SpecterOps hat zwischen 2021 und 2024 systematisch 15 verschiedene Angriffsvektoren auf ADCS dokumentiert — bekannt als ESC1 bis ESC15. Jeder dieser Vektoren ist ein konkreter Weg, wie ein Angreifer mit moderaten Domänen-Rechten zu Domain-Admin-Privilegien gelangt. In den allermeisten Umgebungen, in denen ich als externer Auditor in den letzten Monaten unterwegs war, war mindestens einer davon offen.
Mit dem ISW ADCS Auditor v1.0 stelle ich Ihnen heute das Tool vor, das ich nach diesen Audits gebaut habe — weil ich keine Lust mehr hatte, jedes Mal eine Mischung aus certutil-Aufrufen, PowerShell-Schnipseln und manuellen LDAP-Queries zusammenzubauen.
Warum ADCS-Audits so schwierig sind
ADCS-Schwachstellen sind selten ein einzelner falscher Schalter. Sie entstehen aus der Kombination mehrerer Konfigurations-Eigenschaften, die einzeln betrachtet alle plausibel aussehen. Ein klassisches Beispiel: eine Zertifikatsvorlage hat das Flag msPKI-Certificate-Name-Flag = ENROLLEE_SUPPLIES_SUBJECT gesetzt (der Anforderer darf den Antragsteller-Namen selbst bestimmen), und sie hat pKIExtendedKeyUsage auf Client-Authentifizierung, und Authenticated Users haben Enroll-Rechte. Erst diese drei Eigenschaften zusammen ergeben ESC1 — den klassischen Angriffsvektor für eine Privilege-Eskalation.
Solche Konstellationen finden Sie nicht mit einem einzelnen certutil-Aufruf. Sie brauchen einen LDAP-Bind auf die Configuration-Naming-Context, das Lesen von Templates, die Analyse der Security-Descriptoren, das Verknüpfen mit den veröffentlichenden CAs — und das alles mit Kenntnis der 15 ESC-Muster. Das ist Stundenarbeit pro Forest. Und sie wird selten gemacht.
„Unsere PKI ist sicher, wir haben sie ja vom Microsoft-Partner aufsetzen lassen.” Diese Aussage höre ich oft. Sie ist sachlich falsch. Eine ADCS-Default-Installation bringt mehrere veröffentlichte Vorlagen mit, von denen einige ohne Härtung als ESC-Angriffspfad nutzbar sind. Die Vorlage User beispielsweise enthält ab Werk Konfigurationsmerkmale, die in Kombination mit lax gesetzten Enroll-Rechten zur Eskalation führen können.
Die 15 ESC-Vektoren im Überblick
Damit Sie einen Eindruck bekommen, was ein ADCS-Audit eigentlich abdecken muss, hier die kurze Liste der dokumentierten Schwachstellen-Klassen:
| ESC1 | Misconfigured Certificate Template — Subject in der Anforderung frei wählbar |
| ESC2 | Any-Purpose-EKU oder fehlende EKU — Zertifikat nutzbar für beliebige Zwecke |
| ESC3 | Enrollment Agent Templates ohne Enrollment-Agent-Restrictions |
| ESC4 | Vulnerable Template Access Control — schwache ACLs auf der Vorlage selbst |
| ESC5 | Vulnerable PKI Object Access Control — schwache ACLs auf CA-Container, NTAuth, AIA |
| ESC6 | EDITF_ATTRIBUTESUBJECTALTNAME2 — CA akzeptiert SAN-Erweiterung im Antrag |
| ESC7 | Vulnerable CA Access Control — ManageCA / ManageCertificates an niedrig privilegierte Konten |
| ESC8 | NTLM Relay to AD CS Web Enrollment — /certsrv-Endpunkt ohne EPA / Channel Binding |
| ESC9 | No Security Extension — Zertifikat enthält keine SID-Security-Extension |
| ESC10 | Weak Certificate Mappings — StrongCertificateBindingEnforcement nicht durchgesetzt |
| ESC11 | No RPC Encryption — ICertRequest-Interface ohne erzwungene Verschlüsselung |
| ESC13 | OID Group Link Abuse — Issuance-Policy-OID verknüpft mit privilegierter Gruppe |
| ESC14 | altSecurityIdentities Manipulation — Schreibrecht auf das Attribut |
| ESC15 | EKUwu — Schema-V1-Templates mit Application-Policy-Manipulation |
Jeder dieser Vektoren hat eigene Erkennungskriterien, eigene Voraussetzungen für die Ausnutzung und eigene Behebungs-Empfehlungen. Manuell ist das eine Riesenarbeit. Automatisiert dauert es bei uns rund zwei Minuten pro Forest.
Die Lösung: ISW ADCS Auditor v1.0
Der ISW ADCS Auditor ist eine .NET 10 WPF-Anwendung, die einen vollständigen ESC1-bis-ESC15-Scan einer Active-Directory-Forest-Umgebung in unter zwei Minuten durchführt. Hier die wichtigsten Eigenschaften:
--fail-on critical.%APPDATA% protokolliert — mit Pfad zu HTML- und PDF-Report.Wie der Auditor technisch arbeitet
Wichtig zu wissen: Der ISW ADCS Auditor läuft nicht auf dem Domain Controller und auch nicht auf der CA. Er wird von einer separaten Auditor-Workstation aus betrieben — typischerweise einer Privileged Admin Workstation oder einem Audit-Jumphost. Das ist nicht nur sauberer im Sinne der Tier-Trennung, sondern auch praktisch: ein Tool für alle Forest-Mitglieder, statt eine Installation pro Server.
Die Kommunikation läuft über etablierte Windows-Protokolle:
- LDAP/LDAPS (Port 389/636) für das Auslesen von Zertifikatsvorlagen, Enterprise-CAs und Trust-Anchor-Einträgen aus der Configuration-Naming-Context.
- WinRM zur CA (Port 5985/5986) für die Registry-Werte des CertSvc — EditFlags (ESC6), InterfaceFlags (ESC11), Security-Descriptor (ESC7).
- WinRM zum DC (Port 5985/5986) für die Registry-Werte des Kdc-Dienstes — StrongCertificateBindingEnforcement (ESC10).
- HTTP/HTTPS zur CA (Port 80/443) für die Web-Enrollment-Probe (ESC8).
Bemerkenswert ist die Trennung der WinRM-Konfiguration für CA und DC. In der Praxis sind Domain Controller fast immer härter konfiguriert als CAs: nur HTTPS, strenge Zertifikatsprüfung, oft auf Custom-Ports. Zertifizierungsstellen laufen häufig noch über HTTP mit selbstsignierten Server-Zertifikaten. Eine einzige WinRM-Einstellung für beide passte nie. Der ADCS Auditor bietet daher zwei vollständig getrennte Transport-Bereiche in den Einstellungen — Sie können HTTP-5985 zur CA und HTTPS-5986 mit Cert-Prüfung zum DC betreiben, beides parallel.
Compliance-Frame: was Sie damit nachweisen können
Eine Reihe von Compliance-Vorgaben verlangen heute explizit oder implizit eine ADCS-Härtung und ein nachweisbares Audit. Der ISW ADCS Auditor liefert in jedem Report direkte Referenzen auf folgende Werke:
- BSI IT-Grundschutz Kompendium 2023 — Bausteine APP.2.2 (Active Directory), SYS.1.1 (Allgemeiner Server), NET.1.1 (Netzarchitektur), ORP.4 (Identitäts- und Berechtigungsmanagement), OPS.1.1.3 (Patch- und Änderungsmanagement)
- CIS Microsoft Windows Server 2022 Benchmark v5.0.0
- ISO 27001:2022 — Annex A.5 (Access Control), A.8 (Asset Management), A.12 (Operations Security)
- DSGVO Artikel 32 — Sicherheit der Verarbeitung (Stand der Technik)
- NIS2-Richtlinie — Anforderungen an Authentifizierung und Zugriffskontrolle
- PCI-DSS v4.0 — Requirement 8 (Identify Users), Requirement 10 (Log and Monitor)
Der erzeugte PDF-Report ist als Audit-Beleg ablagefähig und GoBD-konform aufbewahrbar. Bei einer Wirtschaftsprüfung oder einer ISO-27001-Re-Zertifizierung können Sie den Bericht ohne Nachbearbeitung vorlegen.
Beispiel-Workflow: nächtlicher MSP-Audit
Wir betreiben den Auditor bei unseren Kunden typischerweise als Scheduled Task, der jede Nacht um 02:30 läuft. Das Setup ist eine einzige Kommandozeile:
/tr “\”C:\Tools\ADCS Auditor.exe\” –scan –use-stored-credentials –email security@kunde.de –fail-on critical –quiet” ^
/sc DAILY /st 02:30 /ru SYSTEM /rl HIGHEST /f
Was passiert dann:
- Der Auditor verbindet sich mit den hinterlegten Credentials zur Domäne und liest die ADCS-Container per LDAP.
- Pro CA wird via WinRM die Registry-Konfiguration gelesen — ein einziger Round-Trip pro CA.
- Pro Domain Controller werden die für ESC10 relevanten Werte abgefragt.
- Die 15 ESC-Scanner werten den eingelesenen Snapshot aus.
- HTML- und PDF-Reports werden erzeugt, der Audit-Trail aktualisiert, die Mail mit Anhang verschickt.
- Bei kritischen Findings setzt der Prozess ExitCode 1 — Ihr Monitoring-System (Icinga, PRTG, Checkmk) erzeugt automatisch ein Ticket.
Der gesamte Lauf dauert in einer typischen Umgebung (1 Forest, 2 Issuing CAs, 4 DCs, 30 Templates) rund 90 Sekunden. Das Tool skaliert von Single-DC-KMU bis zu Multi-Forest-Konzernumgebungen.
Für wen ist der ISW ADCS Auditor gedacht?
Drei Zielgruppen haben wir beim Design im Blick gehabt:
Lizenzmodell
Wie alle Tools aus dem ISW-ADTools-Portfolio: einmaliger Lizenzkauf, keine Subscription. Pro Auditor-Workstation eine Lizenz. Die Anzahl der geprüften Forests, CAs oder DCs ist nicht limitiert.
Updates für die Major-Version sind im Kaufpreis enthalten. Bei Bekanntwerden neuer ESC-Vektoren — und es werden vermutlich noch welche kommen — wird das Tool nachgeführt.
Active Directory Certificate Services sind ein unterschätztes Risiko in den meisten deutschen Windows-Umgebungen. Die Forschung hat 15 konkrete Angriffsvektoren dokumentiert, die Werkzeuge zum Ausnutzen sind öffentlich verfügbar — und Angreifer benutzen sie. Auf der anderen Seite ist das Audit dieser Vektoren ohne Spezialwerkzeug eine zeitfressende Spezialdisziplin.
Der ISW ADCS Auditor v1.0 schließt diese Lücke. Ein Klick — oder ein Scheduled Task — und Sie wissen, wo Sie stehen. Vor der nächsten ISO-Re-Zertifizierung. Vor dem nächsten Pentest. Vor dem nächsten Vorfall.
Produktseite, Datenblatt und Lizenzbedingungen auf isw-adtools.de
IT-Service Walter • Euskirchen • Made in Germany
Über den Autor: Jörn Walter ist Inhaber von IT-Service Walter (it-service-walter.com) und betreut seit 1993 Windows-Infrastrukturen für mittelständische Kunden im DACH-Raum. Unter der Marke ISW-ADTools entwickelt er professionelle Werkzeuge für Windows-Administratoren und MSPs. Sein Schwerpunkt liegt auf Active-Directory-Sicherheit, BSI IT-Grundschutz und Compliance-Audits.
Tags: ADCS · Active Directory · Certificate Services · ESC1-ESC15 · BSI IT-Grundschutz · CIS Benchmark · ISO 27001 · NIS2 · DSGVO · Penetration Testing · Windows Server · PKI · MSP