AD-CS-Missbrauch erkennen: ESC1 bis ESC16, Zertifikate und der Weg zu Domain Admin

AD-CS-Missbrauch erkennen ist eine der wirkungsvollsten Erkennungen überhaupt, weil die Technik so zuverlässig und zugleich so leise ist. Ein Angreifer, der bereits ein gewöhnliches Domänenkonto und einen Fuß im Netz hat, braucht keine Schwachstelle und keinen Exploit: Er nutzt eine Fehlkonfiguration der Zertifizierungsstelle, lässt sich ein Zertifikat ausstellen, das auf ein höher privilegiertes Konto lautet, und meldet sich damit an. Das Ergebnis ist Rechteausweitung bis hin zu Domain Admin, und weil ein Zertifikat lange gültig ist und von einem Passwortwechsel unberührt bleibt, ist es zugleich eine dauerhafte Hintertür. Dieser Beitrag aus der Serie „Angriff erkennen“ nimmt sich das Thema ausführlich vor: die drei Angriffsfamilien aus Verteidigersicht, eine vollständige Referenz aller Varianten von ESC1 bis ESC16, die Logquellen, das Muster im Log, drei Sigma-Regeln, die Härtung und der Test. Die Grundlagen zur Absicherung des Verzeichnisses stehen unter Active Directory härten.

Was der Angreifer tut

So unterschiedlich die Nummern ESC1 bis ESC16 wirken, für die Erkennung lassen sie sich auf drei Familien zusammenfassen, und jede hinterlässt eine andere Spur. Bewusst auf der Ebene des Prinzips, nicht als Anleitung:

• Zertifikat mit falschem Inhaber (Enrollment- und Mapping-Missbrauch). Eine Zertifikatvorlage erlaubt es dem Antragsteller, den Inhaber selbst zu bestimmen, etwa über einen mitgelieferten Subject Alternative Name (SAN). Ein normaler Benutzer beantragt dann ein Zertifikat, in dessen SAN der Name eines Domain Admins steht, und authentifiziert sich damit. Hierher gehören ESC1, ESC2, ESC3 sowie die Mapping-Varianten ESC9, ESC10, ESC13, ESC14 und ESC15. Die Spur ist die Zertifikatsanfrage auf der CA und die anschließende zertifikatbasierte Anmeldung.
• Zertifizierungsstelle oder Vorlage umkonfiguriert (Fehlkonfiguration und ACL). Statt eine bestehende Fehlkonfiguration zu nutzen, schafft der Angreifer sie: Er ändert mit zu weit vergebenen Rechten eine Vorlage so, dass der erste Fall möglich wird, oder setzt auf der CA ein gefährliches Flag. Hierher gehören ESC4 (Schreibrechte auf eine Vorlage), ESC5 (Schreibrechte auf AD-CS-Objekte), ESC6 und ESC16 (gefährliches CA-Flag) sowie ESC7 (missbrauchbare CA-Rollenrechte). Die Spur ist die Änderung an Vorlage oder CA.
• NTLM-Relay auf die Enrollment-Schnittstelle (Relay). Die CA bietet Schnittstellen für die Zertifikatsanfrage über HTTP (Web Enrollment) oder RPC an. Ein Angreifer zwingt ein privilegiertes Konto, meist ein Computerkonto, zu einer NTLM-Authentifizierung und leitet diese an die CA weiter, um in dessen Namen ein Zertifikat zu beantragen. Hierher gehören ESC8 (HTTP) und ESC11 (RPC). Die Spur ist die NTLM-Anmeldung und eine Zertifikatsanfrage von einem Konto, das sonst keine stellt.

Der gemeinsame Nenner aller drei Familien ist das ausgestellte Zertifikat und seine spätere Nutzung zur Anmeldung. Wer diese beiden Punkte überwacht, erkennt den Großteil der Varianten, unabhängig davon, welche Fehlkonfiguration im Einzelfall ausgenutzt wurde.

Die Varianten ESC1 bis ESC16 im Überblick

Die folgende Referenz fasst alle bekannten Varianten knapp zusammen: das Prinzip in einem Satz und die Erkennungsfamilie, über die sie sichtbar wird. Sie ersetzt keine 16 Einzelartikel, weil sich die Erkennung, wie oben gezeigt, auf drei Muster bündelt. Für die Prüfung der eigenen Umgebung auf diese Fehlkonfigurationen eignen sich die weiter unten genannten Werkzeuge.

Wichtig für die Praxis: Nicht jede Variante ist in jeder Umgebung vorhanden. Die meisten Netze haben eine Handvoll, oft ESC1, ESC6 oder ESC8. Deshalb steht am Anfang die Inventur mit einem Prüfwerkzeug, danach die gezielte Erkennung und Härtung der tatsächlich vorhandenen Schwächen.

Welche Logquellen die Technik zeigt

Die Tabelle zeigt, wo die Überwachung ansetzen muss: auf dem CA-Server, der 4886, 4887 und die CA-Ereignisse schreibt, und auf dem Domain Controller, der die zertifikatbasierte Anmeldung und die NTLM-Authentifizierung protokolliert. Beide sind in vielen Umgebungen nicht vollständig angebunden. Die Felder zu den Ereignissen stehen in der Referenz zu den Event-IDs.

Das Muster im Log

Drei Signale decken die drei Familien ab, und das stärkste ist das erste.

• Antragsteller und Inhaber passen nicht zusammen. Das Kernsignal gegen die größte Familie: In 4886 und 4887 liefert der Antragsteller einen eigenen SAN mit, in dem der UPN eines anderen, oft privilegierten Kontos steht. Ein normaler Benutzer, der ein Zertifikat für administrator@firma.local beantragt, ist fast immer ein Angriff. Webserver-Zertifikate tragen DNS-Namen im SAN, kein upn=; die Unterscheidung ist die Trennschärfe.
• Eine zertifikatbasierte Anmeldung, die nicht zum Konto passt. Kurz nach der Ausstellung meldet sich das Zielkonto per Kerberos mit dem Zertifikat an (4768, PreAuthType 15), oft von einem Client, von dem dieses Konto sich sonst nie anmeldet. Wenn sich ein Domain Admin, der nie eine Smartcard nutzt, plötzlich zertifikatbasiert anmeldet, ist das ein Alarm.
• Eine Änderung an Vorlage oder CA. Gegen die Fehlkonfigurationsfamilie zeigt 5136 Änderungen an den Berechtigungen oder Flags einer Zertifikatvorlage, und die CA-Ereignisse 4899 und 4900 zeigen Änderungen an der CA selbst. Solche Änderungen sind selten und gehören jede einzeln geprüft.

Jedes Signal für sich ist schon aussagekräftig, weil die legitimen Fälle gut abgrenzbar sind. Zusammen, über die RequestId von der Anfrage zur Anmeldung verknüpft, ergeben sie ein lückenloses Bild des Angriffs.

Drei Sigma-Regeln

Die erste Regel fängt den SAN-Missbrauch, die zweite die Änderung an einer Vorlage, die dritte die zertifikatbasierte Anmeldung. Die Relay-Familie (ESC8, ESC11) ist über eine einzelne Regel schwer zu fassen und steht im Abschnitt zur Härtung; der verlässlichste Hinweis ist dort eine Zertifikatsanfrage von einem Computerkonto in Kombination mit einer NTLM-Anmeldung in 8004.

title: AD CS Zertifikat mit mitgeliefertem UPN im SAN (ESC1 und verwandt)
id: 3a9d1e7c-5b24-4f08-9a16-2c7e4d8b6f10
status: experimental
description: Erkennt Zertifikatsanfragen und -ausstellungen, bei denen der
  Antragsteller einen eigenen Subject Alternative Name mit einem UPN mitliefert.
  Typisch fuer ESC1 und verwandte Varianten mit Werkzeugen wie Certipy. Webserver-
  und Geraetevorlagen liefern DNS-SANs statt upn= und werden nicht erfasst.
references:
  - https://attack.mitre.org/techniques/T1649/
author: blue-team.net
tags:
  - attack.credential-access
  - attack.t1649
logsource:
  product: windows
  service: security
  definition: 'Audit Certification Services auf der CA plus CA-Auditfilter (certutil -setreg CA\\AuditFilter 127)'
detection:
  selection:
    EventID:
      - 4886
      - 4887
    Attributes|contains: 'upn='
  condition: selection
falsepositives:
  - Seltene Vorlagen, bei denen ein UPN-SAN legitim mitgegeben wird; einzeln pruefen
level: high

title: AD CS Zertifikatvorlage oder Berechtigung geaendert (ESC4 und verwandt)
id: 5e8b2c41-7a93-4d6f-b015-9c3e7f1a2d84
status: experimental
description: Erkennt Aenderungen an einer Zertifikatvorlage im Verzeichnis, etwa
  an den Berechtigungen oder den Enrollment-Flags. So werden Vorlagen angreifbar
  gemacht (ESC4). Aenderungen sind selten und einzeln zu pruefen.
references:
  - https://attack.mitre.org/techniques/T1649/
author: blue-team.net
tags:
  - attack.credential-access
  - attack.privilege-escalation
  - attack.t1649
logsource:
  product: windows
  service: security
  definition: 'Audit Directory Service Changes auf dem Domain Controller'
detection:
  selection:
    EventID: 5136
    ObjectClass: 'pKICertificateTemplate'
    AttributeLDAPDisplayName:
      - 'nTSecurityDescriptor'
      - 'msPKI-Certificate-Name-Flag'
      - 'msPKI-Enrollment-Flag'
      - 'msPKI-Certificate-Application-Policy'
  condition: selection
falsepositives:
  - Dokumentierte Pflege der PKI durch das AD-Team im Wartungsfenster
level: high

title: Zertifikatbasierte Kerberos-Anmeldung (PKINIT) zur Pruefung
id: 9c4f6a2d-1e85-4b73-8d09-6f2a3c7e5b41
status: experimental
description: Markiert zertifikatbasierte TGT-Anforderungen (PKINIT) ueber
  PreAuthType 15. In Umgebungen ohne Smartcards ein starkes Signal; mit
  Smartcards die bekannten Nutzer und Konten herausfiltern und auf privilegierte
  Konten sowie untypische Clients achten.
references:
  - https://attack.mitre.org/techniques/T1649/
author: blue-team.net
tags:
  - attack.credential-access
  - attack.t1649
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4768
    PreAuthType: 15
  condition: selection
falsepositives:
  - Regulaere Smartcard-Anmeldungen; bekannte Smartcard-Nutzer und -Konten ausnehmen
level: medium

Wie die Regeln ins eigene SIEM übersetzt werden, steht im Beitrag zu Sigma-Regeln; die Übersetzung nach KQL für Microsoft-Umgebungen im Beitrag zu Kusto. Alle drei setzen voraus, dass die CA-Auditierung und die Verzeichnisüberwachung aktiv sind, siehe den Abschnitt zum Test.

Härtung: der Angriff, der gar nicht erst gelingt

AD CS ist der seltene Fall, in dem die Härtung einfacher ist als die Erkennung, weil die meisten Varianten auf wenige konkrete Fehlkonfigurationen zurückgehen. Die wirksamsten Maßnahmen:

• Vorlagen entschärfen. Bei Vorlagen, die Client-Authentifizierung erlauben, den frei wählbaren SAN abschalten (kein ENROLLEE_SUPPLIES_SUBJECT) und die Freigabe der Antragstellung (Manager Approval) aktivieren. Das schließt ESC1 und verwandte Varianten.
• CA-Flags prüfen. Das Flag EDITF_ATTRIBUTESUBJECTALTNAME2 auf der CA deaktivieren (gegen ESC6) und die Security-Extension aktiviert lassen (gegen ESC9 und ESC16). Beides lässt sich mit certutil abfragen.
• Berechtigungen begrenzen. Enrollment-Rechte und vor allem Schreibrechte auf Vorlagen und AD-CS-Objekte eng halten (gegen ESC4, ESC5, ESC7). Niemand außer der PKI-Verwaltung sollte Vorlagen ändern dürfen.
• Relay abstellen. Die HTTP-Web-Enrollment-Schnittstelle nur mit HTTPS und Extended Protection for Authentication (EPA) betreiben oder ganz abschalten (gegen ESC8); NTLM wo möglich ablösen und die RPC-Schnittstelle absichern (gegen ESC11). Die NTLM-Grundlagen dazu stehen unter Event 8004.
• Starkes Mapping erzwingen. Die Zuordnung von Zertifikat zu Konto auf die starke, SID-basierte Variante stellen (gegen ESC9, ESC10, ESC14), wie es die Härtung seit 2022 ohnehin verlangt.

Nach diesen Schritten scheitern die meisten Varianten, und die wenigen verbliebenen erzeugen beim Versuch genau die Ereignisse, auf die die drei Regeln zielen. Erkennung und Härtung greifen hier ineinander, beschrieben auch unter Active Directory härten.

Der Test

Dafür ist ein Lab mit einem Domain Controller und einem CA-Server gedacht; der Test gehört ausschließlich dorthin, niemals in eine Produktivumgebung. Der erste Schritt ist die Inventur: Werkzeuge wie Certipy oder das PowerShell-Modul Locksmith prüfen die eigenen Vorlagen und die CA auf ESC1 bis ESC16 und zeigen, welche Varianten überhaupt vorhanden sind. Das ist zugleich die wichtigste Übung, weil sie die Angriffsfläche sichtbar macht. Zum Prüfen der Erkennung wird im Lab eine bekannte Schwäche nachgestellt und ein Zertifikat mit abweichendem SAN beantragt. Erwartet werden auf der CA 4886 und 4887 mit dem mitgelieferten SAN, auf dem Domain Controller 4768 mit PreAuthType 15 für das Zielkonto und, bei einer geänderten Vorlage, 5136 auf das Vorlagenobjekt. Die drei Sigma-Regeln müssen treffen. Voraussetzung ist, dass die CA-Auditierung (Audit Certification Services plus CA-Auditfilter) und die Verzeichnisüberwachung aktiv sind; fehlt eine davon, entstehen die Ereignisse gar nicht erst. Ergebnis und Datum in den ATT&CK-Navigator, und weil AD CS einer der verlässlichsten Wege zu Domain Admin ist, gehört diese Prüfung in jede Purple-Team-Übung.

Fehlalarme und Tuning

• Autoenrollment. Computer und Benutzer beziehen per Autoenrollment laufend Zertifikate. Diese Anfragen tragen keinen mitgelieferten UPN-SAN und werden von der ersten Regel nicht erfasst; falls doch einzelne Vorlagen einen SAN mitgeben, kommen sie namentlich auf die Ausnahmeliste.
• Webserver- und Gerätezertifikate. Sie tragen DNS-Namen im SAN, kein upn=. Die erste Regel filtert bewusst auf upn=, um sie auszuschließen. Taucht ein legitimer Sonderfall auf, wird die betreffende Vorlage ausgenommen, nicht die Regel.
• Smartcard-Umgebungen. Wo Smartcards im Einsatz sind, ist PKINIT normal, und die dritte Regel erzeugt Rauschen. Dann werden die bekannten Smartcard-Nutzer und -Konten herausgefiltert, und der Fokus liegt auf zertifikatbasierten Anmeldungen privilegierter Konten und auf untypischen Clients.
• PKI-Pflege. Das AD-Team ändert gelegentlich Vorlagen. Solche Änderungen sind geplant, selten und nachvollziehbar; sie werden einzeln geprüft und mit dem Wartungsfenster abgeglichen, nicht pauschal gefiltert.
• Die Gegenmaßnahme, die die Regeln entlastet. Jede im Härtungsabschnitt geschlossene Variante ist eine, die keine Fehlalarme mehr erzeugen und keinen Treffer mehr ermöglichen kann. Die Reihenfolge ist deshalb immer: zuerst inventarisieren und härten, dann die verbliebene Restfläche überwachen.

Fazit

AD-CS-Missbrauch ist der Weg, auf dem ein Angreifer mit einem einfachen Benutzerkonto und ohne Exploit zum Domain Admin wird, und das ausgestellte Zertifikat ist zugleich seine Hintertür für die Zeit danach. So viele Varianten es von ESC1 bis ESC16 gibt, für die Erkennung bündeln sie sich auf drei Muster: der mitgelieferte SAN in 4886 und 4887, die zertifikatbasierte Anmeldung in 4768 und die geänderte Vorlage in 5136. Wer die CA- und Verzeichnisüberwachung einschaltet, die eigene PKI mit einem Prüfwerkzeug inventarisiert, die gefundenen Schwächen härtet und die drei Regeln im Lab gegen eine echte Ausstellung prüft, schließt den verlässlichsten Weg nach oben, den eine Windows-Domäne kennt. Für ein Blue Team ist AD CS damit kein blinder Fleck mehr, sondern eine der dankbarsten Erkennungen überhaupt.