AD-CS-Zertifikatvorlagen auf ESC1–ESC4 prüfen

Die meisten AD-CS-Kompromittierungen benötigen keinen Bug. Sie benötigen eine einzige Zertifikatvorlage, die es einem Benutzer mit geringen Rechten erlaubt, den Antragsteller seines eigenen Zertifikats zu schreiben — oder eine einzige Vorlagen-ACL, die diesem Benutzer erlaubt, die Vorlage so lange umzuschreiben, bis sie es tut. Die Klassen ESC1 bis ESC4 sind allesamt Probleme auf Vorlagenebene und lassen sich daher allein über LDAP prüfen: Jede relevante Einstellung ist ein Attribut eines pKICertificateTemplate-Objekts in der Konfigurationspartition, und jedes Registrierungsrecht ist ein ACE auf demselben Objekt.

Der Leitfaden zur AD-CS-Härtung erklärt jede ESC-Klasse konzeptionell. Dieser Leitfaden ist das zugehörige Prüfverfahren: ein Inventar der veröffentlichten Vorlagen erstellen, jede Vorlage nach den vier Risikodimensionen bewerten (Kontrolle über den Antragsteller, Authentifizierungs-EKUs, wer sich registrieren kann, wer schreiben kann), sie in sicherer Reihenfolge korrigieren und das Ergebnis überprüfen. CA-weite Einstellungen wie EDITF_ATTRIBUTESUBJECTALTNAME2 und die Webregistrierung werden separat in AD-CS-Webregistrierung absichern behandelt.

Messen: Vorlagen inventarisieren und ermitteln, wo sie veröffentlicht sind

Eine Vorlage spielt für die Registrierung erst eine Rolle, wenn eine CA sie veröffentlicht. Der erste Schritt besteht daher darin, die veröffentlichten Vorlagen von den rund 30 Standardvorlagen zu trennen, die ungenutzt im Verzeichnis liegen. Die Namen veröffentlichter Vorlagen sind im Attribut certificateTemplates des pKIEnrollmentService-Objekts jeder CA gespeichert.

$configNC = (Get-ADRootDSE).configurationNamingContext
$pks      = "CN=Public Key Services,CN=Services,$configNC"
$tplBase  = "CN=Certificate Templates,$pks"
$caBase   = "CN=Enrollment Services,$pks"

# Welche CA veröffentlicht welche Vorlage
Get-ADObject -SearchBase $caBase -LDAPFilter '(objectClass=pKIEnrollmentService)' `
    -Properties dNSHostName, certificateTemplates |
    ForEach-Object {
        foreach ($t in $_.certificateTemplates) {
            [pscustomobject]@{ CA = $_.Name; Host = $_.dNSHostName; Template = $t }
        }
    } | Sort-Object Template | Format-Table -AutoSize

Bewahren Sie diese Ausgabe auf. Sie ist zugleich Ihre Liste der Unternehmens-CAs, die neben den Domänencontrollern in Ihr Tier-0-Inventar gehören.

Auditieren: jede Vorlage nach Antragsteller, EKU und Genehmigung bewerten

Vier Attribute entscheiden, ob eine Vorlage für einen Identitätswechsel genutzt werden kann:

Das folgende Skript kombiniert sie mit den Veröffentlichungsdaten. Eine Vorlage ohne EKU wird als authentifizierungsfähig behandelt, weil ein Zertifikat ohne EKU-Einschränkung für jeden Zweck gültig ist (der ESC2-Fall).

$published = Get-ADObject -SearchBase $caBase -LDAPFilter '(objectClass=pKIEnrollmentService)' `
    -Properties certificateTemplates | ForEach-Object { $_.certificateTemplates } | Sort-Object -Unique

$authEku  = '1.3.6.1.5.5.7.3.2','1.3.6.1.4.1.311.20.2.2','1.3.6.1.5.2.3.4','2.5.29.37.0'
$agentEku = '1.3.6.1.4.1.311.20.2.1'   # Certificate Request Agent (ESC3)

Get-ADObject -SearchBase $tplBase -LDAPFilter '(objectClass=pKICertificateTemplate)' -Properties `
    'msPKI-Certificate-Name-Flag','msPKI-Enrollment-Flag','msPKI-RA-Signature',
    'pKIExtendedKeyUsage','msPKI-Certificate-Application-Policy','msPKI-Template-Schema-Version' |
ForEach-Object {
    $eku = @($_.pKIExtendedKeyUsage) + @($_.'msPKI-Certificate-Application-Policy') |
        Where-Object { $_ } | Sort-Object -Unique
    [pscustomobject]@{
        Template        = $_.Name
        Published       = $published -contains $_.Name
        Schema          = $_.'msPKI-Template-Schema-Version'
        SuppliesSubject = [bool]($_.'msPKI-Certificate-Name-Flag' -band 0x1)
        AuthCapable     = ($eku.Count -eq 0) -or [bool]($eku | Where-Object { $_ -in $authEku })
        RequestAgent    = [bool]($eku -contains $agentEku)
        ManagerApproval = [bool]($_.'msPKI-Enrollment-Flag' -band 0x2)
        RASignatures    = [int]$_.'msPKI-RA-Signature'
        EKUs            = $eku -join ', '
    }
} | Where-Object Published | Sort-Object SuppliesSubject, AuthCapable -Descending | Format-Table -AutoSize

Lesen Sie die Ausgabe so: Sind SuppliesSubject und AuthCapable beide wahr, ohne Genehmigung und ohne RA-Signaturen, ist das ein Lehrbuchkandidat für ESC1: Ob er ausnutzbar ist, hängt nur noch davon ab, wer sich registrieren kann. Ist RequestAgent wahr, liegt ein ESC3-Kandidat vor. Eine leere Spalte EKUs bei einer veröffentlichten Vorlage ist ESC2.

Zwei Sonderfälle verdienen einen Hinweis. Erstens bildeten Vorlagen mit Schemaversion 1 (etwa die integrierte Vorlage WebServer), die einen gelieferten Antragsteller zulassen, die Grundlage von ESC15 (CVE-2024-49019), bei dem Anwendungsrichtlinien in die Anforderung eingeschleust werden konnten; das Sicherheitsupdate vom November 2024 hat dies auf der CA behoben. Vergewissern Sie sich, dass Ihre CAs gepatcht sind, und duplizieren Sie v1-Vorlagen in v2+-Versionen unter Ihrer Kontrolle. Zweitens verleihen Vorlagen, deren Ausstellungsrichtlinie über msDS-OIDToGroupLink mit einer AD-Gruppe verknüpft ist (ESC13), dem Zertifikatinhaber die Mitgliedschaft in dieser Gruppe — prüfen Sie daher alle OID-Objekte von Ausstellungsrichtlinien, die dieses Attribut tragen.

Auditieren: Registrierungsrechte und Vorlagen-ACLs

Die Registrierung ist ein erweitertes Recht auf dem Vorlagenobjekt: Certificate-Enrollment (0e10c968-78fb-11d2-90d4-00c04f79dc55) und Certificate-AutoEnrollment (a05b8cc2-17bc-4802-a710-e7c15ab866a2). Auch GenericAll gewährt die Registrierung. Schreibrechte (WriteProperty, WriteDacl, WriteOwner, GenericWrite, GenericAll) auf der Vorlage sind ESC4: Wer sie besitzt, kann das Antragsteller-Flag einschalten.

$rightNames = @{
    '0e10c968-78fb-11d2-90d4-00c04f79dc55' = 'Enroll'
    'a05b8cc2-17bc-4802-a710-e7c15ab866a2' = 'AutoEnroll'
    '00000000-0000-0000-0000-000000000000' = 'AllExtendedRights'
}
$broad    = '(^|\\)(Everyone|Authenticated Users|Domain Users|Domain Computers|Users)$'
$expected = '(^|\\)(Domain Admins|Enterprise Admins|SYSTEM)$'

Get-ADObject -SearchBase $tplBase -LDAPFilter '(objectClass=pKICertificateTemplate)' |
ForEach-Object {
    $tpl = $_
    (Get-Acl -Path "AD:\$($tpl.DistinguishedName)").Access |
        Where-Object { $_.AccessControlType -eq 'Allow' -and $_.IdentityReference.Value -notmatch $expected } |
        ForEach-Object {
            $r = $_.ActiveDirectoryRights.ToString()
            $kind = if ($r -match 'GenericAll|GenericWrite|WriteDacl|WriteOwner|WriteProperty') { 'WRITE (ESC4)' }
                    elseif ($r -match 'ExtendedRight') { $rightNames[$_.ObjectType.ToString()] }
            if ($kind) {
                [pscustomobject]@{
                    Template  = $tpl.Name
                    Published = $published -contains $tpl.Name
                    Trustee   = $_.IdentityReference.Value
                    Right     = $kind
                    Broad     = $_.IdentityReference.Value -match $broad
                }
            }
        }
} | Sort-Object Published, Right -Descending | Format-Table -AutoSize

Führen Sie beide Ausgaben zusammen. Ganz oben auf der Prioritätenliste steht jede veröffentlichte, authentifizierungsfähige Vorlage, die entweder einen gelieferten Antragsteller erlaubt oder Request-Agent-Zertifikate ausstellt und bei der Broad für ein Enroll-Recht wahr ist. Direkt dahinter folgt jede Zeile WRITE (ESC4) für einen Nicht-Administrator — veröffentlicht oder nicht —, denn Schreibzugriff auf eine Vorlage ist ein latentes ESC1, das nur darauf wartet, genutzt zu werden. Vergessen Sie die Container selbst nicht: Schreibzugriff auf CN=Certificate Templates, CN=Enrollment Services oder das Objekt NTAuthCertificates ist ESC5 und gehört in dieselbe Prüfung, wie in AD-ACLs auditieren beschrieben.

Gegenprüfung mit Locksmith und PSPKIAudit

Zwei auf Verteidiger ausgerichtete PowerShell-Werkzeuge lohnen sich zusätzlich zu Ihren eigenen Skripten. Locksmith (Invoke-Locksmith) meldet im Standardmodus ESC1–ESC8 sowie mehrere spätere Klassen und kann Korrekturskripte erzeugen; prüfen Sie seine Modi, bevor Sie einen ausführen, der Änderungen vornimmt. PSPKIAudit baut auf dem Modul PSPKI auf und ergänzt die Analyse ausgestellter Zertifikate. Offensive Werkzeuge wie Certify und Certipy ermitteln dieselben Daten; wenn Ihr Red Team sie nutzt, gleichen Sie deren Befunde mit Ihrem Inventar ab, statt eines der beiden als maßgeblich zu betrachten. Für die Graphansicht, wer über verschachtelte Gruppen ein Registrierungsrecht erreicht, siehe Angriffspfad-Management mit BloodHound.

Erzwingen: in der am wenigsten störenden Reihenfolge korrigieren

Arbeiten Sie die Befunde in dieser Reihenfolge ab; sie beseitigt pro Änderung das meiste Risiko und legt die wenigsten Arbeitsabläufe lahm.

1. Ungenutzte Vorlagen zurückziehen. Prüfen Sie zuvor in der CA-Datenbank die jüngsten Ausstellungen pro Vorlage (siehe „Überprüfen“ unten). Das Zurückziehen wirkt sofort und ist umkehrbar:

# Auf der CA (Modul ADCSAdministration)
Get-CATemplate | Sort-Object Name
Remove-CATemplate -Name 'LegacyVPNUser' -Force

2. Weit gefasste Registrierungsrechte entfernen. Ersetzen Sie Domänen-Benutzer oder Authentifizierte Benutzer auf sensiblen Vorlagen durch eine dedizierte Gruppe, die nur die Konten oder Computer enthält, die das Zertifikat benötigen. Belassen Sie Read für Authentifizierte Benutzer, damit die automatische Registrierung Vorlagen weiterhin finden kann.
3. Das Flag für den gelieferten Antragsteller entfernen. Öffnen Sie in der Konsole Zertifikatvorlagen (certtmpl.msc) die Vorlage, wechseln Sie zur Registerkarte „Antragstellername“ und wählen Sie „Aus Informationen in Active Directory erstellen“. Die Konsole setzt die passenden Subject- und SAN-Flags korrekt, was sicherer ist, als die Bitmaske direkt zu bearbeiten. Wo ein gelieferter Antragsteller eine echte Anforderung ist (Webserverzertifikate, die ein Bereitstellungssystem anfordert), entfernen Sie die Client-Authentifizierungs-EKUs aus dieser Vorlage und beschränken Sie die Registrierung auf den Bereitstellungsdienst.
4. Genehmigung oder RA-Signaturen hinzufügen bei Vorlagen, die einen gelieferten Antragsteller zusammen mit einer Authentifizierungs-EKU behalten müssen. Aktivieren Sie auf der Registerkarte „Ausstellungsvoraussetzungen“ die Option „CA certificate manager approval“.
5. Schreibrechte entziehen für alle Nicht-PKI-Administratoren und den Besitzer der Vorlage auf Enterprise Admins oder Ihre PKI-Administratorgruppe zurücksetzen.
6. Registrierungs-Agenten einschränken. Beschränken Sie auf der Registerkarte „Registrierungs-Agents“ der CA jeden Agenten auf namentlich benannte Vorlagen und Zielgruppen statt auf den Standard „jeder, alle Vorlagen“.

Änderungen an Vorlagenobjekten werden wie jede andere AD-Änderung über die Konfigurationspartition repliziert; nehmen Sie sie also auf einem DC vor und überlassen Sie den Rest der Replikation.

Überprüfen

Führen Sie beide Prüfskripte erneut aus: Keine veröffentlichte, authentifizierungsfähige Vorlage sollte sowohl SuppliesSubject als auch ein Broad-Enroll-Recht aufweisen, und für Nicht-Administratoren sollten keine Zeilen WRITE (ESC4) mehr übrig sein.

Bestätigen Sie vor und nach jeder Änderung anhand der CA-Datenbank, wer eine Vorlage tatsächlich nutzt:

# In den letzten 90 Tagen aus einer Vorlage ausgestellte Zertifikate (auf der CA ausführen)
$since = (Get-Date).AddDays(-90).ToString('MM/dd/yyyy')
certutil -view -restrict "Disposition=20,NotBefore>=$since" `
    -out "RequestID,RequesterName,CommonName,CertificateTemplate,NotBefore" csv > issued-90d.csv

CertificateTemplate wird bei v2+-Vorlagen als Vorlagen-OID gespeichert; ordnen Sie sie anhand der Ausgabe von certutil -template zu. Aktivieren Sie anschließend die Überwachung von Vorlagenänderungen, damit Abweichungen sichtbar werden. EDITF_AUDITCERTTEMPLATELOAD lässt die CA beim Laden einer Vorlage Ereignis 4898 und bei einer geänderten Vorlage 4899 protokollieren, und eine SACL auf dem Container Certificate Templates liefert Ihnen 5136-Ereignisse mit dem geänderten Attribut:

certutil -setreg policy\EditFlags +EDITF_AUDITCERTTEMPLATELOAD
Restart-Service certsvc

Leiten Sie 4886, 4887, 4899 und 5136 an Ihr SIEM weiter und alarmieren Sie, wenn ein Zertifikat mit einem SAN ausgestellt wird, der nicht zum Antragsteller passt. Der Leitfaden zu Auditing und Erkennung behandelt die Erfassungsseite.

Was dabei ausfallen kann

• Zurückziehen einer Vorlage: Bestehende Zertifikate bleiben bis zu ihrem Ablauf gültig, die Erneuerung schlägt jedoch fehl. Automatisch registrierte Rechner protokollieren beim Erneuerungsversuch Registrierungsfehler im Anwendungsprotokoll (Quelle CertificateServicesClient-AutoEnrollment) — prüfen Sie dieses Protokoll nach jeder Änderung auf einer Stichprobe von Clients.
• Entfernen der Registrierung für Domänen-Benutzer oder Domänencomputer: Die automatische Registrierung endet stillschweigend für alle, die nicht in der neuen Gruppe sind. Befüllen Sie die Ersatzgruppe, bevor Sie den alten ACE entfernen, nicht danach.
• Entfernen des Flags für den gelieferten Antragsteller: Bereitstellungssysteme, MDM-Connectors, Load-Balancer-Appliances und Skripte, die einen CSR mit eigenem Antragsteller einreichen, erhalten stattdessen Zertifikate mit dem aus AD abgeleiteten Antragsteller oder scheitern ganz. Stellen Sie ihnen eine dedizierte Vorlage ohne Client-Authentifizierungs-EKUs bereit.
• Genehmigung durch die Zertifikatverwaltung: Anforderungen bleiben ausstehend, bis ein Zertifikatverwalter handelt, was eine unbeaufsichtigte Registrierung unmöglich macht. Verwenden Sie sie nur bei Vorlagen mit geringem Volumen.
• Einschränken der Registrierungs-Agenten: Mitarbeiter der Smartcard-Ausgabe können sich nur noch für die aufgeführten Vorlagen und Gruppen registrieren, sodass neue Kartentypen eine Änderung der CA-Konfiguration erfordern.

Weiterführend: der Themenbereich AD-Zertifikatdienste, starke Zertifikatzuordnung für die KDC-Seite der zertifikatbasierten Authentifizierung und Angriffspfad-Management, um herauszufinden, wer ein Registrierungsrecht indirekt erreicht.