Huy Kha | Senior Architekt für Identität und Sicherheit

Die Ausweitung von Privilegien in Active Directory (AD) ermöglicht es Cyber-Angreifern, den Zugriff auf die Umgebung zu erweitern und möglicherweise ganze Netzwerke zu kompromittieren - und das unbemerkt. Die Enterprise CA Security Configuration (ESC1) ist eine Angriffsmethode, die immer beliebter wird, da sie es böswilligen Akteuren ermöglicht, über ein Tool, das eigentlich dazu gedacht ist, Administratoren das Leben zu erleichtern, privilegierten Zugriff zu erlangen: Zertifikatsvorlagen.

Was ist ein ESC1-Angriff?

Zertifikatsvorlagen vereinfachen die Verwaltung von Active Directory Certificate Services (AD CS) Zertifizierungsstellen (CAs), indem sie einen vorkonfigurierten Satz von Regeln und Einstellungen bereitstellen, die auf eingehende Zertifikatsanforderungen angewendet werden. Sie bieten Administratoren eine Möglichkeit, die Zertifikatsverwaltung zu rationalisieren und die Konsistenz bei der Anwendung von Zertifikatsrichtlinien sicherzustellen.

Allerdings können Zertifikatsvorlagen auch missbraucht werden.

Bei einem ESC1-Angriff nutzt ein Angreifer eine falsch konfigurierte Enterprise CA-Zertifikatsvorlage in AD CS aus, um ein Zertifikat für ein hochprivilegiertes Konto anzufordern - zum Beispiel Domain Admin. Dann verwenden sie dieses Zertifikat, um als dieses Konto zu agieren und so unberechtigte Kontrolle zu erlangen.

Wie funktioniert ein ESC1-Angriff?

Um einen ESC1-Angriff durchzuführen, muss ein böswilliger Akteur AD CS ausführen und die Erlaubnis haben, sich bei einer falsch konfigurierten Zertifikatsvorlage anzumelden.

Der Angreifer sucht nach einer verwundbaren Zertifikatsvorlagenkonfiguration(Abbildung 1) mit:

  • Aktivieren Sie die Einstellung In Anfrage liefern, die es dem Angreifer ermöglicht, ein Zertifikat für jedes Konto anzufordern.
  • Erweiterte Schlüsselverwendung (EKU) Erweiterungen wie z.B. Client Authentication, PKINIT Client Authentication, Smart Card Logon, Any Purpose-oder keine EKU (wie z.B. SubCA)
Abbildung 1. Anfällige Zertifikatsvorlage, die es einem Angreifer ermöglicht, sich als jeder Benutzer innerhalb der Domäne auszugeben

Wenn diese Bedingungen erfüllt sind, kann der Angreifer ein Zertifikat für ein beliebiges Konto in der Domäne anfordern(Abbildung 2) und es dann verwenden, um sich als dieses Konto auszugeben.

Abbildung 2. Anforderung eines Zertifikats im Namen eines bestimmten Kontos

Wie können Sie sich gegen einen ESC1-Angriff verteidigen?

Wenn Ihre Organisation über Zertifikatsvorlagen verfügt, die Subject Alternative Names (SANs) zulassen und Folgendes unterstützen Client Authentication EKUs, könnten sie für einen ESC1-Angriff anfällig sein.

Um sich davor zu schützen, befolgen Sie diese praktischen Schritte:

  • Prüfen Sie Zertifikatsvorlagen: Überprüfen Sie alle Ihre Zertifikatsvorlagen und identifizieren Sie diejenigen, die SANs zulassen und EKU-Erweiterungen wie z.B.:
    • Client Authentication (1.3.6.1.5.5.7.3.2)
    • PKINIT Client Authentication (1.3.6.1.5.2.3.4)
    • Smart Card Logon (OID 1.3.6.1.4.1.311.20.2.2)
    • Any Purpose (OID 2.5.29.37.0)
    • Oder Vorlagen ohne EKU (wie z.B. SubCA)
  • Begrenzen Sie, wer sich anmelden kann: Stellen Sie sicher, dass nur die Benutzer oder Gruppen, die wirklich Zugang benötigen, sich für Zertifikate mit diesen Vorlagen anmelden können. Die Einschränkung des Zugriffs trägt dazu bei, dass möglichst wenige Personen die Vorlagen ausnutzen können.
  • Erfordert die Genehmigung des CA-Managers: Für alle Zertifikatsvorlagen, die SAN erlauben und unterstützen Client Authenticationaktivieren Sie die Genehmigung durch den CA-Zertifikatsmanager. Das bedeutet, dass jemand jede Anfrage genehmigen muss, bevor ein Zertifikat ausgestellt wird.
  • Deaktivieren Sie nicht verwendete Vorlagen: Wenn bestimmte Zertifikatsvorlagen nicht verwendet werden, deaktivieren Sie sie oder passen Sie sie an, um riskante Konfigurationen zu entfernen. Deaktivieren Sie z. B. die Einstellung In Anforderung liefern, damit Benutzer keine Zertifikate für andere Konten anfordern können.

Verteidiger können die kostenlose Purple Knight AD-Sicherheitsbewertungstool verwenden, um unsichere Zertifikatsvorlagen zu identifizieren und Maßnahmen zu ergreifen, um diese zu beheben(Abbildung 3).

Abbildung 3. Purple Knight Tool zeigt verwundbare Zertifikatsvorlagen

Verteidiger können auch verwenden Invoke-Locksmith1 (Abbildung 4), um unsichere Zertifikatsvorlagen schnell zu identifizieren und Maßnahmen zu ergreifen, um sie zu beheben. Das Locksmith PowerShell-Skript enthält eine Option für die automatische Korrektur, aber es ist wichtig, dass Sie alles gründlich testen und überprüfen, bevor Sie irgendwelche Korrekturmaßnahmen ergreifen.

Eine großartige Funktion von Invoke-Locksmith ist, dass sie auch Folgendes umfasst Invoke-RevertLocksmithDadurch kann eine Organisation Änderungen leicht rückgängig machen, wenn sie negative Auswirkungen bemerkt. Dies bietet eine zusätzliche Sicherheit bei der Anpassung von Zertifikatsvorlagen.

Abbildung 4. Abhilfe für anfällige Zertifikatsvorlagen mit Invoke-Locksmith

Wie Sie ESC1-Angriffe erkennen

In einer großen Unternehmensumgebung kann es eine Herausforderung sein, böswillige Anfragen an anfällige Zertifikatsvorlagen zu erkennen. Die Ereignis-IDs 4886 und 4887 können zwar zeigen, welcher Benutzer ein Zertifikat angefordert hat, aber sie verraten nicht den Wert, den ein Angreifer in der subjectAltName um sich als ein bestimmtes Konto auszugeben.

Aus forensischer Sicht werden alle Zertifikatsanforderungen protokolliert (Abbildung 5) und kann in der Benutzeroberfläche der Zertifizierungsstelle unter Ausgestellte Zertifikate angezeigt werden. Dieser Abschnitt zeigt, wenn eine Zertifikatsanforderung Werte wie die in der subjectAltNamezusammen mit anderen wichtigen Details, z.B. wer die Anfrage gestellt hat, welche Zertifikatsvorlage verwendet wurde, die EKU und die entsprechenden Zeitstempel. Diese Protokolle sind hilfreich, um verdächtige Zertifikatsanfragen zu untersuchen und zurückzuverfolgen.

Abbildung 5. Zertifikate, die vom CA-Server ausgestellt wurden

Profile von Bedrohungsakteuren

Die folgenden Bedrohungsakteure haben ESC1-Angriffe in freier Wildbahn ausgeführt:

  • UNC53302
  • APT293

ESC1 Werkzeuge

Die folgenden öffentlichen Tools zum Missbrauch von Active Directory-Zertifikaten können zur Durchführung eines ESC1-Angriffs verwendet werden:

  • Zertifizieren Sie
  • Certipy

Überblick über die Bedrohung

ATT&CK-Taktik: Privilegienerweiterung

Am 4. April 2024 veröffentlichte Google Cloud einen Bericht, der beschreibt, wie der Bedrohungsakteur UNC5330 die Schwachstellen CVE-2024-21893 und CVE-2024-21887 in Ivanti Connect Secure ausnutzte, um in das Netzwerk eines Opfers einzudringen. Sie verwendeten ein LDAP-Bind-Konto, um eine anfällige Windows-Zertifikatsvorlage auszunutzen, ein Computerobjekt zu erstellen und sich als Domänenadministrator auszugeben.4

Am 28. April 2022 meldete Mandiant, dass APT29 falsch konfigurierte Zertifikatsvorlagen ausnutzte, um sich als Admin-Benutzer auszugeben. Durch den Missbrauch dieser Fehlkonfigurationen in AD CS war der Angreifer in der Lage, Zertifikate als niedrigprivilegierte Benutzer anzufordern und hochprivilegierte Konten im Feld Subject Alternative Name (SAN) anzugeben. Dies ermöglichte es ihnen, sich als diese hochprivilegierten Benutzer zu authentifizieren.5

Semperis Schnappschuss

AD CS sollte als Aktivposten der Stufe 0 behandelt werden, da es direkte Kontrolle über die Sicherheit Ihrer gesamten Active Directory-Umgebung hat. Wenn AD CS kompromittiert wird, können Angreifer Zertifikate ausstellen, die es ihnen ermöglichen, sich als hochprivilegierte Konten auszugeben, Sicherheitskontrollen zu umgehen und vollständigen Zugriff auf sensible Systeme zu erhalten.

Erfahren Sie mehr über Privilegieneskalation in AD

Endnoten

  1. https://github.com/jakehildreth/Locksmith/tree/main
  2. https://malpedia.caad.fkie.fraunhofer.de/actor/unc5330
  3. https://malpedia.caad.fkie.fraunhofer.de/actor/apt29
  4. https://cloud.google.com/blog/topics/threat-intelligence/ivanti-post-exploitation-lateral-movement
  5. https://cloud.google.com/blog/topics/threat-intelligence/tracking-apt29-phishing-campaigns