von Marco Wohler

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.

Ausgangslage und Risiko

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.

    Einschränkung der Rechte

    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: 

    Einstellung Wert
    User Account Control: Admin Approval Mode for the Built-in Administrator account Enabled
    User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop Disabled
    User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode Prompt for consent on the secure desktop
    User Account Control: Behavior of the elevation prompt for standard users Automatically deny elevation requests
    User Account Control: Detect application installations and prompt for elevation Use Case [6]
    User Account Control: Only elevate UIAccess applications that are installed in secure locations Enabled
    User Account Control: Run all administrators in Admin Approval Mode Enabled
    User Account Control: Switch to the secure desktop when prompting for elevation Enabled
    User Account Control: Virtualize file and registry write failures to per-user locations Enabled
    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.

    Fazit

    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 vorhanden.

    Über den Autor

    Bereits während seiner Lehre als Logistiker und seiner beruflichen Tätigkeit bei verschiedenen Logistikfirmen interessierte sich Marco Wohler für die Informatik. Dies führte dazu, dass er sich entschied, eine Zweitausbildung als Informatiker EFZ zu absolvieren. Während der praktischen Arbeit in der IT konnte Marco Wohler umfassende Erfahrungen mit Linux- und Windows-Systemen sowie im IT-Support, Release- und Projektmanagement sammeln. Seit November 2014 ist er bei der Oneconsult als System Engineer und Penetration Tester angestellt; seit Dezember 2016 nimmt er ausserdem die Rolle als CISO wahr. Marco Wohler ist GIAC Certified Enterprise Defender (GCED) und zertifizierter OSSTMM Professional Security Tester (OPST).

    Über Oneconsult

    Die Oneconsult-Unternehmensgruppe ist seit 2003 Ihr renommierter Schweizer Cyber Security Services Partner mit Büros in der Schweiz und Deutschland und 1500+ weltweit durchgeführten Security-Projekten.

    Erhalten Sie kompetente Beratung vom inhabergeführten und herstellerunabhängigen Cyber Security-Spezialisten mit 35+ hochqualifizierten Cyber Security Experten, darunter zertifizierte Penetration Tester (OPST, OPSA, OSCP, OSCE, GXPN), IT-Forensiker (GCFA, GCFE, GREM), ISO Security Auditoren (ISO 27001 Lead Auditor, ISO 27005 Risk Manager) und dedizierte IT Security Researcher, um auch Ihre anspruchsvollsten Herausforderungen im Informationssicherheitsbereich zu bewältigen. Gemeinsam gehen wir Ihre externen und internen Bedrohungen wie Malware-Infektionen, Hacker-Attacken und APT sowie digitalen Betrug und Datenverlust mit Kerndienstleistungen wie Penetration Tests / Ethical Hacking, APT Tests unter Realbedingungen und ISO 27001 Security Audits an. Bei Notfällen können Sie rund um die Uhr (24 h x 365 Tage) auf die Unterstützung des Incident Response & IT Forensics Expertenteams von Oneconsult zählen.

    www.oneconsult.com