Die Firewall als einzige Zeugin: Wie wir einen Ransomware-Vorfall forensisch aufgeklärt haben

Samstagvormittag rief uns ein Kunde an. Alle virtuellen Systeme waren aus.

Er verband sich auf den Hypervisor, also den Server, auf dem alle virtuellen Maschinen laufen. Noch bevor dort der Anmeldebildschirm erschien, stand eine Ransom-Note auf dem Bildschirm.

Damit war die Lage klar: kein technischer Ausfall, sondern ein abgeschlossener Angriff. Die virtuellen Festplatten der Server waren verschlüsselt.

Für die Aufklärung war die Ausgangslage schwierig:

• Kein SOC, kein SIEM, kein vergleichbares Monitoring. Es gab keine zentrale Stelle, an der die Ereignisse der letzten Tage gesammelt worden wären.

• Der Virenschutz auf den Servern war für den Angreifer keine Hürde. Er hat an diesem Abend nichts verhindert und keinen verwertbaren Alarm hinterlassen. Wir gehen davon aus, dass die eingesetzte Schadsoftware für gängige Virenscanner nicht erkennbar war.

• Die Server selbst fielen als Quelle weitgehend aus. Ereignisprotokolle, Spuren im Dateisystem, Anmeldeinformationen: Alles lag hinter der Verschlüsselung.

Was blieb, war die Firewall, eine Sophos XGS. Sie stand zwischen Internet, VPN und internem Netz, sie war nicht verschlüsselt, und sie hatte protokolliert. Nicht alles, wie sich zeigen sollte, aber genug.

Ein Detail gehört gleich an den Anfang, weil es die Analyse prägt: Die erweiterten Erkennungsfunktionen der Firewall, unter anderem der Zero-Day-Schutz, waren seit über einem Jahr nicht mehr lizenziert. Der Kunde hatte sich bewusst gegen die Verlängerung entschieden. Die Protokolle für Angriffserkennung und Schadsoftware waren entsprechend leer. Die Firewall hatte an diesem Abend also keine Chance, etwas zu erkennen. Sie konnte nur mitschreiben.

> Zum Stand der Dinge: Die Angreifer haben bis heute keine Daten veröffentlicht, und der Kunde taucht auf ihrer Leak-Seite nicht auf. Das ist keine Entwarnung. Ob und wann gestohlene Daten auftauchen, entscheidet allein der Angreifer. Für die Bewertung nach Datenschutzrecht zählt der Abfluss, nicht die Veröffentlichung.

Grundsätze vor dem ersten Klick

Bevor die eigentliche Analyse beginnt, gelten vier Regeln. Sie klingen banal, werden in der Hektik eines Vorfalls aber regelmäßig verletzt.

1. Erst sichern, dann schauen. Firewall-Protokolle rotieren. Je nach Verkehrsaufkommen reicht das Verbindungsprotokoll nur wenige Tage zurück, in diesem Fall knapp sechs. Jede Stunde Warten kostet Daten vom Anfang des Zeitraums, und genau dort liegt oft der Erstzugriff.
2. Nur lesen. Während der Analyse wird nichts verändert. Jede Änderung, die zur Eindämmung trotzdem sofort nötig ist, wird mit Uhrzeit dokumentiert. Sonst lässt sie sich später nicht von Aktivität des Angreifers unterscheiden.
3. Feststellung und Bewertung trennen. „Um 19:58 Uhr wurde eine RDP-Verbindung zum Domänencontroller aufgebaut“ ist eine Feststellung. „Der Angreifer hatte Domänen-Adminrechte“ ist eine Bewertung. Beides gehört in den Bericht, aber sichtbar getrennt. Versicherung, Datenschutzbehörde und Ermittler müssen erkennen können, was belegt ist und was geschlossen wurde.
4. Keine Kommunikation mit dem Angreifer. Fremde IP-Adressen werden ausschließlich passiv geprüft, über Reputationsdienste und öffentliche Listen. Niemand pingt, scannt oder besucht die Adressen, von denen der Angriff kam.

Frage 1: Was haben wir überhaupt?

Die ersten Minuten nach der Anmeldung an der Firewall gehörten nicht der Analyse, sondern der Sicherung.

Konfigurations-Backup. Zwei Minuten nach der ersten Anmeldung war ein vollständiges Backup der Konfiguration erstellt und heruntergeladen. Es hält fest, wie die Firewall zum Zeitpunkt des Angriffs eingerichtet war: Regeln, Benutzer, VPN-Einstellungen, Portfreigaben. Jede spätere Aussage über die Konfiguration lässt sich damit belegen, auch wenn sie inzwischen geändert wurde.

Fehlermeldungsbericht mit allen Protokollen. Sophos-Firewalls können unter *Diagnose → Tools → Konsolidierter Fehlermeldungsbericht* ein Paket mit System-Momentaufnahme und sämtlichen Protokolldateien erzeugen. Dieses Paket ist vom Hersteller verschlüsselt und nur für dessen Support lesbar. Für die eigene Analyse taugt es nicht, als unveränderter Beweis ist es wertvoll.

Protokolle im Klartext. Für die eigene Auswertung haben wir alle verfügbaren Protokolle vollständig und lesend exportiert: Verbindungen, Authentifizierung, VPN, System, Administration sowie die Schnittstellenstatistiken. Zusammen gut eine Million Einträge:

| Datenquelle | Zeitraum | Umfang |

|---|---|---|

| Verbindungsprotokoll | knapp 6 Tage | ca. 470.000 Einträge |

| Authentifizierung | gut 2 Wochen | ca. 510.000 Einträge |

| VPN | knapp 3 Wochen | ca. 27.600 Einträge |

| System | knapp 3 Wochen | ca. 10.100 Einträge |

| Administration | erst ab Beginn unserer Reaktion | 10 Einträge |

| Angriffserkennung / Schadsoftware | – | leer (nicht lizenziert) |

| Schnittstellen- und WAN-Statistik | 48 h in 5-Minuten-Werten, 1 Monat grob | – |

Prüfsummen. Jede gesicherte Datei bekommt sofort eine SHA-256-Prüfsumme. Damit lässt sich nachweisen, dass die Daten seit der Sicherung nicht verändert wurden.

```powershell

Get-ChildItem .\beweise -File -Recurse |

Get-FileHash -Algorithm SHA256 |

Select-Object Hash, Path |

Export-Csv .\beweise-sha256.csv -NoTypeInformation -Encoding UTF8

```

`Get-ChildItem -File -Recurse` sammelt alle Dateien im Beweisordner, `Get-FileHash -Algorithm SHA256` berechnet je Datei die Prüfsumme, und `Export-Csv` schreibt die Liste in eine Datei, die mit dem Bericht übergeben wird.

Die Tabelle oben ist bereits der erste Befund. Sie zeigt, was fehlt: ein Protokoll über erlaubten ausgehenden Verkehr. Darauf kommen wir zurück.

Frage 2: Wer ist hereingekommen?

Das Grundrauschen vom Signal trennen. Das Authentifizierungsprotokoll zeigte seit mindestens zweieinhalb Wochen laufende Anmeldeversuche am VPN-Portal. Am Nachmittag des Angriffs stieg das auf 1.400 bis 1.500 Versuche pro Stunde. Die Firewall sperrte nach fünf Fehlversuchen jeweils die Quelladresse. Die Angreifer kamen einfach von der nächsten.

Für sich genommen beweist das nichts. Solche Kampagnen laufen gegen fast jedes VPN-Portal, das im Internet steht. Die eigentliche Frage lautet deshalb nicht „Wer hat es versucht?“, sondern „Wer war erfolgreich, und passt das zu diesem Benutzer?“

Erfolgreiche Anmeldungen gegen ihre Herkunft prüfen. Wir haben alle erfolgreichen Anmeldungen am VPN herausgefiltert und deren Quelladressen mit der öffentlichen Liste der Tor-Ausgangsknoten abgeglichen (`https://check.torproject.org/torbulkexitlist`). Die übrigen Adressen haben wir passiv über Reputationsdienste eingeordnet.

Das Ergebnis war eindeutig: Genau ein Konto hatte sich erfolgreich über Tor beziehungsweise über Anonymisierungsdienste angemeldet. Neunmal, alle am selben Abend. Es war das Konto eines Praktikanten.

Kurz davor zeigte das Protokoll, wie der Angreifer dorthin gekommen war. Über Tor wurde eine Liste typisch deutscher Funktions- und Allgemeinkonten durchprobiert: *azubi1*, *buchhaltung*, *zeiterfassung*, *waage*, *admin*, *vpnadmin*, *praktikant1* und weitere. Nur ein Name passte.

> Hinweis zur Tor-Liste: Tor-Ausgangsknoten wechseln. Die Liste sollte möglichst zeitnah zum Vorfall gezogen und mit Datum gesichert werden. Adressen, die zum Zeitpunkt der Analyse nicht mehr auf der Liste stehen, sind damit nicht entlastet.

Ein zweites, unabhängiges Indiz. Sophos-Firewalls legen Benutzer aus dem Active Directory bei deren erster Anmeldung lokal an und vergeben dabei eine fortlaufende Nummer. Das Praktikanten-Konto hatte die höchste Nummer aller Benutzer. Das VPN-Protokoll reichte knapp drei Wochen zurück und zeigte keine einzige frühere Anmeldung. Beides zusammen sagt: Dieses Konto war an diesem Abend zum ersten Mal überhaupt im VPN.

Was der Kunde ergänzen konnte. Das Konto war aktiv. Das Passwort war identisch mit dem Benutzernamen. Und ins VPN durfte es überhaupt nur aus Versehen: Das Konto war intern angelegt worden, indem ein bestehendes Benutzerkonto im Active Directory kopiert wurde, um dessen Berechtigungen zu übernehmen. Mitgekommen ist dabei auch die Mitgliedschaft in der VPN-Gruppe.

Das ist der eigentliche Kern des Falls. Kein Zero-Day, keine ausgefeilte Technik. Ein Konto, das niemand im Blick hatte, mit einem Passwort, das jede Wortliste enthält, und einer Berechtigung, die niemand vergeben wollte.

Frage 3: War das der erste Besuch?

Bevor man eine Zeitleiste festschreibt, muss man prüfen, ob es nicht schon vorher Aktivität gab. Ein Angreifer, der vor Wochen eingedrungen ist und nur an diesem Abend zugeschlagen hat, ist ein völlig anderer Fall.

Wir haben deshalb den gesamten verfügbaren Zeitraum vor dem Angriff gegengeprüft: keine Tor-Adressen, keine VPN-Sitzungen mit auffälligem Verhalten, keine abgewiesenen Verbindungen zu typischen Ports von Fernsteuerungsservern. Das Praktikanten-Konto taucht vorher nur zweimal auf, nachts mit zwei Fehlversuchen von einer Adresse, die zur laufenden Rate-Kampagne gehörte.

Die ehrliche Einschränkung gehört dazu: Erlaubter ausgehender Verkehr wurde nicht protokolliert. Eine Hintertür, die über einen üblichen Port nach außen telefoniert, hätten wir auf diesem Weg nicht gesehen. Deshalb steht im Bericht nicht „Es gab keine frühere Aktivität“, sondern „In den Firewall-Daten gibt es keine Hinweise auf frühere Aktivität“.

Frage 4: Was hat der Angreifer im Netz getan?

Das VPN-Protokoll liefert für jede Sitzung die interne Adresse, die der Client im Tunnel bekommen hat. Mit dieser einen Adresse lässt sich das Verbindungsprotokoll filtern: Alles, was über die Regel zwischen VPN und LAN von dieser Adresse ausging, gehört zur Sitzung des Angreifers. An diesem Abend waren das rund 6.400 Einträge.

Statt jede Zeile einzeln zu lesen, haben wir nach Ziel, Dienst und Datenmenge zusammengefasst. Aus solchen Zusammenfassungen werden Muster sichtbar:

| Ziel (Rolle) | Dienst | Zeitraum | Muster |

|---|---|---|---|

| gesamtes internes Netz, über 300 Adressen | Dateifreigaben, Web | ca. 2 Minuten | breitflächiger Kontakt, fast keine Daten |

| Domänencontroller | Verzeichnisabfragen (LDAP), Kerberos | ca. 80 Minuten | 2.434 Kerberos-Anfragen in 24 Minuten |

| Domänencontroller | Remotedesktop | knapp 2 Stunden | interaktive Sitzung |

| Datei- und Anwendungsserver | Dateifreigaben, RPC | mehrere Stunden | gezielte Lesezugriffe, zusammen gut 100 MB |

| ein einzelnes Gerät | HTTPS | gut 2 Stunden | 2.708 Verbindungen |

| weiterer Server | Remotedesktop | gut 2 Stunden | interaktive Sitzung |

Daraus lassen sich, klar als Bewertung gekennzeichnet, folgende Schlüsse ziehen:

• Zwei Minuten, über 300 Ziele, fast keine Daten: Das ist kein Mensch, der Freigaben durchklickt, sondern eine automatisierte Erkundung des Netzes.

• Tausende Kerberos-Anfragen und Verzeichnisabfragen am Domänencontroller: Das spricht für eine systematische Erkundung des Active Directory und für Versuche, an weitere Anmeldedaten zu kommen. Ein Praktikanten-Konto bringt keine Adminrechte mit. Der Angreifer musste sich also höhere Rechte verschaffen.

• Danach eine interaktive Sitzung auf dem Domänencontroller: Mit hoher Wahrscheinlichkeit war das zu diesem Zeitpunkt gelungen.

• 2.708 HTTPS-Verbindungen auf ein einzelnes Gerät: Das passt zur Weboberfläche einer Verwaltungskonsole. Angesichts der Ransom-Note auf dem Hypervisor liegt nahe, dass es dessen Verwaltungsoberfläche war.

• Über den VPN-Tunnel selbst flossen insgesamt nur rund 165 MB vom Netz zum Angreifer. Das ist wichtig für die nächste Frage.

Frage 5: Sind Daten abgeflossen, und wenn ja, wie viele?

Hier wurde es schwierig. Die naheliegende Quelle, das Verbindungsprotokoll, schwieg. Erlaubter Verkehr vom internen Netz ins Internet wurde schlicht nicht protokolliert. Die Firewall hatte die Verbindungen durchgelassen, aber nicht aufgeschrieben.

Wer an dieser Stelle aufhört, schreibt in den Bericht: „Ein Datenabfluss ist nicht nachweisbar.“ Das wäre formal korrekt und trotzdem falsch.

Die Statistik als zweite Quelle. Unabhängig vom Verbindungsprotokoll führt die Firewall Statistiken über die Datenmenge je Schnittstelle, für die letzten 48 Stunden in 5-Minuten-Werten. Diese Werte zählen jedes Byte, egal ob eine Regel protokolliert oder nicht.

Für diese Werte haben wir zuerst den Normalzustand bestimmt, und erst dann die Abweichung gemessen:

| Zeitraum | Upload ins Internet |

|---|---|

| üblicher Abend, gleiche Uhrzeit | ca. 0,03–0,05 GB pro Stunde |

| Vortag, gleiches Zeitfenster | ca. 0,12 GB |

| Angriffsabend, erste Phase (ca. 15 Minuten) | ca. 2 GB |

| Angriffsabend, zweite Phase (ca. 55 Minuten) | ca. 14 GB, Leitung dauerhaft voll ausgelastet |

| Summe | ca. 16 GB |

Drei Gegenproben machen daraus einen belastbaren Befund:

1. Die Gegenrichtung stimmt. Die interne Netzwerkschnittstelle hat im selben Zeitraum dieselbe Menge aus dem LAN empfangen. Die Daten kamen also aus dem internen Netz und nicht etwa von der Firewall selbst.
2. Der Tunnel scheidet aus. Über das VPN flossen nur rund 165 MB. Der Upload lief direkt von einem internen System ins Internet. Der Angreifer hat also nicht über seine eigene Leitung abgezogen, sondern die Internetleitung des Kunden benutzt.
3. Die Messgenauigkeit ist bekannt. 5-Minuten-Mittelwerte ergeben eine Unschärfe von etwa ±0,5 GB. An der Größenordnung ändert das nichts.

Wohin? Auch ohne Protokoll des erlaubten Verkehrs blieb eine Spur. Für einige Minuten in der ersten Upload-Phase sind Antwortpakete einer Adresse des Cloud-Speicherdienstes MEGA an die Firewall protokolliert. Diese Adresse taucht in den knapp sechs Tagen Verbindungsprotokoll nur in genau diesem Zeitfenster auf. Sie war das einzige neue externe Ziel des Abends.

Auch hier gehört die Grenze in den Bericht: Belegt ist die Verbindung zu MEGA für die erste Phase. Für die zweite, größere Phase ist das Ziel nicht protokolliert. Welches interne System hochgeladen hat, lässt sich aus der Firewall nicht ableiten, weil alle internen Systeme hinter derselben öffentlichen Adresse liegen.

Auf den betroffenen Servern lagen medizinisch relevante Kundendaten. Wir mussten deshalb davon ausgehen, dass sie zu den abgeflossenen Daten gehören.

Frage 6: Wann wurde verschlüsselt?

Wer die virtuellen Festplatten auf einem Hypervisor verschlüsseln will, muss die virtuellen Maschinen vorher ausschalten. Genau das ist in den Daten zu sehen: Ab etwa 21:52 Uhr erzeugten die Server keinen einzigen Netzwerkverkehr mehr. Nicht weniger, sondern gar keinen.

Eine zweite, unabhängige Quelle bestätigt das: Das nächtliche Offsite-Backup überträgt üblicherweise rund 65 GB. In dieser Nacht waren es 0,13 GB. Die Systeme, die gesichert werden sollten, liefen nicht mehr.

Der Datenabfluss endete gegen 21:44 Uhr, wenige Minuten später verstummten die Server. Die Reihenfolge ist typisch für Ransomware mit doppelter Erpressung: erst die Daten mitnehmen, dann verschlüsseln.

Frage 7: Hat sich der Angreifer an der Firewall festgesetzt?

Eine Firewall, die selbst kompromittiert ist, wäre als Zeugin wertlos. Außerdem wäre sie der ideale Ort für eine Hintertür, die jede Neuinstallation der Server überlebt. Diese Frage muss deshalb ausdrücklich beantwortet werden.

• Das Administrationsprotokoll enthielt keinen einzigen Eintrag vor unserer eigenen Anmeldung: keine Anmeldung des Angreifers, keine Fehlversuche, keine Änderungen.

• Die Verwaltungsoberfläche war aus dem Internet gesperrt. Aus dem VPN-Tunnel des Angreifers gab es keine Verbindung zu den Verwaltungsports.

• Aber: Drei Administratorkonten der Firewall hatten keine Multi-Faktor-Authentifizierung, und eines davon meldete sich gegen das Active Directory an. Mit einem kompromittierten AD wäre darüber ein Admin-Zugang zur Firewall möglich gewesen. Das Konto wurde sofort deaktiviert. Zusätzlich vergleichen wir die gesicherte Konfiguration mit dem regelmäßig per Mail versendeten Backup aus der Vorwoche.

Ein leeres Admin-Protokoll über Wochen ist ungewöhnlich, aber plausibel, wenn in dieser Zeit niemand administriert hat. Deshalb steht es im Bericht nicht als Beweis, sondern als Feststellung mit Gegenprobe.

Frage 8: Und alle anderen Konten?

Ein Angreifer mit Domänenrechten kann sich beliebige weitere Zugänge verschaffen. Wir haben deshalb jede VPN-Anmeldung der letzten Wochen nach Benutzer und Herkunft zusammengefasst und alles geprüft, was vom gewohnten Muster abwich. Dazu gehörten eine Anmeldung aus Istanbul, mehrere aus Texas, eine über Starlink und eine regelmäßige Anmeldung aus einem Cloud-Rechenzentrum.

Bewertet haben wir nicht die Herkunft, sondern das Verhalten in der Sitzung: Wer sich aus dem Urlaub verbindet und eine Stunde auf dem Terminalserver arbeitet, sieht in den Verbindungsdaten völlig anders aus als jemand, der das Netz absucht. Alle Auffälligkeiten ließen sich auf normale Arbeit zurückführen, die Reisen hat der Kunde bestätigt. Erst danach stand fest: Der Angreifer hat für den Zugang von außen nur das eine Konto benutzt.

Parallel: Eindämmen, ohne Spuren zu verwischen

Während die Analyse lief, musste das Netz trotzdem sicher werden. Jede Maßnahme wurde mit Uhrzeit in den Bericht übernommen:

• Praktikanten-Konto in AD und Firewall gesperrt, VPN-Portal aus dem Internet genommen

• AD-gestütztes Administratorkonto der Firewall deaktiviert

• Portfreigaben aus dem Internet auf Branchensoftware und Telefonanlage deaktiviert

• Protokollierung des erlaubten ausgehenden Verkehrs eingeschaltet

• eigene Regelgruppe ganz oben im Regelwerk: Alle Server dürfen nicht mehr ins Internet, mit eng begrenzten Ausnahmen (DNS des Domänencontrollers, Telefonie, später das Backup-Ziel)

Nach der Wiederinbetriebnahme haben wir die Protokolle erneut geprüft: keine Verbindungen zu Adressen des Angreifers, zu Tor oder zu MEGA. Die Sperrregel verwarf in dreieinhalb Stunden rund 190.000 Verbindungsversuche der Server, praktisch ausschließlich zu Update-, Cloud- und Fernwartungsdiensten. Das zeigt nebenbei, wie viel Verkehr Server nach außen erzeugen, von dem niemand weiß.

Die Falle bei der Wiederherstellung

Der Domänencontroller wurde auf den Stand vom Vortag zurückgesetzt, isoliert gestartet und anschließend neu aufgebaut. Das ist richtig, hat aber einen Haken, den man leicht übersieht:

Im wiederhergestellten Active Directory gelten dieselben Passwörter und Kerberos-Schlüssel wie zum Zeitpunkt des Angriffs. Alles, was der Angreifer an diesem Abend an Anmeldedaten erbeutet hat, funktioniert im alten Stand weiter. Und das Praktikanten-Konto ist dort wieder aktiv, mit dem Passwort, das seinem Benutzernamen entspricht.

Deshalb gilt nach jeder Wiederherstellung eines kompromittierten AD:

1. das kompromittierte Konto erneut sperren
2. alle Passwörter neu setzen: Benutzer, Administratoren, Dienstkonten
3. das Kennwort des Kontos `krbtgt` zweimal zurücksetzen, mit ausreichendem Abstand dazwischen (mindestens die maximale Ticket-Lebensdauer, standardmäßig 10 Stunden), damit die Replikation abgeschlossen ist und alte Tickets ungültig werden

Die Zeitleiste

Am Ende steht eine Zeitleiste, die sich ausschließlich auf die Daten der Firewall stützt:

| Uhrzeit (Freitag) | Ereignis |

|---|---|

| seit über 2 Wochen | laufende automatisierte Anmeldeversuche am VPN-Portal |

| ab ca. 13:50 | deutlich verstärkte Rate-Kampagne, rund 1.500 Versuche pro Stunde |

| ca. 17:19 | über Tor werden deutsche Kontonamen durchprobiert; erste erfolgreiche Anmeldung mit dem Praktikanten-Konto |

| 18:33 | VPN-Tunnel steht |

| 18:33–18:35 | automatisierte Erkundung des internen Netzes |

| 18:36–19:56 | Abfragen am Domänencontroller (Verzeichnis, Kerberos) |

| 19:58 | Remotedesktop-Sitzung auf dem Domänencontroller |

| 20:25–21:44 | Upload von rund 16 GB ins Internet, anfangs nachweislich zu MEGA |

| ca. 21:52 | Server erzeugen keinen Netzwerkverkehr mehr: Verschlüsselung |

| 22:34 | Angreifer trennt die VPN-Verbindung |

| Samstagvormittag | Anruf des Kunden, Beginn unserer Reaktion |

Von der ersten erfolgreichen Anmeldung bis zur Verschlüsselung vergingen gut viereinhalb Stunden. An einem Freitagabend, an dem niemand hinsah.

Wiederanlauf: Sonntagnachmittag, mit einer Lücke

Am Sonntagnachmittag konnte der Kunde in Teilen wieder arbeiten. Das ist für einen Vorfall dieser Größenordnung schnell und war nur möglich, weil die Backups den Angriff überstanden hatten.

Allerdings nicht alle vollständig. Bei einem Server stellte sich bei der Wiederherstellung heraus, dass die inkrementellen Sicherungen defekt waren. Einige Wochen Daten auf diesem Server sind verloren.

Das ist die zweite Lehre dieses Falls, die mit dem Angriff selbst nichts zu tun hat: Eine Sicherungskette ist nur so gut wie ihr schwächstes Glied. Ob ein Inkrement brauchbar ist, zeigt sich erst bei der Wiederherstellung. Wer das zum ersten Mal im Ernstfall prüft, prüft zu spät.

Die Meldungen an die Datenschutz-Aufsichtsbehörde, an die Cyberversicherung und an die Polizei sind erfolgt.

1. Multi-Faktor-Authentifizierung am VPN

Das ist die eine Maßnahme, die diesen Angriff mit hoher Wahrscheinlichkeit vollständig verhindert hätte. Ein erratenes Passwort ist wertlos, wenn ein zweiter Faktor fehlt.

Bei Sophos-Firewalls lassen sich Einmalkennwörter (TOTP) für VPN-Portal und SSL-VPN unter *Authentifizierung → Einmalkennwort* aktivieren. Wichtig ist, sie für alle Benutzer zu erzwingen, nicht nur für ausgewählte Gruppen. Ein Konto, das niemand auf dem Schirm hat, wird sonst auch bei der MFA-Einführung vergessen.

Ergänzend:

• Sperre pro IP reicht nicht. Fünf Fehlversuche je Adresse halten niemanden auf, der aus dem Tor-Netz oder einem Proxy-Netz mit Tausenden Adressen arbeitet. Wirksamer ist eine Einschränkung nach Herkunftsland und das Sperren bekannter Anonymisierungsnetze, etwa über Länder-Objekte in den Regeln für den Zugriff auf das VPN-Portal und über eine eingebundene Liste von Tor-Ausgangsknoten.

• VPN-Portal nur, wenn es gebraucht wird. Das Portal zum Herunterladen der VPN-Konfiguration muss nicht dauerhaft aus dem Internet erreichbar sein.

2. Konten nicht klonen, oder nach dem Klonen prüfen

Das Kopieren eines bestehenden Kontos ist im Alltag der schnellste Weg zu einem neuen Benutzer mit den richtigen Rechten. Es übernimmt aber alle Gruppenmitgliedschaften, auch die, die niemand bewusst vergeben wollte.

Besser sind rollenbasierte Gruppen (etwa „Rolle Praktikum“), denen ein neues Konto zugeordnet wird. Wer trotzdem klont, sollte die Gruppen danach prüfen. Regelmäßig gehört außerdem auf den Tisch, wer überhaupt ins VPN darf:

```powershell

Get-ADGroupMember -Identity "VPN-User" -Recursive |

Get-ADUser -Properties Enabled, LastLogonDate, PasswordLastSet, whenCreated |

Select-Object SamAccountName, Enabled, whenCreated, PasswordLastSet, LastLogonDate |

Sort-Object LastLogonDate |

Format-Table -AutoSize

```

`Get-ADGroupMember -Recursive` holt alle Mitglieder der VPN-Gruppe, auch über verschachtelte Gruppen. `Get-ADUser -Properties` ergänzt, ob das Konto aktiv ist, wann es angelegt wurde und wann das Passwort zuletzt gesetzt und das Konto zuletzt benutzt wurde. Sortiert nach letzter Anmeldung stehen die Konten oben, die am wahrscheinlichsten niemand mehr braucht. Den Gruppennamen passen Sie an Ihre Umgebung an.

Inaktive Konten insgesamt findet diese Abfrage:

```powershell

Search-ADAccount -AccountInactive -UsersOnly -TimeSpan 90.00:00:00 |

Where-Object Enabled |

Select-Object SamAccountName, LastLogonDate

```

Sie listet aktivierte Benutzerkonten, die sich seit 90 Tagen nicht angemeldet haben.

3. Passwörter, die jede Wortliste kennt, technisch verhindern

Ein Passwort, das dem Benutzernamen entspricht, darf ein Verzeichnisdienst gar nicht erst annehmen. Die Standard-Kennwortrichtlinie des Active Directory verbietet zwar den Kontonamen im Passwort, doch dieser Schutz greift nur bei aktivierten Komplexitätsanforderungen und nur beim Ändern des Passworts. Ein Konto, das mit einem schwachen Passwort angelegt oder von einer Richtlinienänderung nie erfasst wurde, behält es.

Wirksamer sind:

• Microsoft Entra Password Protection für das lokale AD: blockiert bekannte schwache Passwörter und eine eigene Liste verbotener Begriffe (Firmenname, Ort, Funktionsbezeichnungen wie „Praktikant“).

• Längere Mindestlänge statt Sonderzeichen-Pflicht, etwa über eine abgestufte Kennwortrichtlinie (Fine-Grained Password Policy) für Konten mit Fernzugriff.

• Initialpasswörter, die beim ersten Anmelden geändert werden müssen, und Konten, die erst freigeschaltet werden, wenn sie gebraucht werden.

4. Auch erlaubten Verkehr protokollieren

In diesem Fall ließ sich der Datenabfluss nur über einen Umweg belegen. Mit einem einzigen Haken wäre er direkt sichtbar gewesen: Ziel, Quelle, Datenmenge.

In Sophos-Firewalls ist das die Option „Firewall-Verkehr protokollieren“ in der jeweiligen Regel, insbesondere in der Regel vom LAN ins Internet. Zusätzlich sollten die Protokolle per Syslog an ein externes System gehen (*Systemdienste → Protokolleinstellungen*), damit sie nicht nach wenigen Tagen rotieren und auch dann noch vorliegen, wenn die Firewall selbst ausfällt.

> ACHTUNG: Das Protokollieren des gesamten ausgehenden Verkehrs erzeugt deutlich mehr Einträge. Prüfen Sie Speicher und Aufbewahrung, bevor Sie es einschalten, sonst rotieren die Protokolle noch schneller.

5. Server ausgehend standardmäßig sperren

Server müssen nicht beliebig ins Internet. Die Regelgruppe, die wir nach dem Vorfall als Notfallmaßnahme gebaut haben, ist eigentlich der Sollzustand: Server dürfen nur zu definierten Zielen (Updates, Backup-Ziel, Lizenz- und Fachdienste), alles andere wird verworfen und protokolliert.

Ein Upload von 16 GB zu einem Cloud-Speicher wäre damit gescheitert oder zumindest sofort aufgefallen. Ergänzend lassen sich Cloud-Speicherdienste, die im Unternehmen nicht genutzt werden, über Anwendungs- und Webfilter gezielt sperren.

6. Die Erkennung im Active Directory

Auch ohne SOC lassen sich die lautesten Spuren dieses Angriffs auf dem Domänencontroller erkennen. Drei Beispiele:

Kerberos-Tickets mit schwacher Verschlüsselung. Viele Anfragen nach Diensttickets mit RC4-Verschlüsselung (Typ `0x17`) in kurzer Zeit sind ein typisches Zeichen für das Abgreifen von Dienstkonto-Passwörtern:

```powershell

Get-WinEvent -LogName Security -FilterXPath "*[System[EventID=4769] and EventData[Data[@Name='TicketEncryptionType']='0x17']]" -MaxEvents 500 |

Group-Object { $_.Properties[0].Value } |

Sort-Object Count -Descending |

Select-Object Count, Name

```

Die Abfrage holt Ereignis 4769 (Dienstticket angefordert) mit RC4-Verschlüsselung und gruppiert nach anforderndem Konto. Ein einzelnes Konto mit Hunderten solcher Anfragen innerhalb weniger Minuten verdient sofortige Aufmerksamkeit, erst recht, wenn es ein Praktikanten-Konto ist.

Remotedesktop-Anmeldungen auf dem Domänencontroller. Ereignis 4624 mit Anmeldetyp 10 zeigt interaktive RDP-Anmeldungen. Kommen sie aus dem VPN-Adressbereich, ist das außerhalb festgelegter Admin-Konten ein Alarm.

Änderungen an sicherheitsrelevanten Gruppen. Die Ereignisse 4728 und 4732 (Mitglied zu globaler bzw. lokaler Sicherheitsgruppe hinzugefügt) zeigen, wann ein Konto in Gruppen wie „VPN-User“ oder „Domänen-Admins“ landet. Genau dieses Ereignis hätte beim Klonen des Praktikanten-Kontos die unbeabsichtigte VPN-Berechtigung sichtbar gemacht.

7. Firewall-Administration absichern

• MFA für alle Administratorkonten der Firewall

• keine Administrator-Anmeldung über das Active Directory. Wer das AD übernimmt, soll damit nicht auch die Firewall bekommen

• Verwaltungsoberfläche nie aus dem Internet erreichbar

8. Backups regelmäßig zurückspielen

Die Backups haben den Kunden gerettet, und trotzdem fehlen einige Wochen Daten. Regelmäßige Rückspieltests gehören deshalb fest in den Betrieb:

• Vollständige Wiederherstellung, nicht nur das Öffnen einzelner Dateien. Erst die Wiederherstellung über die gesamte Kette aus Voll- und inkrementellen Sicherungen zeigt, ob jedes Glied intakt ist.

• Pro System, nicht stichprobenartig über alle. Ein defektes Inkrement auf einem einzigen Server fällt bei einem Test auf einem anderen nicht auf.

• Mit Protokoll und Datum, damit nachweisbar ist, wann welches System zuletzt erfolgreich wiederhergestellt wurde.

• Nach der 3-2-1-1-0-Regel: drei Kopien, zwei Medientypen, eine außer Haus, eine unveränderlich oder offline, null Fehler beim Rückspieltest.

9. Jemand muss hinsehen

Der Angriff dauerte gut viereinhalb Stunden, an einem Freitagabend. Er erzeugte Tausende Kerberos-Anfragen, eine RDP-Sitzung auf dem Domänencontroller aus dem VPN und einen Upload, der die Leitung über eine Stunde lang voll auslastete. Nichts davon ist subtil.

Der Virenschutz war keine Hürde. Die Erkennungsfunktionen der Firewall waren nicht lizenziert. Und es gab niemanden, bei dem eine dieser Spuren als Alarm angekommen wäre. Genau dafür gibt es ein SOC: nicht als zusätzliches Werkzeug, sondern als die Stelle, die auch Freitagabend um 19:58 Uhr hinsieht.