Ransomware: Wenn Daten zum Druckmittel werden

Einleitung

Ransomware wurde in vielen Unternehmen lange vor allem als Verfügbarkeitsrisiko wahrgenommen: Systeme werden verschlüsselt, der Betrieb steht, und irgendwo fordert jemand Lösegeld. Inzwischen hat sich das Geschäftsmodell der Angreifer jedoch grundlegend weiterentwickelt. Immer häufiger geht es nicht mehr nur darum, Daten unzugänglich zu machen, sondern sie gezielt zu exfiltrieren und mit ihrer Veröffentlichung zu drohen – auch bei besonders sensiblen personenbezogenen Daten von Kundinnen und Kunden, Patienten oder Mitarbeitenden.

In solchen Situationen taucht in Diskussionen schnell die gleiche Frage auf: „Sollten wir nicht zahlen, um unsere Betroffenen zu schützen?“ Meine klare Antwort ist: NEIN.
In diesem Artikel zeige ich, wie Erpressung mit Datenveröffentlichung technisch und organisatorisch abläuft, warum Lösegeldzahlungen weder Datenschutz noch Sicherheit garantieren und welche Maßnahmen tatsächlich helfen, Angriffe zu erschweren, früher zu erkennen und im Ernstfall verantwortungsvoll zu reagieren.

Worum es in diesem Artikel konkret geht:

• wie sich klassische Ransomware-Angriffe hin zu datengetriebenen Erpressungsmodellen entwickelt haben
• welche technischen und organisatorischen Maßnahmen helfen, Exfiltration zu erschweren und früher zu erkennen
• warum Lösegeldzahlungen aus Datenschutz‑, Sicherheits‑ und Governance-Perspektive keine verlässliche Lösung sind
• was Organisationen tun können, um im Ernstfall strukturiert, transparent und verantwortungsvoll zu reagieren

Was ist eigentlich Ransomware?

Ransomware ist eine Form von Schadsoftware, die darauf ausgelegt ist, Unternehmen oder Einzelpersonen zu erpressen. Klassische Varianten verschlüsseln Daten oder ganze Systeme und fordern ein Lösegeld, damit die Betroffenen wieder Zugriff erhalten. Moderne Ransomware-Gruppen gehen inzwischen weiter: Sie kombinieren Verschlüsselung mit Datendiebstahl und drohen zusätzlich damit, die erbeuteten Informationen zu veröffentlichen oder weiterzuverkaufen. Aus technischer Sicht handelt es sich dabei meist um gezielte Angriffe mit mehreren Phasen – vom initialen Zugriff über die Ausbreitung im Netzwerk bis hin zur Exfiltration großer Datenmengen und der anschließenden Erpressung.

Problemrahmen und Relevanz

Bei Erpressung mit Datenveröffentlichung geht es um einen Vertrauensbruch gegenüber den betroffenen Personen, Mitarbeitenden, Geschäftspartnern und der Öffentlichkeit. Sie ist daher weit mehr als ein IT-Problem: Betroffen sind ebenso Datenschutz, Compliance, Reputation und die Frage, wie gut eine Organisation auf den Schutz anvertrauter Daten vorbereitet ist.

Häufig unterschätzt wird, dass Erpressung mit Datenveröffentlichung nicht nur große, prominente Ziele trifft. Gerade kleinere und mittlere Unternehmen, Praxen, Kanzleien oder kommunale Einrichtungen geraten ins Visier: Die Datenbestände sind hochsensibel, die Ressourcen für professionelle IT-Sicherheit aber begrenzt. Für Angreifer ist das eine attraktive Kombination – ausreichend verwertbare Daten bei vergleichsweise geringem Widerstand.

Einmal abgeflossene Daten lassen sich beliebig kopieren, anreichern und in vielen Kontexten wiederverwenden – im Untergrundhandel, für Social Engineering, für erneute Erpressungen oder die direkte Ansprache der Betroffenen. Genau das macht das Modell so profitabel und erklärt, warum sich entsprechende Vorfälle inzwischen regelmäßig in Berichten von Sicherheitsbehörden und Incident-Response-Teams wiederfinden.

Funktionsweise der Angriffe

In der Praxis verlaufen diese Angriffe selten als „ein großer Hack“, sondern als Abfolge mehrerer Phasen:

• Initialzugriff: Ausnutzung unsicherer Remote-Zugänge, ungepatchter Dienste oder kompromittierter Zugangsdaten (z. B. durch Phishing oder schwach geschützte Partnerzugänge). In dieser Phase geht es vor allem darum, einen ersten stabilen Zugangspunkt zu schaffen, über den sich die Angreifer später weiter vorarbeiten können – möglichst ohne sofort aufzufallen.
• Seitwärtsbewegung & Erkundung: Schrittweise Rechteausweitung, Ausbreitung im Netzwerk und Identifikation interessanter Systeme und Datenquellen. Angreifer versuchen, von normalen Benutzerkonten zu privilegierten Konten zu wechseln, in Server- oder Admin-Netze zu gelangen und dabei ein genaues Bild der Umgebung zu gewinnen: Wo liegen Dateiserver, Datenbanken, E-Mail-Systeme, Backups oder Cloud-Speicher mit besonders sensiblen Informationen?
• Exfiltration: Kopieren größerer Datenmengen und Abfluss über scheinbar legitime Kanäle (z. B. verschlüsselter Web-Traffic, VPN, Admin-Tools), möglichst gut im Normalverkehr getarnt. Häufig werden dazu Bordmittel des Betriebssystems oder gängige Administrationswerkzeuge genutzt, damit die Aktivitäten wie normale Administration oder Datensynchronisation aussehen. Ziel ist, möglichst viel verwertbares Material aus der Umgebung herauszubekommen, ohne von Monitoring oder Anomalieerkennung gestoppt zu werden.
• Erpressung: Kontaktaufnahme mit der Organisation, Präsentation von „Beweismustern“, Fristen, Lösegeldforderung und zusätzliche Drohkulisse (Veröffentlichung, weitere Angriffe). Typischerweise legen die Täter Screenshots, Dateilisten oder Datenausschnitte vor, um ihre Drohung zu untermauern, und drohen mit Veröffentlichung im Darknet, Weitergabe an Medien oder direkter Ansprache der Betroffenen. Oft wird dieser Druck noch verstärkt, indem gleichzeitig Systeme verschlüsselt oder zusätzliche Angriffe (z. B. DDoS) gestartet werden – die bekannten Double- oder Multi-Extortion-Szenarien.

Für die Verteidigung ist es entscheidend, diese Angriffskette zu verstehen und in jeder Phase gezielt anzusetzen. Entscheidend ist: Der Schaden entsteht bereits mit dem unbemerkten Abfluss sensibler Daten, nicht erst mit der Erpressungs-Mail – deshalb darf sich die Diskussion nicht auf „zahlen oder nicht zahlen“ verengen, sondern muss alle Phasen des Angriffs in den Blick nehmen.

Präventive Maßnahmen: Angriffe erschweren, Daten schützen

Verantwortungsvolle Vorbereitung erschwert Angreifern sowohl den Zugriff auf sensible Daten als auch deren Abfluss. Die wichtigsten Maßnahmen lassen sich in einige klare Bausteine gliedern:

Angriffsfläche reduzieren:

• Exponierte Systeme (VPN, E-Mail-Gateways, Webanwendungen, Appliances) konsequent härten und zeitnah patchen.
• Regelmäßige, risikobasierte Schwachstellenscans und – wo es sinnvoll ist – Penetrationstests durchführen, um nicht nur „auf dem Papier“ sicher zu sein.
• Alte, nicht mehr benötigte Dienste, Schnittstellen und Accounts konsequent abschalten, statt sie „für alle Fälle“ liegen zu lassen.
• Standardkonfigurationen und Default-Credentials systematisch beseitigen, insbesondere bei Appliances und OT-/IoT-Systemen.

Netzwerk sinnvoll segmentieren:

• Trennung von User-, Server- und Admin-Netzen, statt ein großes, flaches Netz, in dem man sich frei bewegen kann.
• Besonders sensible Systeme (z. B. mit Gesundheits-, Finanz- oder Personaldaten) in eigene, stärker geschützte Segmente legen.
• Zugriffe zwischen Segmenten nur so weit wie nötig erlauben, technisch erzwingen (Firewall/ACLs, Mikrosegmentierung) – alles andere bleibt standardmäßig zu.
• Remote-Zugriffe und Partneranbindungen über klar definierte, überwachte Übergabepunkte führen.

Identitäten und Berechtigungen im Griff haben:

• „Least Privilege“ ernst nehmen: Nur die Rechte vergeben, die jemand wirklich für seine Aufgabe braucht, und zeitlich begrenzen, wo möglich (Just-in-Time-Privilegien).
• Multi-Faktor-Authentisierung (MFA) überall dort verpflichtend machen, wo ein Konto besonders wertvoll ist: Remote-Zugänge, Admin-Konten, zentrale Cloud-Dienste, privilegierte SaaS-Anwendungen.
• Getrennte Admin-Konten nutzen, keine Dauer-Admins auf normalen Arbeitsrechnern, regelmäßige Reviews von Gruppenmitgliedschaften und privilegierten Rollen.
• Passwort- und Secret-Management professionell umsetzen (z. B. Passwortmanager, Rotation, Schutz technischer Accounts und API-Keys).

Robuste Backup- und Restore-Strategien:

Gute Backups verhindern keinen Datenabfluss, ermöglichen nach einem Angriff aber eine schnellere und kontrollierte Wiederherstellung, ohne durch verschlüsselte Systeme zusätzlich erpressbar zu werden.

„Gutes Backup“ bedeutet in der Praxis konkret – unabhängig von der Unternehmensgröße:

• Es existiert eine durchdachte Strategie (z. B. nach der 3‑2‑1‑Regel: mehrere Kopien, unterschiedliche Medien, mindestens ein Offsite‑Backup). In kleinen Unternehmen kann das eine Kombination aus lokalem Backup und einem getrennten Offsite‑Speicher sein; in größeren Umgebungen oft dedizierte Backup‑Appliances und getrennte Rechenzentrums‑ oder Cloud‑Standorte.
• Wo möglich, kommen unveränderbare Sicherungen (Immutable‑ oder WORM‑Backups) zum Einsatz, die nach dem Schreiben für einen definierten Zeitraum nicht mehr gelöscht oder überschrieben werden können. Damit wird es für Angreifer deutlich schwerer, im Rahmen eines Angriffs auch noch die Sicherungen zu kompromittieren.
• Backups werden regelmäßig getestet – nicht nur, ob sie „durchlaufen“, sondern ob sich Systeme und Geschäftsprozesse im Notfall wirklich wiederherstellen lassen. Bei sehr kleinen Umgebungen kann das ein geplanter Restore‑Test pro Quartal sein, bei größeren Organisationen gehören strukturierte Restore‑Tests in die Notfallvorsorge.
• Backup-Infrastruktur und -Zugänge sind mit eigenen administrativen Konten geschützt und logisch oder physisch vom Produktionsnetz getrennt. Mindestens eine Sicherungskopie wird offline, offsite oder unveränderbar gespeichert und ist aus der Produktivumgebung nicht direkt erreichbar. Dadurch können Angreifer Sicherungen nicht ohne Weiteres verschlüsseln, löschen oder manipulieren.

Datenabfluss erschweren (DLP & Egress-Kontrolle):

• Sensible Daten identifizieren und klassifizieren: Wo liegen welche Datentypen, wie schützenswert sind sie, wer darf tatsächlich darauf zugreifen?
• DLP-Funktionen auf Endpunkten, E-Mail-Gateways und Web-Proxys einsetzen, um auffällige Transfers zu markieren, zu protokollieren oder zu blocken.
• Ausgehenden Traffic (Egress) nicht pauschal „alles erlauben“, sondern bewusst steuern und überwachen: Welche Protokolle, welche Ziele, welche Datenmengen sind normal, welche nicht?
• Uploads zu Cloud-Diensten und File-Sharing-Plattformen regulieren und – wo notwendig – auf definierte, kontrollierte Kanäle begrenzen.

Datensparsamkeit und Datenhygiene:

• Nicht alles für immer aufbewahren: Löschkonzepte tatsächlich leben und Altlasten abbauen, statt Datenbestände unbegrenzt wachsen zu lassen.
• Besonders sensible Datensätze (z. B. bestimmte Gesundheits‑, Finanz‑ oder Identitätsdaten) zusätzlich absichern – etwa durch stärkere Verschlüsselung, Pseudonymisierung oder strengere Zugriffsbeschränkungen.
• Test- und Entwicklungsumgebungen nicht mit produktiven personenbezogenen Daten füttern, nur weil es „praktischer“ ist, sondern mit synthetischen oder anonymisierten Daten arbeiten.
• Datenhaltungen und Schatten-IT regelmäßig überprüfen, damit keine unkontrollierten Kopien sensibler Informationen entstehen.

Ein wichtiger Punkt ist: Prävention heißt nicht, dass danach nichts mehr passieren kann. Aber je konsequenter diese Basisthemen umgesetzt sind, desto kleiner wird die Angriffsfläche – und desto besser sind die Chancen, einen Angriff früh zu bemerken oder zumindest den Schaden zu begrenzen.

Detection & Incident Response: Früh merken, strukturiert handeln

So gut Prävention auch ist – einen hundertprozentigen Schutz gibt es nicht. Deshalb ist die zweite Säule genauso wichtig: Angriffe früh zu erkennen und im Ernstfall nicht im Chaos zu versinken. Genau das leisten saubere Detection-Mechanismen und ein geübtes Incident-Response-Vorgehen.

Voraussetzung für die Erkennung einer Datenexfiltration ist ausreichende Sichtbarkeit im eigenen Netzwerk und in angebundenen Cloud-Diensten. Dazu gehört ein zentrales Log-Management oder ein SIEM, in dem relevante Ereignisse zusammenlaufen – etwa Firewall- und Proxy-Logs, Anmeldeereignisse, Aktivitäten auf File-Servern und Datenbanken sowie Security-Events aus Endpoint- und Cloud-Sicherheitslösungen. Entscheidend ist nicht die Menge der Daten, sondern die Erkennung relevanter Anomalien.

Konkret geht es um Use Cases, die gezielt auf Datenabfluss und verdächtige Bewegungen zielen. Dazu zählen zum Beispiel:

• ungewöhnlich große Datenmengen, die in kurzer Zeit an externe Ziele übertragen werden.
• Verbindungen zu bislang unbekannten oder untypischen Zielen, insbesondere in Hochrisiko-Regionen oder zu frischen Domains.
• Massenzugriffe auf File-Shares oder Datenbanken, die nicht zum normalen Nutzungsmuster eines Kontos passen.
• Zugriffe oder Datenbewegungen zu ungewöhnlichen Zeiten, etwa mitten in der Nacht aus Accounts, die sonst tagsüber genutzt werden.
• wiederholte, fehlgeschlagene Zugriffsversuche auf sensible Speicherorte oder Backup-Systeme.

Ergänzend benötigen Endpoints und Server EDR- oder XDR-Lösungen, die auch den Missbrauch legitimer Werkzeuge erkennen. Dazu gehören etwa ungewöhnliche Archivierungen, verschleierte PowerShell-Skripte oder große Datenübertragungen mit Werkzeugen wie Rclone. Solche „Living off the Land“-Aktivitäten sollten durch EDR- und SIEM-Use-Cases anhand auffälliger Prozessketten, Datenmengen und externer Ziele erkannt werden.

All diese Technik nützt aber wenig, wenn unklar ist, was bei einem Alarm passieren soll. Ein klar definierter Incident-Response-Plan ist deshalb Pflicht – gerade in Organisationen mit sensiblen Daten. Darin sollte festgelegt sein, wer im Ernstfall welche Rolle übernimmt, wie eskaliert wird, welche internen und externen Ansprechpartner eingebunden werden (z. B. Datenschutz, Rechtsabteilung, Forensik, Management, Kommunikation) und wie Entscheidungen dokumentiert werden. Wichtig ist, dass dieser Plan nicht nur als PDF in einem Ordner liegt, sondern regelmäßig geübt wird – etwa in Form von Tabletop-Übungen mit realistischen Szenarien, in denen auch unbequeme Entscheidungen (z. B. Systemabschaltungen, Meldepflichten, externe Kommunikation) durchgespielt werden.

Steht der Verdacht auf Datenexfiltration im Raum, geht es im Kern um vier technische Schritte:

• Eindämmung (Containment): Betroffene Systeme sofort isolieren. Besteht der Verdacht auf eine weitere Ausbreitung, müssen auch potenziell gefährdete Netzwerksegmente, Abteilungsnetze oder Standorte kontrolliert voneinander getrennt werden. Auffällige Benutzerkonten sind zu sperren oder deren Zugangsdaten zurückzusetzen; vermutete Exfiltrations- und Steuerungskanäle müssen blockiert werden. Ziel ist, weiteren Schaden zu begrenzen, ohne vorschnell relevante Spuren zu zerstören.
• Schutz der Backups: Backup-Systeme, Repositories, administrative Zugänge und Replikationsverbindungen unverzüglich überprüfen und bei einem möglichen Zugriff der Angreifer kontrolliert vom kompromittierten Netz trennen. Automatische Synchronisationen oder Replikationen sind gegebenenfalls zu stoppen, damit verschlüsselte oder manipulierte Daten nicht in saubere Sicherungen übernommen werden. Bestehende Sicherungen dürfen nicht überschrieben oder unkontrolliert verändert werden.
• Forensik und Scope-Bestimmung: Relevante Logs und Artefakte sichern, um nachzuvollziehen, wie die Angreifer hineingekommen sind, wie lange sie im System waren und auf welche Daten sie mit hoher Wahrscheinlichkeit zugegriffen haben. Diese Erkenntnisse sind sowohl für technische Härtung als auch für die datenschutzrechtliche Bewertung und eventuelle Meldungen entscheidend.
• Wiederherstellung und Härtung: Kompromittierte Systeme bereinigen oder sauber neu aufsetzen, die genutzten Schwachstellen schließen, Konfigurationen nachschärfen und die gewonnenen Erkenntnisse in Monitoring, Use Cases und Schulungen einfließen lassen.

Ein guter Indikator für Reife ist nicht, ob es „keine Vorfälle“ gibt, sondern wie professionell mit einem Vorfall umgegangen wird. Organisationen, die hier vorbereitet sind, geraten im Ernstfall weniger in Panik, treffen weniger Kurzschlussentscheidungen (einschließlich vorschneller Lösegeldzahlungen) und können deutlich besser erklären, was passiert ist und was sie daraus gelernt haben.

Governance, Recht & Transparenz: Verantwortung zeigen, nicht verstecken

Sobald sensible Daten betroffen sein könnten, müssen neben der technischen Reaktion auch Datenschutz, Recht, Management und Kommunikation eingebunden werden. Rollen, Entscheidungswege und Zuständigkeiten sollten bereits vor einem Vorfall eindeutig festgelegt sein. Die Datenschutzbeauftragten bewerten dabei insbesondere die Risiken für Betroffene, während die Rechtsabteilung Melde-, Haftungs- und Sanktionsfragen prüft.

Praktisch bedeutet das:

• innerhalb kurzer Zeit (Stunden, nicht Wochen) eine erste Einschätzung treffen, ob und welche personenbezogenen Daten und gegebenenfalls kritischen Dienste betroffen sind.
• gegebenenfalls die zuständige Datenschutzaufsichtsbehörde binnen 72 Stunden informieren – auch wenn noch nicht alle Details geklärt sind, mit der Option, nachzumelden.
• sofern NIS2-relevant: erhebliche Sicherheitsvorfälle zusätzlich der zuständigen NIS2-/BSI-Stelle melden, idealerweise im gleichen abgestimmten Prozess.
• bei hohem Risiko für die Betroffenen diese direkt informieren, in verständlicher Form und ohne juristische Schutzformeln, die am Kern vorbeigehen.

Sobald eine Datenexfiltration bestätigt oder sehr wahrscheinlich ist, liegt in aller Regel eine meldepflichtige Datenschutzverletzung vor – auch wenn die Daten noch nicht im Darknet aufgetaucht sind. Die typischen „Beweismuster“ der Angreifer (Daten-Samples, Screenshots, Dateilisten) sind deshalb ein ernst zu nehmender Hinweis und kein Grund, abzuwarten, „ob wirklich etwas veröffentlicht wird“.

Parallel dazu stellt sich die Frage, wie offen man insgesamt mit dem Vorfall umgeht. Versuche, Vorfälle kleinzureden oder zu verschweigen, werden mittelfristig fast immer teurer – durch Vertrauensverlust, interne Konflikte oder eine spätere, unkontrollierte Veröffentlichung durch Angreifer oder Dritte. Transparenz bedeutet dabei nicht, jedes technische Detail nach außen zu tragen, sondern die wesentlichen Punkte klar zu benennen:

• Was ist grundsätzlich passiert?
• Welche Arten von Daten sind betroffen?
• Welche Risiken ergeben sich daraus für die Betroffenen?
• Welche Maßnahmen wurden ergriffen, um den Schaden zu begrenzen und Wiederholungen zu vermeiden?

Ein weiterer wichtiger Aspekt in diesem Kontext ist eine klare Haltung zu Lösegeldzahlungen. Wird diese Frage erst im akuten Stressfall diskutiert, ist die Gefahr groß, dass Emotionen, politischer Druck oder Angst vor Reputationsschäden zu Kurzschlussentscheidungen führen. Lösegeldzahlungen bieten weder eine verlässliche Entschlüsselung noch die Garantie, dass gestohlene Daten gelöscht oder nicht veröffentlicht werden. Organisationen sollten deshalb bereits vor einem Vorfall eine klare Grundhaltung festlegen. Abweichungen dürfen allenfalls in extremen Ausnahmefällen nach dokumentierter technischer, rechtlicher und organisatorischer Prüfung erwogen werden.

Wenn die Frage „zahlen oder nicht zahlen“ im Raum steht, sollten mindestens diese Dimensionen strukturiert betrachtet werden:

• rechtliche Risiken (z. B. Sanktionsrecht, Regelungen zur Terrorismusfinanzierung, aufsichtsrechtliche Bewertung, Haftungsfragen).
• technische Lage (Backups, Wiederanlaufszenarien, verbleibende Angriffswege, Grad der eigenen Kontrolle über die Umgebung).
• Risiko für Betroffene (Art und Sensibilität der Daten, potenzielle Missbrauchsszenarien, bereits eingetretene oder absehbare Schäden, Informationsstand der Betroffenen).
• systemische Folgen (Signalwirkung gegenüber Angreifern, Stabilisierung des Geschäftsmodells, mittelbare Risiken für andere Organisationen und Betroffene).

Selbst nach einer Zahlung lässt sich nicht überprüfen, ob Datenkopien tatsächlich gelöscht wurden oder später erneut verwendet werden. Gleichzeitig finanziert jede Zahlung weitere Angriffe und kann je nach Tätergruppe, Zahlungsweg oder beteiligtem Land sanktions- und strafrechtliche Risiken auslösen.

Am Ende geht es bei Governance, Recht und Transparenz um mehr als um Compliance-Häkchen. Es geht darum, ob eine Organisation glaubwürdig vermitteln kann: Wir wissen, was passiert ist, wir nehmen die Auswirkungen ernst, wir informieren ehrlich und wir leiten konkrete Verbesserungen ab. Wer das schafft, wird selbst nach einem schweren Vorfall eher als verantwortungsvoll wahrgenommen – auch wenn der Angriff selbst vielleicht nicht vollständig zu verhindern gewesen wäre.

Fazit

Entscheidend ist nicht das schnelle „Freikaufen“, sondern die Qualität von Vorbereitung, Reaktion und Transparenz. Lösegeldzahlungen bieten keine Garantie für Datenschutz oder Sicherheit, sie finanzieren Kriminalität und erhöhen das Risiko für weitere Angriffe auf andere Organisationen und Betroffene. Verantwortungsvolle Sicherheitsarbeit zeigt sich darin, Angriffe so gut wie möglich zu verhindern, Vorfälle früh zu erkennen, offen mit Betroffenen und Aufsichtsbehörden zu kommunizieren und aus jedem Vorfall konsequent zu lernen. Lösegeld kann man zahlen – Vertrauen, Integrität und Lernbereitschaft nicht.