Inhalt
Was ist ein Active Directory?
Microsoft selbst definiert Active Directory in einer technischen Dokumentation wie folgt:
“Active Directory: The Windows implementation of a general-purpose directory service, which uses LDAP as its primary access protocol. Active Directory stores information about a variety of objects in the network such as user accounts, computer accounts, groups, and all related credential information […]. Active Directory is either deployed as Active Directory Domain Services (AD DS) or Active Directory Lightweight Directory Services (AD LDS) […].”[i]
Active Directory besteht architektonisch betrachtet aus den vier Hauptkomponenten Lightweight Directory Access Protokoll (LDAP), Kerberos, Common Internet File System (CIFS) und Domain Name System (DNS).
Bei LDAP handelt es sich um ein Netzwerkprotokoll, mit dem mittels einer spezifischen Syntax Abfragen (z.B. über die Benutzer) und Änderungen in einem verteilten Verzeichnisdienst durchgeführt werden können. Hierzu muss auf allen beteiligten Systemen eine Übertragung möglich sein. Standardmäßig wird der LDAP-Datenverkehr ungesichert über den TCP-Port 389 übertragen. Man kann den LDAP-Datenverkehr aber auch mit einer gesicherten TLS Verbindung über TCP-Port 636 nutzen.
Das Kerberos Protokoll wird für die Authentifizierung in Active Directory genutzt. Hierbei erhält ein User, der sich beispielsweise mit einem Passwort authentifiziert, ein Ticket Granting Ticket (TGT), mit welchem er dann Tickets für weitere Dienste innerhalb des Netzwerks anfordern kann. Es ist also möglich verschiedene Dienste zu nutzen, ohne sich für jede Aktion erneut authentifizieren zu müssen.
DNS ist in Active Directory für die Namensauflösung zuständig und wird von Microsoft so definiert:
“Domain Name System (DNS): A hierarchical, distributed database that contains mappings of domain names to various types of data, such as IP addresses. DNS enables the location of computers and services by user-friendly names, and it also enables the discovery of other information stored in the database.”[ii]
DNS gewährleistet unter Anderem, dass die Domain Controller (DC), die den Verzeichnisdienst bereitstellen, miteinander kommunizieren können und Clients nach diesen DCs suchen können.
CIFS ist ein Protokoll, dass die Ablage von Dateien und Dokumenten im Netzwerk, sowie auf zentrale Komponenten, wie Drucker ermöglicht. Zum Auffinden der einzelnen Computersysteme und Dienstinformationen (SRV Resource Record) wird wiederum DNS verwendet.
Die Struktur eines Active Directory
In Active Directory werden Domains verwendet, um Organisationsstrukturen nachzubilden; eine Domain ist dabei immer eine Organisationseinheit mit einem eindeutigen Namen, welche u.A. spezifische Sicherheitsrichtlinien und -einstellungen beinhaltet. In der Domain werden Objekte wie Benutzer oder Geräte eines Netzwerks inklusive ihrer Attribute gespeichert. Es ist innerhalb der Domain möglich, diese Objekte über weitere Organisationseinheiten (OU) zu gruppieren. Mehrere Domains können jeweils einen Domaintree bilden, bei welchem eine Domain die Root-Domain darstellt, welcher die anderen Domains untergeordnet sind. Alle Domains eines Domaintrees bilden einen fortlaufenden Namen, bei welchem die untergeordnete Domain jeweils den Namen der übergeordneten Domain enthält.
Beispiel:
- Root-Domain = secuinfra.com
- Untergeordnete Domain = cyberdefense.secuinfra.com
- Untergeordnete Domain = sales.secuinfra.com
Darüber hinaus ist es auch möglich, zwei völlig unabhängige Domains oder Domaintrees über eine Vertrauensstellung miteinander zu verbinden. Der Zusammenschluss verschiedener Domains wird dann als Forest bezeichnet. Hierdurch wird die Möglichkeit geschaffen, auf die Ressourcen einer komplett anderen Domain zuzugreifen, die einen völlig anderen Namensraum hat. So kann es z.B. den Benutzern einer Domain möglich sein sich auf den Rechnern einer anderen Domain anzumelden, insofern zu dieser eine Vertrauensstellung besteht, welche dies erlaubt.
Active Directory beinhaltet entsprechend eine enorme Menge an Informationen über die verwalteten Ressourcen. Dazu gehören unter anderem Benutzer und deren Gruppenzugehörigkeiten, aber auch Informationen zu den Geräten im Netzwerk (z.B. Betriebssystem-Versionen von Computern). Diese Informationen können für einen Angreifer sehr interessant sein, da er sie als Basis nutzen kann, um lohnenswerte Ziele und einfache Einfallspunkte wie veraltete Betriebssysteme mit bekannten Schwachstellen zu finden. So kann er seine nächsten Schritte planen und sein Vorgehen so anpassen, dass er sich möglichst unerkannt in der Infrastruktur bewegt.
Tools wie Bloodhound automatisieren und erleichtern die Beschaffung dieser Informationen, indem sie Active-Directory-Umgebungen analysieren und oft unbeabsichtigte Beziehungen innerhalb einer Active-Directory-Umgebung aufdecken. Mögliche Angriffspfade können so identifiziert und dann per Graphentheorie dargestellt werden. Hierbei reichen die Rechte eines beliebigen Active Directory Benutzers zur Abfrage fast sämtlicher benötigter Informationen aus.
Daher ist es auch für die Verteidigung des Firmennetzwerkes wichtig, einen guten Überblick über Active Directory zu haben und auf die Informationen aus dem Verzeichnisdienst zugreifen zu können. Dies gilt besonders dann, wenn zum Beispiel eine unzureichende oder unvollständige Dokumentation vorhanden ist oder man die Daten nutzen möchte, um Logdaten eines SIEM-Systems anzureichern. Doch wie kann man hier vorgehen?
Man kann natürlich ebenfalls Tools wie Bloodhound nutzen, oder manuell über das GUI eines Domain Controllers (DC) Einblick in die Daten nehmen. Grundsätzlich gibt es auch eine Vielzahl von Tools, die ein Abrufen der in Active Directory gespeicherten Daten ermöglicht und nicht zwingend Zugang mit einem privilegierten Account zum DC erfordern.
Viele dieser Tools sind allerdings Drittanbieter-Tools, die erst heruntergeladen und installiert werden müssen, was nicht immer möglich ist. An dieser Stelle kann man auf eine .NET-Framework Klasse zurückgreifen. Das .NET Framework wird seit Windows Vista zusammen mit dem Betriebssystem installiert. Für PowerShell 2.0 wurde die .NET Klasse System.DirectoryServices, die einen einfachen Zugriff auf Active Directory Domain Services bietet und mit der Komponentenklasse DirectorySearcher Abfragen mittels PowerShell gegen eine AD Domain ermöglicht, entwickelt.
Die Abfragen werden über das in Active Directory implementierte Lightweight Directory Access Protocol (LDAP) durchgeführt. Einen wesentlichen Vorteil, den die Nutzung von PowerShell bietet, ist die Möglichkeit Abläufe zu Automatisieren und auf die individuellen Bedürfnisse anzupassen. So können vorgefertigte Abfragen in Form eines PowerShell-Skripts gespeichert werden, welches als Task regelmäßig ausgeführt werden kann.
Die Nutzung von System.DirectoryServices.DirectorySearcher
Die Voraussetzungen, um System.DirectoryServices.DirectorySearcher zu nutzen, können schnell abgehandelt werden:
- Ein Computer in der Domain mit einem Windows Betriebssystem, dass neuer ist als Windows 7 / Windows Server 2008, inklusive PowerShell.
Die Abfrage selbst besteht aus dem Aufruf der Klasse mit Angabe der Suche und der zu verwendenden Methode mit der gesucht werden soll:
([System.DirectoryServices.DirectorySearcher]'(searchquery)’).Methode()
Doch diese Abfrage kann man auch einfacher halten – mit weniger Tipparbeit und etwas leichter zu merken – denn für System.DirectoryServices.DirectorySearcher gibt es einen Type Accelerator: adsisearcher. Type Acceleratoren sind Aliasse für .NET Framework-Klassen und erleichtern, beziehungsweise beschleunigen die Verwendung dieser Klassen hauptsächlich dadurch, dass sie kürzer sind und damit Zeit sparen. Die obige Suchanfrage kann man also mit adsisearcher auch wie folgt ausführen:
([adsisearcher]'(searchquery)’).Methode()
Adsisearcher bietet zahlreiche Möglichkeiten zum Abfragen von Informationen aus einem Active Directory, bei welchen die Eigenschaften und Methoden eines LDAP-Queries verwendet werden. Es ist es von Vorteil die grundlegende Logik von Filtern bei LDAP-Queries zu verstehen, zum Beispiel, wenn eine Abfrage equal (eindeutig), logisch gleich oder nicht gleich ist:
- Equal to (die Suche findet nur Ergebnisse, die mit der Anfrage übereinstimmen):
(sAMAccountName=Knut) - Wildcard:
(sAMAccountName=*Knut*) - Größer/Kleiner -Operatoren (vergleicht nicht nur Zahlenwerte, prüft auch lexikographische Attributwerte – also können auch Buchstaben und andere Muster verwendet werden):
(sAMAccountName>=Kn*)
(sAMAccountName<=Kn*) - Logical equal to AND (die Suche findet nur Ergebnisse, die mit beiden Suchparametern der Anfrage übereinstimmen):
(&(objectclass=user)(sAMAccountName=Knut)) - Logical equal to OR (die Suche findet nur Ergebnisse, die mit beiden Suchparametern der Anfrage übereinstimmen):
(|(sAMAccountName=icebear)(sAMAccountName=Knut)) - Not equal to (die Suche findet nur Ergebnisse, die den in der Anfrage angegebenen Parameter nicht enthalten):
(!sAMAccountName=Knut)
Zudem muss man auch eine Methode angeben, mit der die Suche ausgeführt werden soll. Hierbei kann man sich entscheiden zwischen FindAll() (gibt eine Sammlung aller gefundenen Einträge zurück) und FindOne() (gibt nur den ersten gefundenen Eintrag zurück).
Relativ einfache Anfragen können zum Beispiel nach Benutzern mit bestimmten Namen durchgeführt werden. Dazu muss man wissen, dass im Attribut sAMAccountName eines Objekts der Anmeldename für das Konto eines Benutzers gespeichert wird und zwar in der Form eines “NT Logon Names”, so wie es auch in der Namensangabe Domain\Anmeldename zusammengesetzt wird. Eine Suche nach dem default Administrator Account, kann man mit einem Filter durchführen, der nach dem sAMAccountName Administrator sucht:
([adsisearcher]'(sAMAccountName=Administrator)’).FindAll()
Möchte man alle Benutzer finden, deren Benutzername mit th beginnt, kann man dies mit einer Wilcardsuche tun:
([adsisearcher]'(sAMAccountName=th*)’).FindAll()
Bei dieser Suche würde man z.B. Objekte mit dem sAMAccountName thorsten.mustermann oder thomas.testuser ausgegeben bekommen. Bei jeder Suche erhält man eine SearchResultCollection, die mehrere Objekte enthält. Jedes Objekt wiederum enthält jeweils den Pfadnamen des Objektes, sowie eine ResultPropertyCollection, in welcher die Attribute des Objektes enthalten sind:
Möchte man diese Attribute einsehen, kann man diese mit FindAll().properties oder FindOne().properties aufrufen:
([adsisearcher]'(sAMAccountName=th*)’).FindAll().properties
Als Suchergebnis erhält man die ResultPropertyCollection der Objekte, dargestellt in einer Zuordnung mit Name zu Value:
Bei einer hohen Anzahl an Ergebnissen wird dies allerdings sehr schnell unübersichtlich, da die Attribute in PowerShell fortlaufend ohne optische Trennung der einzelnen Objekte ausgegeben werden. Nach jedem der in der ResultPropertyCollection enthaltenen Attribute kann mit einem entsprechenden Suchfilter gesucht werden. Neben diesen relativ einfachen Abfragen kann man mit adsisearcher auch Gruppen rekursiv auflösen – um z.B. alle Mitglieder, explizite wie implizite, der privilegierten Domain Admins Gruppe zu finden – oder Bitmaskenabfragen für bestimmte Attribute durchführen. In Bitmasken werden verschiedene Einstellungen von Accounts gespeichert. Mit einer Bitmaskenabfrage des Attributs userAccountControl kann man zum Beispiel herausfinden, ob ein Account deaktiviert ist oder ob ein User sein Passwort nicht ändern kann. Daher lohnt es sich, LDAP und adsisearcher zu verstehen und sich damit zu beschäftigen.
Serienübersicht
- Active Directory, LDAP und adsisearcher – Fahren auf Sicht, oder Durchblick haben?
- Adsisearcher – Get the Object of Interest: Suchen nach spezifischen Usern und Computern
- Adsisearcher – Gruppen rekursiv auflösen
- Adsisearcher – Kein Versteckspiel: User Informationen in der Bitmaske entdecken
[i] [MS-KILE] – v20210625 Kerberos Protocol Extensions, Copyright © 2021 Microsoft Corporation Release: June 25, 2021, Seite 8 (https://winprotocoldoc.blob.core.windows.net/productionwindowsarchives/MS-KILE/%5bMS-KILE%5d.pdf)
[ii] [MS-KILE] – v20210625 Kerberos Protocol Extensions, Copyright © 2021 Microsoft Corporation Release: June 25, 2021, Seite 9 (https://winprotocoldoc.blob.core.windows.net/productionwindowsarchives/MS-KILE/%5bMS-KILE%5d.pdf)
