Domänenadministratoren, Single Sign-on und Malware

Die Gefahr durch Domänenadministrator-Konten wird oft unterschätzt. In diesem Artikel wird beschrieben, wie Angreifer dadurch eine ganze Domäne kompromittieren können. Generell werden Berechtigungen zu locker verteilt und (zum Teil vorhandene) Sicherheitsmechanismen nicht eingesetzt.

Einleitung

Aktuelle Sicherheitsaudits und forensische Untersuchungen von Oneconsult zeigen, wie einfach der anscheinend normale Umgang mit administrativen Benutzern ausgenutzt werden kann. Hat ein Angreifer oder eine Malware erst einmal den Domänencontroller übernommen, ist das meistens der Ernstfall für das Unternehmen – und Anlass zum Feiern für den Angreifer.

Die meisten Unternehmen setzen auf irgendeine Weise Microsoft-Betriebssysteme ein, die oft über einen Domänencontroller in das Netzwerk eingebunden und verwaltet werden. Auch Umsysteme wie Firewalls, VPN Gateways, Linux Systeme und weitere können in das Active Directory eingebunden werden. Das bringt diverse Vorteile mit sich: Dazu gehören Single Sign-on (SSO) und Konten für Domänenadministrationen, die sich überall anmelden und alle Einstellungen verwalten können. Oft werden diese privilegierten Konten neben anderen administrativen Aufgaben auch zur Fehlerbehebung verwendet. Das ist naheliegend, hat doch ein Domänenadministrator die nötigen Rechte und kann sich gegebenenfalls für weiteres Troubleshooting auch noch auf Server und andere Clients verbinden. Auf lange Sicht könnte dieses Vorgehen jedoch verheerende Folgen nach sich ziehen, wie sich weiter zeigen wird.

Die Gefahr der Ausnutzung ist vielseitig: Es muss nicht zwingend ein Angreifer von aussen sein, der eine vorhandene Sicherheitslücke in einem System ausnutzt. Auch Malware, ein missgestimmter Mitarbeiter oder lokale Administratoren (und weitere) können Anmeldedaten eines Domänenadministrators verwerten. Folgend zwei Beispiele:

Gelingt es einem Angreifer, zum Beispiel durch das Ausnutzen einer Sicherheitslücke, zunächst lokale Administratorenrechte auf einem System zu erlangen, sind die folgenden weiteren Szenarien (im Rahmen dieses Artikels) möglich:

• Der Angreifer, der bereits lokale Administratorenrechte besitzt, trägt sich im Autostart ein und wartet, bis sich ein Domänenadministrator anmeldet. Das könnte der Angreifer sogar forcieren, indem er das System manipuliert, damit es sich unsachgemäss verhält – in der Hoffnung, ein Domänenadministrator loggt sich für die Fehlersuche ein. Meldet sich nun wirklich ein Domänenadministrator an, startet das Programm des Angreifers.
• Der Angreifer findet eine noch aktive Sitzung eines Domänenadministrators vor. Dies ist z.B. dann der Fall, wenn ein Domänenadministrator sich per Remote Desktop Protocol (RDP) auf ein System verbunden hatte, dann aber nur das RDP-Fenster schloss, anstatt sich abzumelden. Seine im Hintergrund noch aktive Sitzung kann mit wenig Aufwand übernommen werden und für weitere Verbindungen auf andere Geräte genutzt werden.

Hat der Angreifer erfolgreich eine Sitzung eines Domänenadministrators übernommen, kann er sich per SSO weiterverbinden – oder auf dem Domänencontroller einen neuen Domänenadministrator anlegen, seine Spuren verwischen und mit diesem neuen Konto weiterarbeiten. Die gesamte Domäne ist nun unter der Kontrolle des Angreifers.

Bei Malware sieht das Risiko in Bezug auf Domänenadministratoren wie folgt aus:

• Malware wird mit erhöhten Rechten gestartet oder erlangt durch eine Privilegien-Eskalation erhöhte Rechte.
• Die Malware kann sich eventuell lateral auf verschiedene Systeme ausbreiten, da:
  • Die gleichen Passwörter für lokale, administrative Konten verwendet werden.
  • Domänenbenutzer in die lokale Administratorengruppe auf ganzen Gerätegruppen eingetragen wurden.
• Die Malware findet eine Sitzung eines Domänenadministrators oder kann über einen anderen Weg wie den Autostart in eine Session eines Domänenadministrators eindringen.
• Per SSO kann sich die Malware mit den neu erlangten Berechtigungen weiterverbreiten, ggf. auf den Domänencontroller, erstellt dort eigene Konten, um unabhängig vom ursprünglichen Konto agieren zu können.

Wichtig ist das Bewusstsein des Risikos, das von (über-)privilegierten Benutzerkonten ausgeht. Ist erst einmal der Domänencontroller mit Malware befallen oder von einem Angreifer kompromittiert, muss meistens die ganze Domäne neu aufgebaut werden.

In den Augen des Autors sind vor allem für den Support verwendete Domänenadministratorenkonten ein zentrales Problem. Funktioniert ein System nicht richtig, kommt vor allem in kleineren bis mittleren Betrieben schnell ein Domänenadministrator für die Problemsuche zum Einsatz.

Um dem Problem entgegen zu treten, empfiehlt Oneconsult folgende Massnahmen:

 Least Privileges

Die Mitarbeiter, einschliesslich der Administratoren einer Umgebung, sollten nur die Rechte zugewiesen bekommen, die sie tatsächlich benötigen.

Hier ein paar Beispiele:

• Es sollten so wenige privilegierte Benutzerkonten als möglich eingerichtet werden.
• Benutzerkonten sollten allgemein wann immer möglich personalisiert sein.
• Grundsätzlich sollten lokale Administratoren auf ein System beschränkt sein und ein einzigartiges Passwort haben. Konten, die auf mehreren Geräten (also gleichem Benutzernamen und Passwort) lokale administrative Rechte besitzen, sollten nicht verwendet werden.
• Lokale Benutzer, die nicht personalisiert werden (wie es oft auf Servern anzutreffen ist), sollten ebenfalls ein einzigartiges, sicheres Passwort haben. Diese Konten können mit dem Tool Local Administrator Password Solution (LAPS) von Microsoft verwaltet werden. 
• Hier der Link zu Microsoft LAPS ^[1] und ein Artikel meines Kollegen Fabian Gonzalez ^[2], der einen Beitrag über LAPS veröffentlichte.
• Benötigt ein Entwicklerteam lokale Administratorenrechte auf ihren Systemen, sollte nur das jeweilige Teammitglied Administratorrechte auf seinem persönlichen System bekommen.
• In grösseren Betrieben gibt es oft Administratoren, die nur einen bestimmten Teilbereich – beispielsweise DNS – verwalten. Daher sollten diese Personen nur in die entsprechende Gruppe eingetragen werden (z.B. „DNSAdmins“), statt als Domänenadministratoren zu agieren.
• Der Support sollte ebenfalls nicht mit Domänenadministrator-Rechten arbeiten, sondern mit möglichst eingeschränkten Rechten. Gerade beim Troubleshooting besteht eine erhöhte Gefahr, dass Malware im Spiel ist. Meldet sich ein Domänenadministrator auf einem befallenen System an, kann die Schadsoftware gegebenenfalls seine Anmeldeinformationen oder Sitzung missbrauchen, um weitere Systeme zu infizieren. Beim Einschränken der Rechte kann man sich etwa an den Netzwerksegmenten orientieren: Ein (administratives) Konto, das für die Pflege der Clients im Bürogebäude benutzt wird, sollte sich nicht auf den Servern im Rechenzentrum anmelden dürfen. Deswegen wird empfohlen, einen dedizierten Benutzer für Troubleshooting zu verwenden, der sich nicht auf Servern und möglichst nicht auf anderen Clients anmelden darf. Auf den Servern kann dies mittels Gruppenrichtlinie (User Rights Assignment) konfiguriert werden und die Clients trennt man zum Beispiel per Client Isolation. Auch für komplexere Umgebungen gibt es Strategien und Lösungen, die die Arbeit im Support nicht zu sehr einschränken, jedoch einen gewissen Schutz bieten.

Weiter sollten privilegierte Konten separat zu normalen Konten bestehen. Ein Benutzer setzt einen privilegierten Zugang nur dann ein, wenn er entsprechende Rechte für eine Aufgabe benötigt.

Es empfiehlt sich, die Nutzung dieser Konten erweitert zu protokollieren und Änderungen an Einstellungen und Systemen zu auditierten.

Weitere Informationen zu Least Privileges für Unternehmen jeglicher Grösse bietet Microsoft online. ^{[3] [4] [5]}

User Access Control verwenden

Die User Access Control (UAC) ist eine eingebaute Sicherheitsfunktion von Windows und ist standardmässig aktiv. Die UAC ermöglicht es, administrative Aufgaben als normaler Anwender zu starten, also ohne Ab- und Anmelden Programme mit erhöhten Privilegien zu starten. Weiter schützt die UAC vor allem Administratoren, die direkt mit ihrem Konto (z.B. per RDP) angemeldet sind. Programme, die unter dem administrativen Konto ausgeführt werden, laufen mit UAC standardmässig zunächst ohne administrative Rechte.

In diversen Windows-basierten Audits, die Oneconsult durchgeführt hat, war UAC oft zumindest für die Domänenadministratoren ausgeschaltet – oder gar für alle Benutzer. Es wird empfohlen, die UAC strikt zu verwenden, da sie Malware und Angreifer daran hindern kann, Prozesse mit erhöhten Privilegien zu starten. Gerade Konten mit administrativen Berechtigungen sollten mit UAC geschützt werden, da Malware sonst nativ mit den entsprechenden Berechtigungen gestartet wird.

Des Weiteren schützt UAC in gewissem Rahmen vor lateraler Ausbreitung, da z.B. einige Pass-the-Hash-Attacken mit entsprechend eingestellter UAC verhindert werden können.

Oneconsult empfiehlt, folgende Einstellungen in “Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\User Account Control: [verschiedene Einstellungen]“ per Gruppenrichtlinie vorzunehmen: 

Weiterführende Massnahmen

Im Folgenden sind weitere Massnahmen aufgelistet, die den Rahmen des Artikels sprengen würden und deswegen nicht weiter erläutert werden:

• Verwenden von dedizierten Jump Hosts oder sogenannten Privileged Access Workstations mit erweitertem Loggen für die Verwaltung von Server. ^[7] [8]
• Vorbereiten eines „Incident Accounts“, der bei Verdacht auf Malware oder Hacking ausschliesslich auf dem verdächtigen System Rechte bekommt, um den Vorfall zu untersuchen. Danach wird der Account gelöscht.
• Saubere Netzwerksegmentierung, damit Systeme oder deren administrativen Ports nur von bestimmten Netzwerken oder Hosts (wie dem obengenannten Jump Host) erreichbar sind. ^[9]
• Installieren von neuen Systemen in für diesen Zweck dedizierten Netzwerkzonen, damit ungepatchte und ungeschützte Systeme nicht potenziellen Gefahren ausgesetzt werden.
• Vor allem Administratoren sollten lange (14+ Zeichen) und komplexe Passwörter verwenden, um die privilegierten Accounts zu schützen.
• Es sollte einen Prozess geben, der die Rechtevergabe überprüft. Bei Neueintritt, Abteilungs- und Stellungswechsel sowie bei Austritten müssen die Konten entsprechend angepasst oder gelöscht werden.

Es ist für jeden Betrieb empfehlenswert, einmal über die Verwendung der privilegierten Konten und deren Passwörter nachzudenken. Die Benutzung eines Domänenadministratorenkontos zur falschen Zeit kann unter Umständen die ganze Firma schädigen und die Wiederherstellung des Normalbetriebs um Tage oder Wochen in die Länge ziehen. Mit den obengenannten Massnahmen werden zumindest die kritischsten Punkte behandelt und die IT Sicherheit im Unternehmen erhöht. Mit den weiterführenden Massnahmen im vorigen Kapitel sind zudem weitere Anregungen.

https://www.microsoft.com/en-us/download/details.aspx?id=46899
[2]: https://www.oneconsult.com/de/sichere-passwoerter-fuer-lokale-administratoren/
[3]: https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/implementing-least-privilege-administrative-models
[4]: https://docs.microsoft.com/en-us/microsoft-identity-manager/pam/privileged-identity-management-for-active-directory-domain-services
[5]: https://docs.microsoft.com/en-us/powershell/jea/overview
[6]: https://technet.microsoft.com/en-us/library/dd851376(v=ws.11).aspx
[7]: https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/implementing-secure-administrative-hosts
[8]: https://blogs.technet.microsoft.com/datacentersecurity/2017/10/13/privileged-access-workstationpaw/
[9]: https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzKataloge/Inhalt/_content/m/m05/m05062.html