Vor kurzem hatten die Sicherheitsexperten der Codecentric den Auftrag, bei einem Unternehmen mit mehreren hundert Mitarbeitern die Sicherheit der IT-Infrastruktur zu testen. Die Auftraggeber wähnten sich in Sicherheit: Die Systeme liefen auf der damals neusten Version von Windows 11 bzw. Windows Server 2022 und ein kommerzielles Antivirusprodukt war im Einsatz.
Und dennoch: Nach zwei Tagen waren die Codecentric Sicherheitsexperten Domänenadministratoren mit Vollzugriff auf alle Systeme, ohne dass der Kunde dies bemerkt hatte. Ein Angreifer hätte aus dieser Position Geschäftsdaten exfiltrieren und alle Systeme verschlüsseln oder löschen können. Wie konnte das passieren?
Zusammenfassung des Angriffs
Der Angriff wurde im Rahmen eines sogenannten "Assumed-Breach"-Szenarios durchgeführt, d.h. uns wurde ein normales Benutzerkonto ohne besondere Berechtigung zur Verfügung gestellt, wie es ein Angreifer z.B. durch einen Phishing-Angriff erlangen könnte.
Zuerst führen wir dann eine Enumeration der Domäne durch, d.h. wir schauen auf welche Informationen und Daten unserer Benutzer zugreifen kann. Dabei wurde ein geteilter Filestorage gefunden, durch den, aufgrund falscher Konfiguration, auf persönliche Dateien anderer Benutzer zugegriffen werden konnte. In diesen Dateien konnten viele Passwörter gefunden werden, unter anderem auch ein altes Backup des Passwortmanagers des IT-Admins. Aus diesen Passwörtern wurde eine Liste erstellt, welche schließlich automatisiert gegen die verfügbaren Systeme ausprobiert wurden.
Dadurch konnte auf eines der Systeme zugegriffen werden, auf welchen ein Domänenadministrator angemeldet war. Das Ziel war nun den Speicher des Prozesses auszulesen, in dem die Zugangsdaten des Domänenadministrators temporär gespeichert wurden. Die Ausführung von Schadcode wurde allerdings durch Windows Defender und das Antivirusprodukt verhindert. Aber mittels eines selbst entwickelten Bypass des AMSI (Antimalware Scan Interface) konnte auch dieser Verteidigungsmechanismus umgangen werden. Daraufhin konnten die Zugangsdaten des Domänenadministrators ausgelesen und schließlich zum Login auf dem Domänen-Controller verwendet werden.
Lessons-learned und Maßnahmen
Der oben geschilderte Angriff ist eine gute Demonstration dafür, dass eine Verteidigung von IT-Infrastruktur auf einer Ebene nicht ausreicht. So ist z.B. ein Virenschutz maximal ein temporäres Hindernis für erfahrene Angreifer. Es ist vielmehr ein vielschichtiger Ansatz notwendig, bei dem verschiedene Produkte und Verfahren auf mehreren Ebenen zum Einsatz kommen. Dieses Konzept ist auch als Defense in Depth bekannt.
Hier sind einige Maßnahmen, die den oben geschilderten Angriff erschwert hätten:
- Härtung der Active-Directory Domäne, sodass z.B. ein normaler Benutzer nur die nötigsten Informationen abfragen darf
- Einführen eines geeigneten Passwortmanagements, beispielsweise über LAPS, sodass Passwörter lokaler Administrator nicht auf mehreren Systemen verwendet werden
- Benutzung von Credential Guard, sodass Zugangsdaten nicht so einfach aus dem LSASS Prozess ausgelesen werden können
Die Maßnahme, die allerdings in diesem Fall den größten Einfluss auf die Erfolgschancen eines Angreifers gehabt hätte, wäre die Benutzung von Werkzeugen zum Logging, Monitoring und Alerting, auch als "Security Information and Event Management" (SIEM) bekannt. Die Idee ist es, Logdaten der verschiedensten Systeme zentral zu sammeln, sie auf potentielle Angriffe zu analysieren und bei Erkennung Alarm auszulösen.
Diese Maßnahme schafft eine Sichtbarkeit in die Vorgänge auf Clientsystemen und im Netzwerk und erlaubt es auf einen Angriff zu reagieren, bevor es zu spät ist. Sie macht das Leben der Angreifer deutlich schwieriger, weil diese auf einmal vorsichtig sein müssen, um keine Warnungen oder Alarme auszulösen. Sie können nun nicht mehr beliebig Dinge ausprobieren, bis eine Sicherheitsmaßnahme umgangen ist. Der oben geschilderte Angriffe hätte so schnell bemerkt werden können.
Technische Details des Angriffs
Schritt 1: Enumerieren der Domäne
Mit dem zur Verfügung gestellten, normal privilegierten Benutzerkonto wurden verschiedene Werkzeuge benutzt, um mehr Information über die Domäne zu sammeln:
- SharpHound + Bloodhound
- adPEAS
- Verschieden PowerShell Befehle
Mittels dieser Werkzeuge konnte eine detaillierte Übersicht über Benutzer, Computer, Gruppen und potentielle Privilegien erlangt werden.
Potentielle Gegenmaßnahmen:
- AD-Benutzern Lesezugriff auf bestimmte Objekte verweigern
- Logging & Alerting (SharpHound ist leicht zu erkennen)
- Zugriff auf PowerShell in Citrix erschweren (hierzu sei zu erwähnen, dass ein vollständiges Unterbinden von Kommandozeilen-Aufrufen in der Regel nicht umsetzbar ist)
Schritt 2: Enumerieren der geteilten Verzeichnisse
Der zur Verfügung gestellte Benutzer hatte Zugriff auf sehr viele geteilte Verzeichnisse. In diesen Verzeichnissen wurde explizit nach Dateien gesucht, die potentiell Zugangsdaten beinhalten. Hierbei konnte unter anderem ein Klartext-Backup des Passwortmanagers des IT-Admins sowie Zugangsdaten eines Benutzers mit RDP-Rechten gefunden werden.
Potentielle Gegenmaßnahmen:
- Zugriff auf geteilte Verzeichnisse einschränken
- Keine privaten Nutzerdaten wie Desktop oder Dokument teilen. Die jeweiligen Nutzerverzeichnisse sollten nur für die jeweiligen Nutzer selbst zugreifbar sein.
- Nutzer sensibilisieren, sodass keine Passwortlisten oder Passwortmanager-Backups im Klartext abgelegt werden → Passwortmanagement
- Logging & Alerting (Automatisierte Durchsuchung ist leicht zu erkennen)
Schritt 3: Lokaler Administrator auf dem Admin-Jumphost
Dank der Enumerierung der Domäne war bekannt, dass ein Computer existiert, auf dem Domänen-Administratoren gültige und aktive Sitzungen haben. Mittels der gefundenen Zugangsdaten war eine Authentifizierung über das Remote-Desktop-Protokoll auf diesem Computer möglich. Ziel war nun, die dort verfügbaren Berechtigungen zu erweitern, um mit lokalen Administrator-Privilegien die Zugangsdaten der angemeldeten Domänen-Administratoren auslesen.
Hierzu wurde eine Liste mit allen bekannten, lokalen Administrator-Benutzernamen und eine weitere Liste mit allen bereits identifizierten Passwörtern erstellt. Über das Tool crackmapexec wurden anschließend alle Kombinationen dieser Benutzernamen und Passwörter automatisiert gegen alle Computer in der Domäne ausprobiert. Dies wurde bewusst ausschließlich gegen lokale Nutzer und nicht gegen Domänenbenutzer durchgeführt, um eine Sperrung von Domänenbenutzern und somit eine Einschränkung der Verfügbarkeit zu vermeiden. Über dieses Verfahren wurden unter anderem gültige Anmeldedaten für einen Jumphost-Server der Administratoren identifiziert. Somit war hier eine Anmeldung mit einem lokalen Systemadministrator möglich.
Gegenmaßnahmen:
- Einführen eines geeigneten Passwortmanagements, beispielsweise über LAPS
- Implementieren von geeigneten Gruppenrichtlinien, um das Anmelden von Domänen-Administratoren auf Drittsystemen zu unterbinden (Schützen von Domänenadministratorgruppen)
- Remotedesktopberechtigungen für normale Benutzer auf ein benötigtes Minimum beschränken
Schritt 4: LSASS Prozess auslesen
Die gehashten Zugangsdaten von aktiven Benutzern werden in Windows im sog. LSASS-Prozess gespeichert. Ein lokaler Administrator hat die Berechtigung, diese Daten auszulesen. Allerdings wurde dies in diesem Fall durch den aktivierten Virenschutz unterbunden. Mittels eines sog. AMSI-Bypasses konnte der Virenschutz allerdings umgangen werden und der Prozessspeicher mithilfe des Out-Minidump Skripts trotzdem ausgelesen werden. Dieser Dump wurde anschließend auf die eingesetzten Angreifer-Systeme transferiert. Um die darin enthaltenen Hashes auszulesen, wurde das Tool Mimikatz auf den Angreifer-Systemen genutzt.
Gegenmaßnahmen:
- Benutzung von Credential Guard. Allerdings gibt es da auch Bypasses
- Aktive Sitzungen und Anmeldungen mit Domänenadministratoren außerhalb von Domain-Controllern vermeiden. Generell sollten Domänenadministrator-Konten lediglich zum Administrieren der Domäne selbst genutzt werden.
- Umsetzen eines geeigneten Privileged Access Models für Administratoren
Schritt 5: Kerberos Ticket generieren
Mithilfe des ausgelesen Hashs konnte eine sogenannte Pass-The-Key Attacke ausgeführt werden. Dazu wurde das getTGT.py Skript von Impacket eingesetzt, um mit dem Hash ein Kerberos Ticket zu bekommen.
Mit diesem Ticket wurden die Berechtigungen eines Domänenadministrators und somit die maximal möglichen Privilegien im Netzwerk erlangt.
Gegenmaßnahmen:
- RC4 Key Typ in Kerberos deaktivieren
- Logging & Alerting
Schritt 6: Post Exploitation
Mit diesen Berechtigungen konnten waren nun beliebige Aktionen im Domänenumfeld des Netzwerks durchführbar. Mittels impacket-secretsdump führten wir eine sog. DCSync Attacke durch, die die gehashten Zugangsdaten aller Domänenbenutzer sowie ein Klartext-Passwort des Domänenadministrators lieferte.
Ebenfalls wurde ein eigener Domänen-Administrator mit allen Privilegien angelegt. Von dieser Position wäre ein Angreifer mit bösartigen Absichten beispielsweise in der Lage gewesen, eine Verschlüsselung oder Löschung sämtlicher Unternehmensdaten auszulösen.
Gegenmaßnahmen:
- Logging & Alerting
Über uns
Wir bei Codecentric bieten umfangreiche Beratung und Tests im Bereich IT-Sicherheit an. Spezifisch im Bereich IT-Infrastruktur können wir Ihnen zum Beispiel mit Assessments zur Bestandsaufnahme, Pentests zur Überprüfung oder Red/Purple-Team Übungen zum Training eines Blue-Teams zur Seite stehen. Mehr Informationen finden sie hier.
Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Weitere Artikel in diesem Themenbereich
Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.
Blog-Autor*in
Niklas
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.