AD CS Template-Härtung: ESC1–ESC16 Verteidigungs-Playbook

Kurz gesagt: Die Härtung von AD CS-Vorlagen dient der Absicherung von Zertifikatvorlagen der Active Directory Certificate Services (ADCS) gegen die von SpecterOps dokumentierten und in der CISA-Empfehlung AA23-278A vorgeschriebenen Eskalationspfade ESC1 bis ESC16. Eine einzige falsch konfigurierte Vorlage kann ein Domänenkonto ohne Administratorrechte innerhalb von 60 Sekunden zum Unternehmensadministrator machen, ohne dass die herkömmliche Endpunkterkennung auslöst. Dieses Handbuch beschreibt die vollständige Angriffstaxonomie ESC1 bis ESC16, eine 15-Punkte-Checkliste zur Härtung mit den entsprechenden certutil-Befehlen, die CISA- und NIST-Konformitätsrichtlinien für PKI-Teams sowie eine Entscheidungstabelle zur Auswahl zwischen gehärtetem lokalem AD CS, verwalteter PKI oder einer Hybridlösung.

Microsoft Active Directory Certificate Services (AD CS) bildet seit über zwei Jahrzehnten das Rückgrat der PKI von Unternehmen. Es ermöglicht Organisationen die Ausstellung digitaler Zertifikate für Benutzerauthentifizierung, Computeridentität, Codesignierung , Verschlüsselung, Smartcard-Anmeldung und sichere Kommunikation – alles eng integriert in Active Directory.

Diese tiefe Integration ist jedoch ein zweischneidiges Schwert. Zertifikatvorlagen – die Richtlinienobjekte, die festlegen, welche Zertifikate an wen und mit welchen Berechtigungen ausgestellt werden – werden selbst als AD-Objekte gespeichert. Eine einzige falsch konfigurierte Vorlage kann einem Angreifer innerhalb von Minuten den Weg vom unprivilegierten Domänenbenutzer zum Unternehmensadministrator ebnen, ohne dass die herkömmliche Endpunkterkennung ausgelöst wird.

Das Whitepaper „SpecterOps Certified Pre-Owned “ (2021) markierte einen Wendepunkt. Es dokumentierte acht Eskalationspfade (ESC1–ESC8), die Fehlkonfigurationen von Zertifikatvorlagen zu Einfallstoren für die Kompromittierung von Domänen machten. Seitdem wurde die Taxonomie auf ESC16 erweitert , und Microsoft, CISA ( AA23-278A ), NSA und die Partnerbehörden der Five Eyes ( Gemeinsame Empfehlung vom September 2024 ) reagierten mit Fristen für die Durchsetzung von Vorschriften, Patch-Vorgaben und der formalen Tier-0-Klassifizierung der CA-Infrastruktur. Dieses Handbuch bietet die notwendige technische Tiefe für PKI-Administratoren, Sicherheitsarchitekten und Governance-Teams. Grundlagen dazu finden Sie in den Leitfäden von Encryption Consulting zu „ Was ist PKI?“ , „Zertifizierungsstellen“ und „X.509-Zertifikate“.

Wichtige Erkenntnisse

• AD CS-Zertifikatvorlagen werden als Active Directory-Objekte gespeichert. Eine einzige falsch konfigurierte Vorlage kann einem Angreifer von einem benutzerlosen Domänenkonto zu einem Unternehmensadministratorkonto verhelfen. Im Fall von ESC1 haben Sicherheitsforscher den gesamten Pfad in weniger als 60 Sekunden dokumentiert.
• Die meisten Umgebungen veröffentlichen 30 oder mehr Zertifikatvorlagen, nutzen aber tatsächlich nur 5 bis 8 davon. Durch die Deaktivierung der übrigen Vorlagen wird die Anfälligkeit für ESC1- bis ESC3- und ESC15-Schwachstellen beseitigt, ohne dass dies Auswirkungen auf die reguläre Registrierung hat.
• Die vom CA/Browser Forum im Rahmen der Abstimmung SC-081v3 (April 2025) vorgeschlagene schrittweise Reduzierung der Lebensdauer von TLS-Zertifikaten auf 200 Tage ab März 2026, 100 Tage im März 2027 und 47 Tage bis März 2029 macht die manuelle Pflege von AD CS-Vorlagen und CAs ohne Automatisierung nicht praktikabel.
• Die Template-Härtung schließt die AD CS-spezifischen Angriffspfade. Sie allein bietet jedoch keine Transparenz über den Rest Ihrer kryptografischen Infrastruktur und muss daher in ein umfassenderes kryptografisches Sicherheitsmanagement eingebettet sein, das von … unterstützt wird. CBOM Secure.

Für wen ist die AD CS Template-Härtung relevant?

Die Härtung von AD CS-Vorlagen ist eine funktionsübergreifende Aufgabe. Jede der unten aufgeführten Rollen trägt direkt dazu bei, die Angriffsfläche des ESC zu schließen, bevor sie in einem Red-Team-Bericht oder einem Vorfall auftaucht.

Funktion / Rolle (Role) *	Warum es wichtig ist	Aktionselement
PKI-Administratoren	Eigene Vorlagenkonfiguration, CA-Registry-Einstellungen und Implementierung der 15-Punkte-Checkliste	Führen Sie certutil -catemplates aus, um veröffentlichte Vorlagen als Basiswerte festzulegen; aktivieren Sie die vollständige CA-Audit-Protokollierung (auditfilter 127); planen Sie vierteljährliche Locksmith 2-Scans ein.
Sicherheitsarchitekten	Verantwortung für die ESC-Risikoposition, Tier-0-CA-Klassifizierung gemäß CISA AA23-278A und NIST SP 800-53 SC-17-Konformitätszuordnung	Alle CAs als Tier-0-Assets einstufen; jede veröffentlichte Vorlage der ESC-Taxonomie zuordnen; für hochwertige Vorlagen die Genehmigung des Managers vorschreiben.
Active Directory-Teams	Eigene Vorlagen- und CA-AD-Objekt-ACLs; Write/WriteDACL/GenericAll auf einem Vorlagen-AD-Objekt ist die ESC4/ESC5-Angriffsbedingung	Prüfen Sie alle PKI-AD-Objekt-ACLs; entfernen Sie alle Schreib-/WriteDACL-/WriteOwner-/GenericAll-Berechtigungen, die nicht der Stufe 0 angehören; überprüfen Sie die von übergeordneten Containern geerbten ACEs.
Compliance-Teams	Es muss nachgewiesen werden, dass die Vorgaben von CISA AA23-278A erfüllt und die Kontrollen gemäß NIST SP 800-53 SC-12/SC-17 durchgesetzt werden; CA-Audit-Logs müssen an das SIEM weitergeleitet werden.	Die AD CS-Vorlagenprüfung in den vierteljährlichen Compliance-Bereich einbeziehen; vierteljährliche Locksmith-Scan-Ergebnisse als Prüfungsnachweis fordern.
CISOS	Besitzen Sie den Risikoregistereintrag für AD CS als Angriffsfläche der Stufe 0; eine einzelne ESC1-Vorlage stellt einen Domänenkompromittierungsvektor dar, der die Endpunkterkennung vollständig umgeht.	AD CS-Bewertung in jedem Red-Team-Einsatz fordern; CLM-Tools finanzieren über CertSecure Manager; das AD CS-Risiko in die Berichterstattung auf Vorstandsebene einbeziehen.

Die geschäftlichen Kosten eines fehlerhaften Zertifikatsmanagements

Fehlkonfigurationen von AD CS-Vorlagen treten selten unbemerkt auf. Sie werden meist durch Ausfälle, Auditfeststellungen oder Störungsmeldungen bekannt. Aktuelle Branchenstudien beziffern dieses Risiko:

• Laut [Quelle einfügen] erlebten mehr als 70 % der Organisationen im vergangenen Jahr mindestens einen Ausfall im Zusammenhang mit Zertifikaten. CyberArks Bericht zum Stand der maschinellen Identitätssicherheit 2025.
• Laut der CyberArk-Studie aus dem Jahr 2025 gaben 43 % der Organisationen, die einen Sicherheitsvorfall im Zusammenhang mit der Identität von Maschinen erlitten hatten, an, dass Angreifer diese genutzt hätten, um auf sensible Daten oder Netzwerke zuzugreifen.
• Laut einer Studie geben 91 % der Unternehmen an, mehr digitale Zertifikate als je zuvor einzusetzen, im Vergleich zu 74 % im Jahr 2023. Keyfactors PKI- und Digital Trust-Bericht 2024 (Vanson Bourne-Umfrage unter 1,200 IT- und Sicherheitsverantwortlichen, veröffentlicht im September 2024).
• 45 % der Unternehmen verzeichneten im vergangenen Jahr aufgrund von Zertifikatsproblemen Serviceausfälle, und der Ablauf von Zertifikaten zählte mit 56.6 % zu den drei wichtigsten Anliegen von CISOs im Bereich Zertifikatsmanagement. DigiCerts Vertrauens-Pulsumfrage (Veröffentlicht am 2. Juli 2025).

Die unkontrollierte Verbreitung von Zertifikaten und unkontrollierte Vorlagen verstärken sich gegenseitig. Je mehr Vorlagen und Zertifikate sich in einer Umgebung ohne Governance-Prozess ansammeln, desto wahrscheinlicher ist es, dass eine davon unbemerkt die Bedingungen für ESC1 bis ESC16 erfüllt.

Voraussetzungen vor der Härtung von AD CS-Vorlagen

Erfüllen Sie alle Voraussetzungen, bevor Sie die Punkte der Checkliste umsetzen. Das Auslassen eines dieser Punkte ist die häufigste Ursache für Registrierungsfehler im Zusammenhang mit der Systemhärtung und für eine unvollständige ESC-Abdeckung.

Voraussetzung	Befehl / Überprüfung	Validierungsprüfung	Häufiger Fehler bei fehlender	Eigentümer
Alle Zertifizierungsstellen wurden für CVE-2024-49019 und CVE-2022-26923 gepatcht.	Überprüfen Sie den Windows Update-Verlauf oder WSUS auf KB-Artikel, die in Microsoft-Sicherheitshinweisen für jede CVE aufgeführt sind.	Bestätigen Sie, dass der Patch auf jeder Zertifizierungsstelle in der Hierarchie angewendet wurde; überprüfen Sie dies mit certutil -getconfig um die CA-Version zu bestätigen	ESC15 bleibt auch nach der Implementierung aller anderen Punkte der Checkliste über Schema V1-Vorlagen weiterhin angreifbar.	PKI-Administrator / Windows-Patching-Team
Grundbestand aller veröffentlichten Vorlagen	certutil -catemplates	Die Ausgabe listet alle aktuell auf der CA veröffentlichten Vorlagen auf; speichern Sie diese als Baseline vor der Härtung für die spätere Verwendung.	Das Entfernen von Vorlagen ohne Basislinie führt zu unvorhergesehenen Registrierungsfehlern; es gibt keine Möglichkeit, bei Störungen legitimer Nutzer auf eine Rücksetzung zurückzugreifen.	PKI-Administrator
Vollständige CA-Audit-Protokollierung aktiviert	certutil -setreg ca\auditfilter 127 dann net stop certsvc && net start certsvc	certutil -getreg ca\auditfilter sollte nach dem Neustart den Wert 127 zurückgeben.	Ohne vollständige Audit-Protokollierung bleiben ESC4/ESC5-Vorlagenmodifikationen und ESC7-Angriffe durch Ablehnung von Genehmigungsanfragen in den CA-Ereignisprotokollen unsichtbar.	PKI-Administrator
ESC-Schwachstellenscan vor der Härtung	Run Locksmith 2: Invoke-Locksmith -Mode 5 oder PSPKIAudit: Get-AuditCertificateTemplate	Prüfen Sie die Ergebnisse aller ESC1-ESC16-Befunde; dokumentieren Sie jeden Befund vor jeglichen Änderungen, damit ein erneuter Scan nach der Härtung die vollständige Behebung der Mängel bestätigt.	Eine Härtung ohne vorherigen Scan bedeutet, dass man nicht feststellen kann, was behoben wurde und was noch vorhanden ist.	PKI-Administrator / Sicherheitsarchitekt
CA-Konfiguration und Vorlagensicherung von AD-Objekten	certutil -backupDB <BackupDir> Für die CA-Datenbank; Exportieren von AD-Vorlagenobjekten über ADSI Edit oder PowerShell LDAP-Export	Stellen Sie sicher, dass die Sicherung von einem vom CA-Server unabhängigen Ort aus zugänglich ist; testen Sie die Wiederherstellung im Labor, bevor Änderungen in der Produktionsumgebung vorgenommen werden.	Änderungen an Vorlagen-ACLs oder Eigenschaften, die die Registrierung beeinträchtigen, können ohne eine AD-Objektsicherung nicht rückgängig gemacht werden.	PKI-Administrator
Windows Server 2016 oder höher auf allen Zertifizierungsstellen	winver or Get-ComputerInfo | Select-Object OsName,OsVersion	Bitte prüfen Sie, ob alle Zertifizierungsstellen die Mindestversion des Betriebssystems erfüllen; Server 2012 R2 unterstützt die SID-Erweiterung nicht (Anforderung gemäß KB5014754).	Die strenge Zertifikatszuordnung (KB5014754) ist auf Server 2012 R2 nicht verfügbar; die Behebung von ESC9/ESC10-Problemen ist ohne sie unvollständig.	PKI-Administrator-/Infrastrukturteam

Aufbau der Zertifikatvorlage: Die acht Eigenschaften, die Ihre Risikoposition definieren

Jede AD CS-Vorlage ist ein pKICertificateTemplate-Objekt, das unter CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration in Active Directory gespeichert wird. Das X.509-Zertifikatprofil ist in RFC 5280 definiert , während das Framework für Zertifikatsrichtlinien und Zertifizierungspraktiken RFC 3647 folgt . Microsoft liefert drei Schemaversionen aus:

• Version 1: Legacy-Vorlagen mit eingeschränkter Bearbeitbarkeit und ohne automatische Registrierung. Besonders gefährlich, da Schema V1-Vorlagen anfällig für ESC15 sind (CVE-2024-49019, EKU-Überschreibung über CSR).
• Version 2: Vollständige Konfiguration, automatische Registrierung und alle Standard-Sicherheitskontrollen.
• Version 3: Fügt Unterstützung für die kryptografischen Algorithmen Suite B / CNG (ECDSA P-256/P-384/P-521) hinzu, die mit NIST-SP 800-57 Wichtige Managementempfehlungen.

Registerkarten mit Vorlageneigenschaften und ihre Sicherheitsauswirkungen

Registerkarte „Eigenschaften“	Was es steuert	Häufigster Sicherheitsfehler
Allgemein	Anzeigename, Vorlagenname (CN), Gültigkeitszeitraum, Verlängerungszeitraum, AD-Veröffentlichung	Übermäßig lange Gültigkeitsdauern (standardmäßig 1-2 Jahre); unnötige Veröffentlichung von Zertifikaten im Attribut userCertificate
Kompatibilität	Mindestversionen von Zertifizierungsstelle und Empfänger-Betriebssystem, die die verfügbaren kryptografischen Funktionen einschränken	Die Kompatibilität mit älteren Betriebssystemen bleibt erhalten, wodurch die Verwendung leistungsstärkerer Algorithmen verhindert wird.
Bearbeitung von Anfragen	Zweck (Signatur / Verschlüsselung / Beides), Exportierbarkeit des privaten Schlüssels, CSP/KSP, minimale Schlüssellänge	Exportierbare private Schlüssel für hochwertige Vorlagen; Zulassung schwacher CSPs
Subjekt Name	Erstellung aus AD-Attributen im Vergleich zu vom Teilnehmer angegebenen Werten (CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT)	Die Aktivierung des vom Teilnehmer bereitgestellten SAN ist die Hauptursache für ESC1.
Erweiterungsoptionen	Erweiterte Schlüsselverwendungen (EKUs) pro RFC 5280 §4.2.1.12	Beliebige EKU, fehlende EKU (die als SubCA fungiert) oder zu breit gefasste Authentifizierungs-EKUs
Cryptography	Algorithmus (RSA/ECDSA), Schlüssellänge, Hash pro NIST-SP 800-57	SHA-1 ist weiterhin vorhanden; 1024-Bit-RSA-Schlüssel werden weiterhin akzeptiert
Ausstellungsanforderung	Genehmigung durch den Manager, Unterschriften des autorisierten Anmeldebeauftragten	Keine Genehmigung für sensible Vorlagen (WebServer, CodeSigning, EnrollmentAgent).
Sicherheit / Zugriffskontrolllisten	Wer kann das Vorlagenobjekt lesen, schreiben, anmelden, automatisch anmelden und vollständig kontrollieren?	Authentifizierte Benutzer oder Domänenbenutzer, denen die Registrierung für sensible Vorlagen gewährt wurde

Themenarten und wichtige Nutzungskategorien verstehen

Jede Standardvorlage gehört zu einem Subjekttyp und einer Schlüsselverwendungskategorie. Weitere Informationen finden Sie unter „Was ist ein X.509-Zertifikat?“ und in RFC 5280.

Facharten

• Benutzer: Zertifikate für menschliche Identitäten, einschließlich Authentifizierung, E-Mail-Signatur/Verschlüsselung, EFS, Codesignatur und Smartcard-Anmeldung. Beinhaltet Administrator, Benutzer, Smartcard-Benutzer, Registrierungsagent, Codesignatur, EFS-Wiederherstellungsagent, Exchange-Benutzer/Signatur.
• Rechner: Zertifikate für Maschinenidentitäten, einschließlich Server-/Client-Authentifizierung, IPsec und Kerberos (RFC 4556 PKINIT). Beinhaltet Computer, WebServer, Domänencontroller, Kerberos-Authentifizierung, Arbeitsstationsauthentifizierung, RAS- und IAS-Server.
• Zertifizierungsstelle (CA): Zertifikate, die Zertifizierungsstellen innerhalb der PKI-Hierarchieeinschließlich Root-CA, Subordinate-CA und Cross-Certification-Authority.
• DirEmailRep: Directory Email Replication zur Sicherung des AD-Replikationsverkehrs.
• Schlüsselwiederherstellungsagent: Zertifikate, die die autorisierte Wiederherstellung archivierter privater Schlüssel ermöglichen, sind unerlässlich für Schlüsselverwaltung Führung.

Wichtigste Nutzungskategorien

• Nur Unterschrift: Digitale Signaturen zur Gewährleistung von Integrität und Authentizität gemäß RFC 5280 §4.2.1.3 (CodeSigning, TrustListSigning, EnrollmentAgent, OCSP Response Signing, CA templates).
• Nur Verschlüsselung: Schlüsselverschlüsselung für Vertraulichkeit (BasicEFS, CEPEncryption, EFSRecovery, ExchangeUser, KeyRecoveryAgent).
• Signatur + Verschlüsselung: beide Operationen (Administrator, Computer, Benutzer, Domänencontroller, Webserver, Smartcard-Anmeldung, Kerberos-Authentifizierung, IPSec).

Bewährte Vorgehensweise: Standardvorlagen sollten niemals direkt geändert werden. Duplizieren Sie die Vorlage, deaktivieren Sie das Original und härten Sie die Kopie ab. Weitere Informationen finden Sie im Leitfaden zur Härtung von Active Directory CS von Microsoft.

Standardvorlagen: Risikoprofile, die Sie kennen müssen

Template	Standardregistrierung	Gefährliche Eigenschaften	Angriffsvektoren	Risiko
Benutzer (V1)	Domänenbenutzer	Client Auth EKU, V1-Schema	ESC3, ESC15	HOCH
Computer (V1)	Domänencomputer	Client Auth EKU, V1-Schema	ESC3, ESC8	HOCH
Webserver (V1)	Domänenadministratoren (oft erweiterter Begriff)	Betreff: Unterlagen für Einschreibeschüler	ESC1, ESC15	KRITISCH
SubCA (V1)	Domänenadministratoren	Kein EKU (SubCA-Verhalten)	ESC7	KRITISCH
Registrierungs-Agent	Oft erweitert	Zertifikatsanforderungsagent EKU	ESC3-Kette	HOCH

Häufigste Anwendungsfälle in Unternehmen

Bevor man sich mit Angriffspfaden befasst, ist es hilfreich, die legitimen Anwendungsfälle in Unternehmen zu verstehen, die dem Template-Design zugrunde liegen. Einen umfassenderen Überblick bietet Encryption Consulting mit seinen PKI-Services.

• Webserver / TLS: Die WebServer-Vorlage stellt Zertifikate für interne HTTPS-Endpunkte aus, die von folgenden Richtlinien verwaltet werden: RFC 8446 (TLS 1.3) und RFC 6125Es erfordert berechtigterweise vom Teilnehmer bereitgestellte SANs und ist daher das primäre ESC1/ESC15-Ziel, wenn die Registrierungsberechtigungen erweitert werden. Öffentlich vertrauenswürdige Webzertifikate müssen ebenfalls den folgenden Anforderungen entsprechen: CA/Browser-Forum-Grundanforderungen.

  

• Benutzerauthentifizierung (802.1X / VPN): Die Benutzervorlage stellt EAP-TLS-Zertifikate für die drahtlose Authentifizierung und VPN bereit. Durch die breite Einbindung von Domänenbenutzern eignet sie sich als ESC3/ESC15-Vektor.
• Kerberos-Authentifizierung: Domänencontroller verwenden diese Vorlage für PKINIT-basierte Kerberos-Authentifizierung (RFC 4556)LDAPS und DC-zu-DC-Replikation. Ein Kompromiss ermöglicht die Persistenz der Domäne.

  

• Code-Signierung: Entwickler signieren interne Skripte und Anwendungen. Siehe Was ist Code Signing? Private Schlüssel sollten niemals exportierbar sein, und ihre Ausstellung sollte die Genehmigung des Managers erfordern.

  

  

• Verschlüsselung (EFS / S / MIME): BasicEFS und Exchange-Benutzervorlagen schützen die Datei- und E-Mail-Verschlüsselung. Die Schlüsselarchivierung sollte für die Geschäftskontinuität aktiviert werden. NIST SP 800-57 Schlüsselverwaltung Beratung.

ESC1 bis ESC16: Die vollständige Angriffs-Taxonomie

Angriffspfade lassen sich in fünf Kategorien einteilen. Die vollständige Untersuchung ist im Whitepaper „Certified Pre-Owned“ (PDF) dokumentiert und wird fortlaufend über BloodHound AD CS-Angriffspfade und MITRE ATT&CK T1649 aktualisiert.

Angriffe durch fehlerhafte Template-Konfiguration

ESC1 — Vom Teilnehmer bereitgestelltes SAN (Der Weg Nr. 1)

ESC1 erfordert: (1) aktiviertes CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT, (2) Client Authentication EKU, (3) Registrierung mit geringen Berechtigungen, (4) keine Genehmigung durch den Manager. Der Angreifer gibt [email protected] im SAN an und authentifiziert sich gemäß RFC 4556. Gesamtzeit bis zum Enterprise-Administrator: unter 60 Sekunden.

ESC2 — Beliebige oder fehlende EKU

Templates mit AnyPurpose EKU (OID 2.5.29.37.0) können beliebige Funktionen erfüllen. Templates ohne EKU fungieren gemäß RFC 5280 §4.2.1.12 als untergeordnete CA-Zertifikate und können beliebige neue Zertifikate signieren.

ESC3 – Missbrauch durch Registrierungsagenten

ESC3 verknüpft zwei Vorlagen: Zuerst wird ein Zertifikat für einen Zertifikatsanforderungsagenten beantragt, dann wird dieses verwendet, um im Namen privilegierter Benutzer über Schema V1-Zielvorlagen Zertifikate anzufordern und dabei die normalen Registrierungsbeschränkungen zu umgehen.

ESC15 (CVE-2024-49019 — „EKUwu“)

Die von TrustedSec im Oktober 2024 entdeckte Sicherheitslücke CVE-2024-49019 nutzt Schema-V1-Vorlagen aus, bei denen die msPKI-Certificate-Application-Policy im CSR die pKIExtendedKeyUsage der Vorlage überschreibt. Die WebServer-Vorlage ist das primäre Ziel. Abhilfe: Alle Zertifizierungsstellen patchen und V1-Vorlagen auf V2+ migrieren. Siehe IX509ExtensionMSApplicationPolicies.

Zugriffskontrollfehler

ESC4 – Missbrauch von Template-Objekt-ACLs

Benutzer mit geringen Berechtigungen, die über die Berechtigungen Write, WriteDACL, WriteOwner oder GenericAll für ein AD-Vorlagenobjekt verfügen, können dieses in ein ESC1-Äquivalent umwandeln, ein privilegiertes Zertifikat anfordern und anschließend die Einstellungen wiederherstellen, wodurch nur minimale forensische Spuren hinterlassen werden.

ESC5 – Missbrauch von PKI-Objekt-ACLs

Erweitert ESC4 auf alle PKI-AD-Objekte: NTAuthCertificates, Enrollment Services, CA-Computerobjekte und übergeordnete Container mit vererbbaren ACEs. Siehe die Richtlinien von Microsoft zur AD-CS-Härtung.

ESC7 – Schwachstelle in der CA-Zugriffskontrolle

Benutzer mit geringen Berechtigungen, die ManageCA oder ManageCertificates verwenden, können die SubCA-Vorlage aktivieren, eine Anfrage mit einem beliebigen SAN (abgelehnt) stellen und anschließend die fehlgeschlagene Anfrage genehmigen, um ein SubCA-Zertifikat zu erhalten, das zum Signieren beliebiger Dokumente geeignet ist.

CA-Konfigurationsprobleme

ESC6 — EDITF_ATTRIBUTESUBJECTALTNAME2

Wenn die Zertifizierungsstelle EDITF_ATTRIBUTESUBJECTALTNAME2 aktiviert hat, kann jeder Teilnehmer unabhängig von den Vorlageneinstellungen einen beliebigen SAN angeben. Auf jeder Zertifizierungsstelle deaktivieren:

certutil -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2 net stop certsvc && net start certsvc

ESC12 – CA-Privatschlüssel auf externem Gerät

Zielt auf Zertifizierungsstellen mit privaten Schlüsseln auf externen HSMs ab , deren Anmeldeinformationen im Klartext in der Registry gespeichert sind. Betont die Notwendigkeit von FIPS 140-2/140-3 Level 3- zertifizierten HSM-Implementierungen mit ordnungsgemäßem Anmeldeinformationsmanagement.

ESC16 – Globale SID-Erweiterung deaktiviert

Die SID-Sicherheitserweiterung (OID 1.3.6.1.4.1.311.25.2) ist in der DisableExtensionList der Zertifizierungsstelle global deaktiviert. Ohne sie kann der KDC gemäß KB5014754 kein starkes Zertifikatsmapping durchführen . Die SID-Erweiterung darf auf keiner produktiven Zertifizierungsstelle in der DisableExtensionList enthalten sein.

Schwächen der Zertifikatszuordnung

ESC9 — Keine Sicherheitserweiterung (Vorlagenebene)

Templates mit CT_FLAG_NO_SECURITY_EXTENSION (0x80000) verhindern das Einbetten der SID und erzwingen so eine schwache UPN-basierte Zuordnung. Dies kann ausgenutzt werden, wenn gleichzeitig die eigene UPN modifiziert werden kann.

ESC10 — Schwache Zuordnung auf Registry-Ebene

Wenn StrongCertificateBindingEnforcement auf 0 oder 1 gesetzt ist, wird dieser Schlüssel ab September 2025 gemäß KB5014754 dauerhaft nicht mehr unterstützt . Die vollständige Durchsetzung ist die einzige Option.

ESC13 – Link zur Richtliniengruppe für die Ausstellung

Nutzt msDS-OIDToGroupLink-Attribute aus, die Ausstellungsrichtlinien-OIDs mit privilegierten universellen Gruppen verknüpfen. Siehe die detaillierte Missbrauchstechnik für ADCS ESC13.

ESC14 – Schwache explizite Zertifikatszuordnungen

Betrifft schwache Zuordnungen in altSecurityIdentities (X509RFC822, X509IssuerSubject). Nur starke Zuordnungen bleiben nach KB5014754 erhalten (X509IssuerSerialNumber, X509SKI, X509SHA1PublicKey).

Netzwerk-Relay-Angriffe

ESC8 – NTLM-Relay zu HTTP-Registrierung

Relays erzwingen NTLM-Authentifizierung (über CVE-2021-36942 ) an AD CS-Webregistrierungsendpunkten ohne HTTPS und EPA. Der Angreifer erlangt ein DC-Zertifikat, das DCSync aktiviert. Hinweise zu Sicherheitsmaßnahmen für die Webregistrierung finden Sie in den Netzwerksicherheitsanforderungen des CA/Browser Forums .

ESC11 — NTLM-Relay zu RPC-Registrierung

Betrifft die ICertPassage-RPC-Schnittstelle. Abhilfe:

certutil -setreg CA\InterfaceFlags +IF_ENFORCEENCRYPTICERTREQUEST net stop certsvc && net start certsvc

Was Microsoft, CISA und NSA von Ihnen verlangen, zu beheben

KB5014754: Starke Zertifikatszuordnung ist permanent

Als Reaktion auf CVE-2022-26923 führte Microsoft die SID-Sicherheitserweiterung (OID 1.3.6.1.4.1.311.25.2) ein. Vollständiger Zeitplan für die Implementierung gemäß KB5014754 :

• 2022. Mai: Kompatibilitätsmodus – SID-Erweiterung hinzugefügt, schwache Zuordnung weiterhin akzeptiert
• 2023. April: Deaktivierter Modus entfernt
• Februar 2025: Vollständige Durchsetzung standardmäßig aktiviert
• September 2025: Der Schlüssel „StrongCertificateBindingEnforcement“ wird dauerhaft nicht unterstützt.

Auswirkungen: Nur die Zuordnungen X509IsuerSerialNumber, X509SKI und X509SHA1PublicKey bleiben erhalten. Hinweise zur Aktualisierung von Zertifikatszuordnungen finden Sie im Blogbeitrag „Microsoft’s Strong Certificate Mapping Enforcement“ von Encryption Consulting.

Wichtige Verbesserungen in Windows Server 2025 AD CS:

• CRL-Partitionierung: Teilt monolithische CRLs in Seriennummernbereichspartitionen für große Installationen auf (siehe Leistungsstarke Verbesserungen an ADCS im Jahr 2025)
• 16 KB+ Erweiterungsgrenze: Aktiviert PQC-fähige Metadaten (siehe Leitfaden zur Post-Quanten-Kryptographie von Encryption Consulting)
• Erweiterte Prüfereignisse: 4886-4889 enthalten nun SAN-Werte, Vorlagennamen, Client-Betriebssystem, CSP und Authentifizierungstyp (Microsoft-Audit-Dokumentation)
• Sicherheitsstandards: LDAP-Verschlüsselung obligatorisch, Credential Guard aktiviert, NTLM veraltet, RC4 in Kerberos veraltet

Regierungs- und Branchenhinweise

• CISA/NSA AA23-278A (Oktober 2023)Benennt AD CS-Fehlkonfigurationen als eine der zehn häufigsten Cybersicherheitslücken. Schreibt die Tier-0-CA-Klassifizierung vor.
• Gemeinsame Empfehlung der Five Eyes (September 2024)Mitverfasst von ASD, CISA, NSA, CCCS, NCSC-NZ und NCSC-UK. Hebt ESC1 und ESC8 namentlich hervor.
• MITRE ATT&CK T1649: Erkennungs-/Abwehrrahmen für Zertifikatsdiebstahl und -fälschung (M1047, M1042, M1041).
• CISA-Katalog bekannter ausgenutzter Schwachstellen: CVE-2022-26923 und CVE-2024-49019 mit verbindlichen Fristen für die Behebung von Mängeln.
• NIST SP 800-57 (Schlüsselmanagement) und SP 800-152 (Federal CKMS Profile): Rahmenwerk für die kryptografische Governance.
• NIST SP 800-53 Rev. 5: SC-12 (Kryptographische Schlüsselerzeugung), SC-17 (PKI-Zertifikate), IA-5 (Authenticator-Management) sind direkt auf die AD CS-Governance anwendbar.
• NIST SP 800-207 (Zero Trust Architecture)Zertifikatsbasierte Identität ist grundlegend für Zero Trust. Siehe auch Leitfaden für Zero Trust von Encryption Consulting.

Die 15-Punkte-Checkliste zur Härtung

Setzen Sie diese Kontrollen unverzüglich um. Jede ist bestimmten ESC-Vektoren zugeordnet und entspricht CISA AA23-278A , NIST SP 800-53 SC-12/SC-17 und den AD CS-Härtungsrichtlinien von Microsoft :

1. Alle nicht verwendeten Standardvorlagen veröffentlichen: Die meisten Umgebungen verwenden 5-8, veröffentlichen aber 32+. [Reduziert: ESC1-ESC3, ESC15]
   • Um zu sehen, was aktuell veröffentlicht ist:

     certutil -catemplates

   • Entfernen Sie Vorlagen aus der veröffentlichten Liste der Zertifizierungsstelle:

     certutil -setcatemplates - ,

2. Deaktivieren Sie CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT überall dort, wo es betrieblich nicht erforderlich ist: Die Genehmigung durch den Manager als kompensierende Kontrollmaßnahme aktivieren. [Reduziert: ESC1]
   • Dies ist ein in AD gespeichertes, vorlagenspezifisches Flag (msPKI-Zertifikatsname-Flag). So prüfen Sie den aktuellen Wert:

     certutil -dstemplate

   • Wenn Bit 1 gesetzt ist, löschen Sie es über ADSI Edit oder:

     certutil -dstemplate msPKI-Certificate-Name-Flag -1

3. AnyPurpose EKU entfernen und Vorlagen ohne EKU eliminieren: Sofern sie nicht als untergeordnete CAs fungieren, verhält sich eine fehlende EKU gemäß RFC 5280 §4.2.1.12 wie eine SubCA. [Reduziert: ESC2]
   • EKU ist msPKI-Certificate-Application-Policy und pKIExtendedKeyUsage im AD-Vorlagenobjekt. Überprüfen Sie mit:

     certutil -dstemplate

   • Entfernen Sie OID 2.5.29.37.0 (anyExtendedKeyUsage) und legen Sie spezifische EKU-OIDs fest.

     

     

     

4. Registrierung/Automatische Registrierung auf bestimmte benannte Sicherheitsgruppen beschränken: Gewähren Sie diese Berechtigung niemals authentifizierten Benutzern, Domänenbenutzern oder Domänencomputern für sensible Vorlagen. [Reduziert: ESC1-ESC3, ESC15]

   

5. Managergenehmigung und autorisierte Unterschriften aktivieren: Erforderlich für die Vorlagen WebServer, CodeSigning, SmartCardLogon und EnrollmentAgent. [Reduziert: ESC1, ESC3]

   

6. Minimale Schlüssellängen festlegen und SHA-1 deaktivieren: Verwenden Sie 2048-Bit-RSA (4096-Bit für CA-Schlüssel) oder ECDSA P-384 gemäß dem NIST SP 800-57-Abkürzungsplan. [Entspricht: NIST, CA/B Forum BR]
   • Die minimale Schlüssellänge ist msPKI-Minimal-Key-Size in der Vorlage. Überprüfen Sie dies mit:

     certutil -dstemplate

   • Um den SHA-256-Mindestwert auf der Zertifizierungsstelle selbst festzulegen:

     certutil -setreg ca\csp\CNGHashAlgorithm SHA256 net stop certsvc && net start certsvc

   • Überprüfen:

     certutil -getreg ca\csp\CNGHashAlgorithm

7. Deaktivieren Sie EDITF_ATTRIBUTESUBJECTALTNAME2 auf jeder Zertifizierungsstelle: [Reduziert: ESC6]

   certutil -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2 net stop certsvc && net start certsvc

8. RPC-Verschlüsselung erzwingen: [Reduziert: ESC11]

   certutil -setreg CA\InterfaceFlags +IF_ENFORCEENCRYPTICERTREQUEST net stop certsvc && net start certsvc

9. HTTP-Webregistrierung härten oder entfernen: HTTPS und EPA erzwingen, NTLM deaktivieren. [Reduziert: ESC8]
   • So deaktivieren Sie Remote-RPC-basierte Anfragen:

     certutil -setreg CA\InterfaceFlags +IF_NOREMOTEICERTREQUEST

   • Speziell für HTTP/CES: Deinstallieren Sie die Web-Registrierungsrolle oder konfigurieren Sie IIS neu.
10. Sperrvorlage und CA-DACLs nur für Konten der Stufe 0: Überprüfen Sie regelmäßig alle PKI-AD-Objekte. [Reduziert: ESC4, ESC5, ESC7]
    • Den Sicherheitsdeskriptor der Zertifizierungsstelle anzeigen:

      certutil -getreg CA\Security

11. Entfernen Sie CT_FLAG_NO_SECURITY_EXTENSION aus allen Vorlagen: Stellen Sie sicher, dass die SID-Erweiterung gemäß KB5014754 gestempelt ist. [Reduziert: ESC9]
    • Dies ist das msPKI-Registrierungsflag Bit 0x80000 der Vorlage. Prüfen Sie Folgendes:

      certutil -dstemplate

    • Um zu bestätigen, dass die SID-Erweiterung gestempelt wird (KB5014754), überprüfen Sie das Register der Zertifizierungsstelle:

      certutil -getreg policy\EditFlags

12. Patch für ESC15 (CVE-2024-49019): Migrieren Sie Schema V1-Vorlagen durch Duplizieren zu V2+. [Reduziert: ESC15]
    • Um die Schemaversion einer Vorlage zu überprüfen (suchen Sie nach msPKI-Template-Schema-Version):

      certutil -dstemplate

    • V1-Vorlagen müssen über certtmpl.msc in V2+ dupliziert werden. Die ursprüngliche V1-Vorlage muss nach der Migration veröffentlicht werden.

      

13. Prüfen Sie jedes msDS-OIDToGroupLink- und altSecurityIdentities-Attribut: Entfernt nicht autorisierte Verknüpfungen und schwache Zuordnungen. [Reduziert: ESC13, ESC14]
14. Deaktivieren Sie den Export des privaten Schlüssels für alle Vorlagen, die keine Portabilität erfordern: [Verringert: Zertifikatsdiebstahl]
    • Dies ist das msPKI-Private-Key-Flag der Vorlage – Bit 0x10 (CT_FLAG_EXPORTABLE_KEY) löschen. Über die grafische Benutzeroberfläche: certtmpl.msc öffnen, mit der rechten Maustaste auf die Vorlage klicken, Eigenschaften, Registerkarte „Anforderungsverarbeitung“, Option „Export des privaten Schlüssels zulassen“ deaktivieren.

      

15. Rollentrennung aktivieren und AD CS niemals auf einem DC zusammenführen: Schützen Sie CA-Schlüssel mit FIPS 140-3 Level 3 HSMs.

    certutil -setreg ca\RoleSeparationEnabled 1 net stop certsvc && net start certsvc

    • Um den aktuellen CSP zu überprüfen:

      certutil -getreg ca\csp

Zertifikatslebenszyklus: Verwaltung von der Ausstellung bis zum Widerruf

Die alleinige Härtung von Templates reicht nicht aus, wenn die Verwaltung des Zertifikatslebenszyklus über die gesamte Lebensdauer des Zertifikats hinweg nicht gewährleistet ist. Das Lebenszyklus-Framework orientiert sich an NIST SP 800-57 §8 (Key Management Lifecycle) und RFC 3647 (Certificate Policy / CPS Framework).

Anmeldekontrollen

Definieren Sie Autorisierungs-Workflows gemäß NIST SP 800-53 IA-5 (Authenticator Management) . Verwenden Sie die automatische Registrierung per Gruppenrichtlinie für Standardzertifikate; für hochwertige Vorlagen ist eine manuelle Anfrage und Genehmigung erforderlich. Für moderne Registrierungsprotokolle sollten Sie EST (RFC 7030) , CMP (RFC 4210) oder ACME (RFC 8555) in Betracht ziehen.

Ausstellungsvalidierung

Die Zertifizierungsstelle sollte Anforderer, Subjektinformationen und SANs validieren. Open-Source-Richtlinienmodule wie TameMyCerts setzen Regeln bei der Ausstellung durch. Für eine Lifecycle-Automatisierung auf Unternehmensebene siehe CertSecure Manager.

Widerruf und Statusprüfung

Pflegen Sie CRL-Verteilungspunkte und OCSP-Responder (RFC 6960) zur Echtzeit-Gültigkeitsprüfung. Überwachen Sie Widerrufsfehler (Ereignis-IDs 4870–4873). Informationen zu OCSP-Stapling und Zertifikatslebensdauern finden Sie im Leitfaden von Encryption Consulting.

Gültigkeitszeiträume und Verlängerung

Die Gültigkeitsdauer öffentlich vertrauenswürdiger TLS-Zertifikate wird gemäß CA/Browser Forum Ballot SC-081v3 schrittweise reduziert : Die maximale Gültigkeitsdauer sank am 15. März 2026 von 398 auf 200 Tage, am 15. März 2027 auf 100 Tage und am 15. März 2029 auf 47 Tage. Dieser Zeitplan gilt für öffentlich vertrauenswürdige Zertifikate. Interne, von AD CS ausgestellte Zertifikate unterliegen den Richtlinien Ihres eigenen CP/CPS, jedoch ist die gleiche Automatisierungspraxis bereits lange vor der internen Implementierung durch die Teams anwendbar. Interne Empfehlungen für von AD CS ausgestellte Zertifikate: 1 Jahr für Benutzer, 2 Jahre für Computer, 5 Jahre für ausstellende Zertifizierungsstelle, 10–20 Jahre für Offline-Root-Zertifikate. Beachten Sie die Richtlinien von NIST SP 800-57 Part 1 zur kryptografischen Gültigkeitsdauer.

Wichtige Archivierungs- und Wiederherstellungsfunktionen

Aktivieren Sie die Schlüsselarchivierung in Verschlüsselungsvorlagen, um die Geschäftskontinuität zu gewährleisten. Benennen Sie Schlüsselwiederherstellungsagenten mit strengen Kontrollen gemäß NIST SP 800-152 (Federal CKMS Profile).

Prüfungsstrategie: Die relevanten Ereignis-IDs

Die Überwachung ist der am meisten vernachlässigte Aspekt des AD CS-Betriebs. Aktivieren Sie die vollständige CA-Überwachung gemäß der Dokumentation der Microsoft Audit Certification Services :

1. CA-Auditfilter festlegen: certutil -setreg ca\auditfilter 127 (alle sieben Kategorien)
2. Unterkategorie „Gruppenrichtlinie aktivieren“: Erweiterte Auditrichtlinien, Objektzugriff, Auditzertifizierungsdienste, Erfolg und Misserfolg

Kritische Ereignis-IDs

Event ID	Beschreibung	Was es zu beachten gilt
4886	Zertifikatsanfrage erhalten	Ungewöhnliche Anforderer-/Vorlagenkombinationen; unerwartete Quell-IPs
4887	Zertifikat genehmigt und ausgestellt	SAN/Anforderer-Konflikt; privilegierte Identitäten im SAN-Feld
4888	Zertifikatsantrag abgelehnt	Wiederholte Ablehnungen können auf ESC7-Angriffe mit anschließender Ablehnung und Genehmigung hindeuten.
4890	CA-Manager-Einstellungen geändert	Nicht autorisierte CA-Konfigurationsänderungen (ESC6, ESC7)
4899/4900	Vorlage geändert / Sicherheitsupdate	Änderungen an Vorlageneigenschaften oder ACLs (ESC4-, ESC5-Erkennung)
4768	Kerberos TGT-Anfrage	PreAuthType=16 = zertifikatbasierte Authentifizierung (RFC 4556 PKINIT); korrelieren mit 4887

Leiten Sie alle CA-Ereignisse an Ihr SIEM-System weiter. Korrelieren Sie diese mit den Erkennungsrichtlinien von MITRE ATT&CK T1649 und den Warnmeldungen von Microsoft Defender for Identity AD CS.

Tools, die Ihre blinden Flecken im AD CS aufdecken

Offensive (Autorisierte Tests)

• Certify 2.0 (SpecterOps): C#-Standard mit Unterstützung für ESC1-ESC16. find /vulnerable listet alle ausnutzbaren Fehlkonfigurationen auf.
• Certipy (Oliver Lyak): Python-basiert, Linux-kompatibel. BloodHound-kompatible JSON-Ausgabe, NTLM-Relay für ESC8.

Defensive

• Schlüsseldienst 2 (Trimarc Security)Erstklassige PowerShell-Überwachung für ESC1-ESC16. Generiert für jeden gefundenen Fehler ein Abhilfeskript.
• PSPKIAudit (SpecterOps): PowerShell-Toolkit für ESC1-ESC8, mit Get-CertRequest für die Reaktion auf Sicherheitsvorfälle.
• BloodHound 5.4+: Vollständige AD CS Knoten-/Kantenintegration (ADCSESC1, ADCSESC3, ADCSESC6a/b, ADCSESC9a/b, ADCSESC10a/b, ADCSESC13, GoldenCert).
• Microsoft Defender für Identität: AD CS-Sensor mit Echtzeit-Haltungsanalyse für ESC1-ESC8, ESC11, ESC15.
• TameMyCertsOpen-Source-CA-Richtlinienmodul, das fehlerhafte Anfragen bereits bei der Ausstellung blockiert. Validiert Subjektnamen, beschränkt SANs und erzwingt Schlüssellängen.
• CertSecure Manager (Verschlüsselungsberatung): Unternehmen Zertifikatslebenszyklusverwaltung Plattform zur automatisierten Erkennung, Registrierung, Verlängerung und zum Widerruf von Zertifizierungen in Multi-CA-Umgebungen.

Die operative Realität: Warum On-Premises AD CS an Boden verliert

AD CS wurde für Windows-zentrierte, lokale Umgebungen entwickelt. Eine detaillierte Analyse der Einschränkungen finden Sie in unserem Blogbeitrag „ Risiken in Active Directory-Zertifikatdiensten minimieren“.

Nicht-Windows-Geräte und BYOD

Die automatische Registrierung funktioniert ausschließlich über Gruppenrichtlinien. macOS, Linux, iOS, Android und ChromeOS bieten keine native Unterstützung. NDES/SCEP ( RFC 5272/CMC ) ist die übliche Lösung, birgt jedoch Sicherheitsrisiken. Moderne Alternativen sind EST (RFC 7030) und ACME (RFC 8555) , die beide nicht nativ von AD CS unterstützt werden.

Remote- und Hybrid-Belegschaft

Die Zertifikatsregistrierung über RPC/DCOM erfordert eine Verbindung zu einem Domänencontroller und einer Zertifizierungsstelle. Remote-Mitarbeiter stoßen auf Probleme bei der Zertifikatserneuerung, wenn das VPN selbst ein gültiges Zertifikat voraussetzt. Zero-Trust-Architekturen (NIST SP 800-207) fordern eine zertifikatbasierte Identität unabhängig vom Netzwerkstandort.

Kosten- und Expertiseaufwand

Die Gesamtbetriebskosten umfassen CA-Hardware, HSMs ( FIPS 140-3- zertifiziert), Windows Server-Lizenzen, Offline-Root-Einrichtungen, spezialisiertes PKI-Personal, CRL/AIA-Infrastruktur und Patch-Tests. Prognosen zufolge verfügen 62 % der Unternehmen im Jahr 2026 nicht über ausreichendes PKI-Know-how.

Entscheidungstabelle: Gehärtetes lokales AD CS vs. Managed PKI vs. Hybrid

Nutzen Sie diese Tabelle, um die Diskussion über Eigenentwicklung, Zukauf oder Mischlösung vor Ihrem nächsten Budgetzyklus zu strukturieren:

Kriterium	Gehärtetes On-Premises AD CS	Managed PKI (PKI-as-a-Service)	Hybrid
Optimale Bildschirmwahl	Domänengebundene Windows-Workloads	BYOD, Multi-OS, Cloud, IoT	Unternehmen, die beides betreiben
Anmeldeverfahren	Kerberos/PKINIT, eingeschränktes SCEP über NDES	Native ACME, EST, SCEP, CMP	Beide werden nach Arbeitslasttyp geroutet.
Bereit für den 47-tägigen Zertifizierungsplan	Erfordert eine kundenspezifische Automatisierungsentwicklung	Automatisierte Ausstellung und Verlängerung integriert	Automatisiert für die über PKIaaS gerouteten Workloads
HSM/Schlüsselschutz	Manuelle Integration; FIPS 140-3 optional	HSM-basiert standardmäßig	Hängt davon ab, welche Zertifizierungsstelle das Zertifikat ausstellt.
Nicht-Windows-/Fernunterstützung	Schwach, erfordert Umgehungslösungen	Ureinwohner	Stark über das PKIaaS-Becken
Typischer TCO-Treiber	Hardware, HSMs, spezialisiertes PKI-Personal	Abonnement; weniger interne PKI-Expertise erforderlich	Beides, aber geringere Grenzkosten
Governance-/Audit-Belastung	Hoch, voll und ganz auf Ihrer Seite!	Mit dem Anbieter geteilt	Aufteilung nach Arbeitsbelastung

Für die meisten Unternehmen, die bereits in AD CS investiert haben, ist der praktikable Weg der Hybridansatz: Beibehaltung einer gehärteten, auditierten AD CS-Bereitstellung für in die Domäne eingebundene Windows-Workloads und Hinzufügen einer verwalteten PKI-Schicht für alles, wofür AD CS nie gut konzipiert wurde.

Der pragmatische Hybridansatz

Die optimale Strategie: gehärtetes AD CS für domänenintegrierte Workloads in Kombination mit einer modernen, verwalteten PKI-Plattform für BYOD, Multi-OS, Cloud-Workloads, IoT/OT und Remote-Mitarbeiter. Informationen zu Hybridarchitekturen finden Sie in der Publikation „PKI Design and Implementation“ von Encryption Consulting .

Sichern Sie Ihre PKI: Wie Verschlüsselungsberatung helfen kann

Die Sicherheit von AD CS-Vorlagen erfordert kontinuierliche Governance, Überwachung und Expertise. Encryption Consulting bietet spezialisiertes PKI-Wissen in den Bereichen Bewertung, Implementierung und Managed Services:

PKI-Bewertungsdienste

Unsere umfassende PKI-Gesundheitsbewertung untersucht jeden Aspekt Ihrer AD CS-Bereitstellung anhand der ESC1-ESC16-Taxonomie, der CISA/NSA-Vorgaben , der NIST SP 800-53-Kontrollen und der Best Practices von Microsoft:

• Prüfung der Zertifikatsvorlage: Systematische Überprüfung der ADCS-Zertifikatvorlagenkonfigurationen und des Nutzungsverhaltens auf ausnutzbare Fehlkonfigurationen.
• CA-Infrastrukturprüfung: Hierarchiedesign, HSM-Konfiguration (FIPS 140-3 Compliance), Rollentrennung, Audit-Protokollierung, CRL/AIA-Status.
• Angriffspfadanalyse: Kartierung jedes ausnutzbaren Pfades gemäß dem Zertifiziertes Gebrauchtgerät Rahmen und MITRE ATT&CK T1649.
• Governance-Lückenanalyse: Bewertung gegenüber NIST-SP 800-57, SP800-152, RFC 3647 (CP/CPS) und CA/Browser-Forum-Grundanforderungen.
• Sanierungsfahrplan: Priorisierte, umsetzbare Empfehlungen mit Implementierungshinweisen und Rücknahmeplänen.

PKI als Service (PKIaaS)

Reduzieren Sie die betriebliche Komplexität und stärken Sie gleichzeitig die Sicherheit mit unserer Managed PKI :

• Cloud-verwaltete Zertifizierungsstelle: Vollständig verwaltet mit HSM-unterstützt Schlüsselschutz, integrierte Redundanz, SLA-gesicherte Verfügbarkeit.
• Multi-Protokoll-Registrierung: Ureinwohner SCEP (RFC 5272), EST (RFC 7030), ACME (RFC 8555), CMP (RFC 4210) Unterstützung für jedes Gerät/Betriebssystem/jede Architektur.
• Automatisiertes Lebenszyklusmanagement: Über CertSecure ManagerEntdeckung, Anmeldung, Verlängerung und Widerruf im gesamten Unternehmen.
• Plattformübergreifende Unterstützung: Windows, macOS, Linux, iOS, Android, ChromeOS, IoT, Cloud-Workloads, einheitliche Managementebene.
• Compliance-fähige Berichterstattung: Abgestimmt mit NIST-SP 800-53, SP800-171, SOC 2, PCI DSS und HIPAA.

Jenseits von Vorlagen: Kryptografische Sicherheitslage und Bereitschaft nach der Quantencomputerzeit

Die Template-Härtung schließt die AD-CS-spezifischen Angriffspfade in diesem Playbook. AD CS ist jedoch nur eine Quelle kryptografischer Risiken in den meisten Unternehmen. Die von AD CS ausgegebenen Zertifikate, Schlüssel und Algorithmen müssen zusammen mit allen anderen kryptografischen Systemen transparent sein, insbesondere im Hinblick auf die zunehmende Verbreitung von Post-Quanten-Algorithmen. Das NIST hat FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) und FIPS 205 (SLH-DSA) im August 2024 finalisiert. Weiterführende Informationen:

• Modernisierung von ADCS: Warum PKI ein einheitliches kryptografisches Statusmanagement benötigt — Ausweitung der AD CS-Governance auf eine kontinuierliche Haltungsmanagementpraxis anstelle einer einmaligen Härtungsmaßnahme.
• Was ist kryptografisches Haltungsmanagement? — die Einführung des Bildungszentrums in die Praxis, in die dieses Handbuch einfließt.
• CBOM Secure — erkennt und inventarisiert die Kryptografie, auf die AD CS und der Rest Ihrer Umgebung angewiesen sind, damit Vorlagenkorrekturen nicht im Verborgenen erfolgen.
• PQC-Bereitschaftsbewertung und PQC Kompetenzzentrum — für die Migrationsplanung gemäß NIST FIPS 203/204/205, da von AD CS ausgestellte RSA- und ECDSA-Zertifikate eine Migration zu Post-Quanten-Algorithmen erfordern.
• Leitfaden zur Migration der Post-Quanten-Kryptographie (9 Phasen) — wobei die von AD CS ausgestellten RSA- und ECDSA-Zertifikate in eine umfassendere Migration hin zu ML-KEM und ML-DSA passen.
• Der kryptographische blinde Fleck — warum kryptografische Assets, die niemals in einer CMDB auftauchen, einschließlich von AD CS ausgestellter Zertifikate auf nicht verwalteten Endpunkten, diejenigen sind, die Angreifer zuerst finden.
• PQC-Migration im Jahr 2026 — ein praktischer Blick darauf, was im Hinblick auf die nahenden Fristen für quantensichere Algorithmen zuerst zu tun ist, was in direktem Zusammenhang mit von AD CS ausgestellten RSA- und ECDSA-Zertifikaten steht.

Die Integrität Ihrer Domain hängt von der Sicherheit Ihrer Zertifikatsinfrastruktur ab. Kontaktieren Sie Encryption Consulting noch heute, um eine PKI-Systemprüfung zu vereinbaren.

Fazit

Fehlkonfigurationen von Zertifikatvorlagen stellen nach wie vor die am meisten unterschätzte Angriffsfläche in Active Directory-Umgebungen von Unternehmen dar. Die ESC-Taxonomie wächst stetig, Red-Team-Tools automatisieren die Ausnutzung von Sicherheitslücken schneller, als die meisten Blue Teams Prüfungen durchführen können, und die regulatorischen Vorgaben von Microsoft, CISA und den Five-Eyes-Partnern haben die Schonfrist aufgehoben.

Die in diesem Leitfaden beschriebenen Verteidigungsmaßnahmen sind nicht nur wünschenswert, sondern bilden die operative Grundlage. Organisationen, die ihre CA-Infrastruktur mit der gleichen Sorgfalt behandeln wie ihre Domänencontroller, werden die Sicherheitslücke schließen. Wer zögert, wird feststellen, dass Angreifer die ungeschützten Bereiche bereits ausgenutzt haben.

Benötigt Ihr Team einen Ausgangspunkt? Der PKI-Health-Check von Encryption Consulting kann Ihnen helfen, die in diesem Playbook beschriebenen Vorgehensweisen zu identifizieren – noch bevor ein Angreifer sie erkennt. Für den bevorstehenden Übergang zur Post-Quanten-Verschlüsselung empfiehlt sich die PQC-Readiness-Analyse , um sicherzustellen, dass Ihre AD-CS-Hierarchie für die von NIST FIPS 203, 204 und 205 (Finalisierung August 2024) geforderten Algorithmus-Umstellungen gerüstet ist.

Dieses Handbuch wird vierteljährlich überprüft, da die ESC-Taxonomie aktiv erweitert wird, der CISA-Beratungs-Update-Plan und der Microsoft KB-Durchsetzungs-Zeitplan entsprechend angepasst werden. Außerdem wird es sofort aktualisiert, sobald ein neuer ESC-Pfad öffentlich dokumentiert oder ein CISA KEV-Eintrag für eine AD CS-bezogene CVE hinzugefügt wird.

Häufig gestellte Fragen

Was ist die wichtigste Erkenntnis aus AD CS Template Hardening: ESC1-ESC16 Defense Playbook?

AD CS-Zertifikatvorlagen sind Active Directory-Objekte. Eine einzige Fehlkonfiguration kann einem Angreifer innerhalb von 60 Sekunden von einem Benutzerkonto ohne Administratorrechte Zugriff auf die Unternehmensadministration ermöglichen, ohne dass herkömmliche Endpunkterkennungsmechanismen ausgelöst werden. Die 15-Punkte-Checkliste in diesem Leitfaden schließt jeden ESC-Pfad mit spezifischen certutil-Befehlen, ACL-Steuerungen und Konfigurationsänderungen. Die Absicherung von Vorlagen ist keine einmalige Angelegenheit, sondern erfordert kontinuierliche Überwachung, da sich Vorlagen mit veränderten Umgebungen verändern.

Warum ist die Härtung von AD CS-Vorlagen für PKI-Teams in Unternehmen wichtig?

CISA und NSA nannten Fehlkonfigurationen von AD CS in ihrer Empfehlung AA23-278A (Oktober 2023) als eine der zehn wichtigsten Cybersicherheitsrisiken und ordneten die CA-Infrastruktur der Stufe 0 zu. Die gemeinsame Empfehlung der Five Eyes (September 2024) erwähnte ESC1 und ESC8 namentlich. Über 70 % der Unternehmen verzeichneten im vergangenen Jahr mindestens einen Ausfall im Zusammenhang mit Zertifikaten (CyberArk 2025 State of Machine Identity Security Report). PKI-Teams, die Zertifikatvorlagen nicht aktiv verwalten, arbeiten mit einer bekannten, dokumentierten Angriffsfläche, die von Red-Team-Tools automatisch erfasst und ausgenutzt werden kann.

Welche Risiken erhöhen sich, wenn die AD CS-Template-Härtung manuell und nicht automatisiert durchgeführt wird?

Die manuelle Vorlagenverwaltung erhöht das Risiko von: Vorlagenabweichungen, bei denen gehärtete Konfigurationen zurückgesetzt oder neue Vorlagen ohne Sicherheitsprüfung erstellt werden; verpassten ESC15-Patches (CVE-2024-49019) für Schema V1-Vorlagen in Multi-CA-Umgebungen; Nichterkennung von ESC4/ESC5-ACL-Missbrauch, da die AD-Objektberechtigungen der Vorlagen nicht kontinuierlich überwacht werden; und der Unfähigkeit, den für die Einhaltung von CISA AA23-278A und NIST SP 800-53 SC-17 erforderlichen Prüfrhythmus beizubehalten, wenn die Umgebungen skalieren.

Welche Teams sollten für die AD CS-Template-Härtung verantwortlich sein?

PKI-Administratoren sind verantwortlich für die Konfiguration der Vorlagen, die Einstellungen der Zertifizierungsstelle (CA) und die Implementierung der 15-Punkte-Checkliste. Sicherheitsarchitekten verantworten die Risikobewertung des ESC und die Klassifizierung der Tier-0-Zertifizierungsstelle. Active Directory-Teams sind verantwortlich für die Vorlagen und die Zugriffskontrolllisten (ACLs) von AD-Objekten der Zertifizierungsstelle. Plattform- und Endpunktteams sind verantwortlich für die Registrierungsrichtlinien und den Geltungsbereich der Gruppenrichtlinienobjekte (GPOs) für die automatische Registrierung. Compliance-Teams sind verantwortlich für die Anforderungen an die Audit-Protokolle und die Nachweise gemäß CISA AA23-278A und NIST SP 800-53 SC-17. CISOs sind verantwortlich für den Risikoregistereintrag für AD CS als Tier-0-Angriffsfläche.

Wie hängt die Härtung von AD CS-Vorlagen mit dem Zertifikatslebenszyklusmanagement zusammen?

Die Template-Härtung definiert die Sicherheitsgrenzen bei der Zertifikatsausstellung. Das Zertifikatslebenszyklusmanagement (CLM) sorgt nach der Ausstellung kontinuierlich für deren Einhaltung. Ohne CLM können selbst perfekt gehärtete Templates zu einer unkontrollierten Zertifikatsflut, Ausfällen durch abgelaufene Zertifikate und verwaisten Zertifikaten mit schwachen Algorithmen führen, die weiterhin als vertrauenswürdig gelten. CertSecure Manager bietet automatisierte Erkennung, Registrierung, Verlängerung und Widerruf von Zertifikaten in Umgebungen mit mehreren Zertifizierungsstellen und stellt so sicher, dass die durch die Template-Härtung bei der Ausstellung verhinderten Sicherheitslücken nicht durch betriebliche Abweichungen wieder entstehen.

Wie sollten Organisationen den Erfolg bei der Härtung von AD CS-Vorlagen messen?

Wichtige Kennzahlen: Anzahl der veröffentlichten Zertifikatvorlagen im Vergleich zu den tatsächlich verwendeten Vorlagen (Ziel: Liste der veröffentlichten Vorlagen entspricht Liste der aktiven Nutzung, keine ungenutzten Vorlagen veröffentlicht); Prozentsatz der Vorlagen, bei denen CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT ohne Genehmigung des Managers aktiviert ist (Ziel: null); Prozentsatz der CA- und Vorlagen-AD-Objekte mit Berechtigungen außer Tier-0 Write/WriteDACL/GenericAll (Ziel: null); Zeit seit dem letzten autorisierten Locksmith- oder PSPKIAudit-Scan (Ziel: unter 90 Tagen); und Anzahl der ESC-Musterbefunde im letzten Audit (Ziel: null).

Was sollte im Hinblick auf die Härtung von AD CS-Vorlagen regelmäßig geprüft oder überwacht werden?

Kontinuierliche Überwachung mittels SIEM: Ereignis-ID 4887 (Zertifikat ausgestellt) bei SAN/Anforderer-Diskrepanzen; Ereignis-ID 4899/4900 (Vorlage geändert/Sicherheit aktualisiert) zur Erkennung von ESC4/ESC5; Ereignis-ID 4890 (CA-Manager-Einstellungen geändert) für ESC6/ESC7; Ereignis-ID 4768 PreAuthType=16 für zertifikatbasierte Kerberos-Authentifizierung. Vierteljährliche Prüfung mit Locksmith 2 oder PSPKIAudit anhand der vollständigen ESC1-ESC16-Checkliste; Überprüfung der CA-Registrierungseinstellungen für EDITF_ATTRIBUTESUBJECTALTNAME2 und IF_ENFORCEENCRYPTICERTREQUEST.

Wie wirkt sich die Härtung von AD CS-Vorlagen auf Cloud-, Hybrid- oder Multi-CA-PKI-Umgebungen aus?

In Umgebungen mit mehreren Zertifizierungsstellen (CAs) muss jede ausstellende CA einzeln geprüft und gehärtet werden. Fehlkonfigurationen von Vorlagen auf einer sekundären oder abteilungsinternen CA sind genauso angreifbar wie auf der primären CA. In hybriden Umgebungen, in denen AD CS und Cloud-native CAs parallel betrieben werden, ermöglicht CBOM Secure die kryptografische Erkennung über alle CA-Quellen hinweg. ESC16 (globale SID-Erweiterung deaktiviert) und ESC10 (schwache Registry-Zuordnung) müssen auf jeder CA in der Hierarchie überprüft werden.

Welche Voraussetzungen müssen vor der Implementierung der AD CS-Template-Härtung erfüllt sein?

Voraussetzungen: Windows Server 2016 oder höher auf allen Zertifizierungsstellen (CAs); alle CAs müssen gegen CVE-2024-49019 (ESC15) und CVE-2022-26923 (Certifried) gepatcht sein; eine vollständige Bestandsaufnahme der CAs mittels `certutil -catemplates`; vollständige CA-Überwachungsprotokollierung aktiviert (`certutil -setreg ca\auditfilter 127`); Locksmith 2 oder PSPKIAudit zur Schwachstellenanalyse vor der Härtung; und Sicherung aller CA-Konfigurationen und AD-Vorlagenobjekte vor Änderungen. Die obige Tabelle der Voraussetzungen ordnet jede Voraussetzung einer Validierungsprüfung und einem häufigen Fehler zu.

Auf welche häufigen Fehler sollten Administratoren beim Härten von AD CS-Vorlagen achten?

Die häufigsten Fehler: Entfernen von CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT aus der WebServer-Vorlage ohne Migration bestehender Clients, was die Erneuerung des Webserver-Zertifikats beeinträchtigt; Deaktivieren von EDITF_ATTRIBUTESUBJECTALTNAME2 ohne Neustart des CA-Dienstes (Änderungen mit certutil erfordern net stop/start certsvc, um wirksam zu werden); Migration einer V1-Vorlage zu V2 durch Duplizierung ohne Deaktivierung der ursprünglichen V1-Vorlage; und Verschärfung der ACLs von Vorlagen ohne Dokumentation der Dienstkonten mit Registrierungsrechten, was zu Registrierungsfehlern bei automatisierten Systemen führt.