Blog

ADCS Relaying

10.8.2021 | 6 minutes read

Tags: relaying, adcs, certificates, windows

Im vergangenen Monat sorgte ein Paper von SpectrOps und einige Ankündigungen für Aufsehen in der IT-Security Community. Sie hatten eine Reihe an mehr oder minder bekannten Konfigurationsfehler, die beim Active Directory Certificate Service (ADCS) in der Praxis vorkommen, zusammengefasst und der Öffentlichkeit vorgestellt. Das Paper könnt ihr hier und die Ankündigung könnt ihr hier finden.

In diesem Blogpost möchte ich ein Auge ESC8 - NTLM Relay to AD CS HTTP Endpoints werfen. Einen bereits existierenden Blogeintrag auf Englisch vom Entwickler des dafür notwendigen Codes könnt ihr hier finden.

Hintergrund

Hintergrund Relaying

Das Thema NTLM-Relaying habe ich bereits im Eintrag Microsoft Security Baseline Review kurz angerissen. Weiterhin findet ihr alles zu NTLM-Relay hier. Im Grunde geht es bei NTLM-Relaying darum die eingehnde Verbindung von einem System oder Benutzer, der/das bereits Mitglied einer Domäne ist, entgegen zunehmen und das Gerät einer Anmeldung mittels NTLM aufzufordern. NTLM ist ein Challenge-Response Protokoll, das es ermöglicht eine Anmeldung durchzuführen ohne das Passwort an das Zielsystem zu senden. Der Nachteil an dem Protokoll ist, dass es keinen Integritätsschutz besitzt. Wenn das darunterliegende Protokoll wie SMB mit Standardeinstellungen ebenfalls kein Integritätsschutz besitzt, so kann dies ein Angreifer zu seinem Vorteil nutzen.

Der Angreifer kann eine eigene NTLM-Sitzung zu seinem Zielsystem aufbauen und anstatt die Challenge selber zu lösen, übergibt er sie weiter an ein anderes System, welches gerne eine Anmeldung beim Angreifer durchführen würde. Folgendes Schaubild verdeutlicht das Vorgehen:

NTLM-Relaying

Rechts ist das System, welches gerne eine Verbindung zum Angreifer in der Mitte aufbauen würde. In der Mitte ist der Angreifer und links ist das Zielsystem, auf das der Angreifer gerne zugriff hätte.

Hintergrund ADCS Webenrollment

Die Enterprise CA von Microsoft bietet mehrere Möglichkeiten an, wie Benutzer und Computer ein Zertifikat beantragen und erhalten können. Neben zahlreichen RPC-Varianten (furchtbar kompliziertes Zeug) gibt es auch die Möglichkeit Zertifikate über ein Web-Interface zu erhalten. Dafür muss die Rolle “Certificate Authority Web Enrollment” installiert sein. Dann kann ein Zertifikat auch bequem per POST-Request beantragt und ausgestellt werden. Zur Anmeldung bietet der Dienst die Standard-Windowsanmelde Möglichkeiten, also Kerberos mit Fallback auf NTLM, an.

In der Standeinstellung verwendet der Web Enrollement Server nur das HTTP Protokoll. HTTPS muss extra konfiguriert werden. Im Grunde ist HTTP (wenn es NTLM-Relaying nicht gäbe) in dem Szenario nichts Schlimmes. Ein Angreifer, der die Verbindung mitliest, kann weder etwas mit den Anmeldedaten anfangen - Kerberos ist verschlüsselt und NTLM ein Challenge-Response Protokoll - und selbst wenn er das Zertifikat on-the-fly verändert und abfängt, fehlt ihm immer noch der dazu gehörende private Schlüssel. Ein Problem bezüglich HTTP entsteht hier erst in Kombination mit NTLM-Relay. Da, wie bereits erwähnt, weder NTLM noch HTTP über einen Integritätsschutz verfügt, ist der Angriff erst möglich.

Angriff

Reconnaissance

Alle Informationen, wie ihr eine Windows PKI enumerieren könnt, findet ihr im oben genannten Paper. Im ersten Schritt gilt es herauszufinden, wo die PKI im Unternehmen installiert ist und welche Arten von Zertifikaten verfügbar sind. In einer Windows PKI müssen die einzelnen Arten von Zertifikate, also beispielsweise CodeSigning, E-Mail-Signatur oder was auch sonst erst einmal konfiguriert und zur Verfügung gestellt werden. Die Information, welche Zertifikate es im Unternehmen gibt, werden im zentralen Verzeichnisdienst auch Active Directory genannt publiziert. Zur Abfragen der Informationen benötigt ihr allerdings einen validen Benutzer. Zumindest unter Windows Server 2021.

Linux

Zur Abfrage von Active Directory Informationen kann unter Linux ldapsearch verwendet werden.

ldapsearch -LLL -H ldap://<Server> -D <Username> -w <Password> -b CN=Configuration,DC=<Domain>,DC=<TLD> "(objectCategory=pKIEnrollmentService)"

LDAPSearch

Wenn ihr die Attribute auf dNSHostname und certificateTemplates, wie im Beispiel gezeigt einschränkt, bekommt ihr nur den Hostnamen für die CA und die verfügbaren Templates angezeigt. Sollten die Namen nicht ausreichend sein, um ein Zertifikat auszuwählen, das ihr später “anfragen” wollt, kann euch folgende Abfrage helfen:

ldapsearch -LLL -H ldap://<Server> -D <Username> -w <Password> -b CN=Configuration,DC=<Domain>,DC=<TLD> "(objectCategory=pKICertificateTemplate)"

Hier erhaltet ihr alle Templates, die es gibt, auch die Templates, die nicht abgefragt werden können. Dann wählt ihr euch ein Template mit den entsprechenden pKIExtendedKeyUsage Werten aus. Die empfohlenen Werte hier sind:

Smart Card Logon (1.3.6.1.4.1.311.20.2.2)
Client Authentication (1.3.6.1.5.5.7.3.2)

Windows

Wenn ihr auf einem Domain integriertem System seid, so könnt ihr beispielsweise PowerShell oder certutil verwenden, um die notwendigen Infos zu bekommen. Hier ein kleiner PowerShell sechs Zeiler.

$Searcher = New-Object DirectoryServices.DirectorySearcher
$Searcher.Filter = '(objectCategory=pKIEnrollmentService)'
$Searcher.SearchRoot = 'LDAP://CN=Configuration,DC=hackmich,DC=lab'
$r = $Searcher.FindAll()
"Hostname: " + $r.Properties.dnshostname
"Templates: " + $r.Properties.certificatetemplates

Für diejenigen, die certutils bevorzugen, kann folgender Befehl verwendet werden:

certutil -TCAInfo

Wenn ihr eure PKI gegen die meisten Schwachstellen, die im Paper aufgeführt werden, auditieren wollt, so kann das Tool PSPKIAudit verwendet werden.

PSPKIAudit

In der letzten Zeile seht ihr die entdeckte Schwachstelle.

Wenn ihr den CA Server gefunden habt, einfach die URL http://<Adresse>/certsrv aufrufen und prüfen, ob das Feature Certificate Authority Web Enrollment installiert wurde.

Exploit

Zum Durchführen von NTLM-Relay auf den ADCS benötigt impacket. Allerdings ist der dafür notwendige Branch noch nicht im Hauptzweig angekommen. Daher müsst ihr das Repository von ExAndoridDev verwenden und in den entsprechenden Zweig wechseln.

Das Tool könnt ihr dann mit folgendem Befehl starten:

python3 ./ntlmrelayx.py -t "http://<CA Server>/certsrv/certfnsh.asp" -smb2support --adcs --template "<TemplateName>"

Standardmäßig versucht das Tool ein Zertifikat mit dem Namen Machine anzufragen. Wenn es aber kein Template mit dem Namen gibt, müllt ihr ganz schnell die Liste für fehlerhafte Zertifikate voll und werdet vermutlich entdeckt. Darum würde ich hier immer auf Nummer sichergehen und mir das passende Zertifikat raussuchen. Nun heißt es warten.

Aus irgendeinem Grund wird der Angriff in der Presse untrennbar mit der Lücke PetitPotam assoziiert. Wie ihr euer Opfer dazu bringt eine Verbindung zu euch aufzubauen, ist fürs Relaying egal. Es kann beispielsweise über IPv6-Spoofing, LLMNR/NetBIOS-Spoofing, Printerbug, PetitPotam oder sonst wie geschehen.

Im Beispiel habe ich einfach mit dem Administrator versucht, ein Share auf meiner Kali-Linux zu öffnen. Auch das ist ausreichend. Weiterhin habe ich ein Zertifikat mit dem vielversprechenden Namen “TPMVirtualSmartCardLogon” genommen. Wenn das Zertifikat für die Clientauthentifizierung geeignet ist, könnt ihr beispielsweise Rubeus nutzen, um euch ein TGT zu besorgen:

Rubeus.exe asktgt /domain:hackmich.lab /user:administrator /ptt /dc:192.168.1.5 /certificate:MIISZQIBAzC<REDACTED>

Rubeus

Im Anschluss könnt ihr mit dem TGT machen was ihr wollt.

Erkennen

Das Erkennen von ADCS-Relaying ist relativ schwierig. Eine Sache, die mir bei Tests mit ntlmrelayx aufgefallen ist, dass immer gleich mehrere Zertifikate angefragt wurde. Das kann natürlich von einem erfahrenen Angreifer im Code angepasst werden. Dennoch ist die Anfrage mehrere Zertifikats vom selben Benutzer innerhalb kürzester Zeit ein Indiz, dass jemand versucht ADCS-Relaying auszuführen. Ansonsten habe ich keine Möglichkeit gefunden im Eventlog eine legitime von einer nicht-legitimen Anfrage zu unterscheiden. Falls hier jemand mehr Infos hat, darf er mir die gerne mitteilen.

Weiterhin besteht natürlich die Möglichkeit zu versuchen, NTLM-Relaying im Allgemeinen zu erkennen. Beispielsweise kann in Umgebungen, in denen normalerweise nur Kerberos mit der CA gesprochen wird, die Anmeldung mittels NTLM im Eventlog ein Indiz für einen erfolgreichen Angriff sein.

EventLog

Eine effektive. aber aufwendige Methode NTLM-Relaying zu erkennen ist, wenn die Attribute Workstation Name und Source Network Adress nicht zueinander passen.

Verhindern

Zwei Möglichkeiten einen derartigen Angriff zu verhindern, werden im Paper unter PREVENT8 beschrieben. Die eine Möglichkeit ist die Gruppenrichtlinien “Network security: Restrict NTLM: Incoming NTLM traffic” to “Deny All Accounts” zu verwenden und damit eingehende NTLM Verbindungen auf Host ebene zu unterbinden.

Weiterhin kann der IIS Server so konfiguriert werden, dass der ADCS Endpunkt kein NTLM mehr akzeptiert.

Disable NTLM

Wie immer gilt falls ihr Fragen, Anmerkungen oder Verbesserungsvorschläge zu dem Artikel habt, schreibt eine Mail an info@hackmich.net.