Das Active Directory (AD) ist die zentrale Verwaltung von Zugangsdaten, Rollen und Berechtigungen. Neben der Windows-Infrastruktur werden weitere Anwendungen mittels Single Sign-on angebunden. Wer administrativen Zugang zum AD hat, kontrolliert Zugänge zu Anwendungen und deren Daten und kann sich Kerberos-Tickets ausstellen, die Zugriff auf Informationen erlauben. Ein Angreifer (Offense) im internen Netz wird daher versuchen privilegierte Berechtigungen im AD zu erlangen. Handumkehrt wird die zuständige IT-Abteilung (Defense) bemüht sein, genau dies zu verhindern. Ein Domänen-Benutzer verfügt bereits über umfangreiche Lese-Rechte im AD und kann bereits viele Informationen auslesen, unter anderem Eigenschaften von Benutzern, Gruppen, Zugriffsrechte (ACL) oder Group Policies. Diese Standard-Rechte erschweren die Verteidigung des ADs, da sich ein Angreifer dadurch viele Informationen beschaffen kann.
VORSTELLUNG VON BLOODHOUND
Am 4. August 2016 wurde an der Defcon 24 anlässlich des Talks Six Degrees of Domain Admin von den Entwicklern und Penetration Testern Andy Robbins, Will Schroeder und Rohan Vazarkar das Tool BloodHound vorgestellt und zwei Tage drauf in der Version 1.0 veröffentlicht. Dieses Tool macht sich diese Konstellation der offenen Leserechte in einem Active Directory zu Nutze. Mittels eines sogenannten Ingestor werden Objektes des AD ausgelesen und anschliessend grafisch dargestellt. Das Tool generiert aus den abgefragten Daten eine Übersicht über Benutzer und Gruppen, welche Rechte diese haben und auf welchen Systemen diese angemeldet sind. Für einen Angreifer sind solche Zusammenhänge Gold wert. Er ist damit in der Lage, Wege zu Mitgliedern der Gruppe Domain Admins zu finden und gegebenenfalls diese anzugreifen. Doch auch für die Defense ist BloodHound von hohem Nutzen, da damit allfällige Schwächen identifiziert und anschliessend behoben werden können.
Etwa ein Jahr später wurde im Oktober 2017 die Version 1.4 von BloodHound veröffentlicht. Diese Version bringt verschiedene Verbesserungen mit sich. BloodHound zeigt nun Eigenschaften von Objekten, wie Benutzername, letzte Änderung des Passworts oder Zeitpunkt des Logins, an. Zudem wurde der bisher auf PowerShell v2 basierende Ingestor von Grund auf überarbeitet und mit C# neu geschrieben. Der neue C#-Ingestor heisst Sharp Hound und liegt als Binary oder PowerShell-Skript vor. Mit dem PowerShell-Skript wird das Binary zur Laufzeit entpackt und ausführt. Rohan Vazarkar beschreibt in seinem Blog-Post SharpHound: Evolution of the BloodHound Ingestor die Überarbeitung und neuen Funktionen von SharpHound.
SAMMELN VON DATEN
Zunächst werden Informationen des Active Directory mit SharpHound ausgelesen und im Backend gespeichert. Als Datenspeicher setzt Bloodhound Neo4j ein. Das Backend kann unter Windows, Linux oder macOS installiert werden. SharpHound generiert standardmässig CSV-Dateien, die ins Backend importiert werden. Mittels der Parameter --Uri und --UserPass werden die gesammelten Daten direkt in die Neo4j-Instanz geschrieben. Dies ist nützlich, wenn SharpHound auf verschiedenen Systemen ausgeführt wird oder einer Schleife läuft, um regelmässig Sessions auszulesen (Parameter -c SessionLoop). Je nach AD-Topologie und Netzwerk-Segmentierung ist die Auswertung von SharpHound unvollständig, da beispielsweise der Zugriff auf Server nicht möglich ist und damit Sessions nicht enumeriert werden. Falls möglich sollte SharpHound auf verschiedenen Systemen und Netzwerksegmente ausgeführt werden, um auch ansonsten tote Winkel zu erreichen.
SharpHound liest grundsätzlich Trusts, Sessions, Local Admin und Group Membership aus. Über den Parameter -CollectionMethod kann dies erweitert werden. Wir empfehlen für die initiale Datensammlung zusätzlich Logged On, ACL und Object Props zu sammeln. Bei Logged On sind administrative Rechte auf dem Zielsystem nötig, um die Benutzer auszulesen. Ein Angreifer, mit den Rechten eines Domain User, kann nicht an diese Daten gelangen. SharpHound legt eine Cache-Datei namens BloodHound.bin an, diese beschleunigt die Ausführung bei mehrmaligen Abfragen.
Nützlich für Angreifer sind die Optionen --Stealth und --ExcludeDC. Letztere verhindert, dass Session-Informationen von Domain Controllern (DC) abgefragt werden. Dies verhindert die Entdeckung eines Scans durch Microsoft ATA, da ATA in diesem Kontext nur DCs überwacht.
VISUALISIERUNG VON AD-OBJEKTEN
BloodHound stellt die gesammelten Daten dar, unter Node Info werden kontextbezogen Informationen zum jeweiligen Objekt bereitgestellt:
Von einer Node kann weiter navigiert werden, beispielweise in welchen Gruppen ein Benutzer Mitglied ist oder auf welchen Systemen der Benutzer lokale Administratoren-Rechte besitzt. Dabei wird unterschieden, ob diese Rechte direkt vergeben oder via Vererbung erlangt werden.
Mit der Version 1.4 gab es eine weitere Funktion, die anzeigt welche Benutzer oder Gruppen über DCSync-Rechte verfügen.
Die DCSync-Rechte erlauben es, Objekte zu replizieren. Ein Angreifer kann dies Nutzen, um mit Mimikatz an die Zugangsdaten des Accounts krbtgt zu gelangen.
WEGE ZUM DOMAIN-ADMIN
Wir haben BloodHound in unserem Lab lab.scip.ch auf die Mitglieder der Gruppe Domain Admins angesetzt, um zu eruieren, wie sich ein Angreifer Domain-Admin-Privilegien beschaffen könnte. Im ersten Beispiel ist der Domain-Admin adm_hwashburne auf dem Computer client02 angemeldet.
Der Benutzer adm_jcobb, der als Mitglied der IT-Supporter-Gruppe (G-IT-ADM-Support) lokale Administratorenrechte auf allen Workstations der Domain besitzt, wäre so in der Lage, an Domain-Admin-Zugangsdaten zu gelangen. Ebenso könnten Angreifer den Service-Benutzer für die Workstation-Antivirensoftware (srv_antivirus) dazu missbrauchen. Aus Sicherheitsgründen sollte sich ein Account mit Domain-Admin-Rechten nicht auf einer Workstation oder anderen nicht spezifisch gehärteten Systemen anmelden.
Beim zweiten Beispiel läuft auf dem Computer file01 ein Backup-Job, der durch den Service-Benutzer srv_backup ausgeführt wird. Dieser Benutzer verfügt über Domain-Admin-Rechte.
Der Benutzer adm_zwashburne, ein Mitglied der IT und Administrator von Member-Servern, hätte somit die Möglichkeit an Domain-Admin-Zugangsdaten zu gelangen. In diesem Fall stellt sich die Frage, ob der Backup-Servicebenutzer wirklich Domain-Admin-Rechte benötigt oder dedizierte Rechte nicht ausreichen.
Im dritten Beispiel besteht die Möglichkeit, dass ein Domänenbenutzer auf direktem Weg Domain-Admin-Rechte erlangen kann. Der Benutzer rtam ist Entwickler und hat auf dem Applikationsserver app01 Administratorenrechte erhalten. Gerade auf diesem Server ist der Domain-Admin adm_hwashburne angemeldet.
Die Rechte des Accounts rtam können direkt auf die Stufe eines Domain-Admins eskaliert werden. Es handelt es sich hier um eine unsichere Rechtevergabe. Ein normaler Benutzeraccount sollte nie über Administratorenrechte auf einem Server verfügen. Es sollten stets getrennte Accounts eingesetzt werden: Normale Accounts zur grundlegende Arbeiten und solche, die über administrative Privilegien verfügen. Für Entwickler oder andere Benutzergruppen sollten zudem keine Sonderrechte gelten, auch wenn es sich nur um eine Ausnahme respektive in diesem Fall um einen einzelnen Server handelt. Diese Fehlkonfiguration ermöglicht es, die Kontrolle über die Domäne zu übernehmen.
FAZIT
Die Beispiele zeigen den Nutzen für Offense und Defense gleichermassen. Die Offense fand mehrere interessante Ziele, die zur Rechteerweiterung ausgenutzt werden können. Durch Datensammlung in BloodHound können solche Angriffswege effizient ermittelt werden, ohne Systeme manuell und ohne gezieltes Vorgehen zu untersuchen.
Die Defense spürte mehrere potentielle Schwachstellen auf und kann entsprechende Gegenmassnahmen einleiten. So sollte beispielsweise eine Policy definiert werden, die es verhindert, dass sich Domain-Admin-Accounts auf Workstations anmelden.
Ich kann es nur empfehlen BloodHound in der eigenen AD-Infrastruktur laufen zu lassen und zu analysieren, wie im eigenen Netzwerk der direkteste Weg zum Domain-Admin aussieht. Weidmannsheil!
Was this helpful?
0 / 0