Acht Tage unbemerkt: Wie ein offener RDP-Port zur Vollverschlüsselung führte
Ein offener RDP-Port, gültige Zugangsdaten und acht Tage ohne Reaktion: Ein realer Ransomware-Fall zeigt, wie ein Angriff zur vollständigen Verschlüsselung einer Serverumgebung führte und welche Maßnahmen ihn hätten stoppen können.
Worum es hier geht in einfachen Worten
Ein Unternehmen wollte, dass Mitarbeitende von außen auf ihre Server kommen. Die einfachste Lösung dafür ist seit zwanzig Jahren dieselbe: Man gibt den Fernwartungszugang von Windows direkt im Internet frei. Das funktioniert sofort, kostet nichts und braucht keine zusätzliche Technik.
Es bedeutet allerdings auch, dass dieser Zugang für jeden auf der Welt sichtbar ist. Nicht im übertragenen Sinn: Es gibt Suchmaschinen, die nichts anderes tun, als solche offenen Zugänge zu katalogisieren. Von dort aus probieren automatisierte Systeme rund um die Uhr Benutzernamen und Passwörter durch.
In diesem Fall hat es funktioniert. Acht Tage später war das Unternehmen nicht mehr arbeitsfähig.
Dieser Beitrag beschreibt einen realen Vorfall: was passiert ist, an welchen Stellen er hätte auffallen können, und was Unternehmen konkret anders machen müssen. Ab dem Kapitel "Die Angriffskette" wird es technisch. Wer nur die Konsequenzen braucht, springt zu "Was hätte den Angriff gestoppt".
Der Fall: Freitagmorgen, alles offline
Der Anruf kam an einem Freitagmorgen. Am Apparat der interne Administrator eines Unternehmens, das Monate zuvor einen Backup-Server bei uns bestellt hatte.
Kein SOC-Vertrag, kein Managed Service, eine Hardwarelieferung mit Einrichtung, mehr nicht.
Sein Problem: Er kam auf nichts mehr drauf. Sämtliche Server waren offline.
Als er sich auf die Verwaltungsoberfläche des Hypervisors verband, stand dort ein geöffnetes Fenster. Der Titel: Mimikatz.
Kein Absturz, keine Fehlermeldung, kein Hinweis auf ein technisches Problem. Da hatte jemand an diesem System gearbeitet und sich nicht einmal die Mühe gemacht, das Werkzeug wieder zu schließen. Ab diesem Moment war klar, dass es sich nicht um einen Ausfall handelte, sondern um einen Angriff, und dass dieser Angriff bereits abgeschlossen war.
An diesem Punkt haben wir den Fall an unseren Partner übergeben, der forensische Untersuchungen für uns übernimmt. Dessen Team hat eine separate Wiederherstellungs-VM aufgesetzt und den Verdacht bestätigt: Ransomware. Sämtliche virtuellen Festplatten der Server auf dem Host waren verschlüsselt.
Einordnung in eigener Sache: Nahezu alles, was in diesem Beitrag über den Ablauf des Angriffs steht – die Zeitachse, der Einstiegsweg, die ausgewerteten Protokolle – stammt aus der Arbeit dieses Forensik-Teams, nicht von uns. Wir haben den Fall aufgenommen, die Übergabe organisiert und den Kunden begleitet. Die Rekonstruktion selbst ist Spezialistenarbeit, und sie gehört denen, die sie geleistet haben. Wir erzählen hier davon, weil der Fall lehrreich ist.
Das fehlende Erpresserschreiben
Ein Detail, das zunächst irritierte: Es gab keine Ransom-Note.
Das ist ungewöhnlich, denn das Erpresserschreiben ist für einen Ransomware-Akteur das betriebswirtschaftlich Wichtigste am ganzen Angriff. Ohne Kontaktweg keine Verhandlung, ohne Verhandlung keine Zahlung.
Die Forensik fand die Erklärung schnell: Der Akteur hatte sein eigenes Erpresserschreiben mitverschlüsselt. Es lag auf einem der Volumes, die anschließend im Rutsch mit verschlüsselt wurden.
Das ist mehr als eine Anekdote. Es sagt etwas über die Professionalität des Angreifers und es zeigt, dass man es bei Ransomware längst nicht mehr nur mit hochspezialisierten Gruppen zu tun hat. Ein erheblicher Teil dieser Angriffe wird heute mit eingekauften Werkzeugkästen von Leuten durchgeführt, die die Technik dahinter nicht vollständig verstehen. Für die Verteidigung ist das keine gute Nachricht, sondern eine schlechte: Es senkt die Einstiegshürde.
Warum die Backups überlebt haben
Die Datensicherung war intakt. Nicht wegen einer besonders ausgefeilten Backup-Strategie, sondern wegen zweier Eigenschaften des Servers, den wir Monate zuvor ausgeliefert hatten:
- Er war nicht Mitglied der Domäne.
Damit halfen die Domänen-Anmeldedaten, die sich der Angreifer verschafft hatte, an diesem System nicht weiter. - Er hatte ein eigenes lokales Administrator-Kennwort
– nicht dasselbe wie die übrigen Server der Umgebung.
Der zweite Punkt ist der wichtigere, weil er auch die Frage beantwortet, warum alles andere gefallen ist: Ein einheitliches lokales Administrator-Kennwort über die gesamte Serverlandschaft bedeutet, dass ein einziger kompromittierter Passwort-Hash den Zugriff auf jedes System der Umgebung eröffnet. Genau dafür ist ein Werkzeug wie Mimikatz gebaut.
So liefern wir diese Server standardmäßig aus. In diesem Fall war das der Unterschied zwischen einem sehr schlechten Wochenende und einer eventuellen Insolvenz.
Die Angriffskette
Vom ersten Zugriff bis zur Verschlüsselung
Die entscheidende Frage blieb zunächst offen: Wie ist der Angreifer überhaupt hineingekommen? Beantwortet hat sie die Forensik über die Durchsicht der Firewall-Konfiguration und den Abgleich der Protokolle. Die folgende Darstellung gibt deren Befunde wieder.
Ausgangspunkt: Port 3389 im Internet
Der TCP-Port 3389 – das Remote Desktop Protocol – war direkt aus dem Internet erreichbar. Ohne vorgeschaltetes VPN, ohne Gateway, ohne Einschränkung auf bestimmte Herkunftsadressen.
Das ist keine exotische Fehlkonfiguration, sondern nach wie vor einer der häufigsten Erstzugriffswege bei Ransomware-Vorfällen im Mittelstand. Der Grund ist immer derselbe: Es musste einmal schnell gehen. Ein Dienstleister brauchte Zugriff, jemand musste aus dem Homeoffice arbeiten, eine Anwendung ließ sich anders nicht bedienen. Die Freigabe war als Übergangslösung gedacht und wurde nie zurückgebaut.
Ein solcher Port wird nicht zufällig gefunden. Das gesamte IPv4-Internet ist auf offene Standardports durchsuchbar, und die Ergebnisse sind öffentlich abrufbar. Zwischen der Freischaltung und den ersten automatisierten Anmeldeversuchen liegen üblicherweise Minuten bis Stunden.
Tag 0: Die erste erfolgreiche Anmeldung
Acht Tage vor der Verschlüsselung meldete sich ein Angreifer erstmals erfolgreich an, von einer IP-Adresse, die in einschlägigen Threat-Intelligence-Quellen längst als bösartig geführt wurde.
Zwei Dinge daran verdienen Aufmerksamkeit.
Erstens: Es war eine erfolgreiche Anmeldung, kein Einbruch über eine Sicherheitslücke. Es wurden gültige Zugangsdaten verwendet. Ob geraten, aus einem früheren Datenleck bezogen oder durch systematisches Ausprobieren ermittelt – das Ergebnis ist dasselbe.
Zweitens: Die Herkunftsadresse war bekannt. Ein Abgleich eingehender Verbindungen gegen gängige Reputationslisten hätte diese Anmeldung markiert, bevor sie überhaupt zustande kam.
Tag 1: Der Angreifer macht einen Fehler
Einen Tag später startete der Angreifer Werkzeuge zum Auslesen von Anmeldedaten. Der auf dem System vorhandene Microsoft Defender erkannte das und schlug Alarm – zuverlässig, korrekt und rechtzeitig.
Und dann passierte nichts.
Der Alarm lief in eine Konsole, die niemand regelmäßig ansah. Es gab keine Weiterleitung, keine Benachrichtigung, keinen Prozess, der auf eine solche Meldung reagiert hätte. Damit war die letzte Chance vertan, den Angriff vor der Verschlüsselung zu stoppen.
Dieser Punkt ist der eigentlich schmerzhafte Punkt an dem ganzen Fall. Die Schutztechnik war vorhanden. Sie hat funktioniert. Sie hat sogar genau das gemeldet, was sie melden sollte. Was fehlte, war jemand, der hinsah.
Tag 1 bis 8: Ausbreitung
Was in den folgenden Tagen geschah, hat die Forensik aus den verbliebenen Artefakten rekonstruiert: Mit den ausgelesenen Anmeldedaten und dem einheitlichen lokalen Administrator-Kennwort bewegte sich der Angreifer durch die Umgebung bis zum Hypervisor. Wer den Virtualisierungswirt kontrolliert, braucht sich um die einzelnen Server nicht mehr zu kümmern, er verschlüsselt die virtuellen Festplatten und erledigt damit alles auf einmal.
Tag 8: Die Verschlüsselung
Am Ende steht der Freitagmorgen, an dem nichts mehr geht.
Was an jeder Stelle sichtbar gewesen wäre
Der Angriff hatte acht Tage Vorlauf. In dieser Zeit gab es mehrere unabhängige Gelegenheiten, ihn zu bemerken. Die Artefakte, die dafür nötig gewesen wären, entstehen bei Windows und einer handelsüblichen Firewall ohne jedes Zusatzprodukt:
Auf der Firewall:
- Eingehende Verbindungen auf 3389 aus dem Internet, für sich genommen bereits ein Befund
- Verbindungsaufbau aus Ländern oder Netzbereichen ohne jeden geschäftlichen Bezug
- Massenhafte Verbindungsversuche als typisches Muster automatisierter Anmeldeversuche
In den Windows-Ereignisprotokollen:
- Sicherheit, Ereignis-ID 4625 – fehlgeschlagene Anmeldung. In Serie ein klares Zeichen für systematisches Ausprobieren.
- Sicherheit, Ereignis-ID 4624 mit Anmeldetyp 10 – eine erfolgreiche interaktive Anmeldung über RDP. Der Wert wird interessant, sobald die Quelladresse außerhalb des eigenen Netzes liegt.
- Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational, Ereignis-ID 1149 – erfolgreiche RDP-Authentifizierung inklusive Quell-IP.
- Microsoft-Windows-TerminalServices-LocalSessionManager/Operational, Ereignis-IDs 21 und 25 – Sitzungsanmeldung und Wiederverbindung.
Beim Virenschutz:
- Die Defender-Erkennung der Werkzeuge zum Auslesen von Anmeldedaten. Das ist keine Warnung, die man priorisieren muss – das ist die Meldung, bei der man nachts geweckt werden möchte.
Der Unterschied zwischen "vorhanden" und "wirksam" liegt genau hier. Alle diese Daten existierten. Sie wurden erzeugt, geschrieben und aufbewahrt. Ausgewertet wurden sie erst durch die Forensik nach der Verschlüsselung.
Ein Angriff, der sich über acht Tage erstreckt und dabei mehrere laute Spuren hinterlässt, ist kein Angriff, gegen den man machtlos ist. Er ist ein Angriff, der niemandem aufgefallen ist.
Sofortmaßnahmen im akuten Fall
Falls Sie diesen Beitrag gerade lesen, weil bei Ihnen etwas Ähnliches läuft – die Reihenfolge ist wichtig:
- Nicht ausschalten, sondern vom Netz trennen.
Ein Herunterfahren vernichtet flüchtige Spuren im Arbeitsspeicher, die für die Aufklärung wertvoll sind. Netzwerkkabel ziehen beziehungsweise den Port deaktivieren ist der schonendere Weg. - Nichts überschreiben.
Keine Neuinstallation auf betroffenen Datenträgern, keine "Reparaturversuche". Jede Schreiboperation kostet Beweise. - Sicherungen sofort isolieren.
Backup-Systeme vom Netz nehmen, bevor geprüft wird. Der häufigste Grund für einen Totalverlust ist, dass die Sicherung während der Aufräumarbeiten ebenfalls erreichbar blieb. - Externe Anmeldewege schließen, insbesondere den, über den der Angreifer gekommen ist.
- Forensik hinzuziehen, bevor wiederhergestellt wird.
Wer sofort zurücksichert, ohne den Einstiegsweg zu kennen, stellt unter Umständen die Hintertür gleich mit wieder her. - Meldepflichten prüfen.
Je nach betroffenen Daten greift Art. 33 DSGVO mit einer Frist von 72 Stunden ab Kenntnis. Bei Unternehmen im NIS2-Anwendungsbereich kommen weitere Fristen hinzu. - Zugangsdaten als kompromittiert behandeln
– alle, nicht nur die offensichtlich betroffenen. Wenn Werkzeuge zum Auslesen von Anmeldedaten liefen, gilt das für jeden Zugang, der auf einem betroffenen System jemals verwendet wurde.
ACHTUNG: Widerstehen Sie dem Impuls, "schnell wieder ans Laufen" zu kommen. Der teuerste Fehler in dieser Phase ist ein zweiter Vorfall zwei Wochen später, weil die Ursache nie beseitigt wurde.
Was hätte den Angriff gestoppt
1. RDP gehört nicht ins Internet
Das ist die Kernaussage dieses Beitrags, und sie ist bewusst kompromisslos formuliert. Es gibt keine Konfiguration, die eine direkte RDP-Freigabe ins Internet zu einer vertretbaren Lösung macht.
Auch nicht mit Authentifizierung auf Netzwerkebene (NLA). NLA verhindert, dass eine Sitzung vor der Authentifizierung aufgebaut wird, gegen einen Angreifer mit gültigen Zugangsdaten hilft es nicht.
Auch nicht mit einem geänderten Port. Ein Verschieben von 3389 auf einen ungewöhnlichen Port reduziert das Grundrauschen der automatisierten Scans, hält aber niemanden auf, der gezielt sucht.
Auch nicht "nur für den einen Dienstleister". Genau so entstehen diese Freigaben.
Die Alternativen, nach Aufwand sortiert:
- VPN mit MFA.
Der Zugang wird erst nach erfolgreicher Authentifizierung am VPN überhaupt sichtbar. Für die meisten mittelständischen Umgebungen die naheliegende Lösung, weil die Technik ohnehin vorhanden ist. - Remote Desktop Gateway.
Kapselt RDP in HTTPS und lässt sich mit MFA und Richtlinien für bedingten Zugriff kombinieren. Sinnvoll dort, wo RDP für viele Anwender bereitgestellt werden muss. - Zero-Trust-Zugangslösungen (ZTNA).
Der Client baut eine ausgehende Verbindung zu einem Broker auf, es ist überhaupt kein eingehender Port mehr offen. Der sauberste, aber auch aufwendigste Weg. - Just-in-time-Freischaltung.
Der Zugang wird nur für ein definiertes Zeitfenster und eine definierte Quelladresse geöffnet – geeignet für Wartungszugänge von Dienstleistern.
Und unabhängig davon: Prüfen Sie regelmäßig, was Sie tatsächlich veröffentlichen. Nicht anhand der Dokumentation, sondern von außen. Eine Portfreigabe, von der niemand mehr weiß, ist der Normalfall, nicht die Ausnahme.
2. Ein Alarm, den keiner liest, ist kein Schutz
Der Defender hat funktioniert. Trotzdem ist der Angriff durchgelaufen, weil die Meldung in einer Konsole landete, die niemand geöffnet hatte.
Sicherheitswerkzeuge erzeugen Meldungen. Meldungen sind kein Schutz – sie sind ein Angebot zu handeln. Wer dieses Angebot nicht annimmt, hat die Lizenzkosten bezahlt und den Nutzen verschenkt.
Konkret bedeutet das: Für jede sicherheitsrelevante Meldung muss geklärt sein, wo sie auflaufen, wer sie sieht, innerhalb welcher Zeit reagiert wird und was außerhalb der Geschäftszeiten passiert. Angriffe dieser Art beginnen erfahrungsgemäß gern am Freitagabend.
Wenn ein Unternehmen diese Fragen nicht aus eigener Kraft beantworten kann, ist das der Punkt, an dem ein SOC seinen Nutzen hat: nicht als zusätzliches Werkzeug, sondern als die Instanz, die hinsieht. In diesem Fall lagen zwischen dem ersten Signal und dem Schaden acht Tage.
3. Einheitliche lokale Administrator-Kennwörter beseitigen
Dasselbe lokale Administrator-Kennwort auf allen Servern verwandelt einen einzelnen kompromittierten Rechner in einen Generalschlüssel. Die Lösung ist seit Jahren verfügbar und kostet nichts: Windows LAPS vergibt für jedes System ein eigenes, automatisch rotierendes lokales Administrator-Kennwort und hinterlegt es in Entra ID oder im Active Directory.
Das ist die Maßnahme mit dem besten Verhältnis von Aufwand zu Wirkung in diesem gesamten Beitrag.
4. Das Auslesen von Anmeldedaten erschweren
Werkzeuge wie Mimikatz lesen Anmeldedaten aus dem Speicher des Prozesses lsass.exe. Dagegen gibt es wirksame Bordmittel:
- Credential Guard isoliert die Anmeldedaten virtualisierungsbasiert, sodss sie aus dem laufenden System heraus nicht mehr auslesbar sind.
- LSASS als geschützter Prozess (RunAsPPL) erschwert den Zugriff erheblich.
- Regeln zur Verringerung der Angriffsfläche (ASR) blockieren gezielt den Diebstahl von Anmeldedaten aus lsass.exe.
- Getrennte administrative Konten nach dem Tier-Modell verhindern, dass hochprivilegierte Anmeldedaten überhaupt auf einem gewöhnlichen Server landen.
ACHTUNG: Credential Guard und ASR-Regeln können ältere Anwendungen und Verwaltungswerkzeuge beeinträchtigen. Erst im Überwachungsmodus ausrollen, auswerten, dann erzwingen.
5. Backups so bauen, dass sie einen Angriff überstehen
Die Datensicherung hat in diesem Fall zufällig überlebt. Verlassen sollte man sich darauf nicht. Was ein Backup gegen Ransomware widerstandsfähig macht:
- Nicht in der Domäne.
Das Backup-System darf nicht mit denselben Anmeldedaten erreichbar sein wie der Rest der Umgebung. - Eigene, einzigartige Zugangsdaten, idealerweise mit MFA auf der Verwaltungsoberfläche.
- Mindestens eine unveränderliche oder physisch getrennte Kopie.
Unveränderlichkeit im Speichersystem, ein Bandmedium im Schrank oder ein Cloud-Ziel mit Object Lock – Hauptsache, ein kompromittiertes Administratorkonto kann sie nicht löschen. - Regelmäßige Rückspieltests.
Eine Sicherung, aus der noch nie wiederhergestellt wurde, ist eine Vermutung, kein Backup. - Die 3-2-1-1-0-Regel als Orientierung:
drei Kopien, zwei Medientypen, eine außer Haus, eine unveränderlich oder offline, null Fehler beim Rückspieltest.
Wiederaufbau: rote und grüne Zone
Am Ende dieses Falls stand eine unbequeme Empfehlung, die aus der forensischen Bewertung folgte. Helfen ließ sich an dieser Stelle wenig – nicht, weil die Wiederherstellung technisch unmöglich gewesen wäre, sondern weil in der gewachsenen Umgebung so viele strukturelle Probleme zusammenkamen, dass eine bloße Rücksicherung den Zustand von vor dem Angriff wiederhergestellt hätte. Also genau den Zustand, der den Angriff ermöglicht hat.
Die Empfehlung lautete deshalb: Wiederherstellung in einer roten Zone, Neuaufbau in einer grünen Zone.
Die rote Zone ist ein streng abgeschottetes Netzsegment ohne Verbindung zum künftigen Produktivnetz und ohne Internetzugang. Dorthin werden die betroffenen Systeme zurückgesichert. Sie dient zwei Zwecken: Daten herausholen und nachvollziehen, wie die Umgebung konfiguriert war. Sie ist ausdrücklich kein Produktivbetrieb.
Die grüne Zone ist die neu aufgebaute Umgebung: frische Systeme, neue Domäne, neue Zugangsdaten, von Anfang an mit den Maßnahmen, die vorher gefehlt haben. Aus der roten Zone wandern ausschließlich Daten dorthin – keine Systeme, keine Konfigurationen, keine Konten und schon gar keine ausführbaren Dateien unbekannter Herkunft.
Das ist aufwendig und teuer, und kein Geschäftsführer hört es gern. Die Alternative ist allerdings, eine Umgebung weiterzubetreiben, von der man nicht sagen kann, ob der Angreifer noch darin sitzt.
Für uns blieb an dieser Stelle nur noch das Aufräumen des Schlachtfelds. Genau das ist die Position, in die man nicht kommen möchte und der Grund, warum dieser Beitrag existiert.
Technische Einordnung und relevante Standards
Referenzen und Compliance-Einordnung
Compliance-seitig berührt der Fall unter anderem ISO/IEC 27001:2022, Anhang A: 8.13 (Datensicherung), 8.20 und 8.21 (Netzwerksicherheit und Sicherheit von Netzwerkdiensten), 8.16 (Überwachungsaktivitäten) sowie 5.7 (Bedrohungsinformationen). Im BSI-IT-Grundschutz sind insbesondere der Baustein zum Datensicherungskonzept (CON.3) und die Netzbausteine einschlägig. Für Unternehmen im NIS2-Anwendungsbereich fallen sowohl die Zugriffskontrolle als auch die Behandlung von Sicherheitsvorfällen unter die Maßnahmen nach Art. 21, hinzu kommen Meldepflichten. Datenschutzrechtlich ist bei betroffenen personenbezogenen Daten Art. 33 DSGVO maßgeblich. Die beobachteten Techniken nach MITRE ATT&CK:
| Technik | ATT&CK-ID |
|---|---|
| External Remote Services | T1133 |
| Valid Accounts | T1078 |
| Brute Force: Password Guessing | T1110.001 |
| OS Credential Dumping: LSASS Memory | T1003.001 |
| Remote Services: Remote Desktop Protocol | T1021.001 |
| Impair Defenses | T1562 |
| Inhibit System Recovery | T1490 |
| Data Encrypted for Impact | T1486 |
Fazit
Dieser Angriff war weder raffiniert noch neu. Er nutzte einen offenen Standardport, gültige Zugangsdaten, ein frei verfügbares Werkzeug und ein einheitliches lokales Administrator-Kennwort. Er hinterließ acht Tage lang Spuren in Protokollen, die auf den betroffenen Systemen ohnehin geschrieben wurden. Und er wurde von der vorhandenen Schutzsoftware korrekt erkannt.
Gescheitert ist die Verteidigung nicht an fehlender Technik, sondern an drei Entscheidungen: einen Fernwartungszugang ins Internet zu stellen, überall dasselbe Kennwort zu verwenden und die Meldungen der eigenen Sicherheitswerkzeuge nicht zu lesen.
Alle drei sind ohne Investition korrigierbar. Die vierte Entscheidung – jemanden zu haben, der auf die Alarme schaut – kostet Geld. Sie ist immer noch günstiger als ein Wiederaufbau in einer grünen Zone.
Wenn Sie nicht sicher sagen können, welche Dienste Ihres Unternehmens gerade aus dem Internet erreichbar sind oder wo Ihre Sicherheitsmeldungen auflaufen: Sprechen Sie uns an. Beides lässt sich in kurzer Zeit klären.
