In diesem Beitrag wird die Bedeutung von Standard-Leseberechtigungen in der Active Directory (AD)-Sicherheit hervorgehoben, die oft vernachlässigt wird. Der AD-Forest ist nicht nur eine Sicherheitsgrenze, sondern sollte auch als der Bereich betrachtet werden, auf den ein Eindringling zugreifen und die Sicherheit von AD-Objekten bewerten kann, nachdem er in das Netzwerk einer Organisation eingedrungen ist. Das Entfernen bestimmter Standard-Leseberechtigungen ist eine risikoarme Maßnahme, die es Eindringlingen erschwert, Erkundungen durchzuführen und ihre nächsten Schritte zu planen. Das Verständnis der eingebauten Logik von Microsofts Schutzmechanismus für die privilegiertesten Konten im Verzeichnis ist entscheidend für das Verständnis der Vor- und Nachteile dieses Mechanismus.
In diesem Beitrag wird erläutert, wie Sie den Schutzmechanismus anpassen können, indem Sie riskante Standard-Leseberechtigungen entfernen, um die AD-Sicherheit zu verbessern. Darüber hinaus befasst sich das Papier mit dem Problem der Fehlkonfiguration in den meisten AD-Infrastrukturen und damit, wie man die Berechtigungen für Objekte korrigiert, die einst Teil einer privilegierten Gruppe waren, jetzt aber nicht mehr sind. Letztendlich ist die Sicherung von AD durch die Einschränkung der Sichtbarkeit von Objekten und der allgemeinen Leseberechtigungen entscheidend für die Reduzierung der Angriffsfläche von AD und die Verbesserung der Sicherheit.
Einschränkung der Aufklärung und der seitlichen Bewegungsfreiheit
Eine ordnungsgemäße Sperrung wirkt sich direkt darauf aus, wie schwierig - oder einfach - es für Eindringlinge ist, Active Directory (AD) während der Aufklärungsphase eines Angriffs gegen Sie zu verwenden.
Wie in Abbildung 1 dargestellt, tritt diese Phase ein, nachdem ein bösartiger Benutzer in Ihrem Unternehmensnetzwerk Fuß gefasst hat, in der Regel durch Täuschung Ihrer Mitarbeiter über Phishing-E-Mails oder spezielle bösartige Websites. In diesem Stadium hat der Eindringling in der Regel nur das AD-Konto eines normalen authentifizierten Benutzers übernommen (d.h. ein nicht privilegiertes Mitarbeiterkonto, das nicht das AD Ihres Unternehmens verwaltet). Sie denken vielleicht, dass ein unprivilegierter Benutzer keine Bedrohung für die Sicherheit Ihres Unternehmens darstellt, aber wie lange wird ein Eindringling unprivilegiert bleiben? Eindringlinge nutzen zunächst bekannte Schwachstellen des Betriebssystems oder der Treiber auf unzureichend gepatchten Endgeräten, um ihre lokalen Privilegien zu erhöhen und so schnell administrativen Zugriff auf den kompromittierten Client zu erhalten. Dies ermöglicht es ihnen, andere Schutzmechanismen auf dem Client zu deaktivieren, weitere Malware herunterzuladen und ein Befehls- und Kontrollsystem einzurichten, das in der Regel einen direkten Fernzugriff durch andere Bandenmitglieder ermöglicht. Das nächste Ziel wäre es, sich seitlich zu anderen Clients zu bewegen und eine ordentliche Erkundung durchzuführen, mit dem Ziel, ein Domänen-Administratorkonto zu kompromittieren, um schließlich die Domänenherrschaft zu erlangen.
Dennoch ist das eigentliche Ziel des Eindringlings klar: an Ihre sensiblen Geschäftsdaten zu gelangen und sie zu extrahieren, um Sie unter Druck zu setzen. Besser noch, diesen Druck zu erhöhen, indem so viele Systeme in Ihrer Umgebung wie möglich verschlüsselt werden, einschließlich aller Server, ihrer Backups und der Sicherheitskopien dieser Backups. Auf diese Aktionen folgt dann eine freundliche Lösegeldforderung, in der eine Bitcoin-Zahlung innerhalb weniger Stunden oder Tage gefordert wird und versprochen wird, dass Sie bei Zahlung einen Entschlüsselungsschlüssel erhalten und Ihre sensiblen Daten definitiv nicht an den Meistbietenden im Dark Web weitergegeben werden. Würden Sie zahlen? Im Idealfall werden Sie diese Frage nicht beantworten müssen. Stattdessen werden Sie Ihre Bemühungen darauf verwenden, Eindringlinge daran zu hindern, ihr Ziel zu erreichen, Ihr AD zu übernehmen und Ihr Unternehmen zu zerstören. Der erste Schritt besteht darin, es jedem Eindringling zu erschweren, Ihre privilegierten Benutzer zu finden und sensible Daten aus Ihrem AD zu lesen.
Das Sperren von AD kann den Unterschied ausmachen
Ein "Lockdown" von AD bezieht sich in der Regel auf die Änderung von Berechtigungen im Verzeichnis (d.h. die Änderung einiger der Standardberechtigungen). Leider sind diese Berechtigungen viel zu offen und geben zu viele der in Ihrem AD gespeicherten Informationen an die Bösewichte weiter. Typische Benutzer und Geschäftsanwendungen benötigen diese Informationen nur selten, so dass das Entfernen einiger Berechtigungen im AD Sie der allgemeinen Best Practice der IT-Sicherheit sehr viel näher bringt: dem Modell der geringsten Privilegien, bei dem Sie Benutzern nur so viele Berechtigungen erteilen, wie sie für ihre Arbeit benötigen. Bei jeder Änderung von Berechtigungen im AD müssen Sie jedoch immer das Für und Wider abwägen, wie sich diese Änderungen auf Ihre Geschäftsanwendungen auswirken könnten. Denn ein absolut sicheres AD, das Ihre Geschäftsanwendungen nicht unterstützt, ist für Sie keine Hilfe. Im Idealfall verfügen Sie über eine solide Testumgebung, die nicht nur eine Test-AD-Forest enthält (die genauso konfiguriert ist wie Ihre Produktions-AD), sondern auch eine Kopie der wichtigsten Geschäftsanwendungen, die Sie verwenden. In dieser Umgebung können Sie die Auswirkungen von Änderungen der Berechtigungen im AD testen, bevor Sie sie in der Produktion implementieren.
In jedem Fall müssen Änderungen der Berechtigungen sorgfältig geplant werden (siehe Abbildung 2). Die gute Nachricht ist, dass es relativ einfach ist, die ursprünglichen Berechtigungen wiederherzustellen (z.B. wenn bei Ihren Tests einige Artefakte übersehen wurden). Die Dokumentation der Berechtigungen, die Sie im AD ändern, ist entscheidend, damit Sie solche Änderungen rückgängig machen können. Ein geeignetes AD-Auditing-Tool kann dies für Sie tun und sorgt dafür, dass Sie auf der sicheren Seite sind.
Ihre privilegierten Objekte sind ein Hauptziel für Eindringlinge
Wenn Sie einen bestimmten Bereich auswählen müssen, um mit der Sperrung Ihres AD zu beginnen, sollte die erste Wahl eindeutig Ihre privilegierten Konten und Gruppen sein. Dabei handelt es sich um Ihre Unternehmens- und Domänenadministratorengruppen und deren Mitglieder, aber auch um die anderen speziellen Gruppen wie Kontobetreiber, Serverbetreiber usw. und deren Mitglieder. In einem richtig konfigurierten AD wird keine Ihrer Geschäftsanwendungen diese privilegierten Gruppen und Konten verwenden. Solche Anwendungen müssen auch keine LDAP-Abfrage (Lightweight Directory Access Protocol) durchführen, wie z.B. "Wer ist Mitglied der Gruppe der Domänenadministratoren", um zu funktionieren. Daher ist diese AD-Sperre in der Regel eine risikoarme Aufgabe. AD verwendet das Attribut 'adminCount' bei Objekten, um diejenigen zu kennzeichnen, die es als 'privilegiert' einstuft. Die entsprechenden Objekte haben dieses Attribut auf 1 gesetzt. Um zu verstehen, welche Gruppen Ihr AD als privilegiert einstuft, können Sie eine einfache LDAP-Abfrage mit dem folgenden Filter durchführen:1
(&(groupType:1.2.840.113556.1.4.803:= 2147483648)(admincount=1))
Diese Abfrage sucht nur nach Sicherheitsgruppen, insbesondere nach solchen, die mit einer '1' in ihrem adminCount-Attribut gekennzeichnet sind. Verwenden Sie Ihre bevorzugte LDAP-Abfragemethode, z.B. DSQUERY:
dsquery * domainroot “(&(groupType: 1.2.840.113556.1.4.803:=2147483648) (admincount=1))”
oder PowerShell:
Get-ADObject -LDAPfilter “(&(groupType: 1.2.840.113556.1.4.803:=2147483648) (admincount=1))”
oder den LDAP-Filter direkt in der AD Users & Computers Microsoft Management Console (MMC) mit der Option Benutzerdefinierte Suche/Erweitert (siehe Abbildung 3). Die Ergebnisse in Ihrer Domäne könnten anders ausfallen, insbesondere wenn Sie andere Gruppen in diese standardmäßigen privilegierten Gruppen verschachtelt haben, auch wenn dies nur vorübergehend ist. Die Ergebnisse hängen auch von der Betriebssystemversion Ihrer AD-Domänencontroller ab und davon, wie Sie zwischen den Versionen aktualisiert haben. Im Idealfall weicht Ihre Liste jedoch nicht allzu sehr von dieser Vorgabe ab. Falls doch, haben Sie möglicherweise einige Bereinigungsarbeiten (siehe unten) vor sich. Zunächst ist es wichtig zu verstehen, was das Attribut adminCount bedeutet und woher es stammt, sowie einige Grundlagen des AD-Verhaltens und -Designs.
Die fein abgestufte Delegation von Berechtigungen war ein Eckpfeiler des Erfolgs von AD
Als Microsoft vor mehr als 23 Jahren AD entwickelte, fügte es leistungsstarke Funktionen zur Delegation von Berechtigungen hinzu, und zwar bis hin zu jedem Attribut der Objekte im Verzeichnis. Die Grundlage dieser Fähigkeit war die Speicherung separater Berechtigungen, genannt Sicherheitsdeskriptor oder Zugriffskontrollliste (ACL), für jedes Objekt in AD als Teil des Objekts selbst (gespeichert im Attribut nTSecurityDescriptor ). Das AD-Sicherheitsmodell unterstützte die Vererbung von Berechtigungen über einen ganzen Baum von Organisationseinheiten (OUs) hinweg, um Berechtigungen effizient zu konfigurieren, ohne sie für alle Objekte einzeln festlegen zu müssen. Das Modell ermöglichte es aber auch, explizite Berechtigungen direkt für ein Objekt (z.B. eine andere OU, einen Benutzer oder eine Gruppe) festzulegen (siehe Abbildung 4). Die expliziten Berechtigungen dieses Objekts konnten mit den geerbten Berechtigungen gemischt werden oder die Vererbung von Berechtigungen vom übergeordneten Objekt blockieren.
Diese Flexibilität ermöglichte es selbst den größten Unternehmen, ein zentrales, globales IT-Verzeichnis zu verwenden, mit dem wichtige Supportaufgaben an andere Teams delegiert werden konnten. Zu der Zeit, als AD entwickelt wurde, war es üblich, in jedem Land, in dem ein Unternehmen tätig war, separate Helpdesk-Teams einzusetzen. Diese Teams übernahmen klassische Supportaufgaben wie das Zurücksetzen des Kennworts eines Benutzerkontos in ihrer Region, das Hinzufügen von Computerobjekten oder sogar das Hinzufügen von Benutzern zu Gruppen, die für den Geschäftsbetrieb erforderlich waren. Durch die Delegation von Berechtigungen auf der richtigen OU-Ebene (z.B. OU=PHX,OU=US, DC=mycompany,DC=com) und die Vererbung von Berechtigungen auf die relevanten Objekte (z.B. Benutzer, Computer, Gruppen) in der gesamten OU-Verzweigung konnten die Mitglieder einer entsprechenden Helpdesk-AD-Gruppe alle notwendigen Supportaufgaben für die Benutzer, Computer und Gruppen in jeder der Unter-OUs durchführen. Diese Fähigkeit setzte nicht voraus, dass die Gruppenmitglieder die Berechtigung hatten, den AD-Dienst selbst zu verwalten. Mit anderen Worten: Die Helpdesk-Mitarbeiter waren nicht Mitglied der Gruppe der Domänenadministratoren und konnten die AD-Konfiguration nicht ändern, keine neuen Domänencontroller (DCs) befördern und sich nicht bei AD-Domänencontrollern anmelden.
Solche Helpdesk-Benutzer mit spezifischen delegierten Rechten in AD werden als AD-Datenadministratoren bezeichnet, während die wirklich privilegierten Konten, wie z.B. Domänenadministratoren, als AD-Serviceadministratoren bekannt sind. Was aber, wenn sich ein 'echtes' Domänenadministratorkonto in einer Unter-OU befindet, der die Helpdesk-Mitarbeiter die Rechte zum Zurücksetzen von Benutzerkennwörtern erteilen? Oder schlimmer noch, was ist, wenn jemand dem Helpdesk keine Rechte auf der richtigen Sub-OU-Ebene erteilt, sondern dies auf der Domänen-Root-Ebene tut? Ohne einen zusätzlichen Schutzmechanismus in AD, der verhindert, dass ein Datenadministrator, wie z.B. ein Helpdesk-Konto, Änderungen (wie z.B. das Zurücksetzen des Kennworts) an einem Dienstadministrator, wie z.B. einem Domänenadministratorkonto oder einem anderen privilegierten Konto oder einer Gruppe, vornimmt, wäre die Gesamtsicherheit jeder AD-Implementierung in einem schlechten Zustand. Jeder beauftragte Helpdesk-Mitarbeiter könnte leicht das gesamte AD kompromittieren.
SDPROP: Die eingebaute AD-Schutzfunktion
Der Schutz dieser privilegierten AD-Objekte ist genau die Aufgabe des Security Descriptor Propagation (SDPROP) Prozesses. Dieser Prozess läuft regelmäßig (standardmäßig alle 60 Minuten oder wie konfiguriert) auf jedem primären Domänencontroller-Emulator (PDCE) jeder Domäne in einem AD Forest und sucht nach allen privilegierten Objekten in der jeweiligen AD-Domäne. SDPROP prüft nicht nur die Mitgliedschaft in den Standardgruppen (z.B. Domänenadministratoren), sondern verfolgt weiterhin alle Gruppen, die in diesen privilegierten Gruppen verschachtelt sind, und markiert sie und ihre Mitglieder als 'privilegiert'. Da Sie zu diesen privilegierten Gruppen Benutzer, Gruppen und sogar Computerobjekte hinzufügen können, werden alle diese Objekte bei der Überprüfung berücksichtigt. Wichtiger Hinweis: Die Objekte müssen sich in derselben Domäne befinden wie die privilegierte Gruppe, damit sie von SDPROP berücksichtigt werden. Erwarten Sie also nicht den gleichen Schutz für Benutzer, die aus einer anderen Domäne hinzugefügt wurden.
Für jedes privilegierte Objekt, das SDPROP findet, vergleicht der Prozess den nTSecurityDescriptor des Objekts mit einer speziellen Berechtigungsvorlage, die ausschließlich für den Schutz dieser privilegierten Objekte reserviert ist. Diese Vorlage gewährt eine Reihe von Berechtigungen, stellt aber vor allem sicher, dass nur Administratoren, Domänenadministratoren und Unternehmensadministratoren das Kennwort von privilegierten Konten ändern können. Wenn der SDPROP-Prozess eine Abweichung zwischen den Berechtigungen auf den gefundenen Objekten und denen in der Vorlage feststellt, ersetzt er den nTSecurityDescriptor des betreffenden Objekts durch den in der Vorlage und aktualisiert dann das Attribut adminCount des Objekts mit einer '1'.
Hinter den Kulissen: AdminSDHolder
Die spezielle Berechtigungsvorlage, die SDPROP in Ihre privilegierten Objekte kopiert, ist konfigurierbar. Es ist der nTSecurityDescriptor(permissions) aus dem AdminSDHolder-Objekt Ihrer Domäne. Dieser Name sollte Ihnen bekannt vorkommen: Es handelt sich um das Objekt 'Admin Security Descriptor Holder', ein Container-Objekt, das sich im System-Container jeder Domäne befindet(CN=AdminSDHolder,CN=System,DC=myco mpany,DC=com). Die Standardberechtigungen für AdminSDHolder sind vergleichsweise restriktiv, was Änderungen an den Objekten angeht. Das ist das, was Sie von Berechtigungen erwarten würden, die allen privilegierten Gruppen und Benutzern in Ihrem AD aufgedrückt werden sollen. Die Beispielliste der Berechtigungen in Abbildung 5 stammt aus einer kürzlich erfolgten Bereitstellung eines Testlabors auf Windows Server 2019, das keine Exchange-Server enthält. Wenn Sie Exchange in Ihrer Umgebung haben, werden Sie weitere Berechtigungen zu dieser Vorlage hinzufügen. Schließlich hatten die Exchange-Entwickler erwogen, das AD für ihre Anwendung zu "besitzen". Denken Sie vorerst daran, dass die folgenden Berechtigungen auf alle Ihre privilegierten Objekte in der jeweiligen AD-Domäne gestempelt werden. Vor allem aber können Sie sehen, dass in dieser Zugriffskontrollliste (ACL) die Vererbung nicht aktiviert ist. Mit anderen Worten, die ACL blockiert die Vererbung der Berechtigungen, die auf einem übergeordneten Objekt (OU) festgelegt sind, einschließlich der bereits erwähnten Berechtigungen zum Zurücksetzen des Helpdesk-Passworts. Auf diese Weise schützt die Kombination aus SDPROP und AdminSDHolder Ihre privilegiertesten Konten vor schlecht konfigurierten Berechtigungen in Ihrem AD.
Technisch gesehen können Sie einige Standard-Administratorgruppen im AD davon abhalten, vom SDPROP-Prozess als privilegiert betrachtet zu werden, insbesondere die Gruppen der Kontobetreiber, Server-Betreiber, Druck-Betreiber und Backup-Betreiber. Die Mitglieder würden dann nicht mit den Berechtigungen aus dem AdminSDHolder-Objekt überschrieben werden. Da jedoch jede Gruppe ihr eigenes Risiko in Bezug auf die Erhöhung von Berechtigungen in AD hat, wird diese Konfiguration nicht empfohlen. Es lohnt sich, diese Gruppen zu schützen, oder noch besser, sie gar nicht erst zu verwenden. Wenn Sie mehr darüber erfahren möchten, wie Sie diese Gruppen vom SDPROP-Prozess ausschließen (oder wieder einschließen), lesen Sie den Artikel 'Active Directory-Sicherheit: Das AdminSDHolder Objekt verstehen'.2
Die Rolle des Attributs AdminCount
Das Attribut adminCount selbst hat keine wirkliche Sicherheitsrelevanz. Es ist ein einfaches Hilfsmerkmal, mit dem Sie über eine LDAP-Abfrage leichter feststellen können, welche Berechtigungen für Objekte durch die für diese spezielle Vorlage festgelegten Berechtigungen ersetzt wurden, wie oben gezeigt. Beachten Sie, dass ein Benutzer, eine Gruppe oder ein Computer, den Sie aus einer privilegierten Gruppe entfernen , nicht mehr privilegiert ist. Der SDPROP-Prozess schreibt die Ereignis-ID 4780 in das Sicherheitsereignisprotokoll des primären Domänencontrollers (PDC), wenn er die AdminSDHolder-Berechtigungen für privilegierte Objekte stempelt und diese Objekte mit dem Attribut adminCount (auf 1 gesetzt) aktualisiert. Es macht diese Änderungen jedoch weder rückgängig, sobald ein Objekt nicht mehr privilegiert ist, noch schreibt es ein Ereignis in das Ereignisprotokoll, das Sie darüber informiert, dass es nicht mehr als privilegiert gilt. Wenn Sie beispielsweise jemanden vorübergehend zur Gruppe der Domänenadmins hinzufügen und der SDPROP-Prozess ausgeführt wird, bevor Sie den Benutzer entfernen, hat dieser Benutzer immer noch die gesperrte nTSecurityDescriptor-Einstellung und ist mit adminCount=1 gekennzeichnet. Das Gleiche gilt für jedes Objekt. Idealerweise sollten Sie also keinen Benutzer vorübergehend zu einer privilegierten Gruppe hinzufügen. Wenn Sie dies doch getan haben, sollten Sie die Berechtigungen und das adminCount-Attribut bereinigen, damit der Benutzer wieder in seinen ursprünglichen Zustand versetzt wird. Dieser Bereinigungsprozess wird später in diesem Dokument beschrieben.
Ein genauerer Blick auf AdminSDHolder-Berechtigungen
Wenn Sie diese Konzepte verstanden haben, sind Sie dann mit den Berechtigungen zufrieden, die über das AdminSDHolder-Objekt und SDPROP für alle Ihre privilegierten Konten erteilt werden? Wenn Sie sich diese Berechtigungen genauer ansehen, auch ohne Exchange, werden Ihnen einige fragwürdige Berechtigungen auffallen, wie in Abbildung 6 hervorgehoben, die der Seite mit den erweiterten Sicherheitseinstellungen des AdminSDHolder-Objekts entnommen wurde, die Sie entweder über AD-Benutzer und -Computer oder ADSI bearbeiten erreichen. Welchen Zugriff gewähren diese anderen als 'speziell' markierten Einträge dem jeweiligen Sicherheitsprinzipal in dieser ACL? Leider ist der Standard-AD-Sicherheitseditor nicht besonders gut in der Lage, die im Attribut nTSecurityDescriptor gespeicherte SDDL-Zeichenfolge richtig zu konvertieren. Selbst wenn Sie den entsprechenden Zugriffskontrolleintrag (ACE) öffnen, werden diese speziellen Berechtigungen oft nicht angezeigt. Sie müssen sie also entweder direkt über PowerShell finden, etwa durch (Get-Acl'AD:CN=AdminSDHolder,CN=System,D C=mydom,DC=local').access, oder Sie verwenden DSACLS.exe, wobei die Ausgabe in beiden Fällen schwer zu entziffern ist. Ein vergleichsweise einfaches, leistungsstarkes und oft übersehenes Tool für die ACL-Verwaltung ist LDP.exe, das alle ACEs mit den relevanten Informationen perfekt anzeigt. Befolgen Sie diese Schritte, um die korrekten Berechtigungen Ihres AdminSDHolder-Objekts vollständig anzuzeigen: Starten Sie LDP.exe;
- Wählen Sie Verbindung > Binden (oder Strg + B) und binden Sie sich als der aktuell angemeldete Benutzer;
- Wählen Sie Ansicht > Struktur (oder Strg + T) und wählen Sie Ihre Domain als BaseDN;
- Navigieren Sie im Domänenbaum auf der linken Seite zu System > AdminSDHolder;
- Klicken Sie mit der rechten Maustaste auf das Objekt AdminSDHolder und wählen Sie Erweitert > Sicherheitsdeskriptor;
- Klicken Sie auf OK , um den Sicherheitsdeskriptor anzuzeigen;
Das resultierende Fenster sollte ähnlich aussehen wie in Abbildung 7. Wenn Sie dies mit Abbildung 6 aus dem Standard-Sicherheitseditor vergleichen, können Sie sehen, dass sogar die ACEs in der gleichen Reihenfolge sortiert sind. Wenn Sie die AdminSDHolder-Berechtigungen nie mit dem Standard-Sicherheitseditor (wie er in AD-Benutzer und -Computer und ADSIedit verwendet wird) aktualisiert haben, zeigt Ihnen der LDP.exe-Sicherheitseditor sogar die ursprünglichen, vor Windows 2000 kompatiblen Zugriffs-ACEs an, die für viele Objekttypen aufgeteilt sind. Der Standard-Sicherheitseditor kann diese ACEs nicht einmal richtig verarbeiten und ersetzt sie bei jeder anderen Aktualisierung der ACL einfach durch eine allgemeine Leseberechtigung. Sobald Sie mit der Benutzeroberfläche (UI) des Standard-Sicherheitseditors aktualisiert haben, werden diese anderen ACEs für diese Gruppe automatisch entfernt. Dies geschieht nicht, wenn die Berechtigung AdminSDHolder (oder eine andere) mit dem Sicherheitseditor LDP.exe aktualisiert wird. Daher ist LDP.exe im Allgemeinen die sicherere Option, wenn Sie kritische ACLs in AD aktualisieren.
Sie können nun ganz einfach feststellen, dass die Berechtigungen "Jeder" und "Selbst" nicht von Belang sind. Die Berechtigung zum Ändern des Kennworts sieht zwar gefährlich aus, bedeutet aber nichts anderes als das Recht, das Kennwort eines Benutzers zu ändern, wenn Sie das alte Kennwort desselben Benutzers kennen (im Gegensatz zur Berechtigung zum Zurücksetzen des Kennworts, die es einem Administrator erlaubt, jedes bestehende Kennwort zu überschreiben). Abgesehen davon, was ist das Problem mit den hervorgehobenen ACEs? Das Konto MSOL_5c0317387a29 (d.h. 'MSOL_' plus eine zufällige Zeichenfolge), das in Abbildung 7 orange hervorgehoben ist, ist in den meisten Umgebungen zu finden. Bei diesem Konto handelt es sich um ein Standardkonto, das bei der Einrichtung des Azure AD Connect-Tools automatisch erstellt wird, das das Konto für die Synchronisierung von Objekten zwischen lokalem AD und Azure AD verwendet. Ältere Versionen von Azure AD Connect fügten bei Verwendung der Express-Installationsoption das Konto automatisch zur AdminSDHolder ACL hinzu, um die Kontrolle über die privilegierten Gruppen und Benutzer zu ermöglichen. Wenn Sie Ihr Azure AD Connect-Konto manuell konfiguriert haben oder eine neuere Version des Tools verwenden, finden Sie diesen Eintrag möglicherweise nicht.
Sie sollten keine privilegierten AD-Konten oder -Gruppen in Azure AD replizieren, da dies zu zusätzlichen Angriffspfaden zwischen den beiden Verzeichnissen führen könnte. Wenn Sie diese Regel befolgen, ist es nicht erforderlich, das Sync-Konto auf diese Weise zu berechtigen, also können Sie den Eintrag aus AdminSDHolder auch entfernen. Das Sync-Konto selbst muss jedoch als hoch privilegiert und sensibel angesehen werden, so dass das Entfernen der ACL hier die AD-Angriffsfläche nicht wesentlich verringert. Anders sieht es bei den beiden rot markierten Einträgen aus: die Gruppen access3 und authentifizierte Benutzer , die vor Windows 2000 kompatibel waren. Beide erhalten volle Leserechte für jedes privilegierte Objekt im AD. Das ist sicherlich nicht ideal. Jeder Benutzer (oder Computer) in Ihrem AD-Forest kann den Inhalt jeder privilegierten Gruppe (z.B. Domain Admins) aufzählen und die verschiedenen Gruppenmitgliedschaften jedes privilegierten Benutzers auflisten. Das ist genau das, was Eindringlinge mögen: Sie können leicht herausfinden, wen sie in Ihrem AD ins Visier nehmen und welches Konto sie kapern und für einen Pass-the-Hash- oder einen anderen Angriff nutzen können, um die Vorherrschaft über die Domäne und den Forest zu erlangen. Ihre Benutzer und Geschäftsanwendungen werden diese Informationen höchstwahrscheinlich nie nachschlagen müssen, warum sollten Sie sie also gewähren?
Die Antwort ist einfach: Sie sollten es nicht tun. Entfernen Sie diese beiden Berechtigungen (einschließlich aller anderen ACEs, die der vor Windows 2000 kompatiblen Zugriffsgruppe zugewiesen sein könnten). Ersetzen Sie sie einfach durch eine Berechtigung für eine andere Gruppe, z.B. SVC-ADconfig- AdminSDHolder-READ. Machen Sie diese Gruppe zu einer lokalen Domänengruppe, damit Sie ihre Mitgliedschaft kontrollieren können, wenn Sie ein Dienstkonto oder ein Computerobjekt benötigen, auf dem Software läuft, die das Recht hat, Daten von Ihren privilegierten Objekten zu lesen. Die Verwendung des Typs Domänenlokale Gruppe ermöglicht es Ihnen, beliebige Benutzer, globale oder universelle Gruppen oder Computer aus jeder Domäne in Ihrem AD Forest hinzuzufügen. Sie benötigen diese Fähigkeit möglicherweise für Software oder Systeme, die Sie zur Überwachung oder Verwaltung Ihres AD verwenden. Wenn Sie z.B. Semperis Directory Services Protector (DSP) einsetzen, möchten Sie das Computerkonto DSP zu dieser Gruppe hinzufügen. Aber alle anderen Benutzer und Computer sind davon abgeschnitten, irgendetwas über Ihre privilegierten Objekte zu lesen, was eine effektive Möglichkeit ist, Ihre AD-Angriffsfläche zu reduzieren. Eindringlinge werden einfach daran gehindert, die richtigen Objekte aufzuzählen. Beachten Sie, dass diese Aktion für jede Domäne in Ihrem AD Forest wiederholt werden muss.
Eine aktualisierte AdminSDHolder-Vorlage in der Stammdomäne würde dann wie in Abbildung 8 aussehen. Um die Auswirkungen solcher Änderungen auf Ihre AD-Sicherheitslage zu bestimmen, sollten Sie die Rechte verwenden, die ein Eindringling über einen normalen Domänenbenutzer sowohl vor als auch nach der Änderung der Berechtigung für das AdminSDHolder-Objekt in Ihrer Produktionsumgebung zur Verfügung hätte. Der Einfachheit halber wird in diesem Beispiel die Sicherheit der Stammdomäne in einem AD-Forest überprüft und die untergeordnete Domäne ignoriert. In Wirklichkeit werden Sie die Sicherheit aller Domänen in der Gesamtstruktur überprüfen wollen.
Leistungsstarke AD-Schwachstellen-Scanner verwenden
Sie können diese einfachen Überprüfungen ganz einfach mit kostenlosen Tools durchführen: dem Purple Knight AD vulnerability scanning tool,4 BloodHound5 und SharpHound (das Datensammel-Tool von BloodHound). Eindringlinge verwenden oft eine Kombination aus SharpHound im Netzwerk des Opfers und BloodHound auf einem externen Rechner, um den kürzesten Angriffspfad zur Gruppe der Domänenadministratoren zu finden. Beide Schwachstellen-Scans können in einer AD-Umgebung einfach und ohne besondere Konfiguration wiederholt werden, obwohl die Einrichtung von BloodHound und seinen Abhängigkeiten (z.B. NEOj4-Datenbank, Java JDK) einen erheblichen Aufwand erfordern kann. Purple Knight erfordert keine weitere Installation als das Herunterladen und Entpacken der entsprechenden .zip-Datei.
Vor der Anpassung von AdminSDHolder
In diesem Beispiel werden beide Scans als einfacher Benutzer, JustArootUser, durchgeführt. Dieser Benutzer hat keine besonderen Administratorrechte im AD, ist aber ein authentifizierter Benutzer in der AD-Forest. Dieses Szenario ahmt die Aktionen eines Eindringlings in Ihrer AD-Umgebung nach. Der erste Scan mit Purple Knight zeigt 29 Indikatoren der Gefährdung (Indicators of Exposure, IOEs) - Schwachstellen, die ein Eindringling für einen Angriff auf AD nutzen könnte (siehe Abbildung 9). Der BloodHound/SharpHound-Scan listet alle Domänenadministratorkonten auf (siehe Abbildung 10), auf die der einfache Benutzer zugreifen kann, sowie den kürzesten Pfad für diesen Benutzer zur Gruppe der Domänenadministratoren (siehe Abbildung 11).
Nach der Anpassung von AdminSDHolder
Nachdem Sie den ACE für die authentifizierten Benutzer und die vor Windows 2000 kompatiblen Zugriffsgruppen aus dem AdminSDHolder in der Root-Domäne entfernt und den ACE für die Gruppe SVC-ADconfig- AdminSDHolder-READ hinzugefügt haben, müssen Sie warten, bis der SDPROP-Prozess ausgeführt wird, und Ihre privilegierten Objekte aktualisieren, damit deren nTSecurityDescriptor-Attribute mit denen der AdminSDHolder-Vorlage aktualisiert werden. Dieser Vorgang dauert etwa eine Stunde, aber Sie können die Aktualisierung auch manuell auslösen, wie später in diesem Dokument beschrieben. Nach diesen Aktionen findet ein Purple Knight -Scan nur noch 18 IOEs - 11 Schwachstellen weniger als zuvor (siehe Abbildung 12). Jetzt, da der einfache Benutzer weder die Gruppe der Domänenadmins noch ihre Mitglieder aufzählen kann, zeigt ein BloodHound/SharpHound-Scan, dass ein Eindringling weder Mitglieder der Gruppe sehen noch Angriffspfade zu ihnen finden kann (siehe Abbildungen 13 und 14).
Ist AD jetzt sicher?
Beachten Sie, dass die Schwachstellen gegenüber privilegierten Konten nicht vollständig verschwinden; sie sind für Angreifer einfach nicht so leicht zu erkennen. Aber die richtigen Schwachstellen zu finden, um Ihr AD anzugreifen, ist gerade viel schwieriger geworden. Zum Beispiel können Angreifer nicht mehr sehen, welche privilegierten Benutzer durch die Gruppe "Geschützte Benutzer" geschützt sind - eine Gruppe, von der Sie möchten, dass Ihre Domänenadministratoren und andere privilegierte Benutzer Mitglied sind, da die Gruppe das tut, was ihr Name besagt: Konten vor verschiedenen Angriffsvektoren wie Pass-the-Hash-Angriffen schützen. Mit dem Lockdown können Eindringlinge keinen detaillierten Angriffspfad mehr zu Ihren privilegiertesten Konten planen und müssen andere Wege finden, um Ihr AD zu kompromittieren. Diese Wege sind oft komplexer. Wenn Sie Ihr AD und Ihre Endpunkte angemessen überwachen, könnten solche Angriffe einen früheren Alarm für Ihr Security Operations Center (SOC) Team auslösen. Mit einer Kombination aus Tools wie Microsoft Defender for Identity, Semperis Directory Services Protector und SentinalOne XDR kommen Sie in diesem Bereich recht weit.
Dennoch bedeutet diese Einschränkung der Berechtigungen nicht, dass Sie auf andere bewährte Sicherheitsverfahren verzichten können. Sie sollten Ihre AD-Infrastruktur immer noch ernsthaft in Schichten einteilen. Das bedeutet zumindest, dass sich Ihre höchst privilegierten Konten niemals bei einem anderen System als den Domänencontrollern (oder anderen hochgradig vertrauenswürdigen Systemen der Stufe 0) anmelden. Das Verstecken des Zugriffs auf Ihre privilegierten Konten ist nur ein Aspekt dieser Art von administrativem Tiering und zielt speziell auf die von Angreifern verwendeten Erkundungstechniken ab, wie sie im MITRE ATT&CK Framework beschrieben werden.6
Denken Sie auch daran, dass der Purple Knight Scan auch nach der Sperrung des AdminSDHolders noch andere potenzielle Schwachstellen entdeckt hat. IOEs wie "Nicht standardmäßige Prinzipale mit DC-Sync-Rechten in der Domäne" oder "Domänenvertrauen zu einer Drittanbieter-Domäne ohne Quarantäne" wurden immer noch über die Standardberechtigungen für authentifizierte Benutzer auf anderen Objekten in der Domäne gefunden - und könnten von Eindringlingen immer noch zur Angriffsplanung genutzt werden.
Sie sind noch nicht fertig ...
Nachdem Sie nun die Gruppe SVC- ADconfig-AdminSDHolder-READ erstellt haben, müssen Sie der Gruppe noch die richtigen Konten hinzufügen, die Sie für das Lesen von privilegierten Objekten wieder aktivieren möchten. Zu diesen Konten gehören niedrig privilegierte Dienstkonten für Sicherheits- und Verwaltungstools sowie in einem Forest mit mehreren Domänen die Domänenadministratoren anderer Domänen. Abbildung 15 zeigt zum Beispiel die Ansicht der Domänenadministratoren einer untergeordneten Domäne auf die Stammobjekte der Gesamtstruktur. Dieses Konto, das sich auf die Berechtigungen für authentifizierte Benutzer in AdminSDHolder verlassen hat, hat keine Rechte mehr, um die privilegierten Gruppen der Stammdomäne zu lesen.
Dieses Problem lässt sich leicht beheben, indem Sie die Domänenadministratorgruppe der untergeordneten Domäne (global) zur lokalen Gruppe SVC-ADconfig- AdminSDHolder-READ in der Stammdomäne hinzufügen. Sobald Sie die untergeordnete Domäne gesperrt haben, müssen Sie diese Aufgabe wiederholen, um die Domänenadministratorgruppe der Root-Domäne zur Gruppe der untergeordneten Domäne hinzuzufügen - oder Sie können die spezielle AdminSDHolder-Gruppe zu einer universellen Gruppe in Ihrer Root-Domäne machen, sie für alle AdminSDHolder-Vorlagen in diesem Forest verwenden und alle Domänenadministratorgruppen zu ihr hinzufügen. Sie haben die Wahl. Es versteht sich von selbst: Aktivieren Sie die Vererbung nicht für die AdminSDHolder-Vorlage selbst. Dies würde die gesamte Funktion außer Kraft setzen. Beachten Sie auch, dass Sie AdminSDHolder verwenden können, um Ihr AD durch das Entfernen von Berechtigungen zu sperren, und dass Eindringlinge das Objekt auch verwenden können, um in einem kompromittierten AD persistent zu werden. Dazu erstellt ein Eindringling zunächst einen unauffälligen Benutzer und versteckt ihn irgendwo in Ihrer OU-Struktur. Dann weist er diesem Benutzer in der Vorlage AdminSDHolder die Berechtigung zu, Benutzerkennwörter zurückzusetzen. SDPROP erledigt den Rest und ermöglicht es dem Eindringling, die Kontrolle zu behalten. Natürlich müssen Sie diese Vorlage ständig auf Änderungen überwachen. Schließlich müssen Sie, wie bereits erwähnt, die übrig gebliebenen Admins und Admin-Gruppen bereinigen, die Sie im Laufe der Jahre möglicherweise erstellt haben.
Privilegierte Objekte bereinigen: Fehlkonfigurierte Objekte aufspüren
Mit den folgenden Schritten können Sie Objekte ausfindig machen und bereinigen, die zuvor von AD als privilegiert eingestuft wurden (und daher über SDPROP 'gestempelt' wurden, indem ihre ACL aktualisiert und das Attribut adminCount auf '1' gesetzt wurde), die aber nicht mehr Mitglied einer privilegierten Gruppe sind:
- Mark all existing groups with admincount=1 via the telephoneNumber attribute (or some other unused attribute) so that you can more easily locate these groups again in a later stage of the clean-up: Get-ADObject-LDAPfilter “(&(groupType:1.2.840.113556.1.4.803:= 2147483648)(admincount=1))”| Set-ADObject -Replace @ {telephoneNumber=“adminCount- Check-20220730”};
- Löschen Sie die aktuelle Einstellung für das Attribut adminCount für alle zuvor gefundenen Gruppen: Get- ADObject -LDAPfilter "(&(group Type:1.2.840.113556.1.4.803:= 2147483648)(admincount=1))" | Set- ADObject -Clear "adminCount";
- Stellen Sie sicher, dass der SDPROP-Prozess alle relevanten Objekte neu prägt: SDPROP führt nur dann eine Aktualisierung relevanter Objekte durch, wenn eine Änderung der ACL auf dem Ziel oder dem AdminSDHolder erfolgt. Der einfachste Weg, um sicherzustellen, dass SDPROP seine Aufgabe erfüllt, ist das manuelle Hinzufügen eines gefälschten ACEs (z.B. 'Backup Operators' auf 'List Object' zulassen) in AdminSDHolder und das anschließende Entfernen des ACEs;
- Erzwingen Sie die Ausführung von SDPROP.
Sie können bis zu 60 Minuten auf die Ausführung des SDPROP-Prozesses warten (d.h. warten, bis der Standardzeitplan den Vorgang auslöst). Oder Sie können den DC mit der PDCE FSMO-Rolle zwingen, den SDPROP-Prozess auf Ihren Befehl hin zu starten, indem Sie den Befehl RunProtectAdminGroupsTask an die RootDSE Ihrer Domäne senden. Die einfachste Methode ist die Verwendung von LDP.exe als Benutzer mit Domänen-Administratorrechten: Wählen Sie beim Start die Option 'Als Administrator ausführen':
- Starten Sie LDP.exe, indem Sie die Option Als Administrator ausführen wählen;
- Wählen Sie Verbindung > Verbinden und geben Sie die Rolle DC mit PDC-Emulator in Ihrer Domäne an;
- Drücken Sie Strg + B oder wählen Sie Verbindung > Binden , um sich als der aktuell angemeldete Benutzer zu verbinden;
- Drücken Sie Strg + M oder wählen Sie Durchsuchen > Ändern, um einen Änderungsvorgang zu starten;
- Lassen Sie DN: leer und geben Sie RunProtectAdminGroupsTask als Attribut und 1 als Wert ein;
- Wählen Sie Operation ADD und klicken Sie dann auf Enter oder drücken Sie Alt + E;
- Wenn Sie den Eintrag [Add] RunProtectAdminGroupsTask:1 in der Eintragsliste des Fensters Ändern sehen (siehe Abbildung 16), klicken Sie auf die Schaltfläche Ausführen , um den Vorgang zu starten und den SDPROP-Prozess auszuführen.
- Warten Sie, bis der SDPROP-Prozess die Verarbeitung beendet hat. Sie können entweder überprüfen, ob
mit dem Attribut adminCount=1 zu den bekannten Objekten zurückkehrt, die Sie erwarten (z.B. die direkten Mitglieder Ihrer Domänen-Admins-Gruppe), oder Sie überprüfen Ihr Sicherheitsereignisprotokoll auf der PDCE und stellen sicher, dass keine weiteren Ereignisse mit der ID 4780 (Aufgabenkategorie: Benutzerkontenverwaltung) erzeugt werden. Diese Ereignisse zeigen Ihnen, welche Objekte durch den SDPROP-Prozess zurückgesetzt wurden. - Prüfen Sie, welche Gruppen nicht aktualisiert wurden, indem Sie das vorherige Flag verwenden und einen Filter für die Gruppen hinzufügen, bei denen adminCount nicht auf '1' gesetzt ist: Get- ADObject-LDAPfilter “(&(groupType: 1.2.840.113556.1.4.803:=2147483648)(telephoneNumber=adminCount-Check-20220730)(!(adminCount=1)))”;
- Das Ergebnis des letzten Filters sind die Objekte, auf deren Bereinigung Sie sich bald konzentrieren sollten. Sie enthalten immer noch die ACL aus der AdminSDHolder-Einstellung zu der Zeit, als sie eine privilegierte Gruppe waren, was auch bedeutet, dass sie keine Berechtigungen erben, die Sie möglicherweise auf OU-Ebene festgelegt haben;
- Wiederholen Sie das gleiche Verfahren mit Ihrem Computer und Ihren Benutzerkonten. Wahrscheinlich möchten Sie das Attribut telephoneNumber nicht als temporäres AdminSDHolder-check-flag für die Benutzerobjekte verwenden; vielleicht wird facsimileTelephoneNumber nicht mehr verwendet. Der richtige LDAP-Filter zum Auffinden der privilegierten Benutzer wäre: (&(objectClass=user) (objectCategory=person) (admincount=1));
- Entfernen Sie den gefälschten ACE aus dem AdminSDHolder-Objekt, nachdem Sie Ihre Bereinigungsobjekte bestimmt haben.
Privilegierte Objekte bereinigen: Zurücksetzen der ACLs für fehlkonfigurierte Objekte
Die Verwendung von PowerShell zur Wiederherstellung von ACLs für die betreffenden Objekte ist etwas schwieriger. Es gibt kein einfaches PowerShell-Äquivalent zur Option "Standardwerte wiederherstellen", die in der Benutzeroberfläche für erweiterte Sicherheitseinstellungen für AD-Objekte verfügbar ist. Diese Standardeinstellungen sind im AD-Schema gespeichert, und zwar im Attribut defaultSecurityDescriptor der entsprechenden Objektklasse. Wenn Sie in der Sicherheits-Benutzeroberfläche auf die Option Standardwerte wiederherstellen klicken, werden die richtigen Klassenberechtigungen aus dem Schema gelesen und dann wieder auf das Objekt angewendet. Wenn Sie nur einige wenige falsch konfigurierte Objekte haben, ist diese Methode vielleicht der einfachste Weg, diese zu beheben. Was aber, wenn Sie viele solcher Objekte an mehreren Standorten haben?
Eine Möglichkeit ist die Verwendung des DSACLS-Tools mit der Option /resetDefaultDACL , die die Sicherheit des Objekts auf die im Schema definierten Standardwerte zurücksetzt. Und obwohl Microsoft kein PowerShell-Äquivalent für das direkte Zurücksetzen einer ACL auf den Standard erstellt hat, können Sie das Cmdlet Get-ACL verwenden, um die ACL von einem anderen Objekt derselben Klasse zu übernehmen und diese ACL dann über das Cmdlet Set-ACL auf falsch konfigurierte Objekte zu übertragen. Im Grunde können Sie ACLs mit den PowerShell-Befehlen Get-ACL und Set-ACL von einem Objekt in ein anderes kopieren und einfügen. Da der defaultSecurityDescriptor aus dem Schema auch bei der Erstellung eines neuen Objekts einer bestimmten Klasse gelesen und verwendet wird, können Sie zum Kopieren der ACL einfach ein Dummy-Objekt erstellen. Das Objekt kann sogar ein deaktiviertes Objekt sein, da sein Zustand nicht Teil der ACL ist.
Leider können Sie die Ausgabe des Cmdlets Get-ADObject nicht einfach über die Pipeline in das Cmdlet Set-ACL leiten, da letzteres den Objektpfad in einem bestimmten Format erhalten muss: den Distinguished Name (DN) des Objekts mit vorangestelltem 'AD:'. Daher müssen Sie eine Schleife durch die Liste der von Get-ADObject zurückgegebenen Objekte ziehen, den richtigen Pfad für die Verwendung mit Set-ACL bilden und dann den entsprechenden Befehl in der Schleife ausführen. Das folgende PowerShell-Skript setzt die ACLs von Objekten der Benutzerklasse auf die ACLs eines neu erstellten Dummy-Kontos namens DefaultUserACL zurück (das Attribut facsimileTelephoneNumber wurde zuvor markiert, um die falsch konfigurierten Konten zu finden).
#Set path for ACLing to AD
Set-Location AD:
#Grab ACL objects from a sample user- account (e.g. newly created account)
$DefaultAcl = (Get-Acl “AD:CN= DefaultUserACL,OU=MyOU,DC=mydo m,DC=local”)
#query for the old AdminCount objects that must get their permissions reset $OldAdminCountObjects =
Get-ADObject -LDAPfilter
“(&(objectClass=user)
(objectCategory=person)(facsimile TelephoneNumber=adminCount- Check-20220730)(!(adminCount=1)))”
#work through every object, grab the DN, create the proper ACL-DN-Path and set sample ACL on object
ForEach ($Object in $$OldAdminCountObjects){
$ACLpath = “AD:” + $Object. distinguishedName
write-host “Resetting permissions on”,
$ACLpath
Set-Acl -Path $ACLpath -AclObject
$DefaultAcl#update flag of object
Set-ADObject -Identity $Object.
distinguishedName -Replace
@{facsimileTelephoneNumber=“ACL was reset 20220730”}
}
Wenn Sie das Skript für Gruppen oder Computer anpassen, stellen Sie sicher, dass Sie zum richtigen LDAP-Filter mit dem von Ihnen gewählten Attribut wechseln, um die Suche nach diesen Objekten zu erleichtern. Wenn Sie es vorziehen, können Sie die Erstellung dieser Dummy-Objekte überspringen und die gleiche Schleifenlogik verwenden, um die DSACLS-Tools auszuführen, indem Sie den Distinguished Name des Objekts und die Option /resetDefaultDACL verwenden. Beide Methoden helfen Ihnen, alte, privilegierte Objekte in Ihrem AD ordnungsgemäß zu bereinigen.
AD-Sicherheit erfordert ständige Aufmerksamkeit
Dieses Dokument soll Ihnen helfen, die Vorteile der in AD integrierten Sicherheitsfunktionen AdminSDHolder und SDPROP zu verstehen, die Ihre privilegiertesten Objekte innerhalb Ihres AD schützen, und wie Sie diese Objekte noch besser schützen können, um die Aufklärungsphase eines Angriffs zu bekämpfen. Je schwieriger Sie es Eindringlingen machen, an Ihre privilegiertesten Objekte heranzukommen, desto besser. Wie beschrieben, sollte diese Härtungsmethode von einer angemessenen Einteilung Ihrer administrativen Konten und einer aktiven Überwachung Ihres AD und Ihrer Endpunkte begleitet werden. Die Absicherung Ihres AD war schon immer wichtig, und die kontinuierliche Zunahme von Ransomware-Angriffen unterstreicht diese Notwendigkeit.
Ressourcen
1. Mueller, R. und Geelen, P. (September 2020 [November 2011]), 'Active Directory: LDAP Syntax Filters', Microsoft, verfügbar unter https://social.technet. microsoft.com/wiki/contents/articles/5392.active- directory-ldap-syntax-filters.aspx (Zugriff am 25. September 2022).
2. Smith, R. (Januar 2018), 'Active Directory Security: Understanding the AdminSDHolder Object", Petri, verfügbar unter https://petri.com/ active-directory-security-understanding- AdminSDHolder-object (Zugriff am 25. September 2022).
3. Grillenmeier, G. (November 2021), 'Understanding the Risks of Pre-Windows 2000 Compatibility Settings in Windows 2022', Semperis, verfügbar unter https://www.semperis.com/blog/security-risks- pre-windows-2000-compatibility-windows-2022/ (Zugriff am 25. September 2022).
4. Purple Knight, "Uncover Active Directory vulnerabilities before attackers do", verfügbar bei https://www.semperis.com/purple-knight (abgerufen am 25. September 2022).
5. GitHub, 'BloodHound 4.2.0 - Azure Refactor', verfügbar unter https://github.com/BloodHoundAD (Zugriff am 25. September 2022).
6. MITRE ATT&CK, 'Reconnaissance', verfügbar unter https://attack.mitre.org/tactics/TA0043 (Zugriff am 25. September 2022).
