Szenario kompromittierter Admin-Account: Lateral Movement erkennen und stoppen

Donnerstag, 06:42 Uhr: Eine Anmeldung, die niemand bemerkt

Die Weber Logistik GmbH betreibt drei Lagerhallen in Norddeutschland, beschäftigt 180 Mitarbeiter und nutzt eine klassische Windows-Infrastruktur: Active Directory, Exchange On-Premises, ein ERP-System für die Lagerverwaltung, einen Terminalserver für die Disponenten und eine VPN-Anbindung für die IT-Administration an den Außenstandorten.

Die IT-Abteilung besteht aus sechs Personen. IT-Leiter Markus Vogt hat drei Domänen-Admin-Accounts in der Firma – eine Situation, die ein durchdachtes Privileged Access Management verhindern soll: seinen eigenen, einen für den Stellvertreter und einen generischen „admin-srv" Account, der für automatisierte Aufgaben wie Software-Deployment und Monitoring genutzt wird. Dieser generische Account hat das Passwort „Weber2024!", das vor 14 Monaten gesetzt und seitdem nicht geändert wurde. Der Account hat keine Multi-Faktor-Authentifizierung, weil er für automatisierte Prozesse genutzt wird und MFA den Workflow stören würde.

Am Donnerstagmorgen um 06:42 Uhr meldet sich dieser Account über die VPN-Verbindung am Domänencontroller an. Markus Vogt sitzt zu dieser Zeit noch beim Frühstück. Die automatisierten Tasks, die den Account normalerweise nutzen, laufen zwischen 02:00 und 04:00 Uhr nachts. Die Anmeldung um 06:42 Uhr registriert niemand, weil das Sicherheitsmonitoring zwar Logs schreibt, aber keine Echtzeit-Alerts für Admin-Anmeldungen konfiguriert sind.

Der Angreifer ist drin.

Wie der Account kompromittiert wurde

Drei Wochen vor dem Vorfall hat ein Mitarbeiter der Weber Logistik eine Phishing-Mail geöffnet und seine Zugangsdaten auf einer gefälschten Microsoft-365-Login-Seite eingegeben. Sein regulärer Benutzeraccount wurde kompromittiert, aber das allein hätte noch keinen großen Schaden angerichtet. Der Angreifer nutzte diesen Einstiegspunkt, um sich im Netzwerk umzusehen.

Über den kompromittierten Benutzer-Account loggte sich der Angreifer auf dem Terminalserver ein, auf dem alle Disponenten arbeiten. Dort fand er, was Angreifer in Active-Directory-Umgebungen fast immer finden: gespeicherte Credentials. In diesem Fall hatte der generische Admin-Account „admin-srv" vor Monaten eine Remote-Desktop-Sitzung auf dem Terminalserver geöffnet und sich angemeldet. Die Zugangsdaten lagen im Credential Cache des Servers, ein bekanntes Problem, das sich mit Tools wie Mimikatz trivial ausnutzen lässt.

Der Angreifer hatte jetzt einen Domänen-Admin-Account. Und damit de facto die Kontrolle über die gesamte IT-Infrastruktur.

Donnerstag bis Mittwoch: Sieben Tage unbemerkt

Der Angreifer verhält sich in der folgenden Woche bemerkenswert diszipliniert. Er meldet sich nur zu Zeiten an, die für den Admin-Account nicht vollkommen untypisch sind (früher Morgen, später Abend). Er nutzt keine auffälligen Hacking-Tools, sondern die Werkzeuge, die ohnehin auf jedem Windows-Server vorhanden sind: PowerShell, Remote Desktop, WMI (Windows Management Instrumentation) und PsExec. Diese Technik heißt „Living off the Land" und ist extrem schwer zu erkennen, weil die verwendeten Programme legitime Systemwerkzeuge sind.

Was der Angreifer tut

Tag 1 bis 2: Aufklärung. Der Angreifer kartiert das Netzwerk. Er fragt das Active Directory nach allen Computerobjekten, Benutzerkonten, Gruppenmitgliedschaften und Netzwerkfreigaben ab. Er identifiziert die Server, das ERP-System, den Exchange-Server und den Backup-Server. Er findet heraus, welche Benutzer in welchen Gruppen sind und wer Zugriff auf was hat.

Tag 3 bis 4: Persistence schaffen. Der Angreifer legt einen zusätzlichen Domänen-Admin-Account an („svc-monitoring"), der wie ein legitimer Service-Account aussieht. Er richtet eine geplante Aufgabe auf dem Domänencontroller ein, die bei jedem Neustart eine Reverse Shell öffnet. Selbst wenn der kompromittierte „admin-srv" Account gesperrt wird, hat der Angreifer noch einen Rückweg ins Netzwerk.

Tag 5 bis 6: Daten identifizieren. Der Angreifer durchsucht die Netzwerkfreigaben nach wertvollen Daten: Verträge, Kundenlisten, Finanzberichte, Konstruktionszeichnungen. Bei einem Logistikunternehmen sind Kundenverträge und Frachtdaten besonders interessant, weil sie Rückschlüsse auf Geschäftsbeziehungen und Warenströme zulassen.

Tag 7: Datenexfiltration. Der Angreifer beginnt, ausgewählte Daten über verschlüsselte HTTPS-Verbindungen an einen externen Server zu übertragen. Er nutzt dafür einen Cloud-Storage-Dienst, der in der Firewall nicht blockiert ist, weil er auch von Mitarbeitern genutzt wird.

Mittwoch, 15:30 Uhr: Die Anomalie wird sichtbar

Der Durchbruch kommt durch einen Zufall, der eigentlich keiner sein sollte. Julia Meier, die stellvertretende IT-Leiterin, prüft routinemäßig die Active-Directory-Gruppenmitgliedschaften, eine Aufgabe, die sie alle zwei Wochen manuell durchführt, weil es kein automatisiertes Tool dafür gibt. Sie findet einen Account namens „svc-monitoring" in der Gruppe „Domain Admins".

Julia stutzt. Sie kennt alle Service-Accounts der Firma, und „svc-monitoring" gehört nicht dazu. Sie fragt Markus Vogt, der den Account auch nicht kennt. Sie fragt die anderen IT-Kollegen. Niemand hat diesen Account angelegt.

Das ist der Moment, in dem aus einer Routine-Prüfung ein Sicherheitsvorfall wird.

Die Alarmzeichen, die vorher da waren

Rückblickend gab es Warnsignale, die bei aktivem Monitoring aufgefallen wären:

• Ungewöhnliche Anmeldezeiten: Der „admin-srv" Account meldete sich seit einer Woche zu Zeiten an, die von seinem normalen Muster abwichen. Ein Anomalie-basiertes Monitoring hätte das erkannt.
• Ungewöhnliche Quell-IPs: Die Anmeldungen kamen über die VPN-Verbindung, aber von einer IP-Adresse, die keinem bekannten IT-Mitarbeiter zugeordnet war.
• LDAP-Enumeration: Massenhafte LDAP-Abfragen gegen das Active Directory in kurzer Zeit sind ein typisches Zeichen für Aufklärungsaktivitäten.
• Neuer Account in privilegierter Gruppe: Die Erstellung eines neuen Domain-Admin-Accounts hätte einen sofortigen Alert auslösen müssen.
• Ungewöhnliche ausgehende Datenströme: Die Datenexfiltration über den Cloud-Storage-Dienst war volumenmäßig ungewöhnlich.

Keines dieser Zeichen wurde in Echtzeit erkannt, weil die Weber Logistik kein SIEM-System (Security Information and Event Management) betreibt und keine automatisierten Alerts für privilegierte Account-Aktivitäten konfiguriert hat.

Mittwoch, 15:45 Uhr: Die Eindämmung beginnt

Julia und Markus handeln jetzt nach dem Incident-Response-Plan. Die Situation ist heikel, denn sie müssen davon ausgehen, dass der Angreifer möglicherweise gerade aktiv im Netzwerk ist und ihre Maßnahmen beobachten kann, insbesondere wenn er den Exchange-Server kompromittiert hat und E-Mails mitlesen kann.

Kommunikation über sicheren Kanal

Erste Regel: Keine Kommunikation über die firmeninterne Infrastruktur. Julia und Markus wechseln auf ihre privaten Mobiltelefone und eine verschlüsselte Messenger-App. Alle weiteren Absprachen laufen über diesen Kanal.

Sofortmaßnahme 1: Kompromittierte Accounts deaktivieren

Markus deaktiviert beide verdächtigen Accounts: „admin-srv" und „svc-monitoring". Aber das reicht nicht. In einer Active-Directory-Umgebung bleiben Kerberos-Tickets gültig, auch wenn der Account deaktiviert wird. Ein Kerberos-Ticket hat standardmäßig eine Lebensdauer von 10 Stunden. Der Angreifer könnte also mit einem bereits ausgestellten Ticket noch stundenlang auf Ressourcen zugreifen.

Markus setzt deshalb das Passwort des krbtgt-Accounts zurück. Das ist der Account, der alle Kerberos-Tickets im Active Directory signiert. Durch die Zurücksetzung werden alle bestehenden Tickets ungültig, und jeder Benutzer und Dienst im Netzwerk muss sich neu authentifizieren. Das verursacht kurzzeitige Störungen (einige Dienste verlieren ihre Authentifizierung und müssen neu gestartet werden), aber es ist die einzige Möglichkeit, sicher zu sein, dass der Angreifer keine gültigen Tickets mehr hat.

Wichtig: Der krbtgt-Account muss zweimal zurückgesetzt werden, mit einem Abstand von mindestens 12 Stunden. Der Grund ist technisch: Active Directory speichert das aktuelle und das vorherige Passwort des krbtgt-Accounts, und Tickets, die mit dem vorherigen Passwort signiert wurden, sind weiterhin gültig. Erst nach dem zweiten Reset sind alle alten Tickets definitiv ungültig.

Sofortmaßnahme 2: Alle Admin-Passwörter zurücksetzen

Markus setzt die Passwörter aller Domänen-Admin-Accounts zurück, einschließlich seines eigenen und des Stellvertreter-Accounts. Er verwendet dabei Passwörter mit mindestens 20 Zeichen, die er über einen Passwort-Manager generiert.

Zusätzlich setzt er die Passwörter aller Service-Accounts zurück, die auf den kompromittierten Systemen gelaufen sind. Jeder Account, dessen Credentials möglicherweise im Credential Cache eines kompromittierten Systems lagen, muss als kompromittiert betrachtet werden.

Sofortmaßnahme 3: VPN-Zugang sperren

Die VPN-Verbindung wird vollständig deaktiviert. Jeder Remote-Zugang zum Firmennetz ist bis auf Weiteres gesperrt. Die IT-Mitarbeiter an den Außenstandorten werden telefonisch informiert und arbeiten vorübergehend offline.

Sofortmaßnahme 4: Geplante Aufgaben prüfen

Markus und Julia durchsuchen alle Server nach verdächtigen geplanten Aufgaben (Scheduled Tasks) und Diensten. Sie finden die Reverse Shell auf dem Domänencontroller und entfernen sie. Außerdem prüfen sie die Autostart-Einträge, die GPO-Skripte (Group Policy Objects) und die WMI-Event-Subscriptions, die der Angreifer ebenfalls für Persistenz nutzen könnte.

Donnerstag: Externe Forensik und Schadensanalyse

Am Donnerstagmorgen trifft das externe Forensik-Team ein. Ihre Aufgabe ist es, den vollständigen Umfang der Kompromittierung zu ermitteln und sicherzustellen, dass keine weiteren Hintertüren im Netzwerk verbleiben.

Forensische Methodik

Die Forensiker arbeiten nach einer strukturierten Methode:

1. Timeline erstellen. Anhand der Sicherheitslogs (Domänencontroller, Fileserver, VPN-Gateway, Firewall) wird eine vollständige Timeline der Angreifer-Aktivitäten erstellt. Wann hat er sich zuerst angemeldet? Auf welchen Systemen war er aktiv? Welche Daten hat er zugegriffen? Wann hat die Exfiltration begonnen?

2. Compromise Assessment. Jedes System, auf dem der Angreifer aktiv war oder das mit einem kompromittierten System kommuniziert hat, wird auf Indicators of Compromise (IoCs) geprüft. Das umfasst: verdächtige Dateien, unbekannte Dienste, manipulierte Registry-Einträge, ungewöhnliche Netzwerkverbindungen und modifizierte Systemdateien.

3. Datenexfiltration quantifizieren. Anhand der Firewall-Logs und der Proxy-Logs wird ermittelt, welche Datenmengen an welche externen Adressen übertragen wurden. Bei der Weber Logistik zeigt die Analyse, dass etwa 15 Gigabyte an Daten über den Cloud-Storage-Dienst abgeflossen sind.

4. Persistence-Mechanismen identifizieren. Die Forensiker suchen systematisch nach allen Wegen, über die der Angreifer zurückkommen könnte: zusätzliche Accounts, geplante Aufgaben, Backdoors in Skripten, manipulierte GPOs, Golden Tickets (Kerberos-Tickets, die mit dem gestohlenen krbtgt-Hash erstellt wurden).

Ergebnisse der Forensik

Die forensische Analyse ergibt:

• Der Angreifer war 8 Tage im Netzwerk aktiv
• Er hatte Zugriff auf 14 von 22 Servern
• Er hat Daten von drei Netzwerkfreigaben exfiltriert (Kundenverträge, Frachtdaten, Personaldaten)
• Er hat einen Golden Ticket erstellt, der ihm dauerhaften Zugang ermöglicht hätte (jetzt durch den doppelten krbtgt-Reset invalidiert)
• Er hat auf dem Exchange-Server E-Mails des Geschäftsführers und des IT-Leiters mitgelesen
• Auf zwei Servern wurden zusätzliche Backdoors gefunden (Web-Shell auf dem internen Wiki-Server, manipuliertes PowerShell-Profil auf dem Deployment-Server)

Freitag bis Wochenende: Recovery und Härtung

Die Recovery-Phase beginnt, nachdem die Forensiker bestätigt haben, dass alle Persistence-Mechanismen identifiziert und entfernt wurden.

Systeme bereinigen oder neu aufsetzen

Für jeden kompromittierten Server wird einzeln entschieden: Bereinigung oder Neuinstallation? Die Faustregel lautet: Wenn der Angreifer Admin-Rechte auf dem System hatte, ist eine Neuinstallation sicherer als eine Bereinigung, weil nicht sicher ausgeschlossen werden kann, dass tief im System versteckte Backdoors übersehen werden.

Bei der Weber Logistik werden vier Server neu aufgesetzt: der Domänencontroller (das Herz der Infrastruktur, bei einer Kompromittierung immer neu aufsetzen), der Terminalserver (Einstiegspunkt des Angriffs), der Fileserver (Daten werden aus dem Backup wiederhergestellt) und der Deployment-Server (manipuliertes PowerShell-Profil).

Die übrigen kompromittierten Server werden bereinigt, mit frischen Betriebssystem-Patches versehen und intensiv überwacht.

Credential-Hygiene

Der umfassende Credential Reset wird fortgesetzt:

• Alle Benutzerpasswörter werden erzwungen zurückgesetzt (beim nächsten Login)
• Alle Service-Account-Passwörter werden manuell auf starke, einzigartige Passwörter geändert
• Der generische „admin-srv" Account wird nicht wiederhergestellt, stattdessen werden individuelle Service-Accounts mit minimalen Berechtigungen angelegt
• Der krbtgt-Account wird ein zweites Mal zurückgesetzt (12 Stunden nach dem ersten Reset)
• Managed Service Accounts (gMSA) werden für automatisierte Aufgaben eingerichtet, bei denen das Passwort automatisch rotiert wird

MFA überall

Die Multi-Faktor-Authentifizierung wird für alle Admin-Accounts und alle VPN-Zugänge aktiviert. Der Einwand „MFA stört den Workflow bei Service-Accounts" wird nicht mehr akzeptiert. Für automatisierte Aufgaben gibt es technische Lösungen (Managed Service Accounts, zertifikatsbasierte Authentifizierung), die MFA für interaktive Anmeldungen nicht ausschließen.

Netzwerksegmentierung verschärfen

Die Weber Logistik implementiert eine stärkere Segmentierung:

• Admin-Workstations werden in ein eigenes VLAN gestellt, von dem aus ausschließlich die Administration der Server erfolgt (Privileged Access Workstation-Konzept)
• Der Domänencontroller ist nur noch von den Admin-Workstations erreichbar, nicht mehr von beliebigen Clients
• Der Terminalserver erhält kein Recht mehr, auf den Domänencontroller zuzugreifen
• Lateral Movement zwischen Server-Segmenten wird auf definierte Ports und Protokolle beschränkt

Monitoring aufbauen

Der vielleicht wichtigste Punkt: Die Weber Logistik implementiert ein grundlegendes SIEM-System, das folgende Events in Echtzeit überwacht und bei Anomalien alarmiert:

• Anmeldungen von Admin-Accounts (jede Anmeldung, nicht nur fehlgeschlagene)
• Erstellung neuer Accounts in privilegierten Gruppen
• Änderungen an Group Policy Objects
• Massenhafte LDAP-Abfragen
• Ungewöhnliche ausgehende Datenströme
• Anmeldungen außerhalb der definierten Arbeitszeiten
• Anmeldungen von unbekannten Quell-IPs

Woche 2 bis 4: Behördliche Meldungen und Aufarbeitung

Meldepflichten

Die Weber Logistik prüft ihre Meldepflichten:

DSGVO: Da Personaldaten und Kundenkontaktdaten exfiltriert wurden, liegt eine meldepflichtige Datenpanne vor. Die Meldung an die Datenschutzaufsichtsbehörde erfolgt innerhalb von 72 Stunden. Die betroffenen Personen werden benachrichtigt.

NIS2: Als Logistikunternehmen mit über 50 Mitarbeitern und signifikantem Umsatz muss die Weber Logistik prüfen, ob sie unter die NIS2-Regulierung fällt. Falls ja, ist eine Erstmeldung ans BSI innerhalb von 24 Stunden erforderlich.

Strafanzeige: Wird erstattet, mit allen forensischen Ergebnissen.

Lessons-Learned-Workshop

Zwei Wochen nach dem Vorfall führt Markus einen strukturierten Workshop durch. Die Ergebnisse sind schmerzhaft, aber lehrreich:

Ursache 1: Generischer Admin-Account ohne MFA. Der Account „admin-srv" hatte ein schwaches, seit 14 Monaten unverändertes Passwort und keine MFA. Das ist die häufigste Ursache für kompromittierte Admin-Accounts in KMU-Umgebungen. Generische Accounts erschweren die Nachvollziehbarkeit und werden selten mit derselben Sorgfalt behandelt wie persönliche Accounts.

Ursache 2: Credential Caching auf dem Terminalserver. Die gespeicherten Credentials im Credential Cache des Terminalservers ermöglichten die Eskalation vom normalen Benutzer zum Domänen-Admin. Dieser Vektor ist seit Jahren bekannt und lässt sich durch Credential Guard, eingeschränkte Admin-Anmeldungen auf Servern und regelmäßiges Bereinigen des Credential Cache entschärfen.

Ursache 3: Fehlendes Monitoring. Kein einziges der Warnsignale wurde in Echtzeit erkannt. Ohne Julias manuelle Routineprüfung der Gruppenmitgliedschaften wäre der Angreifer möglicherweise noch Wochen oder Monate unentdeckt geblieben.

Ursache 4: Zu flache Netzwerksegmentierung. Der Terminalserver, die Fileserver und der Domänencontroller waren alle im selben Netzwerksegment. Der Angreifer konnte sich ohne Hürden lateral bewegen.

Der Maßnahmenplan

Was dieser Fall lehrt

Kompromittierte Admin-Accounts sind der Jackpot für jeden Angreifer, weil sie die Schlüssel zum gesamten Königreich darstellen. Die laterale Bewegung mit Admin-Rechten ist in den meisten Active-Directory-Umgebungen erschreckend einfach, weil die Netzwerke zu flach sind, zu viele Accounts zu viele Rechte haben und das Monitoring zu schwach ist.

Generische Admin-Accounts sind ein Relikt. Sie gehören abgeschafft und durch individuelle, MFA-geschützte Accounts mit minimalen Berechtigungen ersetzt. Automatisierte Aufgaben laufen über Managed Service Accounts, nicht über Accounts mit Domain-Admin-Rechten.

Der Angreifer nutzt deine eigenen Werkzeuge. Living-off-the-Land-Techniken sind deshalb so effektiv, weil PowerShell, WMI und Remote Desktop in keiner Blocklist stehen. Die Erkennung erfordert Verhaltensanalyse, nicht signaturbasierte Erkennung: Nicht ob PowerShell genutzt wird, ist verdächtig, sondern wann, von wem und für was.

Ein doppelter krbtgt-Reset ist Pflicht. Bei jeder Kompromittierung eines Domain-Admin-Accounts muss der krbtgt-Account zweimal zurückgesetzt werden, um Golden Tickets zu invalidieren. Das ist keine optionale Maßnahme, sondern eine notwendige.

Monitoring privilegierter Accounts ist nicht optional. Eine durchdachte Logging- und Monitoring-Strategie ist die Grundlage: Jede Anmeldung eines Admin-Accounts, jede Änderung an privilegierten Gruppen und jede Erstellung neuer Accounts in sensiblen Gruppen muss in Echtzeit überwacht und bewertet werden. In ISMS Lite lassen sich Berechtigungskonzepte dokumentieren, Zugriffskontrollen nachverfolgen und Sicherheitsvorfälle strukturiert aufarbeiten. Ohne dieses Monitoring bleiben Angreifer Wochen oder Monate unentdeckt.

Die Kompromittierung beginnt selten beim Admin. In diesem Fall war der Einstiegspunkt eine einfache Phishing-Mail. Der Weg zum Admin-Account führte über Credential Caching auf einem Terminalserver. Die Verteidigung muss die gesamte Angriffskette berücksichtigen, nicht nur den letzten Schritt.

Weiterführende Artikel

• Active Directory absichern: Die wichtigsten Maßnahmen für den Mittelstand
• Berechtigungskonzept erstellen: Vom Wildwuchs zur strukturierten Zugriffskontrolle
• MFA einführen: Warum ein Faktor nicht reicht
• Logging- und Monitoring-Strategie: Was du überwachen musst und warum
• Tabletop-Übung planen: Sicherheitsvorfälle am Schreibtisch durchspielen