Ransomware im Krankenhaus: Warum der Notfallplan wichtiger ist als jede Firewall

Im Februar 2024 legte ein einziger Ransomware-Angriff (Schadsoftware, die Dateien verschlüsselt und für die Freigabe Lösegeld verlangt) die Patientenakten-Systeme von mehr als hundert rumänischen Krankenhäusern innerhalb eines Tages lahm. Ärztinnen und Ärzte griffen wieder zu Stift und Papier, Laboranfragen wanderten per Hand zwischen den Abteilungen, Apotheken füllten Bestellungen nach handschriftlichen Notizen aus. Es gab keine gemeldeten Todesfälle, und die meisten Kliniken liefen nach etwa einer Woche wieder normal. Genau dieser ruhige Ausgang, nicht ein katastrophaler, macht den Fall lehrreich: Incident Response im Krankenhaus, also die organisierte Reaktion auf einen laufenden Angriff, entscheidet sich seltener daran, ob man den Angriff verhindert, als daran, was in den Stunden und Wochen danach passiert.

Was Incident Response wirklich bedeutet

Prävention und Incident Response lösen zwei unterschiedliche Probleme, und ein Krankenhaus, das im einen gut ist, ist es im anderen nicht automatisch auch. Prävention will den Angreifer draußen halten: Software patchen, das Netzwerk segmentieren, Personal für Phishing-Mails sensibilisieren. Incident Response geht von einer anderen Annahme aus, nämlich dass der Angreifer bereits drin ist. Die Fragen sind dann enger gefasst: Lassen sich betroffene Systeme schnell genug isolieren, damit sich der Schaden nicht weiter ausbreitet? Kann man aus dem Backup wiederherstellen, statt mit dem Angreifer zu verhandeln? Wie läuft die Patientenversorgung weiter, während die Rechner stillstehen? Und sobald der sichtbare Ausfall vorbei ist: Wie lange dauert der unsichtbare Teil der Erholung, also das Nachholen von allem, was sich während der Blackout-Phase angestaut hat?

Rumäniens Krankenhäuser beantworten alle vier Fragen gut, und genau deshalb lohnt sich der genaue Blick, nicht nur die Schlagzeile. Der Angriff selbst war nichts Besonderes: veraltete Software, eine Kriminellen-Gruppe, die es aufs Geld abgesehen hatte, und ein gemeinsam genutztes System, das einem einzigen Einbruch eine breite Reichweite verschaffte. Ungewöhnlich war die Reaktion, die folgte, aufgebaut Monate bevor irgendjemand von einem bevorstehenden Angriff wusste.

Was in Rumäniens Krankenhäusern geschah

Der Angriff begann an einem Kinderkrankenhaus in Pitești, an einem Samstag, dem 10. Februar 2024, als das Personal feststellte, dass Patientenakten plötzlich verschlüsselt und unlesbar waren. In den folgenden zwei Tagen griff er auf Dutzende weitere Einrichtungen über, die dieselbe Software nutzten: das Hipocrate Information System, ein Klinikinformationssystem eines Anbieters aus Bukarest namens Romanian Soft Company, das Aufnahmen, Laborergebnisse, Apothekenbestellungen und Abrechnung für einen Großteil der rumänischen Krankenhausbetten abwickelt. Weil so viele Kliniken an derselben Plattform hingen, breitete sich die Ransomware schneller aus, als die IT-Abteilung eines einzelnen Krankenhauses allein hätte reagieren können. Als Rumäniens nationale Cybersicherheitsbehörde DNSC den Schaden fertig eingeschätzt hatte, waren bei 26 Krankenhäusern tatsächlich Daten verschlüsselt, und rund 79 weitere waren vorsorglich vom Internet getrennt worden, bevor die Ransomware sie erreichen konnte. Zusammen ergibt das die vielzitierte Zahl von “100 Krankenhäusern”: eine Mischung aus getroffenen und vorsorglich abgeschalteten Einrichtungen.

Das Werkzeug hinter dem Angriff war ein Ransomware-Stamm namens Backmydata, eine Variante der älteren Ransomware-Familie Phobos, die seit Jahren unter kriminellen Gruppen kursiert. Die Angreifer forderten 3,5 Bitcoin, je nach Wechselkurs zum Zeitpunkt der Berichterstattung zwischen etwa 157.000 und 160.000 Euro. Diese Zahlen sind nützlich, um die Größenordnung einzuordnen, aber sie sind auch der Teil der Geschichte, der am schnellsten veraltet. Was in sechs Monaten oder sechs Jahren noch zählt, ist nicht der Bitcoin-Kurs. Es ist, was die Krankenhäuser als Nächstes taten.

Warum aus einem Einbruch ein Problem für hundert Kliniken wurde

Das waren nicht hundert einzelne Sicherheitspannen, die gleichzeitig passierten. Es war eine einzige gemeinsam genutzte Software, die auf jedes Krankenhaus überschwappte, das an sie angeschlossen war, ganz gleich, wie gut sich das jeweilige IT-Team vorbereitet hatte.

Dieselbe Logik erklärt Angriffe auf die Software-Lieferkette, bei denen eine einzige kompromittierte Komponente still und leise jede Organisation erreicht, die sie installiert hat, ebenso wie den Trend zu Zero-Trust-Architektur, bei der die Verbindung zu einer gemeinsamen Plattform nicht automatisch weitreichenden Zugriff auf den Rest des Netzwerks gewähren soll. Keine der beiden Ideen hätte diesen konkreten Angriff verhindert, aber beide zeigen dieselbe Schwachstelle: Gemeinsam genutzte Infrastruktur bedeutet einen gemeinsamen Schadensradius.

Das Lösegeld, das niemand zahlte

Die rumänischen Behörden rieten über die DNSC öffentlich davon ab, Lösegeld zu zahlen, und niemand zahlte. Schon die Lösegeldforderung selbst brach mit einem ungeschriebenen Muster der Branche: Laut DNSC enthielt die Nachricht der Angreifer lediglich eine E-Mail-Adresse als Kontakt, ohne Gruppennamen, ohne Logo, ohne die Selbstinszenierung, mit der moderne Ransomware-Banden sonst für sich werben und Opfer unter Druck setzen. Die Gruppe hinter dem Angriff wurde nie öffentlich identifiziert, eine ungewöhnliche Lücke für einen Angriff dieser Größenordnung.

Ein Koordinator statt hundert Einzelkämpfer

Ein Teil dessen, was den Schaden begrenzte, passierte, bevor die meisten betroffenen Krankenhäuser überhaupt von ihrem Risiko wussten. Die DNSC traf als zentrale koordinierende Stelle die Entscheidung, rund 79 Gesundheitseinrichtungen vorsorglich vom Internet zu trennen, sobald das Ausmaß des Angriffs klar wurde. Das ist eine Entscheidung, die nur eine Instanz mit Befugnis über viele Krankenhäuser gleichzeitig schnell treffen kann. Das IT-Team eines einzelnen Krankenhauses, so kompetent es auch sein mag, kann eine benachbarte Einrichtung, über die es keine Befugnis hat, nicht einfach abschalten.

Das ist der Teil der Reaktion, der in Nachbetrachtungen selten auftaucht, weil er absichtlich unspektakulär ist: jemand mit der Befugnis, sektorweit zu handeln, und ein bereits vorhandener Plan dafür, was zu tun ist, wenn ein gemeinsam genutztes System kompromittiert wird, statt Dutzender Krankenhäuser, die parallel dieselbe Notlage entdecken und improvisieren.

Das Backup, das tatsächlich funktionierte

Der Grund, warum die rumänischen Behörden von einer Zahlung abraten konnten und die Krankenhäuser diesem Rat auch folgten, läuft auf eine nüchterne Tatsache hinaus: Die meisten betroffenen Krankenhäuser hatten aktuelle Backups, die tatsächlich getestet worden waren und sich wiederherstellen ließen. Die DNSC nannte genau diese Backups als Grund dafür, dass die Systeme wieder liefen, ohne dass jemand mit den Angreifern verhandeln musste.

Ein Backup, das nur auf dem Papier einer IT-Richtlinie existiert, ist etwas anderes als eines, das unter Druck eingeübt und als funktionsfähig bestätigt wurde, und diese Lücke bleibt meist unsichtbar, bis genau der Tag kommt, an dem sie zählt.

Stift und Papier haben noch eine Aufgabe

Während die digitalen Systeme ausfielen, improvisierte das Personal nicht. Es griff auf handschriftliche Aufnahmen, Laboranfragen und Apothekenbestellungen zurück, einen manuellen Notbetrieb, der schon vor dem Angriff aufgebaut und geübt worden war, nicht im Moment erfunden. Dieser Unterschied ist entscheidend: Ein eingeübter Rückfallplan lässt ein Krankenhaus in reduziertem Tempo weiterlaufen, während ein improvisierter genau dann Fehler produziert, wenn Patientinnen und Patienten sie am wenigsten verkraften können.

Mit der Rückkehr der Rechner endete die Papier-Ära noch nicht. Das Nacherfassen wochenlanger handschriftlicher Aufzeichnungen in den digitalen Systemen dauerte deutlich länger, als die Krankenhäuser selbst in den Normalbetrieb zurückzuholen, was in etwa fünf Tagen gelang. Die sichtbare Erholung und die unsichtbare laufen auf unterschiedlichen Zeitachsen, und Organisationen, die nur die erste einplanen, werden von der zweiten meist überrascht.

Was Rumäniens Ausgang anders machte

Zwei andere gut dokumentierte Cyberangriffe auf Krankenhäuser liefern einen aufschlussreichen Vergleich. Der WannaCry-Angriff 2017 auf den britischen Gesundheitsdienst NHS störte Dutzende Klinikverbünde und führte zu Tausenden abgesagten Terminen, war aber ein unkontrolliert im Internet wütender Wurm statt eines gezielt auf Krankenhäuser gerichteten Angriffs, und es gibt keinen bestätigten Zusammenhang mit einem Todesfall. Der Angriff 2024 auf Synnovis, einen Labordienstleister für Londoner Kliniken, war gezielter und in seinen Folgen schwerwiegender: Eine Untersuchung des King’s College Hospital NHS Trust aus dem Jahr 2025 kam zu dem Schluss, dass die Störung, vor allem durch verzögerte Bluttest-Ergebnisse, zum Tod eines Patienten beitrug, der erste öffentlich bestätigte Fall in Großbritannien, bei dem ein Cyberangriff zu einem Todesfall beitrug.

Rumäniens Vorfall liegt in der Größenordnung zwischen diesen beiden, hebt sich im Ausgang aber deutlich ab. Es gab keine gemeldeten Todesfälle, und der Normalbetrieb kehrte binnen Tagen zurück, nicht erst nach Wochen. Die eingesetzte Technik, von der Stange gekaufte Ransomware gegen veraltete oder unsegmentierte Systeme, war weder deutlich fortschrittlicher noch primitiver als in den beiden anderen Fällen. Der Unterschied lag in der Vorbereitung: getestete Backups, eine nationale Stelle mit einem eingespielten Ablaufplan für die Koordination, und Personal, das bereits wusste, wie man ein Krankenhaus auf Papier betreibt.

Häufig gestellte Fragen

Was umfasst die Reaktion auf einen Ransomware-Angriff im Krankenhaus wirklich?

Es ist die Summe der Entscheidungen und Maßnahmen, die ein Krankenhaus trifft, sobald ein Angriff bereits läuft oder entdeckt wurde: betroffene Systeme isolieren, entscheiden, ob aus dem Backup wiederhergestellt oder verhandelt wird, die Patientenversorgung über manuelle Prozesse am Laufen halten und sich mit externen Behörden abstimmen. Das ist ein eigenständiges Problem, getrennt von der Prävention, und wer im einen gut ist, ist es im anderen nicht automatisch auch.

Warum werden Krankenhäuser so oft zum Ziel von Ransomware?

Krankenhäuser laufen auf gemeinsam genutzten, vernetzten Systemen, die rund um die Uhr verfügbar sein müssen, was einen Ausfall für die Patientenversorgung besonders schmerzhaft macht und den Druck erhöht, schnell wiederherzustellen. Viele Kliniken setzen zudem auf jahrzehntealte Software, die sich nicht ersetzen lässt, ohne die Versorgung zu unterbrechen, wodurch bekannte Schwachstellen länger ungepatcht bleiben als in anderen Branchen.

Sollte ein Krankenhaus jemals Lösegeld zahlen?

In diesem Fall empfahl die DNSC, nicht zu zahlen, und die Krankenhäuser folgten dem Rat, weil ihre Backups eine Erholung ohne Zahlung ermöglichten. Sicherheitsbehörden wie die US-amerikanische Cybersicherheitsbehörde CISA und das FBI raten grundsätzlich zum Gleichen, aus drei Gründen: Zahlen garantiert kein funktionierendes Entschlüsselungswerkzeug, es finanziert weitere Angriffe, und es setzt einen Anreiz, erneut zum Ziel zu werden. Die Entscheidung hängt in der Praxis fast immer daran, ob verlässliche Backups bereits existieren, weshalb deren vorheriges Testen wichtiger ist als die Zahlungsfrage selbst.

Wie lange dauert die Erholung eines Krankenhauses von Ransomware realistisch?

In Rumänien liefen die Krankenhäuser nach rund fünf Tagen wieder annähernd normal, aber das Nacherfassen des aufgelaufenen Papier-Rückstaus in die digitalen Systeme dauerte Wochen länger. Wie schnell sich ein Haus erholt, hängt weit stärker davon ab, ob die Backups aktuell und wiederherstellbar sind, als von der Schwere des Angriffs selbst.

Was kann ein Krankenhaus konkret zur Vorbereitung tun?

Die wiederkehrende Lehre aus Ransomware-Fällen im Gesundheitswesen, nicht nur aus diesem, lautet: regelmäßig getestete und nachweislich wiederherstellbare Backups vorhalten, einen eingeübten manuellen Rückfallplan, den das Personal tatsächlich geübt hat und nicht nur gelesen, sowie im Voraus wissen, welche externe Behörde oder welches Incident-Response-Team im Ernstfall anzurufen ist. Nichts davon erfordert exotische Technik, was mit erklärt, warum es so oft trotzdem fehlt.

Die Lehre für IT-Teams im Krankenhaus

Das Bemerkenswerteste an Rumäniens Ausgang ist, wie wenig davon abhing, den Angriff zu stoppen. Die Krankenhäuser wurden trotzdem gehackt, die Lösegeldforderung kam trotzdem an, und die gemeinsame Software war trotzdem kompromittiert. Was die Sache davor bewahrte, zur Tragödie zu werden, war Monate zuvor entschieden worden: ob Backups getestet waren, ob eine nationale Behörde einen einsatzbereiten Ablaufplan zur Koordination hatte, und ob das Personal wirklich geübt hatte, ein Krankenhaus auf Papier zu betreiben. Wer das als Geschichte über Ransomware-Software liest, verpasst den Punkt. Es ist eine Geschichte darüber, welche Entscheidungen vor dem Angriff getroffen werden, denn sobald der Angriff beginnt, sind das die einzigen Entscheidungen, die noch übrig sind.