Die meisten Organisationen und Unternehmen verwenden das Active Directory in ihrer Infrastruktur als zentrale Lösung für die Verwaltung ihrer Ressourcen. Dabei stehen viele vor großen Herausforderungen bei der Absicherung und Stärkung dieser Active Directory-Umgebungen. Fehlendes Fachwissen, begrenzte Budgets, architektonische Herausforderungen aufgrund historisch-gewachsener Systemlandschaften sowie die daraus resultierende Notwendigkeit, Legacy-Systeme zu unterstützen, sind mögliche Ursachen für anfällige IT-Systeme.
Für Bedrohungsakteure stellt das Active Directory eine verlockende Zielscheibe dar, da eine erfolgreiche Kompromittierung in der Regel Zugang zu fast allen Unternehmensressourcen ermöglicht. Dies bietet Angreifern eine ideale Möglichkeit, z. B. Ransomware in das Netzwerk einzuschleusen, um finanzielle Forderungen stellen zu können.
Durch das Bekanntwerden von Schwachstellen im Active Directory besteht jederzeit die Gefahr, dass ganze Active Directory-Umgebungen ohne großen Aufwand kompromittiert werden können. Dabei ist es zunächst einmal unerheblich, über welchen Account oder über welche Schwachstelle der Einbruch gelungen ist. Denn ist den Angreifern der initiale Einbruch in das Firmennetzwerk gelungen, suchen sie nach sogenannten „Low-Hanging-Fruits“ innerhalb der Active Directory Umgebung, um Ihre Rechte auszuweiten.
Gerade für kleinere und mittelständische Unternehmen gestaltet sich das frühzeitige Erkennen von Angriffen auf das Active Directory als schwierig. Aufgrund der Firmengröße verfügen deren IT-Abteilungen in der Regel nicht über ein zureichendes Budget und die notwendigen Ressourcen für den Betrieb von Enterprise Security Lösungen wie SIEM oder EDRs. Doch gerade das rechtzeitige Erkennen von Angriffen ist entscheidend, um schnell zu reagieren und Schäden an der Reputation sowie finanzielle und datenschutzrechtliche Folgen zu vermeiden, bevor sie sich verschlimmern können.
Dennoch können mit Hilfe von „Deception“-Techniken auch Unternehmen, die lediglich über geringe IT-Security-Budgets verfügen, produktunabhängig bestimmte Angriffe wie Kerberoasting auf das Active Directory frühzeitig erkennen und deren Ausführung verzögern. Hierfür müssen gewisse Voraussetzungen erfüllt und präventive Maßnahmen bei der Nutzeranlage von sogenannten „Decoys“ getroffen werden. Diese „Decoys“ werden innerhalb einer Active Directory Umgebung platziert, um die Aufmerksamkeit von Angreifern auf diese zu ziehen, um so einen Alert auszulösen.
Praxisbeispiel: Anwendung von „Deception“-Techniken zur Erkennung von Kerberoasting Aktivitäten
Kerberoasting ist eine effiziente Technik für Angreifer, die lediglich über wenig Rechte innerhalb einer Domäne verfügen. Im Jahr 2014 präsentierte Tim Medin den Kerberoasting-Angriff bei seiner Präsentation „Attacking Microsoft Kerberos – Kicking the Guard Dog of Hades“ auf der Derbycon Konferenz. Beim Kerberoasting wird die Eigenheit bei der User-Anlage in Microsoft Kerberos ausgenutzt, dass jeder gültige Domain-User einen Ticket Granting Server (TGS) für einen beliebigen Dienst beantragen und anschließend das Ticket für Offline-Passwort-Cracking-Versuche verwenden kann.
Je nach Stärke der Passwörter können Angreifer in kurzer Zeit und in den meisten Fällen relativ unbemerkt Benutzeraccounts kompromittieren und diese für weitere Angriffe verwenden.
Die einzige Voraussetzung für die Durchführung eines solchen Angriffs ist die Kenntnis über die existierenden Benutzerkonten, die einen sogenannten „Service Principal Name“ (SPN) gesetzt haben. Da alle existierenden SPNs mit einem simplen LDAP Query abgerufen werden können, stellt dies eine vergleichsweise geringe Einstiegsbarriere dar.
Gelingt es also dem Angreifer einzelne oder alle SPNs zu kennen, kann er im System Service Tickets (TGS) für ebenjene anfragen. Die durch die Abfrage erlangten Service-Tickets residieren im Arbeitsspeicher des Angreifers, aus welchem er diese anschließend extrahieren und auf einer Festplatte speichern kann. Nachdem der Eindringling nun über die TGS-Tickets aller Service Accounts verfügt, kann er versuchen, die verschlüsselten Teile der Tickets mit Hilfe eines Brute-Force-Angriffs zu entschlüsseln.
Praktische Durchführung des Kerberoasting-Angriffs mit GetUserSPNs.exe
Zur praktischen Ausnutzung der gefundenen Schwachstelle in Microsoft Kerberos stehen mehrere öffentlich verfügbare Tools bereit. Die bekanntesten sind das Python-Skript GetUserSPNs.py und das PowerShell-Script Invoke-Kerberoast. In diesem Beispiel verwendet unser fiktiver Angreifer GetUserSPNs.exe (eine statisch kompilierte Version von GetUserSPNs.py für Windows) für die Durchführung.
Um den Angriff möglichst realistisch zu beschreiben, verfügt der Angreifer in unserem Szenario zunächst lediglich über ein unprivilegiertes Benutzerkonto, um die TGS Tickets anzufordern und deren Hashes für den Cracking-Prozess zu extrahieren. Dieser Account ist jedoch für das Tool GetUserSPNs.exe bereits ausreichend.
Die gewonnene Ausgabedatei kann im Anschluss in jedes beliebige Passwort-Cracking Tool importiert werden, mit deren Hilfe ein Offline-Brute-Force Angriff auf die extrahierten Hashes durchgeführt wird. Der Vorteil von Offline-Cracking Angriffen besteht darin, dass sie selbst keine Spuren im System des angegriffenen Unternehmens hinterlassen und somit nicht entdeckt werden können. Darüber hinaus ermöglichen sie eine deutlich höhere Anzahl von Brute-Force-Versuchen pro Sekunde im Vergleich zu jeglichen Online-Angriffen.
hashcat -a 0 -m 13100 -O kerberoasted_impacket.txt /opt/wordlists/Top2Billion-probable-v2/Top2Billion-probable-v2.txt -r rules/hob064.rule
Wie in der oberigen Abbildung sichtbar, war es dem Passwort-Cracking-Tool möglich, einen der extrahierten Hashes in die Klartextform zurückzurechnen. Dem Angreifer erlaubt die gewonnene Information die Kontrolle über den betroffenen Account und ermöglicht es ihm so, seine Rechte im Netzwerk auszuweiten.
Anzeichen eines Kerberoasting-Angriffs im Domain-Controller
Auch wenn Kerberoasting-Angriffe vergleichsweise unbehelligt erfolgen, gibt es doch einige Hinweise, die ein aufmerksamer Administrator im Domain-Controller selbst erkennen kann. Denn analysiert man die Logging-Aktivitäten auf dem Domain-Controller während eines Angriffs, dann fallen folgende Events auf:
Die oben beschriebene Anfrage eines TGS-Tickets für einen SPN hinterlässt in Form der erzeugten Event-ID 4769 ihre Spuren im angegriffenen System. Sieht man sich das erzeugte Event genauer an, findet man dort weite Angaben zum angefragten „Service Name“, dem „Ticket Encryption Type“ sowie der IP-Adresse des anfragenden Systems. Diese Attribute helfen, einen Angriff frühzeitig zu erkennen.
Integration einer „Deception“-Technik mittels „Honeypot“-Accounts
Auch wenn Kerberoasting-Angriffe die oben beschriebenen Spuren im System hinterlassen, ist es doch relativ unwahrscheinlich, dass ein Administrator diese sofort bemerkt und dementsprechend zeitnah agieren kann. Daher ist es sinnvoll bereits bei der Implementierung der Active Directory die Deception-Techniken mit einzuplanen und umzusetzen.
Hierfür werden sogenannte „Decoys“ – also ungenutzte „Honeypot“-Accounts – erstellt, die als leere Attrappen für potenzielle Angreifer dienen. Hierbei wird die Tatsache ausgenutzt, dass während eines Kerberoasting-Angriffs mehrere Anomalien in den Windows-Logs zu sehen sind. Insbesondere die Tatsache, dass die bekannten Tools standardmäßig SPN-Tickets für alle Accounts, die ein „SPN-Attribut“ gesetzt haben, anfordern (siehe Abbildung 1: LDAP Query zum Extrahieren von allen Domain Accounts die einen SPN gesetzt haben), kann als Frühwarnsystem verwendet werden.
Diese „Honeypot“-Accounts haben nämlich keine eigentliche Funktion im Active Directory und sollten im Regelfall nicht verwendet werden. Im „normalen“ Betrieb werden für diese also keine „TGS“-Tickets für den Service angefragt. Ist dies doch der Fall, handelt es sich mit hoher Wahrscheinlichkeit um den Versuch eines Kerberoasting-Angriffs.
Bei der Anlage des Honeypot-Accounts im Active Directory gelten einige Besonderheiten im Vergleich zu normalen Usern, wie der folgende PowerShell-Befehl zeigt:
New-ADUser -Name "DBAdmin" -DisplayName "DBAdmin" -SamAccountName "dbadm" -description "DatabaseAdministrationAccount" -UserPrincipalName "dbadm" -GivenName "Database" -Surname "Administrator" -AccountPassword ((ConvertTo-SecureString "kd329-/Sl2(2)02(§23kcJk3A$" -AsPlainText -Force)) -Enabled $true -Path "OU=ServiceAccounts, OU=AdministrativeAccounts, DC=WINDOMAIN, DC=LOCAL" -ChangePasswordAtLogon $false -PasswordNeverExpires $trueIm Anschluss kann mithilfe des „setspn“-Befehls eine SPN für den betroffenen Account gesetzt werden.
setspn -s http/wef.windomain.local:1433 windomain.local\dbadmNach Setzen des SPNs sollte folgende Meldung erscheinen:
SPN-Anfragen für den Honeypot-Account mit Windows-Board-Mitteln frühzeitig erkennen
Wir verwenden in diesem Beispiel den Windows Event Viewer zur Erkennung eines potenziellen Angriffs, um zu demonstrieren, dass dies bereits mittels Standard-Funktionen innerhalb des Active Directorys bzw. Windows realisierbar ist. Selbstverständlich ist es auch möglich dies mittels Monitoring-Lösungen von Drittanbietern umzusetzen.
Der Windows Event Viewer bietet sich für das Tracking von Anomalien bei „Honeypot“-Accounts an, da dort sogenannte „Custom Views“ erstellt werden können, die nach spezifischen Events filterbar sind. Um Ticket-Anfragen des erstellten Honeypot Accounts herauszufiltern, kann folgende XML-Syntax verwendet werden:
<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">
*[EventData[Data[@Name='ServiceName'] and (Data='dbadm')]]
and
*[System[(EventID='4769')]]
</Select>
</Query>
</QueryList>Eine mögliche „Custom“-View würde bei einer SPN Ticket-Anfrage des Honeypot-Accounts wie folgt aussehen:
Die „Custom View“-Ansicht erlaubt neben der einfachen Anlage von Events auch die Einstellung von „geplanten Aufgaben“, die im Falle eines neuen Events für den im „Custom View“ eingestellten Filter ausgeführt werden.
Windows Event Viewer bietet dafür folgende bereits eingebaute Funktion an:
In diesem Beispiel wird eingestellt, dass bei Auslösen des Events eine E-Mail an den „Administrator“ der AD-Umgebung gesendet wird.
Bei der Ausführung des Kerberoasting-Angriffs auf den Honeypot-Account erhält dieser eine E-Mail zur Alarmierung bei potenziell bösartigen Aktivitäten.
Fazit
Bereits mit einem geringen IT-Security-Budget ist es möglich, Angriffe wie Kerberoasting frühzeitig zu erkennen. Gelingt es, den Angriff zu verzögern oder im besten Fall sogar zu stoppen, können schlimmere Folgen für das Unternehmen abgewendet werden. Natürlich bilden derartige Alert-Systeme nur einen Baustein bei der Einführung und Umsetzung von Sicherheitssystemen, um die eigene IT-Infrastruktur zu schützen. Dennoch zeigt das Beispiel Kerberoasting, wie einfach und wirksam Deception-Techniken implementiert werden können.
Abbildung 1: Auszug legitimer Anfragen an den Webserver
