SecCore Essentials - Active Directory Tier Model

Zusammenfassung

Dieser Blogeintrag behandelt wichtige Konfigurationen und Designimplementierungen des On-Premise Active Directory Tiering Modells. Dieses SecCore Essential ist implementiert wenn die folgenden Maßnahmen ergriffen wurden:

• Die Active Directory Struktur umfasst zumindest drei unterschiedliche Administrationsebenen für Computer, Benutzer- und Service-Accounts:
  • Tier 0: Domain Ebene
  • Tier 1: Enterprise Server Ebene
  • Tier 2: Client Workstation Ebene
• GPOs die explizit alle Arten der Anmeldung für Konten aus anderen Ebenen einschränken wurden implementiert:
  • Deny log on as a service
  • Deny log on as a batch job
  • Deny log on locally
  • Deny log on through Terminal Services
• Kein niedrig privilegierter Account hat administrative Berechtigungen für Systeme
• Administrative Accounts sind von normalen Accounts getrennt
• Es existieren Privileged Access Workstations (PAW) für jede Administrationsebene

Einleitung

Das Microsoft Active Directory Zugriffsmodell ist standardmäßig nicht sicher. Accounts können zu beliebigen Gruppen hinzugefügt und mit administrativen Berechtigungen auf jedem System ausgestattet werden. Dies kann zu Verstößen des Least Privilege Principle¹ führen. Ohne starke Sicherheitseinstellungen auf Client und Server Systemen ist es auch möglich, Passwörter und Passwort-Hashes von angemeldeten Accounts auszulesen und für weitere Angriffe sowie Lateral Movement zu verwenden.

Um dieses Problem zu beseitigen, sollte die administrative Ebene eines Active Directory Netzwerks in zumindest drei Teile (sogenannte Tiers) aufgeteilt werden:

Tier 0 - Die Domain Ebene

Diese umfasst zentrale Domänendienste wie den Domänen-Controller, Active Directory Federation Services (ADFS) oder Active Directory Certificate Services (ADCS). Administrative Accounts in dieser Ebene des Tiering Modells können die gesamte Domäne und alle Dienste verwalten. Daher stellt sie die oberste und kritischste Ebene dar.

Tier 1 - Die Enterprise-Server Ebene

Diese Ebene umfasst Server, die Unternehmensdienste zur Verfügung stellen. Darunter fallen unter anderem Datenbankserver, Dateiserver und Unternehmensapplikationen wie ERP-Systeme. Accounts in dieser Ebene können Server administrieren, die nicht Teil der Kerninfrastruktur der Active Directory Domäne sind, aber trotzdem sensible Daten beinhalten. Berechtigungen für diese Ebene sollten nach dem Least Privilege Principle vergeben werden. Bestimmte Server- oder Applikationsadministratoren sollten nur Berechtigungen auf den Server(gruppen) erhalten, die sie benötigen.

Tier 2 - Die Client-Workstation Ebene

Die Client-Workstation Ebene sollte nur Client-Geräte wie Laptops oder Workstations enthalten. Es handelt sich hierbei um die am wenigsten privilegierte Ebene. Accounts erhalten hier nur Zugriff auf Clients um Probleme zu beheben und Endnutzern zu helfen. Dies ist auch die Ebene, über welche durch Schadsoftware am ehesten Angriffe auf das Netzwerk passieren.

Wenn dieses Modell korrekt implementiert wurde, ist es nicht mehr möglich, sich von einer Ebene zur nächsten zu bewegen, da diese strikt voneinander getrennt sind.

Durch GPOs muss auch sichergestellt werden, dass keine Anmeldungen von anderen Ebenen erlaubt werden.

Zusätzlicher Hinweis

Systeme, die Tier 0 Geräte oder VMs auf welche Art auch immer verwalten oder sichern, dürfen nicht im Active Directory verwaltet werden. Sie sollten gar nicht an die Domäne angebunden sein und sind daher in keiner Tiering-Ebene zu finden.

Solche Systeme sind unter anderem:

• Virtualisierungs-Hypervisoren
• Backup Systeme
• Server Management Schnittstellen wie HPE iLO oder Dell iDRAC

In unserem Network Layer Security und Backup Management Essential stehen weitere Informationen zur Verfügung, wie solche Systeme abgesichert werden können.

Häufige Angriffsvektoren

Der folgende Abschnitt beschreibt potenzielle Angriffsvektoren, die auftreten, wenn das Tiering-Modell nicht oder nicht korrekt implementiert wurde.

Lateral Movement auf kritische Systeme

Im Zuge eines Angriffs ist es ein häufiges Ziel, die derzeitigen Berechtigungen zu erhöhen. Im Fall eines Active Directory Netzwerks ist die Domain Administrators Gruppe ein lohnenswertes Ziel, da diese über weitreichende Berechtigungen verfügt. Angriffe gehen dabei häufig von niedrig privilegierten Systemen wie zum Beispiel Arbeitslaptops aus, da diese am ehesten mit Schadsoftware infiziert werden können. Anschließend wird versucht, Anmeldedaten oder Zugriff auf sensiblere Systeme wie Datenbankserver oder Domänen Controller zu erlangen. Ein häufiger Angriffsvektor ist hierbei, Zugangsdaten von höher privilegierten Accounts, welche sich auf niedrig privilegierten Systemen angemeldet haben, auszulesen. Hat sich zum Beispiel ein Account mit administrativen Berechtigungen auf vielen Servern an einer Client-Workstation angemeldet, kann dessen Passwort kompromittiert werden, wenn die Workstation mit Schadsoftware infiziert wurde.

Dieser Angriff kann auf weiteren Systemen wiederholt werden, bis am Schluss ein Account in der Domain Administrators Gruppe kompromittiert wurde.

Angriffsszenario

Dieses Szenario demonstriert, wie fehlendes Active Directory Tiering ausgenutzt werden kann, um im Falle eines Angriffs die Active Directory Domäne zu kompromittieren. Der Aufbau dieses Angriffsszenarios ist wie folgt:

• Es wurde kein Tiering Modell implementiert
• Domänen-Administratoren werden für alltägliche Aufgaben verwendet
• Ein Client-System wurde bereits vollständig kompromittiert und administrative Berechtigungen erlangt
• Es wurde keine Rücksicht auf OPSEC genommen, der direkteste Ansatz wurde gewählt

Mit administrativen Berechtigungen auf einem Microsoft Windows System ist es möglich, geplante Tasks als NT AUTHORITY\SYSTEM zu erstellen und auszuführen. Dieser Account besitzt die höchstmöglichen Berechtigungen auf dem System. Mit diesen Berechtigungen kann nun ein geplanter Task erstellt werden:

Wie im Screenshot oben ersichtlich, wird dieser Task als die Domain Users@lab.local Gruppe ausgeführt. Ebenfalls wird dieser Task bei der Anmeldung von beliebigen Accounts gestartet:

Das bedeutet, dass sobald sich ein Account der Gruppe Domain Users@lab.local anmeldet, dieser Task als der angemeldete Account ausgeführt wird. Dies kann nun ausgenutzt werden, indem eine Action im Task erstellt wird:

Dieser Befehl erstellt einen neuen Account in der Domäne und fügt diesen der Domain Admins@lab.local Gruppe hinzu:

C:\Windows\System32\cmd.exe /c "net user hacker NicePWD1! /add /dom & net group "Domain Admins" /add hacker /dom"

Nun muss nurmehr darauf gewartet werden, dass sich ein Domain Admin auf diesem kompromittierten System anmeldet. Alternativ kann auch absichtlich ein Fehler provoziert werden, um einen Support- oder administrativen Account zur Anmeldung zu bringen. Dies wird den neuen Account hacker@lab.local zur Domain Admins@lab.local Gruppe hinzufügen:

Gegenmaßnahmen

Wenn eine mehrstufige Tiering-Architektur mit Anmelderestriktionen implementiert ist, insbesondere die Sperre von Anmeldungen von Tier 0- und Tier 1-Accounts auf Client-Systemen, können sich diese nicht mehr verbinden und dieser Angriff schlägt fehl.