17 Jul Troopers Conference Recap: ACL-basierte Active Directory-Angriffe und Verteidigungsmaßnahmen
Inhaltsverzeichnis
- 1 Unser Thema – Hidden Pathways: Exploring the Anatomy of ACL-Based Active Directory Attacks and Building Strong Defenses
- 2 Der vollständige Vortrag als Video
- 3 Los geht’s mit dem Thema des Vortags – wirklich 😊
- 4 Was sind AD ACLs / ACEs?
- 5 Wie können ACLs ausgenutzt werden (Beispiele)
- 6 Warum sind ACLs auch heute noch ein Sicherheitsproblem?
- 7 Was können wir jetzt tun?
- 8 Rollen und Verantwortlichkeiten definieren
- 9 Eine neue OU-Struktur Aufbauen
- 10 Berechtigungen setzen
- 11 Hoch privilegierte Gruppen verschieben
- 12 Berechtigungen regelmäßig setzen
- 13 Neue Objekte, delegieren und verschieben
- 14 Fazit
- 15 Off Topic
Letzten Monat war es so weit, Teal hat das erste Mal mit einem Speaker Slot an der Troopers 23 Security Konferenz in Heidelberg teilgenommen. In diesem Blogartikel möchten wir das vorgestellte Thema nochmals einer größeren Audienz zur Verfügung stellen. Wir glauben fest daran, dass eine Tiering Struktur die IT-Sicherheit nachhaltig verbessern kann. Es gibt jedoch ein paar Themen zu beachten und genau diese möchten wir an dieser Stelle teilen.
Doch zunächst was ist die Troopers überhaupt? Eingefleischte Sicherheits-Enthusiasten wird sie wahrscheinlich ein Begriff sein, aber vermutlich kennt sie längst nicht jeder. Die Troopers ist eine jährliche Sicherheitskonferenz in Heidelberg, die sehr tiefgreifend IT-Security Themen in Trainings, Vorträgen und Roundtables behandelt. Immer wieder sind auch Active Directory Sicherheitsthemen auf der Agenda. Auch die Speaker sind international anerkannt. So hat z.B. von Sean Metcalf (Mr. AD Security 😊 Sean Metcalf – Active Directory Security (adsecurity.org)), aber auch unsere Partnerfirma SpecterOps bereits Vorträge dort gehalten.
Grund genug für uns auch dabei sein zu wollen. Deswegen haben wir Anfang 2023 zusammen mit unseren Freunden von SpecterOps einen Vortrag eingereicht – der zu unserer Freude auch schnell angenommen wurde.
Unser Thema – Hidden Pathways: Exploring the Anatomy of ACL-Based Active Directory Attacks and Building Strong Defenses
Während wir mit SpecterOps brainstormten, erkannten wir schnell das Potenzial, unsere jeweiligen Stärken zu vereinen und unseren Zuhörern einen wertvollen Mehrwert zu bieten. SpecterOps ist mit BloodHound und BloodHound Enterprise spezialisiert darauf, Angriffspfade aufzuspüren, zu visualisieren und technische Informationen als Verteidigungsmaßnahmen zu präsentieren. Teal hilft den Kunden administrative Prozesse und Architekturen zu bewerten und so zu verbessern, dass die Angriffsfläche verkleinert wird und die Auswirkung eines erfolgreichen Angriffs möglichst minimiert wird.
Rein aus technischer Sicht betrachtet ist es „einfach“ einen Angriffspfad zu schließen, indem man z.B. eine Berechtigung entfernt. In einer gewachsenen komplexen IT-Infrastruktur ist es aber oftmals sehr schwierig ohne gute Vorbereitung Änderungen „mal eben“ durchzuführen. Genau hier setzen wir an und helfen unseren Kunden. Ziel ist es die Prozesse und Verhaltensweise so anzupassen, dass die Betriebsmannschaft einbezogen und Sicherheitsmaßnahmen angemessen implementiert werden können.
Der vollständige Vortrag als Video
Nach einer zugegeben etwas längeren Einleitung nun aber zu Thema.
Im Active Directory gibt es sowohl Standardberechtigungen als auch historisch gewachsene Fehlkonfigurationen, die ein Angreifer ausnutzen kann. Zunächst gehen wir kurz darauf ein, wie Berechtigungen im AD funktionieren, beschreiben dann wieso dieses altbekannte Thema auch heute noch relevant ist um abschließend unseren Lösungsansatz vorzustellen.
Was sind AD ACLs / ACEs?
Jedes Objekt im Active Directory hat eine Access Control List (ACL). Genau wie im NTFS Filesystem beschreibt die ACL „wer was darf“. Die ACL setzt sich aus einzelnen Access Controll Entries (ACEs), die eine atomare Berechtigung definieren, zusammen. Das sieht dann so aus:
Das User Objekt „Andy“ hat eine ACL die sich aus 32 ACEs zusammensetzt. Um einige Beispiele zu nennen:
-
- Die Gruppe „Account Operators“ hat das Recht „Full Control“
- Die Gruppe „Cert Publishers“ hat das Recht die Eigenschaft „UserCertificate“ zu lesen und zu schreiben
- Die Gruppe Service Desk hat das Recht „Reset Password“
Wie können ACLs ausgenutzt werden (Beispiele)
Bloodhound visualisiert die (bekannten) Ausnutzbaren ACLs in so genannten Edges:
In diesem Beispiel kann die Gruppe Helpdeskadmins Mitglieder zur Gruppe Serveradmins hinzufügen. Da Andy Mitglied dieser Gruppe ist, hat auch er dieses Recht. Die Gruppe Serveradmins hat wiederum das Recht „Generic All“ = Vollzugriff auf einen Server namens „Adminserver01“.
Das Recht „Vollzugriff“ kann auf verschiedene Arten ausgenutzt werden:
-
-
- Wenn der Kunde LAPS einsetzt, kann der Angreifer das Passwort des lokalen Administrators auslesen
- Ein shadow credential Angriff mit dem das TGT oder der NTLM Hash des Objekts gestohlen wird
- Ein Resource Based Constrained Delegation Angriff der einen beliebigen User gegen das Objekt authentifiziert.
-
Warum sind ACLs auch heute noch ein Sicherheitsproblem?
ACL basierte Angriffe sind nicht neu, Miskonfigurationen begegnen uns aber in quasi jeder Umgebung.
Wir haben 4 Gründe identifiziert, warum das unserer Meinung nach so ist:
-
-
- ACLs sind kompliziert.
Der Default Security Descriptor definiert die Berechtigungen, die jedes neu erstellte Objekt hat. Würde z.B. ein Pentest Report aufzeigen, dass ein Angreifer die weiter oben beschriebene „Full Control“-Berechtigung ausgenutzt hat, könnte man denken, das das Entfernen der Berechtigung das Problem löst. In der Realität wird aber jedes neu erstellte Objekt diese ACE wieder enthalten und somit wieder ausnutzbar sein.
Neben dem Default Security Descriptor gibt es noch den AdminSD Holder Prozess. Dieser schützt die aus Microsoft’s Sicht schützenswerten Objekte und überschreibt Änderungen an den Berechtigungen. Um beim Beispiel des Pentest Reports zu bleiben, würde man die Berechtigung eines geschützten Objekts nach dem Pentest anpassen, würde die Änderung nach einer Stunde wieder rückgängig gemacht werden. Leider werden nicht alle relevanten Objekte vom AdminSD Holder Prozess geschützt. - Es werden nach wie vor neue Angriffswege die alle auf ACLs basieren gefunden. Hier ein Beispiel was allein in Bloodhound seit 2017 hinzugefügt wurde:
- Die Anzahl von ACLs und Beziehungen zu anderen Objekten ist unfassbar groß. Auf dem folgendem Bloodhound Enterprise Screenshot aus einer relativ kleinen Umgebung mit ~4500 Benutzern ist zu erkennen, dass es 360.000 ACLs bzw. ~480.000 Beziehungen gibt.
- ACLs sind kompliziert.
-
Das sind Größenordnungen weit jenseits von dem was manuell geprüft werden kann.
Was können wir jetzt tun?
Eine und die von uns favorisierte Lösung ist eine Tiering Struktur einführen und die Assets anhand ihres Schutzbedarfs zu schützen. Ein Teilaspekt und Kernthema des Troopers Vortrags / dieses Artikels ist der Aufbau einer geschützten OU Struktur als Grundgerüst für das Tiering. Über einige der anderen Maßnahmen haben wir schon gebloggt (LINK1, LINK2), weitere Artikel werden folgen.
Wir empfehlen ausdrücklich NICHT Berechtigungen in existierenden OUs anzupassen (vereinzelte Quick Wins ausgenommen). Stattdessen sollte eine neue OU-Struktur erstellt, mit den passenden Rechten versehen und befüllt werden.
Die Empfehlungen für die Berechtigungen basieren auf einem Best Practice Guide aus dem Jahre 2011 😊. Diese 12 Jahre alte Quelle ist nach wie vor gültig und, wir kennen derzeit keine neuere gültige Referenz. Falls jemand eine neuere Quelle hat, kann er sich sehr gerne melden. Wir würden auch ein Eis spendieren 😊.
Rollen und Verantwortlichkeiten definieren
Zuerst muss die Frage beantwortet werden – wer soll was machen? Was sich einfach anhört, ist oftmals nur sehr schwer zu beantworten. Unternehmen wissen oftmals nicht, wer was übernehmen soll. Oder es kommen Aussagen wie – alle in Team XY müssen lokaler Administrator auf allen Servern sein. Genau so funktioniert es aber nicht. Es ist mühsam und schmerzhaft, diese Altlast muss aber dennoch zwingend beseitigt werden. Hier ein Auszug als Beispiel wie eine Definition aussehen könnte:
Eine neue OU-Struktur Aufbauen
Microsoft empfiehlt im ESAE-Modell eine Unterteilung in Tier0, Tier1 und Tier2. Das kann beispielsweise so aussehen:
Die Struktur kann natürlich an die Bedürfnisse der jeweiligen Organisation angepasst werden.
Um es unseren Lesern einfacher zu machen, haben wir ein Skript zu Erstellung der OUs veröffentlicht:
https://github.com/teal-technology-consulting/New-TealTierOUs
Die OUs werden über eine XML definiert und per Skript angelegt. Einfach unseren Vorschlag übernehmen, oder die XML anpassen.
Berechtigungen setzen
Als nächstes müssen auf die neu erstellten OUs die Berechtigungen aus dem Best Practise Guide gesetzt werden. Auch hierfür haben wir ein Skript veröffentlicht: teal-technology-consulting/Set-TealTierOUAcl: Sets secure permissions on a tiering OU structure (github.com)
Es unterbindet die Vererbung auf der obersten Ebene (Administration OU im Beispiel oben), setzt die gewünschten Berechtigungen und entfernt alle direkten Berechtigungen auf untergeordneten OUs.
Die Vererbung auf den untergeordneten OUs bleibt eingeschaltet, damit Delegierungen wie gewohnt vererbt werden.
Hoch privilegierte Gruppen verschieben
Der Best Practise Guide besagt, dass die Standard Gruppen „Domain Admins“, „Schema Admins“ und Enterprise Admins in die gesicherte OU-Struktur verschoben werden sollen.
Aus unserer Sicht ist das nicht ausreichend. Neben den genannten Gruppen und den Gruppen die durch den Admin SD Holder Prozess geschützt sind, ist heute bekannt, dass weitere builtin-Gruppen ausgenutzt werden können.
Microsoft hat zwar eine Dokumentation welche Gruppen verschoben werden dürfen, aus unserer Sicht enthält die Dokumentation Fehler und ist auch nicht immer hilfreich:
Daher empfehlen wir alle Gruppen aus der „Users“ OU zu verschieben, NACHDEM man die Auswirkung in der eigenen Umgebung getestet hat.
Berechtigungen regelmäßig setzen
Nun wären wir eigentlich soweit, die restlichen Assets in die korrekten Ous zu verschieben. Weiter oben haben wir erwähnt, dass neue Objekte die ACLs aus dem Default Security Descriptor erhalten. Dadurch bekommen die Account Operatoren weitreichenden Zugriff auf Benutzer und Gruppenobjekte die innerhalb der geschützten OU Struktur neu angelegt werden:
“The Account Operators group grants limited account creation privileges to a user. Members of this group can create and modify most types of accounts, including accounts for users, Local groups, and Global groups. Group members can log in locally to domain controllers.”
Grundsätzlich empfehlen wir die Account Operators nicht zu nutzen, was natürlich einen Angreifer nicht davon abhält die Berechtigungen auszunutzen. Daher haben wir ein Skript geschrieben, welches regelmäßig z.B. alle 15 Minuten durch einen Scheduled Task ausgeführt werden soll und die Account und Print Operatoren aus den ACLs aller Objekte in der geschützten OU Struktur entfernt.
Das Skript ist hier zu finden:
Eine alternative Option ist den Default Security Descriptor anzupassen. Da wir nicht ausschließen können, dass dies unbeabsichtigte Seiteneffekte nach sich zieht, bevorzugen wir die Skript Variante.
Neue Objekte, delegieren und verschieben
Die OU-Struktur ist nun einsatzbereit und es können Assets in die Struktur verschoben werden. Das ist je nach Organisationsgröße durchaus ein langwieriger Prozess.
Es empfiehlt sich zuerst mit den neu anzulegenden Objekten zu starten und die Administratoren im Umgang mit der neuen Struktur zu schulen.
Werden Bestandsobjekte verschoben, müssen die Berechtigungen kontrolliert werden, da direkt gesetzte ACEs mit umgezogen werden. Das gilt übrigens auch für Group Policy Objekte, die an die neue OU-Struktur verlinkt werden.
Um die Tiertrennung der Accounts durchzusetzen, sollten Kerberos Authentication Policy Silos eingerichtet werden. Aber das ist ein Thema für einen anderen Post 😉.
Fazit
Mit den aufgezeigten Änderungen kann ein erheblicher Beitrag zu Steigerung der IT-Sicherheit realisiert werden. Die gezeigten Tätigkeiten sind teilweise komplex und mühsam, lohnen sich aber definitiv. Zum einen hat man nach der Durchführung definiert wer welche Verantwortlichkeiten hat und veraltete Berechtigungsstrukturen aufgeräumt. Das ganze Thema kann vollständig ohne teuren Detection and Response Lösungen realisiert werden – kostet also keine Lizenzen, sondern „nur“ den Aufwand von vorhandenen IT-Ressourcen. Nicht falsch verstehen, Detection and Response Tools haben natürlich auch einen Mehrwert, aber oftmals hat man mehrere Tools im Einsatz die teilweise sogar dasselbe umsetzen. Hier könnte man sinnvoll sparen und stattdessen die Zeit und das Budget für die Beseitigung von Altlasten verwenden. Bei Fragen unterstützen wir gerne, einfach bei uns melden.
Off Topic
An dieser Stelle ein herzliches Dankeschön an unseren Alex, dass er diesen Vortrag vorbereiten und bei der Troopers präsentiert hat. Sobald der Talk online ist, werden wir diesen auch noch verlinken. Bis dahin ein paar Impressionen von der Troopers, inklusive Feueralarm mitten in der Nacht 😊.
Klicken Sie auf den unteren Button, um den Inhalt von www.linkedin.com zu laden.
Klicken Sie auf den unteren Button, um den Inhalt von www.linkedin.com zu laden.
Klicken Sie auf den unteren Button, um den Inhalt von www.linkedin.com zu laden.
Klicken Sie auf den unteren Button, um den Inhalt von www.linkedin.com zu laden.
Sieh dir diesen Beitrag auf Instagram an
Sieh dir diesen Beitrag auf Instagram an
LATEST POSTS
-
Datensicherheit durch Tiering – Schutz auf jeder Ebene
In diesem Artikel geben wir Ihnen einen genaueren Einblick in die Bedeutung von Microsoft Tiering für Ihre IT-Sicherheit. Wir haben uns die zugrunde liegenden Probleme sowie die kritischen Bereiche und Systeme angesehen,...
16 Oktober, 2024 -
it-sa 2024: Besuchen Sie uns in Nürnberg!
In diesem Jahr sind wir das erste mal gemeinsam mit unserem Partner FB Pro GmbH mit einem Stand und einem Fachvortrag auf einer der bedeutendsten IT-Sicherheitsmessen Europas vertreten: der it-sa 2024 in Nürnberg...
15 August, 2024 -
Windows LAPS: Was kann das „neue“ LAPS und sollte ich es nutzen?
Seit längerem ist nun eine neue Version von LAPS – Windows LAPS – verfügbar. In diesem Artikel wollen wir auf die Neuerungen eingehen und beleuchten, ob eine Migration auf die neue Version Sinn macht....
15 Juli, 2024