AD CS Missbrauch (ESC1/ESC8) & Admin-Rechte — Akuity SOC

In Windows Active Directory-Infrastrukturen bilden die Active Directory Certificate Services (AD CS) das Rückgrat der unternehmensweiten Public-Key-Infrastruktur (PKI). Allerdings bergen fehlerhafte Zertifikatsvorlagen und ungesicherte Web-Endpunkte erhebliche Risiken für Privilege Escalation, erfasst unter der MITRE ATT&CK-Technik T1649. Durch die Ausnutzung von ESC1- und ESC8-Schwachstellen können reguläre Benutzer gefälschte Authentifizierungszertifikate anfordern und in kürzester Zeit vollwertige Domain Admin-Rechte erlangen.

Anatomie der Angriffsvektoren ESC1 und ESC8

Beide Angriffspfade nutzen die Kerberos-Erweiterung PKINIT (Public Key Cryptography for Initial Authentication), um ein X.509-Zertifikat gegen ein privilegiertes Kerberos Ticket Granting Ticket (TGT) einzutauschen:

• ESC1 (Fehlkonfigurierte Zertifikatsvorlagen): Diese Schwachstelle tritt auf, wenn ein Zertifikatstemplate authentifizierten Benutzern Registrierungsrechte gewährt, das Flag CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT gesetzt ist (wodurch der Antragsteller den Subject Alternative Name frei wählen darf) und das EKU für Client-Authentifizierung aktiviert ist. Der Angreifer fordert ein Zertifikat an und trägt als SAN die Identität eines Domain-Admins ein.
• ESC8 (NTLM-Relay gegen AD CS Web Enrollment): Der HTTP-Registrierungsdienst von AD CS (unter http://<CA_SERVER>/certsrv/) verfügt standardmäßig häufig weder über SMB-Signing noch über Extended Protection for Authentication (EPA). Mittels RPC-Zwang (z. B. PetitPotam) veranlasst der Angreifer einen Domänencontroller zur NTLM-Authentifizierung an einem kompromittierten System und leitet diesen Datenstrom per NTLM-Relay an die AD CS-Webschnittstelle weiter, um ein Maschinenzertifikat mit Domain-Controller-Rechten zu erhalten.

Der tote Winkel nativer Sicherheitsüberwachung

Wird das ausgestellte Zertifikat für eine Kerberos AS-REQ-Anfrage verwendet, verbucht das Active Directory die Anmeldung unter regulären Event-IDs (z. B. 4624 oder 4768). Ohne Korrelation mit den Rohdaten aus Defender for Identity und tiefe Einsicht in die Zertifikatsattribute lässt sich ein solcher PKINIT-Angriff kaum von legitimem Smartcard- oder PAW-Verkehr unterscheiden.

Advanced Hunting KQL-Erkennung

Mit der folgenden Advanced Hunting (KQL)-Abfrage in Microsoft Defender XDR identifizieren Sie verdächtige zertifikatbasierte Authentifizierungen privilegierter Konten von nicht autorisierten Arbeitsstationen:

IdentityLogonEvents
| where Protocol == "Kerberos" and ActionType == "LogonSuccess"
| extend ExtFields = todynamic(AdditionalFields)
| where tobool(ExtFields.IsCertBasedAuth) == true
| extend CertThumbprint = tostring(ExtFields.CertThumbprint),
         CertIssuer = tostring(ExtFields.CertIssuer),
         SubjectName = tostring(ExtFields.CertSubjectName)
| where AccountName in~ ("Administrator", "krbtgt") 
     or AccountName endswith "$"
| lookup kind=leftouter (IdentityInfo | summarize AdminGroups = make_set(GroupMembership) by AccountName = AccountUpn) on AccountName
| where AdminGroups has_any ("Domain Admins", "Enterprise Admins") or AccountName endswith "$"
| where not(IPAddress in ("127.0.0.1", "::1") or DeviceName endswith ".paw.domain.local")
| project Timestamp, AccountName, DeviceName, IPAddress, CertThumbprint, CertIssuer, SubjectName, AdminGroups

Automatisierte SOAR-Remediation mit Akuity SOC

Die Abwehr von PKI-Kompromittierungen erfordert präzise Eingriffe, um laterale Bewegungen unverzüglich zu stoppen:

• Auflösung der X.509-Opazität: Der In-App-KI-Assistent von Akuity SOC dekodiert Zertifikatsattribute und PKINIT-Erweiterungen in unter 2 Sekunden direkt im Ticket, ohne dass Daten an externe Web-Decoder übertragen werden (keine CyberChef-Datenlecks).
• 1-Klick-SOAR-Abwehr: Sofortige Ausführung von confirmUserCompromised() und revokeSessions() in Microsoft Entra ID und Active Directory zur Abmeldung des Angreifers, kombiniert mit isolateDevice() über Defender for Endpoint auf dem Quellhost des NTLM-Relays.
• Zero-Trust-Governance: Jede SOAR-Isolierungsmaßnahme erfordert eine starke MFA-AAL2-Bestätigung und generiert ein revisionssicheres Audit-Protokoll gemäß NIS 2 und SOC 2 Type II.

Technische FAQ

Worin besteht der Hauptunterschied zwischen ESC1 und ESC8?

ESC1 beruht auf einer Fehlkonfiguration einer Zertifikatsvorlage, die es Antragstellern gestattet, eine beliebige Identität im SAN-Feld zu definieren. ESC8 ist ein NTLM-Relay-Angriff auf ungeschützte AD CS-HTTP-Webregistrierungsdienste, bei dem Authentifizierungsdaten missbraucht werden, um legitime Maschinenzertifikate anzufordern.

Welche Sofortmaßnahmen sichern Umgebungen gegen ESC8 ab?

Deinstallieren Sie die AD CS-Webregistrierungskomponente (IIS /certsrv), sofern diese nicht zwingend erforderlich ist. Ist der Betrieb notwendig, aktivieren Sie Extended Protection for Authentication (EPA), erzwingen Sie HTTPS mit Channel Binding und deaktivieren Sie NTLM zugunsten von Kerberos.