Active Directory Übersicht
Warum AD enumerieren?
Rechte und Privilegien in der AD
Microsoft Remote Server Administration Tools (RSAT)
Die Macht von NT AUTHORITY\SYSTEM
LDAP Übersicht
Active Directory Suchfilter
LDAP Suchfilter
Enumeration von Active Directory mit Built-in Tools
LDAP Anonymous Bind
Credentialed LDAP Enumeration
Active Directory Übersicht
Active Directory ist ein Verzeichnisdienst für Windows-Netzwerkumgebungen. Es ist eine verteilte, hierarchische Struktur, die eine zentrale Verwaltung der Ressourcen einer Organisation ermöglicht. AD bietet Authentifizierungs- und Autorisierungsfunktionen innerhalb einer Windows-Domänenumgebung. Es wurde erstmals mit Windows-Server 2000 veröffentlicht. Es ist abwärtskompatibel, viele Funktionen sind nicht standarmäßig „sicher“ und es kann leicht falsch konfiguriert werden.
AD ist im Wesentlichen eine große Datenbank, auf die alle Benutzer innerhalb der Domäne zugreifen können, unabhängig von Ihrer Berechtigungsstufe. Daher kann ein einfach AD-Benutzerkonto dazu verwendet werden, um die meisten der in AD enthaltenen Objekte aufzulisten. Unter anderem:
– Computer
– Benutzer
– Gruppeninformationen
– Richtlinien
– Functional Levels
– Kennwortrichtlinien
– Group Policy Objects (GPOs)
– Kerberos-Delegierung
– Domain Trusts
– Access Control Listen (ACLs)
Mit diesen Daten kann die allgemeine Sicherheitslage einer Active-Directory-Umgebung ermittelt werden. So können mit den Informationen Fehlkonfigurationen, freizügige Richtlinien und ähnliches identifiziert werden um sich vertikal und horizontal im Netzwerk auszubreiten. Die daruf aufbauende Angriffe könnten sein:
– Kerberoasting / ASREPRoasting
– NTLM Relaying
– Manipulation des Netzwerktraffics
– Passwort-Spraying
– Ausnutzung der Kerberos Delegtion
– Ausnutzung von Domain Trusts
– Diebstahl von Anmeldeinformationen
– Object control
Es ist daher für Organisationen und Unternehmen wichtig Ihre Active Directory Umgebung entsprechend abzuhärten parallel zu einer strengen Patching- und Konfigurationsverwaltungsrichtlinie und einer ordnungsgemäßen Netzwerksegmentierung. Sollte es einem Angreifer gelingen das Netzwerk zu infiltrieren, kann ein solides AD-Netzwerk diesen daran hintern sich im Netzwerk zu bewegen, und den Angreifer dazu zwingen Maßnahmen zu ergreifen die die Wahrscheinlicheit erhöhen das er entdeckt wird.
Active Directory Struktur
Active Directory ist in einer hierarchischen Baumstruktur angeordnet, mit einer Gesamtstruktur an der Spitze, die eine oder mehrere Domänen enthält, die wiederum verschachtelte Unterdomänen enthalten können. Eine Gesamtstruktur ist die Sicherheitsgrenze, innerhalb derer alle Objekte unter administrativer Kontrolle stehen. Eine Gesamtstruktur kann mehrere Domänen enthalten, und eine Domäne kann weitere untergeordnete Domänen oder Sub-Domänen enthalten. Eine Domäne ist eine Struktur, innerhalb derer die enthaltenen Objekte (Benutzer, Computer und Gruppen) zugänglich sind. Objekte sind die grundlegendste Einheit von Daten in AD.
Sie enthält viele eingebaute Organisationseinheiten (OUs), wie „Domänencontroller“, „Benutzer“ und „Computer“, und neue OUs können nach Bedarf erstellt werden. OUs können Objekte und Unter-OUs enthalten, was die Zuweisung verschiedener Gruppenrichtlinien ermöglicht.
Wir können diese Struktur grafisch sehen, indem wir Active Directory Users and Computers auf einem Domain Controller öffnen. In der Domäne miracle.local sehen wir verschiedene OUs wie Computers, Angestellte, Servers, Workstations, etc. Viele dieser OUs haben darin verschachtelte OUs, wie z. B. die OU Manager unter Angestellte. Dies trägt dazu bei, eine klare und kohärente Struktur innerhalb von Active Directory beizubehalten, was besonders wichtig ist, wenn wir Group Policy Objects (GPOs) hinzufügen, um Einstellungen in der gesamten Domäne durchzusetzen.
Warum AD enumerieren?
Wenn wir als Hacker/Pentester die Netzwerke unserer Kunden untersuchen, können wir immer noch einen Schritt weiter gehen und unseren Kunden einen zusätzlichen Nutzen bieten, indem wir ihnen ein detailliertes Bild ihrer AD-Stärken und -Schwächen vermitteln. Unternehmensumgebungen unterliegen im Laufe der Jahre vielen Veränderungen: Hinzufügen und Entfernen von Mitarbeitern und Hosts, Installation von Software und Anwendungen, die Änderungen im AD erfordern, oder Unternehmensrichtlinien, die Änderungen der GPOs erfordern. Diese Änderungen können durch Fehlkonfigurationen zu Sicherheitslücken führen, und es ist unsere Aufgabe als Analyst, diese Schwachstellen zu finden, sie auszunutzen und unseren Kunden zu helfen, sie zu beheben.
Der Start
Sobald wir uns in einer AD-Umgebung befinden, sollten wir damit beginnen diese zu enumerieren. Hier kann unser Fokus auf folgende Objekte gelegt werden:
– Domain functional level
– Kennwortrichtlinie
– AD-Benutzer
– AD-Computer
– AD-Gruppen und -Mitgliedschaften
– Domain trusts relationships
– GPO Informationen
– Fernzugriffsrechte
Mit diesen Informationen können wir nach „Low Hanging Fruits“ suchen, z. B. dass unser aktueller Benutzer oder die gesamte Gruppe der Domänenbenutzer RDP- und/oder lokalen Administratorzugriff auf einen oder mehrere Hosts hat. Einer Grund davon ist die unsachgemäße Verwendung von Jump-Hosts, ein anderer sind Fehlkonfigurationen der Citrix Server Remote Desktop Services (RDS). Wir sollten auch überprüfen, welche Rechte unser aktueller Benutzer in der Domäne hat. Ist er Mitglied einer privilegierten Gruppe? Wurden ihnen besondere Rechte übertragen? Haben wir Kontrolle über ein anderes Domänenobjekt wie einen Benutzer, Computer oder eine GPO?
Der Enumerationsprozess ist iterativ. Während wir uns durch die AD-Umgebung bewegen und Hosts und Benutzer kompromittieren, müssen wir weitere Enumerationsprozesse durchführen, um zu sehen, ob wir weiteren Zugriff erhalten haben, der uns hilft, unser Ziel zu erreichen.
Rechte und Privilegien in der AD
AD enthält viele Gruppen, die ihren Mitgliedern mächtige Rechte und Privilegien gewähren. Viele dieser Gruppen können missbraucht werden, um die Rechte innerhalb einer Domäne zu erweitern und schließlich Domänenadministrator- oder SYSTEM-Rechte auf einem Domänencontroller (DC) zu erlangen. Einige dieser Gruppen sind unten aufgeführt.
| Gruppe | Beschreibung |
| Default Administrators | Domain Admins und Enterprise Admins „Super“-Gruppen. |
| Server Operators | Mitglieder können Dienste ändern, auf SMB-Freigaben zugreifen und Dateien sichern. |
| Backup Operators | Mitglieder dürfen sich lokal bei DCs anmelden und sollten als Domänenadministratoren betrachtet werden. Sie können Schattenkopien der SAM/NTDS-Datenbank erstellen, die Registry aus remote auslesen und über SMB auf das Dateisystem des DCs zugreifen. Diese Gruppe wird manchmal der lokalen Gruppe Backup Operators auf Nicht-DCs hinzugefügt. |
| Print Operators | Mitglieder können sich lokal bei den DCs anmelden und Windows so manipulieren, dass ein bösartiger Treiber geladen wird. |
| Hyper-V Administrators | Wenn es virtuelle DCs gibt, sollten alle Virtualisierungsadministratoren, wie Mitglieder der Hyper-V-Administratoren, als Domänenadministratoren betrachtet werden. |
| Account Operators | Mitglieder können nicht geschützte Konten und Gruppen in der Domäne ändern. |
| Remote Desktop Users | Mitglieder erhalten standardmäßig keine nützlichen Berechtigungen, aber oft zusätzliche Rechte wie Anmeldung über Remotedesktopdienste zulassen und können sich mithilfe des RDP-Protokolls lateral bewegen. |
| Remote Management Users | Mitglieder sind berechtigt, sich bei DCs mit PSRemoting anzumelden (Diese Gruppe wird manchmal der lokalen Remote-Management-Gruppe auf Nicht-DCs hinzugefügt). |
| Group Policy Creater Owner | Mitglieder können neue GPOs erstellen, müssen aber zusätzliche Berechtigungen erhalten, um GPOs mit einem Container wie einer Domäne oder OU zu verknüpfen. |
| Schema Admins | Mitglieder können die Active Directory-Schemastruktur ändern und jede zu erstellende Gruppe/GPO durch ein kompromittiertes Konto in die Standardobjekt-ACL einschleusen. |
| DNS Admins | Mitglieder haben die Möglichkeit, eine DLL auf einen DC zu laden, verfügen aber nicht über die erforderlichen Berechtigungen zum Neustart des DNS-Servers. Sie können eine bösartige DLL hochladen und auf einen Neustart als warten (Persistenz). Das Laden einer DLL führt oft dazu, dass der Dienst abstürzt. Ein zuverlässigerer Weg, diese Gruppe auszunutzen, ist die Erstellung eines WPAD-Eintrags. |
Mitgliedschaften in Gruppen enumerieren:
Get-ADGroup -Identity „DNS Admins“ -Properties *
Zuweisung von Benutzerrechten
Abhängig von der Gruppenzugehörigkeit und anderen Faktoren, wie z. B. über Gruppenrichtlinien zugewiesene Berechtigungen, können Benutzern verschiedene Rechte für ihr Konto zugewiesen werden. Dieser Microsoft-Artikel über die Zuweisung von Benutzerrechten enthält eine ausführliche Erläuterung der einzelnen Benutzerrechte, die in Windows festgelegt werden können.
Wenn Sie den Befehl whoami /priv eingeben, erhalten Sie eine Liste aller Benutzerrechte, die dem aktuellen Benutzer zugewiesen sind. Einige Rechte stehen nur administrativen Benutzern zur Verfügung und können nur aufgelistet/umgesetzt werden, wenn eine erweiterte cmd- oder PowerShell-Sitzung ausgeführt wird. Bei diesen Konzepten der erweiterten Rechte und der User Account Control(UAC) handelt es sich um Sicherheitsfunktionen, die mit Windows Vista eingeführt wurden, um Anwendungen standardmäßig davon abzuhalten, mit vollen Rechten ausgeführt zu werden, sofern dies nicht unbedingt erforderlich ist.
Wenn wir die Rechte, die uns als Administrator in einer Konsole mit Standard-Benutzerrechten und in einer anderen Konsole mit erweiterten Rechten zur Verfügung stehen, vergleichen, werden wir feststellen, dass sie sich drastisch unterscheiden.
Standard-Benutzerrechte:
Benutzerrechte erweitert:
Ein Standard-Domänenbenutzer hat dagegen deutlich weniger Rechte:
Domänenbenutzerrechte
whoami /priv PRIVILEGES INFORMATION ———————- Privilege Name Description State ============================= ============================== ======== SeChangeNotifyPrivilege Bypass traverse checking Enabled SeIncreaseWorkingSetPrivilege Increase a process working set Disabled
Die Rechte der Benutzer erhöhen sich je nach den Gruppenmitgliedschaft, und/oder je nach den ihnen zugewiesenen Privilegien. Nachfolgend finden ist ein Beispiel für die Rechte, die Benutzern der Gruppe „Backup Operators“ gewährt werden.
whoami /priv PRIVILEGES INFORMATION ———————- Privilege Name Description State ============================= ============================== ======== SeShutdownPrivilege Shut down the system Disabled SeChangeNotifyPrivilege Bypass traverse checking Enabled SeIncreaseWorkingSetPrivilege Increase a process working set Disabled
Benutzer in dieser Gruppe haben andere Rechte, die derzeit durch die UAC eingeschränkt sind. Dennoch können wir aus diesem Befehl ersehen, dass sie das SeShutdownPrivilege haben, was bedeutet, dass sie einen Domänencontroller herunterfahren können, was zu einer massiven Dienstunterbrechung führen könnte, wenn sie sich lokal bei einem Domänencontroller anmelden
Microsoft Remote Server Administration Tools (RSAT)
RSAT Background
Die Remote Server Administration Tools (RSAT) sind seit den Tagen von Windows 2000 Teil von Windows. RSAT ermöglicht es Systemadministratoren, Windows Server-Rollen und -Funktionen von einer Workstation mit Windows 10, Windows 8.1, Windows 7 oder Windows Vista aus fernzuverwalten. RSAT kann nur auf Professional- oder Enterprise-Editionen von Windows installiert werden. In einer Unternehmensumgebung kann RSAT Active Directory, DNS und DHCP aus der Ferne verwalten. Mit RSAT können wir auch installierte Serverrollen und -funktionen, Dateidienste und Hyper-V verwalten. Die vollständige Liste der in RSAT enthaltenen Tools lautet:
- SMTP Server Tools
- Hyper-V Management Tools
- Hyper-V Module for Windows PowerShell
- Hyper-V GUI Management Tools
- Windows Server Update Services Tools
- API and PowerShell cmdlets
- User Interface Management Console
- Active Directory Users and Computers Snap-in
- Active Directory Sites and Services Snap-in
- Active Directory Domains and Trusts Snap-in
- Active Directory Administrative Center Snap-in
- ADSI Edit Snap-in
- Active Directory Schema Snap-in (Not Registered)
- Active Directory Command Line Tools
- Active Directory Module for Windows PowerShell
- IIS Management Tools
- IIS Management Console
- IIS Management Compatibility
- Feature Tools
- Remote Desktop Services Tools
- Role Tools
- Update Services Tools
- Group Policy Tools
Wir können mit PowerShell überprüfen, ob und welche RSAT-Tools installiert sind:
Wir können mit dem folgenden Befehl alle verfügbaren Tools installieren:
Get-WindowsCapability -Name RSAT* -Online | Add-WindowsCapability –Online
Bei Bedarf können wir auch einzelne Tools installieren:
Add-WindowsCapability -Name Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0 –Online
Domänenkontext für die Enumerierung
Vielen Tools fehlen die Parameter für Anmeldeinformationen und Kontext und sie beziehen diese Werte stattdessen direkt aus dem aktuellen Kontext. Es gibt einige Möglichkeiten, den Kontext eines Benutzers in Windows zu ändern, wenn Sie Zugriff auf ein Kennwort oder einen Hash haben, z. B.: Mit „runas /netonly“ können Sie das integrierte Befehlszeilentool runas.exe nutzen.
runas /netonly /user:miracle.local\timo powershell
Andere Tools, wie Rubeus und mimikatz, können mit Klartext-Anmeldeinformationen oder einem NTLM-Passwort-Hash angewendet werden:
rubeus.exe asktgt /user:timo /domain:miracle.local /dc:192.168.10.101 /rc4:ad22e855e1648def97bbc9cb51156a52
mimikatz.exe sekurlsa::pth /domain:miracle.local /user:timo /rc4:ad22e855e1648def97bbc9cb51156a52
Enumerierung mit RSAT
Wenn wir eine Domäne kompromittieren, können wir RSAT nutzen, um das AD zu untersuchen. Während RSAT uns GUI-Tools wie Active Directory Users and Computers und ADSI Edit zur Verfügung stellt, ist das wichtigste Tool das PowerShell Active Directory-Modul.
Alternativ können wir die Domäne von einem nicht mit der Domäne verbundenen Host aus aufzählen (vorausgesetzt, er befindet sich in einem Subnetz, das mit einem Domänencontroller kommuniziert), indem wir alle RSAT-Snap-Ins mit „runas“ über die cmd starten. Dies ist besonders nützlich, wenn wir einen internen Penetrationtest durchführen, gültige AD-Anmeldeinformationen erhalten und die Enumeration von einer Windows-VM aus durchführen möchten.
Wir können die MMC-Konsole auch von einem Computer aus öffnen, der nicht mit der Domäne verbunden ist, indem wir die folgende Befehlssyntax verwenden:
C:\> runas /netonly /user:Domain_Name\Domain_USER mmc
Wir können eines der RSAT-Snap-Ins hinzufügen und die Zieldomäne im Kontext des Zielbenutzers in der Zieldomäne auflisten. Nach dem Hinzufügen der Snap-Ins erhalten wir eine Fehlermeldung, dass die „angegebene Domäne entweder nicht existiert oder nicht kontaktiert werden konnte“. Von hier aus müssen wir mit der rechten Maustaste auf das Snap-In Active Directory-Benutzer und -Computer (oder ein anderes Snap-In) klicken und Domäne ändern wählen.
Geben Sie die Zieldomäne in das Dialogfeld Domäne ändern ein. Anschließend können Sie nun die Domäne mit einem der AD RSAT-Snapins untersuchen.
Die Macht von NT AUTHORITY\SYSTEM
Das LocalSystem-Konto NT AUTHORITY\SYSTEM ist ein integriertes Konto in Windows-Betriebssystemen, das vom service control manager verwendet wird. Es hat die höchste Zugriffsebene im Betriebssystem (und kann mit den Trusted Installer-Rechten noch leistungsfähiger gemacht werden). Dieses Konto hat mehr Berechtigungen als ein lokales Administratorkonto und wird zur Ausführung der meisten Windows-Dienste verwendet. Es ist auch üblich, dass Dienste von Drittanbietern standardmäßig im Kontext dieses Kontos ausgeführt werden. Das SYSTEM-Konto hat die folgenden Berechtigungen:
| Privileg | Standardzustand |
| SE_ASSIGNPRIMARYTOKEN_NAME | deaktiviert |
| SE_AUDIT_NAME | aktiviert |
| SE_BACKUP_NAME | deaktiviert |
| SE_CHANGE_NOTIFY_NAME | aktiviert |
| SE_CREATE_GLOBAL_NAME | aktiviert |
| SE_CREATE_PAGEFILE_NAME | aktiviert |
| SE_CREATE_PERMANENT_NAME | aktiviert |
| SE_CREATE_TOKEN_NAME | deaktiviert |
| SE_DEBUG_NAME | aktiviert |
| SE_IMPERSONATE_NAME | aktiviert |
| SE_INC_BASE_PRIORITY_NAME | aktiviert |
| SE_LOAD_DRIVER_NAME | deaktiviert |
| SE_LOCK_MEMORY_NAME | aktiviert |
| SE_MANAGE_VOLUME_NAME | deaktiviert |
| SE_PROF_SINGLE_PROCESS_NAME | aktiviert |
| SE_RESTORE_NAME | deaktiviert |
| SE_SECURITY_NAME | deaktiviert |
| SE_SHUTDOWN_NAME | deaktiviert |
| SE_SYSTEM_ENVIRONMENT_NAME | deaktiviert |
| SE_SYSTEMTIME_NAME | deaktiviert |
| SE_TAKE_OWNERSHIP_NAME | deaktiviert |
| SE_TCB_NAME | aktiviert |
| SE_UNDOCK_NAME | deaktiviert |
Das SYSTEM-Konto auf einem domänenverbundenen Host kann eine Active Directory Umgebung untersuchen, indem es sich als Computerkonto ausgibt, welches im Grunde ein spezielles Benutzerkonto ist. Wenn wir während einer Anaylse auf einem domänenverbundenen Host mit SYSTEM-Rechten landen und keine nützlichen Anmeldeinformationen im Speicher oder andere Daten auf dem Computer finden können, gibt es immer noch andere Methoden, die wir tun können. Der Zugriff auf SYSTEM-Ebene in einer Domänenumgebung ist fast gleichbedeutend mit einem Domänenbenutzerkonto. Die einzige wirkliche Einschränkung besteht darin, dass keine cross-trust Kerberos-Angriffe wie Kerberoasting durchgeführt werden können.
Es gibt mehrere Möglichkeiten, sich auf einem Host Zugriff auf die SYSTEM-Ebene zu verschaffen, unter anderem:
– Remote Windows-Exploits wie EternalBlue oder BlueKeep.
– Missbrauch eines Dienstes, der im Kontext des SYSTEM-Kontos ausgeführt wird.
– Missbrauch von SeImpersonate-Privilegien mit RottenPotatoNG gegen ältere
– Windows-Systeme, Juicy Potato oder PrintSpoofer, wenn sie auf Windows 10
Windows Server 2019 abzielen.
– Lokale Schwachstellen zur Ausweitung von Privilegien in Windows-
Betriebssystemen wie der Windows 10 Task Scheduler 0day.
– PsExec mit dem Flag -s
Durch den Zugriff auf SYSTEM-Ebene auf einem domänenverbundenen Host sind wir in der Lage,:
– Durchsuchen der Domäne und Sammeln von Daten wie Informationen über
Domänenbenutzer und -gruppen, lokalen Administratorzugriff,
Domänenvertrauensstellungen, ACLs, Benutzer- und Computereigenschaften usw.
mit BloodHound und PowerView/SharpView.
– Durchführen von Kerberoasting-/ASREPRoasting-Angriffen.
– Ausführen von Tools wie Inveigh zum Sammeln von Net-NTLM-v2-Hashes oder
Durchführen von Relay-Angriffen.
– Durchführen von Token-Impersonation, um ein privilegiertes
Domänenbenutzerkonto zu entführen.
– Durchführen von ACL-Angriffen.
LDAP Übersicht
Das Lightweight Directory Access Protocol (LDAP) ist ein wesentlicher Bestandteil von Active Directory (AD). LDAP ist ein quelloffenes und plattformübergreifendes Protokoll, das für die Authentifizierung bei verschiedenen Verzeichnisdiensten (z. B. AD) verwendet wird. Wie im oben beschrieben, speichert AD Informationen wie Passwörter und erleichtert die gemeinsame Nutzung dieser Informationen mit anderen Geräten im Netzwerk. LDAP ist die Sprache, die Anwendungen zur Kommunikation mit anderen Servern verwenden, die ebenfalls Verzeichnisdienste anbieten. Mit anderen Worten: LDAP ist eine Möglichkeit, wie Systeme in der Netzwerkumgebung mit AD „kommunizieren“ können.
Eine LDAP-Sitzung beginnt damit, dass zunächst eine Verbindung zu einem LDAP-Server hergestellt wird, der auch als Directory System Agent bezeichnet wird. Der Domänencontroller in AD lauscht aktiv auf LDAP-Anforderungen, wie z. B. Sicherheitsauthentifizierungsanforderungen.
Die Beziehung zwischen AD und LDAP kann mit Apache und HTTP verglichen werden. Genauso wie Apache ein Webserver ist, der das HTTP-Protokoll verwendet, ist Active Directory ein Verzeichnisserver, der das LDAP-Protokoll verwendet.
AD LDAP-Authentifizierung
LDAP ist für die Authentifizierung von Anmeldeinformationen gegenüber AD eingerichtet und verwendet eine „BIND“-Operation, um den Authentifizierungsstatus für eine LDAP-Sitzung festzulegen. Es gibt zwei Arten der LDAP-Authentifizierung.
1. Simple Authentication: Dazu gehören die anonyme Authentifizierung, die unauthentifizierte Authentifizierung und die Benutzername/Passwort-Authentifizierung. Einfache Authentifizierung bedeutet, dass ein Benutzername und ein Passwort eine BIND-Anfrage zur Authentifizierung beim LDAP-Server erstellen.
2. SASL Authentication: Das SASL-Framework (Simple Authentication and Security Layer) verwendet andere Authentifizierungsdienste wie Kerberos, um sich an den LDAP-Server zu binden, und verwendet dann diesen Authentifizierungsdienst (in diesem Beispiel Kerberos), um sich bei LDAP zu authentifizieren. Der LDAP-Server verwendet das LDAP-Protokoll, um eine LDAP-Nachricht an den Autorisierungsdienst zu senden, der eine Reihe von Challenge/Response-Nachrichten initiiert, die entweder zu einer erfolgreichen oder nicht erfolgreichen Authentifizierung führen. SASL kann aufgrund der Trennung der Authentifizierungsmethoden von den Anwendungsprotokollen zusätzliche Sicherheit bieten.
LDAP-Authentifizierungsnachrichten werden standardmäßig im Klartext gesendet, so dass jeder LDAP-Nachrichten im internen Netzwerk ausspähen kann. Es wird empfohlen, TLS-Verschlüsselung oder ähnliches zu verwenden, um diese Informationen bei der Übertragung zu schützen.
LDAP Queries
Wir können mit dem Verzeichnisdienst über LDAP-Abfragen kommunizieren, um den Dienst um Informationen zu bitten. Die folgende Abfrage kann zum Beispiel verwendet werden, um alle Workstations in einem Netzwerk zu finden (objectCategory=Computer), während diese Abfrage verwendet werden kann, um alle Domänencontroller zu finden: (&(objectCategory=Computer)(userAccountControl:1.2.840.113556.1.4.803:=8192)).
LDAP-Abfragen können verwendet werden, um benutzerbezogene Suchen durchzuführen, z. B. „(&(objectCategory=person)(objectClass=user))„, die alle Benutzer sucht, sowie gruppenbezogene Suchen wie „(objectClass=group)„, die alle Gruppen zurückgibt. Hier ist ein Beispiel für eine einfache Abfrage, um alle AD-Gruppen mit dem Cmdlet „Get-ADObject“ und dem „LDAPFilter-Parameter“ zu finden.
LDAP-Abfrage – Benutzerbezogene Suche
Get-ADObject -LDAPFilter ‚(objectClass=group)‘ | select name
Wir können auch LDAP-Abfragen verwenden, um eine detailliertere Suche durchzuführen. Diese Abfrage durchsucht die Domäne nach allen administrativ deaktivierten Konten.
LDAP-Abfrage – Detaillierte Suche
Get-ADObject -LDAPFilter ‚(&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=2))‘ -Properties * | select samaccountname,useraccountcontrol
Weitere Beispiele für einfache und erweiterte LDAP-Abfragen für AD finden Sie unter den folgenden Links:
– LDAP-Abfragen in Bezug auf AD-Computer
– LDAP-Abfragen in Bezug auf AD-Benutzer
– LDAP-Abfragen in Bezug auf AD-Gruppen
LDAP-Abfragen sind äußerst nützliche Methoden zur Abfrage von Active Directory. Wir können diese nutzen, um eine Vielzahl von Informationen zu sammeln, die AD-Umgebung zu analysieren und nach Fehlkonfigurationen zu suchen.
Active Directory-Suchfilter
PowerShell Filters
Mit Filtern in PowerShell können Sie über die Pipeline verarbeitete Ausgaben effizienter verarbeiten und genau die Informationen abrufen, die Sie von einem Befehl benötigen. Filter können verwendet werden, um bestimmte Daten in einem großen Ergebnis einzugrenzen oder Daten abzurufen, die dann an einen anderen Befehl weitergeleitet werden können. Wir können Filter mit dem Filter-Parameter verwenden. Ein einfaches Beispiel ist die Abfrage eines Computers nach installierter Software: get-ciminstance win32_product | fl
Der obige Befehl kann eine beachtliche Ausgabe liefern. Wir können den Filter-Parameter mit dem notlike-Operator verwenden, um alle Microsoft-Software herauszufiltern (was bei der Aufzählung eines Systems nach lokalen Vektoren für die Rechteerweiterung nützlich sein kann).
get-ciminstance win32_product -Filter „NOT Vendor like ‚%Microsoft%'“ | fl
Operators
Der Filter-Operator erfordert mindestens einen Operator, der dazu beitragen kann, die Suchergebnisse einzugrenzen oder eine große Menge an Befehlsausgaben auf etwas Verständlicheres zu reduzieren. Richtiges Filtern ist wichtig, vor allem beim Aufzählen großer Umgebungen und bei der Suche nach sehr spezifischen Informationen in der Befehlsausgabe. Die folgenden Operatoren können mit dem Parameter Filter verwendet werden:
| Filter | Bedeutung |
| -eq | Gleich |
| -le | Weniger oder Gleich |
| -ge | Größer oder Gleich |
| -ne | Nicht Gleich |
| -lt | Weniger als |
| -gt | Größer als |
| -approx | Ungefähr gleich |
| -bor | Bitweise OR |
| -band | Bitweise AND |
| -recursivematch | Rekursive Übereinstimmung |
| -like | Wie |
| -notlike | Nicht wie |
| -and | Boolsches AND |
| -or | Boolsches |
| -not | Boolsches Not |
Filter-Beispiele: AD-Objekteigenschaften
Ein Filter kann mit Operatoren verwendet werden, um eine Vielzahl von AD-Objekteigenschaften zu vergleichen, auszuschließen, zu suchen usw.. Filter können in geschweifte Klammern, einfache Anführungszeichen, Klammern oder doppelte Anführungszeichen eingeschlossen werden. Der folgende einfache Suchfilter, der Get-ADUser verwendet, um Informationen über den Benutzer Jonas Borgartz zu finden, kann zum Beispiel wie folgt geschrieben werden:
Get-ADUser -Filter „name -eq ‚jonas borgartz'“
Get-ADUser -Filter {name -eq ‚jonas borgartz‚}
Get-ADUser -Filter ’name -eq „jonas borgartz„‚
Wie oben zu sehen, kann der Eigenschaftswert (hier: sally jones) in einfache oder doppelte Anführungszeichen gesetzt werden. Das Sternchen (*) kann bei Abfragen als Platzhalter verwendet werden. Der Befehl Get-ADUser -filter {name -like „jonas*“} mit einem Platzhalter würde alle Domänenbenutzer zurückgeben, deren Name mit joe beginnt (jonas, jonasl, usw.). Bei der Verwendung von Filtern müssen bestimmte Zeichen escaped werden:
| Zeichen | Escaped als | Hinweis |
| „ | `” | Wird nur benötigt, wenn die Daten in Anführungszeichen gesetzt sind. |
| ‚ | \’ | Nur erforderlich, wenn die Daten in einfache Anführungszeichen gesetzt werden. |
| NUL | \00 | Standard-LDAP-Escape-Sequenz. |
| \ | \5c | Standard-LDAP-Escape-Sequenz. |
| * | \2a | Wird automatisch umgangen, aber nur bei -eq und -ne Vergleichen. Verwenden Sie die Operatoren -like und -notlike für Platzhaltervergleiche. |
| ( | /28 | Automatisch escaped. |
| ) | /29 | Automatisch escaped |
| ) | /29 | Automatisch escaped |
Der folgende Befehl durchsucht alle Hosts in einer Domäne mit Get-ADComputer und filtert nach der Eigenschaft DNSHostName, die das Wort SQL enthält.
Get-ADComputer -Filter „DNSHostName -like ‚SQL*'“
Wir können nach Administrativen Gruppen filtern indem wir nach dem Attribut adminCount filtern. Die Gruppen, bei denen dieses Attribut auf 1 gesetzt ist, sind durch AdminSDHolder geschützt und werden als geschützte Gruppen bezeichnet. AdminSDHolder ist Eigentum der Gruppe Domain Admins. Es hat die Berechtigung, die Berechtigungen von Objekten in Active Directory zu ändern.
Get-ADGroup -Filter „adminCount -eq 1“ | select Name
Wir können auch Filter kombinieren. Suchen wir nach allen administrativen Benutzern, bei denen das Attribut DoesNotRequirePreAuth gesetzt ist, was bedeutet, dass diese für einen ASREP-Roasting Angriff anfällig sind.
Get-ADUser -Filter {adminCount -eq ‚1‘ -and DoesNotRequirePreAuth -eq ‚True‘}
Abschließend noch ein Beispiel für die Kombination von Filtern und die mehrfache Weiterleitung der Ausgabe, um die gewünschten Informationen zu finden. Der folgende Befehl kann verwendet werden, um alle administrativen Benutzer mit dem Attribut „servicePrincipalName“ zu finden, was bedeutet diese für einen Kerberoasting-Angriff anfällig sind. Dieses Beispiel wendet den Parameter Filter an, um Konten zu finden, deren Attribut adminCount auf 1 gesetzt ist, leitet diese Ausgabe weiter, um alle Konten mit einem Service Principal Name (SPN) zu finden, und wählt schließlich einige Attribute zu den Konten aus, darunter den Kontonamen, die Gruppenmitgliedschaft und den SPN.
Get-ADUser -Filter „adminCount -eq ‚1‘“ -Properties * | where servicePrincipalName -ne $null | select SamAccountName,MemberOf,ServicePrincipalName | fl
Es würde extrem viel Zeit in Anspruch nehmen, eine Active Directory-Umgebung mit Kombinationen der oben genannten Befehle zu durchforsten. Dieses letzte Beispiel könnte schnell und einfach mit Tools wie PowerView oder Rubeus durchgeführt werden. Dennoch ist es wichtig, bei der Aufzählung von AD fachkundig Filter anzuwenden, da die Ausgabe von Tools wie PowerView sogar noch weiter gefiltert werden kann, um uns präzise Ergebnisse zu liefern.
LDAP-Suchfilter
Der Parameter LDAPFilter mit denselben Cmdlets ermöglicht die Verwendung von LDAP-Suchfiltern. Die Syntax für diese Filter ist definiert in RFC 4515 – Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters.
LDAP-Filter müssen ein oder mehrere Kriterien enthalten. Gibt es mehr als ein Kriterium, können sie mit logischen AND- oder OR-Operatoren miteinander verknüpft werden. Diese Operatoren werden den Kriterien (Operanden) immer vorangestellt, was auch als polnische Notation bezeichnet wird. Filterregeln sind in Klammern eingeschlossen und können gruppiert werden, indem die Gruppe in Klammern eingeschlossen und einer der folgenden Vergleichsoperatoren verwendet wird:
| Operator | Funktion |
| & | and |
| | | or |
| ! | not |
Einige Beispiele für AND- und OR-Verknüpfungen lauten wie folgt:
AND Operationen:
– Ein Kriterium: (& (..C1..) (..C2..))
– Mehr als zwei Kriterien: (& (..C1..) (..C2..) (..C3..))
OR Operationen:
– Ein Kriterium: (| (..C1..) (..C2..))
– Mehr als zwei Kriterien: (| (..C1..) (..C2..) (..C3..))
Es sind auch verschachtelte Operationen möglich, z. B. „(|(& (..C1..) (..C2..))(& (..C3..) (..C4..)))“ bedeutet „(C1 AND C2) OR (C3 AND C4)“.
Suchkriterien
Beim Schreiben eines LDAP-Suchfilters müssen wir eine Regelanforderung für das betreffende LDAP-Attribut angeben (z. B. „(displayName=jonas)“). Die folgenden Regeln können verwendet werden, um unsere Suchkriterien zu spezifizieren:
| Kriterien | Regel | Beispiel |
| Gleich | (attribute=123) | (&(objectclass=user)(displayName=Smith) |
| Nicht Gleich | (!(attribute=123)) | (!objectClass=group) |
| Vorhanden | (attribute=*) | (department=*) |
| Nicht vorhanden | (!(attribute=*)) | (!homeDirectory=*) |
| Größer als | (attribute>=123) | (maxStorage=100000) |
| Weniger als | (attribute<=123) | (maxStorage<=100000) |
| Ungefährer Treffer | (attribute~=123) | (sAMAccountName~=Jason) |
| Wildcard | (attribute=*A) | (givenName=*Sam) |
Object Identifiers (OIDs)
Wir können auch passende Regeln für Object Identifiers(OIDs) mit LDAP-Filtern verwenden, wie in diesem Suchfilter-Syntax-Dokument von Microsoft aufgeführt:
| Regel OID | String-Bezeichner | Beschreibung |
| 1.2.840.113556.1.4.803 | LDAP_MATCHING_RULE_BIT_AND | Eine Übereinstimmung wird nur gefunden, wenn alle Bits des Attributs mit dem Wert übereinstimmen. Diese Regel ist gleichbedeutend mit einem bitweisen AND-Operator. |
| 1.2.840.113556.1.4.804 | LDAP_MATCHING_RULE_BIT_OR | Eine Übereinstimmung ist gegeben, wenn ein Bit des Attributs mit dem Wert übereinstimmt. Diese Regel ist gleichbedeutend mit einem bitweisen OR-Operator. |
| 1.2.840.113556.1.4.1941 | LDAP_MATCHING_RULE_IN_CHAIN | Diese Regel ist auf Filter beschränkt, die sich auf den DN beziehen. Dies ist ein spezieller „erweiterter“ Übereinstimmungsoperator, der die Abstammungskette in Objekten bis zur Wurzel durchläuft, bis er eine Übereinstimmung findet. |
Wir können die oben genannten OIDs mit einigen Beispielen verdeutlichen. Nehmen wir die folgende LDAP-Abfrage:
(&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=2))
Diese Abfrage gibt alle administrativ deaktivierten Benutzerkonten oder ACCOUNTDISABLE (2) zurück. Wir können diese Abfrage als LDAP-Suchfilter mit dem Cmdlet „Get-ADUser“ für unsere Zieldomäne kombinieren. Die LDAP-Abfrage kann wie folgt gekürzt werden:
Get-ADUser -LDAPFilter ‚(userAccountControl:1.2.840.113556.1.4.803:=2)‘ | select name
Schauen wir uns nun ein Beispiel für die erweiterbare Übereinstimmungsregel „1.2.840.113556.1.4.1941“ an. Betrachten wir die folgende Abfrage:
(member:1.2.840.113556.1.4.1941:=CN=Jonas Borgartz,OU=Hacker,OU=IT,OU=Mitarbeiter,DC=Miracle,DC=LOCAL)
Diese passende Regel findet alle Gruppen, in denen der Benutzer Harry Jones („CN=Jonas Borgartz,OU=Hacker,OU=IT,OU=Mitarbeiter,DC=Miracle,DC=LOCAL„) Mitglied ist. Die Verwendung dieses Filters mit dem Cmdlet „Get-ADGroup“ ergibt die folgende Ausgabe:
LDAP-Abfrage – Alle Gruppen suchen
Get-ADGroup -LDAPFilter ‚(member:1.2.840.113556.1.4.1941:=CN=Jonas Borgartz,OU=Hacker,OU=IT,OU=Mitarbeiter,DC=Miracle,DC=LOCAL)‘ | select Name
Filtertypen, Elementtypen und escaped Zeichen
Bei LDAP-Suchfiltern gibt es die folgenden vier Filtertypen:
| Operator | Bedeutung |
| = | Gleich |
| ~= | Ungefähr gleich |
| >= | Größer oder gleich |
| <= | Kleiner oder gleich |
Und wir haben vier Arten von Elementen:
| Typ | Bedeutung |
| = | Einfach |
| =* | Anwesend |
| =something* | Teilzeichenfolge |
| Extensible | variiert je nach Typ |
Schließlich müssen die folgenden Zeichen bei der Verwendung in einem LDAP-Filter escaped werden:
| Zeichen | in Hex |
| * | \2a |
| ( | \28 |
| ) | \29 |
| \ | \5c |
| NUL | \00 |
Beispiel LDAP Filter
Erstellen wir ein paar weitere LDAP-Filter. Wir können den Filter „(&(objectCategory=user)(description=*))“ verwenden, um alle Benutzerkonten zu finden, die kein leeres Beschreibungsfeld haben. Dies ist eine nützliche Suche, die bei jedem internen Pentest durchgeführt werden sollte, da es nicht ungewöhnlich ist, Passwörter für Benutzer zu finden, die im Benutzerbeschreibungsattribut im AD gespeichert sind (das von allen AD-Benutzern gelesen werden kann). Kombiniert man dies mit dem Cmdlet „Get-ADUser„, kann man nach allen Domänenbenutzern suchen, die kein leeres Beschreibungsfeld haben.
Get-ADUser -Properties * -LDAPFilter ‚(&(objectCategory=user)(description=*))‘ | select samaccountname,description
Der Filter „(userAccountControl:1.2.840.113556.1.4.803:=524288)“ kann verwendet werden, um alle Benutzer oder Computer zu finden, die als vertrauenswürdig für die Delegation oder die uneingeschränkte Delegation gekennzeichnet sind. Mit Hilfe dieses LDAP-Filters können wir die Benutzer aufzählen:
Get-ADUser -Properties * -LDAPFilter ‚(userAccountControl:1.2.840.113556.1.4.803:=524288)‘ | select Name,memberof, servicePrincipalName,TrustedForDelegation | fl
Wir können auch Computer mit dieser Einstellung abfragen:
Get-ADComputer -Properties * -LDAPFilter ‚(userAccountControl:1.2.840.113556.1.4.803:=524288)‘ | select DistinguishedName,servicePrincipalName,TrustedForDelegation | fl
Um nach Benutzern zu suchen deren „adminCount“-Attribut auf 1 gesetzt ist und deren „useraccountcontrol“-Attribut mit dem Flag „PASSWD_NOTREQD“ versehen ist, was bedeutet, dass für das Konto ein leeres Passwort festgelegt werden kann, können wir zwei LDAP-Suchfilter wie folgt kombinieren:
(&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=32))(adminCount=1)
LDAP Query – Users With Blank Password
Get-AdUser -LDAPFilter ‚(&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=32))(adminCount=1)‘ -Properties * | select name,memberof | fl
Es kommt zwar selten vor, aber von Zeit zu Zeit finden wir Konten ohne Passwort. Daher ist es immer wichtig, Konten mit gesetztem PASSWD_NOTREQD-Flag aufzulisten und zu prüfen, ob sie tatsächlich kein Passwort haben. Dies kann absichtlich geschehen (vielleicht als Zeitersparnis) oder versehentlich, wenn ein Benutzer mit dieser Markierung sein Kennwort über die Befehlszeile ändert und versehentlich die Eingabetaste drückt, bevor er ein Kennwort eingibt. Alle Unternehmen sollten regelmäßig Kontenprüfungen durchführen und diese Markierung von allen Konten entfernen, für die es keinen triftigen geschäftlichen Grund gibt, sie zu setzen.
Mehr über LDAP-Filter könnt Ihr hier lernen: https://learn.microsoft.com/en-us/archive/technet-wiki/5392.active-directory-ldap-syntax-filters
Recursive Match
Der Parameter „RecursiveMatch“ kann in ähnlicher Weise verwendet werden wie die Übereinstimmungsregel OID „1.2.840.113556.1.4.1941“. Ein gutes Beispiel hierfür ist die Suche nach allen Gruppen, zu denen ein AD-Benutzer gehört, sowohl direkt als auch indirekt. Dies wird auch als „verschachtelte Gruppenmitgliedschaft“ bezeichnet. Der Benutzer jonas.borgartz ist beispielsweise kein direktes Mitglied der Gruppe Domain Admins, hat aber abgeleitete Domain Admin-Rechte, weil die Gruppe Security Operations Mitglied der Gruppe Domain Admins ist.
Wir können dies mit PowerShell auf verschiedene Arten auflisten, eine Möglichkeit ist das Cmdlet „Get-ADGroupMember“.
Get-ADGroupMember -Identity „Security Operations“
Die Suche nach der Gruppenzugehörigkeit eines Benutzers mit Get-ADUser, die sich auf die Eigenschaft memberof konzentriert, zeigt keine verschachtelten Gruppenmitgliedschaften an. Wir können verschachtelte Gruppenmitgliedschaften mit der OID der passenden Regel und dem RecursiveMatch-Parameter finden, wie in den folgenden Beispielen zu sehen ist. Das erste Beispiel zeigt einen AD-Filter und den RecursiveMatch, um rekursiv nach allen Gruppen zu suchen, in denen der Benutzer jonas.borgartz Mitglied ist.
Get-ADGroup -Filter ‚member -RecursiveMatch „CN=Jonas Borgartz,OU=Ethical Hacker,OU=IT,OU=Mitarbeiter,DC=MIRACLE,DC=LOCAL“‚ | select name
Eine andere Möglichkeit, dieselben Informationen zurückzugeben, ist die Verwendung eines LDAPFilters und der passenden Regel-OID.
Get-ADGroup -LDAPFilter ‚(member:1.2.840.113556.1.4.1941:=CN=Jonas Borgartz,OU=Ethical Hacker,OU=IT,OU=Mitarbeiter,DC=MIRACLE,DC=LOCAL)‘ |select Name
SearchBase- und SearchScope-Parameter
Selbst kleine Active Directory-Umgebungen können Hunderte, wenn nicht Tausende von Objekten enthalten. Active Directory kann sehr schnell wachsen, wenn Benutzer, Gruppen, Computer, OUs usw. hinzugefügt und ACLs eingerichtet werden, wodurch ein immer komplexeres Netz von Beziehungen entsteht. Es kann auch sein, dass wir uns in einer riesigen, 10-20 Jahre alten Umgebung mit Zehntausenden von Objekten befinden. Die Untersuchung dieser Umgebungen kann zu einer unhandlichen Aufgabe werden, so dass wir unsere Suche verfeinern müssen.
Wir können die Leistung unserer Befehle und -skripte verbessern und die Menge der zurückgegebenen Objekte reduzieren, indem wir unsere Suchen mit dem Parameter „SearchBase“ einschränken. Dieser Parameter gibt einen Active Directory-Pfad an, unter dem gesucht werden soll, und ermöglicht es, die Suche nach einem Benutzerkonto in einer bestimmten OU zu beginnen. Der Parameter „SearchBase“ akzeptiert einen OUs Distinguished Name (DN) wie „OU=Mitarbeiter,DC=MIRACLE,DC=LOCAL“.
Mit „SearchScope“ können wir festlegen, wie tief wir in der OU-Hierarchie suchen möchten. Dieser Parameter hat drei Stufen:
| Name | Level | Beschreibung |
| Basis | 0 | Das Objekt wird als SearchBase angegeben. Wenn wir zum Beispiel nach allen Benutzern in einer OU fragen, die einen Basisbereich definiert, erhalten wir keine Ergebnisse. Wenn wir einen Benutzer angeben oder Get-ADObject verwenden, erhalten wir nur diesen Benutzer oder dieses Objekt zurück. |
| OneLevel | 1 | Sucht nach Objekten in dem durch die SearchBase definierten Container, aber nicht in Untercontainern. |
| SubTree | 2 | Sucht nach Objekten, die in der SearchBase und allen untergeordneten Containern, einschließlich ihrer Kinder, enthalten sind, rekursiv in der gesamten AD-Hierarchie. |
Bei der Abfrage von AD mit „SearchScope“ können wir den Namen oder die Nummer angeben (d.h. SearchScope Onelevel wird genauso interpretiert wie „SearchScope 1“).
SearchBase und SearchScope Parmameter Beispiele
Schauen wir uns einige Beispielabfragen an, um den Unterschied zwischen Base, OneLevel und Subtree zu verdeutlichen. In diesen Beispielen konzentrieren wir uns auf die OU „Mitarbeiter“.
Alle AD Benutzer aufzählen:
PS C:\> (Get-ADUser -SearchBase „OU=Mitarbeiter,DC=MIRACLE,DC=LOCAL“ -Filter *).count
500
Erwartungsgemäß gibt die Angabe mit SearchScope von Base nichts zurück.
PS C:\> Get-ADUser -SearchBase „OU=Mitarbeiter,DC=MIRACLE,DC=LOCAL“ -SearchScope Base -Filter *
PS C:\>
Wenn wir jedoch „Base“ mit „Get-ADObject“ angeben, erhalten wir nur das Objekt (Mitarbeiter OU) zurück.
PS C:\> Get-ADObject -SearchBase „OU=Mitarbeiter,DC=MIRACLE,DC=LOCAL“ -SearchScope Base -Filter *
DistinguishedName Name ObjectClass ObjectGUID
—————– —- ———– ———-
OU=Mitarbeiter,DC=MIRACLE,DC=LOCAL MitarbeiterorganizationalUnit 38f82767-9a2e-593f-bfc6-776bdg0b2087
Wenn wir OneLevel als SearchScope angeben, erhalten wir einen Benutzer zurück.
PS C:\> Get-ADUser -SearchBase „OU=Mitarbeiter,DC=MIRACLE,DC=LOCAL“ -SearchScope OneLevel -Filter *
DistinguishedName : CN=Jonas Borgartz ,OU=Mitarbeiter,DC=MIRACLE,DC=LOCAL
Enabled : True
GivenName : jonas
Name : Jonas Borgartz
ObjectClass : user
ObjectGUID : 3f54328f-cc2e-547c-56fe-58ee595166c0
SamAccountName : jonas.borgartz
SID : S-1-5-21-2974783334-34321228446-2222799441-1313
Surname : borgartz
UserPrincipalName : jonas.borgartz@miracle
Wenn wir schließlich Subtree in SearchBase angeben, erhalten wir alle Objekte in allen untergeordneten Containern, was der oben festgelegten Benutzerzahl entspricht.
PS C:\> (Get-ADUser -SearchBase „OU=Mitarbeiter,DC=MIRACLE,DC=LOCAL“ -SearchScope Subtree -Filter *).count
970
Enumeration von Active Directory mit Built-in Tools
Eine ordnungsgemäße Analyze ist ein wichtiger Bestandteil für alle Penetrationstests und Red-Teaming-Projekte. Die Analyse von AD, insbesondere in großen Unternehmensumgebungen mit vielen Hosts, Benutzern und Diensten, kann eine ziemlich anstregende Aufgabe sein und eine überwältigende Menge an Daten liefern. Mehrere eingebaute Windows-Tools können von Sysadmins und Pentestern zur Aufzählung von AD verwendet werden. Open-Source-Tools wurden auf der Grundlage der gleichen Techniken entwickelt. Viele dieser Tools (wie SharpView, BloodHound und PingCastle) können eingesetzt werden, um den Analyzeprozess zu beschleunigen und die Daten in einem konsumierbaren und umsetzbaren Format zu präsentieren. Die Kenntnis mehrerer Tools und „Offense in-depth“ ist wichtig, wenn Sie bei einem Test „living of the land“ anwenden müssen oder bestimmte Tools aufgrund von IDS/IPs Systemen nicht funktionieren.
User-Account-Control (UAC) Attribute
User-Account-Control-Attribute steuern das Verhalten von Domänenkonten. Diese Werte sind nicht zu verwechseln mit der Windows User Account Control-Technologie. Viele dieser UAC-Attribute sind sicherheitsrelevant: https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/useraccountcontrol-manipulate-account-properties
Wir können diese Werte mit AD-Cmdlets aufzählen:
PS C:\> Get-ADUser -Filter {adminCount -gt 0} -Properties admincount,useraccountcontrol | select Name,useraccountcontrol
Name useraccountcontrol
—- ——————
Administrator 66048
krbtgt 66050
jonas.borgartz 512
sqltest 512
sql-backup 66048
sql-dev 66048
Um die useraccountcontrol-Werte zu interpretieren, müssen wir sie noch in die entsprechenden Flags umwandeln. Dies kann mit diesem Skript geschehen. Nehmen wir den Benutzer Jonas Borgartz mit dem useraccountcontrol-Wert 512 als Beispiel.
PS C:\> .\Convert-UserAccountControlValues.ps1
Please provide the userAccountControl value: : 512
Name Value
—- —–
PASSWD_NOTREQD 32
NORMAL_ACCOUNT 512
DONT_EXPIRE_PASSWORD 65536
DONT_REQ_PREAUTH 4194304
Wir können auch PowerView verwenden, um diese Werte aufzuzählen. Wir sehen, dass einige der Benutzer mit dem Standardwert 512 oder Normal_Account übereinstimmen, während andere umgewandelt werden müssen.
PowerView – Domänenkonten
PS C:\> Get-DomainUser * -AdminCount | select samaccountname,useraccountcontrol
samaccountname useraccountcontrol
————– ——————
Administrator NORMAL_ACCOUNT, DONT_EXPIRE_PASSWORD
krbtgt ACCOUNTDISABLE, NORMAL_ACCOUNT, DONT_EXPIRE_PASSWORD
jonas.borgartz NORMAL_ACCOUNT
sqltest NORMAL_ACCOUNT
sql-backup NORMAL_ACCOUNT, DONT_EXPIRE_PASSWORD
sql-sec NORMAL_ACCOUNT, DONT_EXPIRE_PASSWORD
clara.moor NORMAL_ACCOUNT, DONT_EXPIRE_PASSWORD
Enumeration mit eingebauten Tools
Tools, die Sysadmins wahrscheinlich selbst verwenden, wie z. B. das PowerShell AD-Module, die Sysinternals Suite und die AD DS-Tools, stehen wahrscheinlich auf der Whitelist und bleiben unbemerkt. Mehrere integrierte Tools können für die AD-Enumeration genutzt werden, darunter:
DS Tools ist standardmäßig auf allen modernen Windows-Betriebssystemen verfügbar, erfordert jedoch eine Domänenverbindung, um Enumeration-Aktivitäten durchzuführen.
C:\> dsquery user „OU=Mitarbeiter,DC=miracle,DC=local“ -name * -scope subtree -limit 0 | dsget user -samid –
pwdneverexpires | findstr /V no
samid pwdneverexpires
sql-backup yes
sql-scan yes
sql-se yes
sql-test yes
clara.moor yes
jonas.borgartz yes
<SNIP>
dsget succeeded
Windows Management Instrumentation (WMI) kann auch für den Zugriff und die Abfrage von Objekten in Active Directory verwendet werden. Viele Skriptsprachen können mit dem WMI AD Provider interagieren, aber PowerShell macht dies sehr einfach.
Get-WmiObject -Class win32_group -Filter „Domain=’MIRACLE'“ | Select Caption,Name
Active Directory Service Interfaces (ADSI) ist ein Satz von COM-Schnittstellen, die Active Directory abfragen können. PowerShell bietet wiederum eine einfache Möglichkeit, damit zu interagieren.
([adsisearcher]“(&(objectClass=Computer))“).FindAll() | select Path
LDAP Anonymous Bind
LDAP anonymous binds ermöglicht es nicht authentifizierten Angreifern, Informationen aus der Domäne abzurufen, z. B. eine vollständige Auflistung von Benutzern, Gruppen, Computern, Benutzerkontoattributen und der Domänenkennwortrichtlinie. Linux-Hosts mit Open-Source-Versionen von LDAP und Linux vCenter-Appliances sind häufig so konfiguriert, dass sie anonymous binds zulassen.
Wenn ein LDAP-Server anonymous binds zulässt, muss ein Angreifer kein Objekt kennen, um eine beträchtliche Menge an Informationen aus der Domäne abzufragen. Dies kann auch genutzt werden, um einen Passwort-Spraying-Angriff durchzuführen oder Informationen wie Passwörter aus Kontobeschreibungsfeldern auszulesen. Tools wie windapsearch und ldapsearch können zum Aufzählen von Domäneninformationen über eine anonyme LDAP-Verbindung verwendet werden. Die Informationen, die wir über eine anonyme LDAP-Verbindung erhalten, können genutzt werden, um einen Passwort-Spraying- oder AS-REPRoasting-Angriff zu starten und Informationen wie Passwörter, die in Kontobeschreibungsfeldern gespeichert sind, zu lesen.
Wir können LDAP anonymous bind mit ldapsearch untersuchen und alle AD-Objekte aus LDAP abrufen.
ldapsearch -H ldap://192.168.10.101-x -b „dc=miracle,dc=local“
Windapsearch ist ein Python-Skript, das anonyme und authentifizierte LDAP-Aufzählungen von AD-Benutzern, -Gruppen und -Computern mithilfe von LDAP-Abfragen durchführt. Es ist eine Alternative zu Tools wie ldapsearch, für die Sie eigene LDAP-Abfragen erstellen müssen. Wir können es verwenden, um die LDAP-NULL Session Authentifizierung zu bestätigen, indem wir einen leeren Benutzernamen mit -u „“ angeben und –functionality hinzufügen, um die Domänenfunktionsebene zu bestätigen.
python3 windapsearch.py –dc-ip 192.168.10.101 -u „“ –functionality
Wir können eine Liste aller Domänenbenutzer erstellen, die wir für einen Passwort-Spraying-Angriff verwenden können.
python3 windapsearch.py –dc-ip 192.168.10.101 -u „“ -U
Wir können Informationen über alle Domänencomputer erhalten.
python3 windapsearch.py –dc-ip 192.168.10.101 -u „“ -C
Credentialed LDAP Enumeration
Wie bei SMB können wir, sobald wir die Domänenanmeldeinformationen haben, eine Vielzahl von Informationen aus LDAP extrahieren, einschließlich Benutzer, Gruppe, Computer, Vertrauen, GPO-Informationen, die Domänenkennwortrichtlinie usw. ldapsearch-ad.py und windapsearch sind nützlich für die Durchführung dieser Aufzählung.
python3 windapsearch.py –dc-ip 192.168.10.101 -u miracle\\jonas.borgartz –da
Ldapsearch-ad
Dieses Tool kann alle Standardaufzählungen und einige integrierte Suchen durchführen, um die Dinge zu vereinfachen. Wir können schnell die Kennwortrichtlinie abrufen.
python3 ldapsearch-ad.py -l 10.129.1.207 -d miracle-u jonas.borgartz -p Sommer2020 -t pass-pols