Privilegierte Accounts sind als kritisch zu betrachtende Komponente einer IT-Infrastruktur anzusehen. Wer sich nicht mit den eminenten Risiken des Themas beschäftigt und seine privilegierten Windows Accounts, wie zum Beispiel Domain Administratoren, nicht adäquat schützt, exponiert seine Infrastruktur den wachsenden Bedrohungen von Cybercrime. Die Praxis zeigt, dass fahrlässiges Verhalten doch immer wieder anzutreffen ist. Sind gerade hoch privilegierte Accounts exponiert, reicht es oft schon aus, dass ein Angreifer den “richtigen” Client kompromittiert, um die Kontrolle über eine komplette Infrastruktur zu erlangen.

Privilegierte Accounts zu schützen ist in der Theorie nicht kompliziert, einige wenige Prinzipen sind zu beachten. In der Praxis sind dann doch viele unterschiedliche Faktoren mit einzubeziehen, um adäquates Handling und Management sicherzustellen. Dabei gibt es einige ganz praktische Massnahmen, welche gewisse Risiken minimieren, die sehr schnell und einfach implementiert werden können. In diesem Artikel sollen eben solche aber auch tiefgreifenderen Konzepte vorgestellt werden.

Exponierte privilegierte Accounts

Wann sind privilegierte Accounts exponiert? Eine Art dies einfach zu erklären wäre: umso “näher” ein privilegierter Account dem Internet ist, umso exponierter ist er. Also mit Domain-Administrator-Rechten auf einem Standard-Client einzuloggen exponiert diesen Account. Die Sicht eines Angriffes ist meist auch von aussen nach innen, also zum Beispiel:

• Angriff von Internet auf einen Client
• Angriff von einem Client auf einen Server
• Angriff von einem Server auf einen sensitiven Server (zum Beispiel Domain Controller, Datenbanken)

Eine gängige Annahme in der IT-Security ist, dass stehts von einem kompromittierten Client ausgegangen werden muss. Folgend eine grobe Beschreibung von möglichen Aktionen eines Angreifers:

1. Zugriff auf ein System mittels Infizierung durch Schadsoftware (Social Engineering, Spear-Phishing) oder direkten physischen Zugriff (z.B. internen/externe Mitarbeiter), meist mit nicht-privilegierten Benutzer
2. Privilege Escalation zu lokalen Administrator-Rechten mittels Ausnutzen von Schwachstellen oder anderen Techniken
3. Beschaffung von NTML Hashes, respektive Auslesen der Hashes der auf dem System eingeloggten Benutzen (Mimikatz, responder.py, Network Sniffing z.B. mit ettercap)
4. Lateral Movement mit den zusammengetragenen Hashes oder Tickets (Pass the Hash oder Pass-the-Ticket, etc.) um Zugriff auf weitere Systeme zu erlangen (Bloodhound)
5. Wiederholen von Schritt 3 & 4 bis für das Angriffsziel geeignete Rechte im Netzwerk erlangt werden konnten
6. Zugriff auf das Zielsystem (z.B. Zahlungsserver) und Ausführen bösartiger Aktionen (z.B. betrügerische Zahlung ausführen)

Obige beschrieben Punkte können sehr langsam von statten gehen. Angreifer müssen vorsichtig und “lautlos” vorgehen, um eine allfällige Detektion zu verhindern. Für Schritt 1-5 des Angriffspfads können gut mehrere Monate aufgewendet werden.

Folgend einige Beispiele von exponierten privilegierten Accounts aus der Praxis:

• Sind öffentliche zugängliche Systeme vorhanden, z.B. ein Internet-PC in einem Hotel, lassen sich darauf schon mal in einem unattended.txt Domain Administrator Credentials finden
• Hat der Benutzer des infizierten Systems bereits lokale Administrator Rechte, können die NTLM Hashes ohne Privilege Eskalation ausgelesen werden (Entwickler, Superuser)
• Im Besten Falle für den Angreifer hat der eingeloggte Benutzer gleich Domain Admin Rechte (IT Administratoren, “Superuser”)
• Es existieren “Service Principal Names” für persönliche Benutzer mit Domain-Administrator Rechten, welche mit Kerberoasting Attacken angegriffen werden können
• Standard Benutzer mit defacto Domain-Administrator Rechten durch verschachtelte AD-Gruppen. Dazu muss nicht eine Member Of Beziehung vorhanden sein, sondern auch Beziehungen wie GenericAll oder AddMember.

Defensive Techniken

Folgend nun einige Konzepte und Praktiken, die als Startpunkt oder Inspiration zur Sicherung der eigenen privilegierten Accounts dienen.

Mit privilegierten Accounts sind nicht nur Administratoren und Domain-Administratoren gemeint. Dazu gehören viele der Service Benutzer sowie Standard Accounts mit Zugriff auf sensitive Daten (Geschäftsleitung und Management, Finanzabteilungen, etc.).

Prozesse und interne Weisungen

Folgende Prinzipen und Konzepte sollten sich in den Security Policies für Identify and Access Management (IAM) grundsätzlich und Privileged Account Management (PAM) im Spezifischen wiederfinden:

• Kennen Sie Ihre Daten und Ihre Benutzer (Datenklassifikationen und Benutzerkonzepte)
• Least-Privilege Prinzip
• Segregation of Duties Prinzip
• Multi-Faktor Authentication für alle privilegierten Zugriffe
• Starke Passwort Policy (z.B. für Benutzer mit Domain-Administrator-Rechten 24+ Zeichen)
• Aufzeichnen der Aktivitäten von privilegierten Benutzer (Session Recording und Logging)
• Verbot der Nutzung von einem privilegierten Account durch mehrere Benutzer (Account Sharing)
• Verschärfte Audit-Prozesse von privilegierten Accounts
• Automatisierte IAM-Prozesse (löschen/deaktivieren von privilegierten Accounts, wenn Mitarbeiter austritt, Abt. wechselt, Zugriff nicht mehr benötigt, etc.)
• Vermeiden von hardcodierten Passwörtern in Applikationen
• Privilegierte Zugriffe durch externen Partner nicht vergessen

Wer einen umgänglichen Anforderungskatalog für seine Security Policies bezüglich Access Management sucht, kann sich bei den Access Controls AC2, AC3, AC5 und AC6 aus dem Katalog des NIST Cybersecurity Framework bedienen.

Sind interne Weisungen und Policies vorhandenen, müssen diese auch um- und durchgesetzt werden können, ansonsten existiert die “Sicherheit” nur auf dem Papier. Daher gehören auch Prozesse zur Durchsetzung und Kontrolle der Weisungen wie auch Ressourcen für die Implementation und Betrieb stets dazu.

Unangenehm aber nötig ist die Definition über die Handhabung bei Verstössen gegen die Weisung. Es kommt vor, dass sich der eine oder andere IT-Mitarbeiter über die Jahre an Domain-Administrator-Rechte seines normalen Accounts gewöhnt hat und diese nicht gerne abgeben bez. nicht mit mehreren Accounts arbeiten möchte. Nichts destotrotz wird mit den “alten Gewohnheiten” das Risiko respektive die Exponierung von privilegierten Accounts teilweise massiv erhöht.

Windows Active Directory

Microsoft bietet eine umfassende und praktische Dokumentation mit dem Titel Best Practices for Securing Active Directory an. Darin finden sich diverse Kapitel, welche sich mit der Sicherung von Accounts und privilegierten Accounts beschäftigen.

Weitere Microsoft Ressourcen finden sich unter folgenden Links:

• Privileged Access Management for Active Directory Domain Services
• Securing Privileged Access

Das Studium dieser Lektüre ist empfehlenswert. Unter anderen sind folgende Themen aus den Microsoft-Unterlagen spannend:

• Privileged Access Management Lösung (PAM) in AD DS
  • Tool rund um das Management von privilegiertem Access
  • Risikominimierung von Pass-the-Hash
  • Isolation und Scoping von Privilegien
  • Multi-Faktor Authetication
• Just Enough Administration
  • PowerShell Tool um die Anzahl von privilegierten Accounts zu minimieren
  • Erlaubt spezifische administrative Arbeiten (welche mit PowerShell erledigt werden können) ohne privilegierten Account

Da die Dokumentation von Microsoft sehr umfangreich und weitreichend ist, anbei einige wenige Punkte, die gleich Umgesetzt werde können (Quickwins). In späteren Umsetzungsphasen können den obigen verlinkten Anleitungen von Microsoft im Detail umgesetzt werden.

Konsequente Einhaltung der Prozesse

• Prozess zur Review der Administratoren Gruppen im AD und lokal auf den Clients/Servern etablieren. Meist sind da zu viele Benutzer drin, welche die hohen Rechte nur temporär oder aus Bequemlichkeit “benötigen”. Diese konsequent und regelmässig entfernen. Hierbei auch die Verschachtlung von Gruppen beachten.
• Tägliche Arbeiten auf Clients stets ohne privilegierte Accounts verrichten. Dies betrifft vor allem Entwickler, IT-Administratoren und IT Support Mitarbeiter.
• Verbot von Support-Arbeiten mit Domain-Administrator-Rechten auf den Clients/Servern
• Zugriff auf sensible Daten/Server sowie Arbeiten mit hoch privilegierten Accounts (z.B. Domain Admin) von einem dedizierten Admin-Jump-Host ermöglichen, respektive nicht von einem Client aus, der am Internet exponiert ist
• Der built-in Lokale Administrator Benutzer auf Servern und Clients sollte deaktiviert werden und dessen Passwort solle auf jedem Client/Server einzigartig sein. Dazu kann das Tool LAPS von Microsoft verwendet werden.

Passwort Policy

Sehr starke Passwort Policy (komplexe und keine sprechenden Passwörter, min. 24 Zeichen), für mindestens folgenden Benutzer/Gruppen:

• Domain Administrators
• Enterprise Administrators
• Schema Administrators
• Account Operators
• Backup Operators
• BUILTIN\Administrators
• Service Accounts für Softwareinstallationen und Updates
• Service Accounts für Security Scans und Antivirussoftware

Client und Server Hardening

Folgende Group Policy Logon Rights Restrictions verhindern viele der Lateral Movement Techniken:

• Deny access to this computer from the network
• Deny logon as a batch job
• Deny logon as a service
• Deny logon locally
• Deny logon through Remote Desktop

Weitere Hardening Guides:

• Windows 10 Client Hardening
• Windows Server Hardening

Einsatz des Tools Bloodhound für AD. Damit lässt sich in kurzer Zeit ein Bild darüber verschaffen welche Benutzer mit welchen Rechten auf welchem System eingeloggt sind. Damit lassen sich mögliche Angriffspfade und ein entsprechendes Nichteinhalten von internen Richtlinien erkennen, sowie das Erkennen von Schwachstellen an denen nachgebessert werden kann.

Logging und Monitoring

Zu Letzt das Thema Logging und Monitoring von privilegierten Account:

• Grundsätzlich Advanced Audit Policies aktivieren
• Security Log Monitoring zentralisieren, z.B. mit Graylog
• Die Cheat-Sheet Sektion von malwarearchaeology.com bietet gute Einstiegshilfen bezüglich was und warum geloggt und alarmiert werden kann
• Microsoft bietet eine erweiterte Liste von wichtigen Event IDs, welche bei Analyse und Alerting hilfreich sein können

Nicht in der obigen Liste geführt wird Netzwerksegmentierung, mindestens zwischen der Client- und Server-Population. Falls nicht vorhanden, ist einiges an Aufwand nötig um dies umzusetzen. Jedoch gehört die Abschottung von den Servern zu den am Internet exponierten Clients zu den Grundpfeilern eines modernen Security-Konzepts.

Fazit

Priviligierte Benutzer werden in der Praxis noch nicht flächendeckend und ausreichend geschützt. Dadurch werden Angriffe auf eine entsprechende Infrastruktur vereinfacht. Fehlt dazu noch eine adäquates Security Logging und Monitoring, kann eine allfällige Kompromittierung für lange Zeit nicht erkannt werden. Unter Umständen wird so die gesamte Infrastruktur teils fahrlässig exponiert.

Microsoft hat mit ihrer aktuellen Software auf die gängigen Angriffs-Pfade reagiert und umfangreiche Dokumentationen dazu erstellt sowie Funktionen und Tools bereitgestellt, um unter anderem den Missbrauch von privilegierten Accounts zu erschweren. Jedoch sind die Risiken und Lösungen doch noch in einigen Unternehmen nicht bekannt. Abschliessend sind die hier vorgestellten Punkte nicht, aber die Konzepte und Tools können in den gängigen AD-Umgebungen als Startpunkt und Inspiration dienen.

Über den Autor

Dominik Altermatt arbeitet seit 2003 in der IT-Branche. Unter anderem hat er sich mehrere Jahre mit Data Leakage Prevention bei einer Grossbank beschäftigt. Heute liegen seine Schwerpunkte neben klassischen Penetration Tests bei der Einführung und der Weiterentwicklung von IT-Security-Management-Prozessen. (ORCID 0000-0003-4575-4597)

Links

• https://blog.stealthbits.com/complete-domain-compromise-with-golden-tickets/
• https://blog.stealthbits.com/passing-the-hash-with-mimikatz
• https://docs.microsoft.com/en-us/microsoft-identity-manager/pam/privileged-identity-management-for-active-directory-domain-services
• https://docs.microsoft.com/en-us/powershell/jea/overview
• https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/appendix-l—events-to-monitor
• https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/best-practices-for-securing-active-directory
• https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/monitoring-active-directory-for-signs-of-compromise
• https://docs.microsoft.com/en-us/windows-server/identity/securing-privileged-access/securing-privileged-access
• https://github.com/SpiderLabs/Responder
• https://nvd.nist.gov/800-53
• https://pentestlab.blog/2018/06/12/kerberoast/
• https://vuldb.com/de/
• https://www.cisecurity.org/benchmark/microsoft_windows_server
• https://www.ettercap-project.org/
• https://www.graylog.org/
• https://www.malwarearchaeology.com/cheat-sheets/
• https://www.microsoft.com/en-us/download/details.aspx?id=46899