Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03197.jsonl.gz/907

Credential Tiering
Marius Elmiger
Die Grundlagen des Tierings verstehen
Dieser zweite Artikel einer zweiteiligen Serie bietet einen Leitfaden für den Übergang zu einer Active Directory Credential Tiering Umgebung mit Schwerpunkt auf Tier-0. Ausserdem wird eine Methode zur kontinuierlichen Messung der Sicherheitsverbesserungen vorgestellt. Die beschriebenen Methoden lassen sich auch auf andere identitätszentrierte Lösungen übertragen. Der folgende Abschnitt orientiert sich am Tiering-Modell von Microsoft, welches im ersten Teil beschrieben wird, und an unseren Erfahrungen mit der Implementierung sowie der Ausnutzung von nicht segregierten Umgebungen während unserer Engagements.
Bevor man sich kopfüber in die Umsetzung stürzt, kann es von Vorteil sein, einen Plan zu haben. Die Einführung von Credential Tiering ist oft ein umfangreiches Projekt, das einen detaillierten Überblick über die Strategie, die Ziele und die Aufgaben erfordert, um Credential-Tiering einzuführen. Ein Projektplan hilft dabei bei der Organisation der Ressourcen und des Risikomanagements und gewährleistet einen systematischen Ansatz bei der Umsetzung. Die folgenden grundlegenden Aspekte sollten zuerst beachtet werden:
Die genannten Aspekte könnten zu umfangreichen Diskussionen führen, bei denen einige Personen möglicherweise das gesamte Projekt in Frage stellen. Dies ist jedoch die erste Phase eines Bewusstseinswandels, den die Mitarbeiter durchlaufen werden. Wir empfehlen, die Herausforderungen zunächst in einem breiteren, vom Unternehmen losgelösten Kontext zu erläutern und insbesondere eine direkte Wahrscheinlichkeitsbewertung zu vermeiden. Die Problematik von komplexen Aussagen wie Wenn wir x nicht durchführen, haben wir Anzahl y direkte oder indirekte Angriffswege nach z lässt sich durch eine anschaulichere Darstellung deutlicher machen. Ein reales Szenario könnte beispielsweise zeigen, wie bestimmte Benutzer über ihr tägliches Benutzerkonto auf den Passwort-Vault eines Unternehmens zugreifen, in dem privilegierte Anmeldedaten von Active Directory enthalten sind. Das tägliche Benutzerkonto wird zusammen mit jeder Entität, die Administratorrechte für den Vault besitzt, zu einem indirekten Domain-Admin gemacht. Dadurch besteht das Risiko, dass Privilegien von einem beliebigen Tier auf Tier-0 eskaliert werden können. Sobald die grundlegenden Herausforderungen verstanden sind, kann die Diskussion auf die Unternehmensperspektive übergehen, um nuancierte Gespräche zu fördern. Der Fokus sollte konsequent auf der Trennung von administrativem Zugriff auf das Active Directory liegen, welches in vielen Unternehmen zu den wichtigsten Diensten gehört. Weitere Beispiele hierfür finden sich im ersten Teil Credential Tiering: The Value of Containment Part 1.
Ein Haus braucht ein starkes Fundament, genau wie Tiering. Wenn Tier-0 kompromittiert wird, erhält der Angreifer die Kontrolle über alles, was von Active Directory kontrolliert wird. Aus diesem Grund sollte eine robuste Tier-0 an erster Stelle stehen. Die folgenden übergeordneten Implementierungsschritte können als Leitfaden dienen:
msDS-KeyCredentialLink leer ist. Die Neuerstellung ist immer die bessere Option, um Hintertüren wie Shadow Credentials zu vermeiden
Von hier an beginnt die Uhr zu ticken. Die folgenden Schritte sollten zeitnah durchgeführt werden, um mögliche Manipulationen durch noch nicht überführte Tier-0-Entitäten während der Umstellung zu verhindern.
Die Identifizierung von Tier-0-Entitäten ist einer der ersten Schritte bei der Umsetzung von Tier-0, um die Auswirkungen von nicht segregierten Tier-0-Entitäten aufzuzeigen und den Übergang zu Tier-0 zu unterstützen. Um Tier-0-Entitäten schnell und effektiv zu identifizieren kann die Graph Theory verwenden werden. Gewisse Tools, welche die Graph Theory verwenden, haben bereits die nötige Logik implementiert und helfen bei einem Assessment von Abhängigkeitsbasierten Lösung wie Active Directory enorm. Das bekannteste Tool ist BloodHound von der Firma SpecterOps sowie Adalanche von Lars Karlslund. Der nachfolgende Ansatz kann für A1, A2, A3, A7, B2 und B10 verwendet werden.
BloodHound FOSS oder BloodHound CE vorbereiten
CREATE USER bloodhoundce SET PASSWORD 'bloodhoundce' CHANGE NOT REQUIRED SET STATUS Active SET HOME DATABASE bloodhoundce; GRANT ROLE admin TO bloodhoundce
bloodhound.config.json vorgenommen werden, um auf die externe Neo4j-Datenbank zu verweisen. Die Verwendung der Neo4j Community-Edition ist dabei nicht mehr erforderlich und die
docker-compose.yml kann dementsprechend angepasst werden. Sofern die containerisierte Neo4j Community-Edition verwendet wird, muss die
docker-compose.yml angepasst werden, damit von extern auf Neo4j bzw. auf den Neo4j Browser zugegriffen werden kann. Des Weiteren müssen die APOC und GDS plugins manuell installiert werden. Möglicherweise sind trotzdem nicht alle benötigten Funktionen verfügbar welche weiter unten für die Auswertung verwendet werden. Daher empfehlen wir die Verwendung der Neo4j Desktop-Version, die mehrere Datenbanken sowie Funktionen wie Graph-Algorithmen und Analysetools von Drittanbietern unterstützt. Wenn jedoch eine Einrichtung im Servermodus erforderlich ist, wird die Community- oder eine lizenzierte Version benötigt.
SharpHound ausführen
runas /netonly aus. Wenn der Benutzer über Administratorrechte auf den Endpunkten verfügt, kann zusätzlich auch die Erfassungsmethode
LoggedOn ausgeführt oder von Anfang an mit
All verwendet werden, um genauere Daten über die angemeldeten Benutzer auf den Endpunkten zu erfassen. Wenn Sie BloodHound FOSS verwenden, muss die SharpHound Version v1.1.1 verwendet werden.
SharpHound.exe --SecureLDAP --disablecertverification --domain yourdomain.intra -c DCOnly SharpHound.exe --SecureLDAP --disablecertverification --domain yourdomain.intra -c ComputerOnly
SharpHound.exe --SecureLDAP --disablecertverification --domain yourdomain.intra -c Session --Loop --Loopduration 04:00:00
Importieren der gesammelten Daten in BloodHound
Tier-0 Entitäten markieren
tier0 und
highvalue Flag. Die Queries sollten über den Neo4j Browser ausgeführt werden.
// Reset highvalue property Match (u) SET u.highvalue=false; // Assign three new properties (Tiering) to all nodes MATCH (u) SET u.tier0 = false, u.tier1 = false, u.tier2 = false; // Set the Tier-0 property to true for well known Tier-0 objects UNWIND ["500","502","512","516","518","519","520","526","527","544","548","549","550","551","555","557","562","569","580"] as TierZeroRid MATCH (u) where u.objectid ENDS WITH "-"+TierZeroRid Set u.tier0=true; // Find all domain objects and set the tier0 property MATCH (u:Domain) SET u.tier0=true; //Find all objects that allow unconstrained delegation and set the tier0 property MATCH (u{unconstraineddelegation:true}) Set u.tier0=true; //Find all objects that can directly or indirectly manipulate objects that have the property tier0 set to true Match p=allshortestpaths((u)-[r:MemberOf|AdminTo|AllExtendedRights|AddMember|ForceChangePassword|GenericAll|GenericWrite|Owns|WriteDacl|WriteOwner|ExecuteDCOM|AllowedToDelegate|ReadLAPSPassword|Contains|GPLink|AddAllowedToAct|AllowedToAct|SQLAdmin|ReadGMSAPassword|HasSIDHistory|SyncLAPSPassword|AddSelf|WriteSPN|AddKeyCredentialLink|DCSync*1..]->(n{tier0:true})) Where u<>n Set u.tier0=true; //Identify all entities with remote access to Tier-0 assets. These entities matter because they could become indirect Tier-0 administrators by escalating privileges on the target. For example, if a user can RDP to a client where a Tier-0 administrator is active, it might lead to compromising the Tier-0 accounts. Match p2=allshortestpaths((u)-[r2:HasSession|CanRDP|CanPSRemote|ExecuteDCOM*1..]->(n{tier0:true})) Where u<>n Set u.tier0=true; //OPTIONAL: Set all Tier-0 marked nodes as highvalue to have a better visibility in the BloodHound GUI (All Tier-0 objects will receive a diamond icon in BloodHound) MATCH (u{tier0:true}) SET u.highvalue = true;
Externe Tier-0-Dienste finden und kennzeichnen
Alle Tier-0-Entitäten, die direkt über Active Directory verwaltet werden, sollten nun automatisch identifiziert worden sein. Was fehlt, sind Anwendungen oder Dienste, die Tier-0-Objekte indirekt verwalten können, deren Zugriffsverwaltung aber von der externen Anwendung übernommen wird. Zum Beispiel Lösungen wie Backup (NetBackup, ARCserve, Veeam), Virtualisierung (ESX, Hyper-V), Überwachung (SCOM, Ivanti), Systemverwaltungssysteme (SCCM, Ivanti), Schwachstellen-Scanner (Nessus), AV (McAfee, Symantec, Defender), EDR (MDE, Tanium, CrowdStrike, SentinelOne), IAM (One identity, Sailpoint, NetIQ), SIEM (Splunk, Microsoft Sentinel, Qradar) usw. Diese Dienste verwenden häufig einen Agenten auf den Endpunkten oder Dienstkonten und verfügen über eine eigene Implementierung der rollenbasierten Zugriffskontrolle (RBAC). Um herauszufinden, wer Zugriff auf was hat, müssen daher zunächst die auf Tier-0-Systemen ausgeführten Dienste ermittelt und dann der Applikationsbesitzer der Lösung befragt werden. Darüber hinaus können Systemverwaltungstools oder Schwachstellen-Scanner bei der Identifizierung aktiver Dienste und Prozesse auf einem Tier-0-System helfen. Andernfalls kann auch die Ausführung eines einfachen PowerShell-Skripts auf einem identifizierten Tier-0-System helfen, mögliche Tier-0-relevante Dienste oder Prozesse zu erkennen:
# Get all running services and processes $RunningServices = Get-Service | Select-Object @{Name="Type"; Expression={"Service"}}, Name, DisplayName, Status $RunningProcesses = Get-Process | Select-Object @{Name="Type"; Expression={"Process"}}, Name, Id # Combine and output to grid view $RunningServices + $RunningProcesses | Out-GridView -Title "Running Services and Processes"
Nach der Identifizierung von Diensten oder Prozessen, die auf Tier-0-Servern laufen, sollte der Applikationsbesitzer in der Lage sein, die notwendigen Informationen darüber bereitzustellen, welche Benutzer über administrative Berechtigungen verfügen. Häufig werden in der Anwendung selbst AD-Gruppen oder AD-Benutzer verwendet. Die identifizierten AD-Objekte sollten als Tier-0 gekennzeichnet werden. Dazu kann die folgende Cypher-Query verwenden werden, um nach einem bestimmten
samaccountname zu suchen und das Tier-0-Flag zu setzen:
// Example to set the tier0 and highvalue flag on the node with the samaccountname grp-TenableAdmin MATCH (u) where toLower(u.samaccountname) = toLower("grp-TenableAdmin") Set u.tier0=true, u.highvalue = true
Neben der Kontaktaufnahme mit dem Applikationsbesitzer von Tier-0-Anwendungen ist es manchmal auch hilfreich, die Neo4j-Datenbank nach bekannten Diensten zu durchsuchen. Die folgende Abfrage kann dafür verwendet werden:
// Modify the following keywords with service terms to suit your specific environment UNWIND ["nessus", "tenable", "sccm", "scom", "ivanti", "esx", "vmware", "mcafee", "symantec", "tanium", "splunk", "qradar", "netbackup", "arcserve", "veeam", "crowdstrike", "sentinelone", "sailpoint", "netiq"] AS word MATCH (n) WHERE toLower(n.name) CONTAINS toLower(word) OR toLower(n.description) CONTAINS toLower(word) OR any(x IN n.serviceprincipalnames WHERE toLower(x) CONTAINS toLower(word)) OR toLower(n.distinguishedname) CONTAINS toLower(word) RETURN word as keyword, LABELS(n)[1] as type, n.name, n.description, n.distinguishedname ORDER BY type
Erstellung einer Liste der identifizierten Tier-0-Entitäten
Nach dem befolgen der oben beschriebenen Schritte sollten die meisten Tier-0-Entitäten identifiziert worden sein. Oftmals wird zur weiteren Planung das sehr “beliebte” Tool Excel verwendet. Über den Neo4j Browser kann eine csv-Datei generiert werden. Wenn der Datensatz zu gross sein sollte, kann der folgende Cypher-Query verwendet werden:
// Create a csv file with all Tier-0 entities // Enable apoc.export.file.enabled=true in the neo4j.conf // Will be saved to: C:\neo4j\Database\relate-data\dbmss\dbms-guid\import CALL apoc.export.csv.query("Match (u) where u.tier0=true return distinct LABELS(u)[0] as type, u.name, u.enabled,u.description,u.objectid, u.distinguishedname order by type", 'all-tier0-entities.csv', {quotes: true, delimiter: ','});
Während des Evaluierungsprozesses können unnötige Tier-0-Entitäten bereits entfernt werden. Entitäten, die neu erstellt oder migriert werden müssen, können entsprechend dem Implementierungszeitplans gekennzeichnet werden. Um Verbesserungen vor, während und nach der Einführung von Tier-0 zu verfolgen, kann das folgende Dashboard nützlich sein:
Die Abbildung zeigt, wie viele Entitäten eine direkte oder indirekte Verbindung zur Domäne Admin Gruppe oder anderen Tier-0-Entitäten haben. Der Prozentsatz muss je nach Grösse der Organisation angepasst werden. Die in der Demo dargestellte Umgebung hat insgesamt 2489 aktive Benutzerkonten. Daher sollte das Ziel für die Tier-0-Konten etwa 0,4 % bis 0,5 % betragen, je nach Grösse des Active Directory-Teams und der für die Tier-0-Trennung erforderlichen Dienstkonten.
Weiter unten im Dashboard wurden die Graph-Algorithmen der Closeness-Centrality und Degree-Centrality verwendet, um potenziell privilegierte Entitäten anzuzeigen.
Der Degree-Centrality Algorithmus kann helfen, beliebte Knoten in einer Graph-Datenbank zu bestimmen. Der Algorithmus misst die Anzahl der eingehenden und ausgehenden Edges eines Nodes. Wenn Nodes eine hohe Anzahl von Edges, insbesondere von ausgehenden Edges, aufweisen, kann der Node bzw. die AD-Entität hoch privilegiert sein. Im Gegensatz dazu misst der Closeness-Centrality Algorithmus die durchschnittliche Entfernung eines Nodes zu allen anderen Nodes und erstellt eine Liste von Nodes, die Informationen effizient durch einen Graphen verbreiten können. Daher haben Nodes mit einem hohen Closeness-Wert die kürzesten Entfernungen zu allen anderen Knoten, was ein Hinweis darauf sein kann, dass eine Entität privilegiert sein kann. Weitere Informationen zu den beiden Algorithmen können unter der offiziellen Neo4j-Webseite oder in dem Papier Start thinking in graphs: using graphs to address critical attack paths in a Microsoft cloud tenant gefunden werden.
Um das obige Dashboard zu verwenden, muss die NeoDash-Anwendung installiert und das Dashboard, welches unter GitHub zu finden ist, importiert werden. NeoDash kann über die Neo4j Desktop-Anwendung aus der graph app gallery oder direkt von GitHub heruntergeladen werden. NeoDash funktioniert auch mit der Neo4j Community Edition.
Tier-0 kann in der Regel ausnahmslos und ohne Ausfallzeiten eingeführt werden. Sie dauert, je nach technischem Wissen der Mitarbeiter, 6-12 Monate (Ausgenommen politische Debatten). Die Umsetzung von Tier-1 ist schwieriger und kann viel Zeit in Anspruch nehmen. Vielleicht kann nicht alles vollständig getrennt werden, aber wichtig ist die Priorisierung von privilegierten Tier-1-Administratoren und geschäftskritischen Anwendungen. Sie müssen von weniger wichtigen Tier-1-Ressourcen sowie Tier-2 getrennt und geschützt werden. Ein anderer Ansatz besteht darin, eine weiteres Tier hinzuzufügen. Das heisst, Tier-1 ist nur für IT- und geschäftskritische Lösungen gedacht. Tier-2 ist für die weniger kritischen Serveranwendungen, und Tier-3 ist für Client-Administratoren.
Ein Thema, welches in diesem Artikel nicht im Detail angesprochen wurde, aber für die Implementierung von Tiering unerlässlich ist, ist die Härtung der Systeme sowie die Zugriffsrichtlinien. Die Härtung sollte entweder den CIS- oder den Microsoft-Richtlinien folgen. Mein Kollege Michael Schneider hat ein Tool namens HardeningKitty geschrieben, mit welchem die Härtungsrichtlinien überprüft werden können. Noch wichtiger sind die Zugriffsrichtlinien, die den Tiering Zugriff erlauben oder verweigern. Der bevorzugte Weg ist die Verwendung von Authentication Policies and Authentication Policy Silos in Kombination mit Authentication Mechanism Assurance (AMA). Es reicht aber auch, nur mit SmarCards und Group Policies zu starten.
Die Umsetzung von Tiering ist kein einfaches Unterfangen. Der Grund dafür liegt nicht primär in der technischen Schwierigkeit einer solchen Implementierung, sondern meist in der bestehenden Routine, wie ein Active Directory heute noch betrieben wird. Diese Routine zu ändern und Transparenz darüber zu schaffen, welche AD Objekte nun privilegiert sind und diese effektiv zu schützen, stellt für Organisationen immer noch eine Herausforderung dar. Tiering ist kein Tool, das man installieren kann, es ist eine klar definierte Art und Weise, wie ein Active Directory sicherer betrieben werden soll, es definiert einen Zustand anhand eines Regelwerks, das es einzuhalten gilt. Besitzt ein Active Directory kein Regelwerk welches die privilegierten Entitäten restriktiv schützt, ist das Active Directory der Gefahr der Komprimierung ausgesetzt. Vor allem die indirekten Tier-0 Berechtigungen wachsen in grösseren Unternehmen ohne Tiering ins Unermessliche, da immer mehr Tools angeschafft werden, die meist alle Server oder Clients und somit auch die Active Directory Domain Controller bzw. deren Administratoren betreffen. Die beiden Artikel Part-1 und Part-2 beschreiben die Herangehensweise an die Umsetzung von Tiering mit theoretischen und auch praktischen Beispielen um mit einer Tiering Umsetzung zu beginnen. Der Schwerpunkt beider Artikel lag hauptsächlich auf Active Directory, aber alle Identity-Provider Lösungen haben die gleichen Herausforderungen, so dass der vorgestellte Ansatz auch für andere Lösungen wie Microsoft Entra ID, Google Cloud Identity und AWS Identity verwendet werden kann, um privilegierte Entitäten effektiv schützen zu können.
Unsere Spezialisten kontaktieren Sie gern!
Marius Elmiger
Marius Elmiger
Marius Elmiger
Marius Elmiger
Unsere Spezialisten kontaktieren Sie gern!
Weitere Artikel im Archiv