Sauberer Wiederherstellungspunkt nach Ransomware: Warum nicht jedes Backup vertrauenswürdig ist
Der Cyberangriff auf die Berliner Landesverwaltung zeigt in diesen Tagen exemplarisch, wie lange ein Angreifer unbemerkt in einem Netzwerk aktiv sein kann, bevor ein Vorfall überhaupt auffällt. Nach aktuellem Kenntnisstand hatten sich die Täter bereits ab dem 7. August Zugang zu den Systemen zweier Senatsverwaltungen verschafft, entdeckt und isoliert wurden die betroffenen Bereiche jedoch erst am 14. August – aufgefallen war der Vorfall zudem eher zufällig, weil der zentrale IT-Dienstleister ITDZ Berlin ungewöhnliche Netzwerkaktivität bemerkte, die eigentlich nicht in seinen Zuständigkeitsbereich fiel (Borns IT- und Windows-Blog). Am 1. September bestätigte die Berliner Senatsverwaltung offiziell, dass bei dem Angriff auch Passwörter im Klartext abgeflossen sind, gespeichert in gewöhnlichen Office-Dateien einzelner Fachverfahren (heise online). Seither werden rund 12.000 Systeme im Landesnetz durchgehend gescannt, um weitere Kompromittierungen auszuschließen.
Diese Konstellation – ein Angreifer, der über Tage oder Wochen unentdeckt bleibt, bevor Schaden sichtbar wird – stellt Unternehmen und Behörden vor eine Frage, die in der öffentlichen Debatte um Ransomware oft zu kurz kommt: Wenn der genaue Zeitpunkt der ersten Kompromittierung erst im Nachhinein rekonstruiert werden kann, welcher Sicherungsstand eines Backups ist dann überhaupt noch vertrauenswürdig?
Inhaltsverzeichnis
Cyberangriff auf Berlin: Eine Woche unbemerkter Zugriff vor der Entdeckung
Der Fall Berlin macht die Problematik in mehrfacher Hinsicht sichtbar. Erstens lag zwischen dem eigentlichen Eindringen und der Isolierung der betroffenen Systeme eine Lücke von rund einer Woche – Zeit, in der sich Angreifer typischerweise nicht nur Zugriff verschaffen, sondern auch weitere Zugangsdaten sammeln, Berechtigungen ausweiten und sich in benachbarten Systemen festsetzen. Zweitens wurde der Vorfall nicht durch eine gezielte Überwachung der betroffenen Verwaltungen selbst entdeckt, sondern eher beiläufig durch einen externen Dienstleister. Drittens zeigt die Notwendigkeit, nachträglich 12.000 Systeme systematisch zu scannen, dass die Behörden selbst nach der akuten Reaktion nicht sicher wissen konnten, wie weit sich die Kompromittierung tatsächlich ausgebreitet hatte. Regierender Bürgermeister Kai Wegner erklärte öffentlich, das Land Berlin lasse sich nicht erpressen (Tagesspiegel) – die eigentliche technische Herausforderung, herauszufinden, ab welchem Zeitpunkt die Systeme wieder als vertrauenswürdig gelten können, bleibt davon jedoch unberührt.
Warum ein technisch funktionierender Restore einen sauberen Wiederherstellungspunkt nicht garantiert
Klassische Backup-Konzepte orientieren sich an Recovery Time Objective (RTO) und Recovery Point Objective (RPO) – also daran, wie schnell und mit wie viel Datenverlust eine Wiederherstellung erfolgen kann. Ob ein Restore-Prozess technisch zuverlässig funktioniert, ist eine eigene, wichtige Fragestellung, die regelmäßiges Recovery Testing beantwortet. Der vorliegende Fall wirft jedoch eine davon zu unterscheidende, vorgelagerte Frage auf: Selbst wenn ein Restore-Prozess technisch einwandfrei funktioniert, sagt das nichts darüber aus, ob der gewählte Wiederherstellungspunkt selbst noch unkompromittiert ist.
Im Berliner Fall lässt sich diese Lücke konkret nachvollziehen: Zwischen dem 7. August, dem nach heutigem Kenntnisstand frühesten Zugriffszeitpunkt, und dem 14. August, an dem die betroffenen Verwaltungen isoliert wurden, liegen sieben Tage. Jeder in diesem Zeitraum erstellte Sicherungsstand wäre nach klassischer RPO-Logik unauffällig – ein Restore auf den 10. oder 12. August hätte auf den ersten Blick als naheliegende, aktuelle Wahl gegolten. Tatsächlich hätte ein solcher Restore jedoch mit hoher Wahrscheinlichkeit dieselbe, bereits laufende Kompromittierung mit zurückgespielt.
Der Berliner Fall liefert dafür ein konkretes Beispiel: Die betroffenen Fachverfahren speicherten Passwortlisten im Klartext in gewöhnlichen Office-Dateien. Solche Dateien werden von Standard-Backup-Jobs routinemäßig mitgesichert, ohne dass ihr sicherheitskritischer Inhalt gesondert bewertet wird. Wurden diese Dateien bereits während der siebentägigen Kompromittierung ausgelesen, wäre ein Restore aus dieser Zeitspanne zwar formal „vor der Verschlüsselung“ – die betroffenen Zugangsdaten wären trotzdem bereits in den Händen der Angreifer, unabhängig vom gewählten Wiederherstellungspunkt.
Risiko Re-Infektion: Was ein falscher Wiederherstellungspunkt für Unternehmen bedeutet
Für betroffene Organisationen bedeutet das in der Praxis einen erheblichen Mehraufwand nach einem Vorfall. Statt einfach den jüngsten verfügbaren Sicherungsstand zurückzuspielen, muss zunächst forensisch geklärt werden, seit wann eine Kompromittierung tatsächlich bestand – ein Prozess, der Tage bis Wochen dauern kann und währenddessen den eigentlichen Wiederanlauf verzögert. Wird stattdessen vorschnell auf einen vermeintlich sicheren Stand zurückgegriffen, besteht das Risiko einer sogenannten Re-Infektion: Das System läuft zwar wieder, der Angreifer hat jedoch weiterhin Zugriff oder kann über zurückgespielte, aber kompromittierte Zugangsdaten erneut eindringen.
Diese Unsicherheit erhöht auch den Druck auf Kommunikations- und Meldeprozesse. Solange nicht klar ist, welche Systeme und welcher Zeitraum tatsächlich betroffen sind, lässt sich auch der Umfang einer möglichen Datenschutzverletzung nur vorläufig einschätzen – mit entsprechenden Folgen für die Bewertung nach DSGVO und für die interne wie externe Kommunikation.
Fünf Anforderungen an eine Recovery-Strategie, die saubere Wiederherstellungspunkte sicherstellt
Aus dieser Problematik ergeben sich mehrere Anforderungen an eine belastbare Recovery-Strategie:
Mehrere Wiederherstellungspunkte über einen längeren Zeitraum vorhalten. Wer nur die letzten ein bis zwei Sicherungsstände aufbewahrt, hat im Fall einer längeren unentdeckten Kompromittierung möglicherweise keinen sauberen Punkt mehr zur Verfügung, auf den zurückgegriffen werden kann.
Wiederherstellungspunkte vor dem Restore aktiv prüfen. Statt blind auf den jüngsten Stand zurückzugreifen, sollte ein Restore-Kandidat in einer isolierten Umgebung auf Auffälligkeiten wie unerwartete Prozesse, veränderte Konfigurationen oder eingebettete Schadsoftware untersucht werden, bevor er in die Produktivumgebung übernommen wird.
Regelmäßiges Recovery Testing als Voraussetzung, nicht als Ersatz. Ob ein Restore-Prozess technisch funktioniert, sollte über strukturiertes Recovery Testing laufend nachgewiesen werden. Diese Testung beantwortet jedoch nicht die Frage, ob der getestete Wiederherstellungspunkt selbst frei von Kompromittierung ist – beide Prüfungen sind notwendig, aber unterschiedlich.
Zugangsdaten und Berechtigungen bei jeder Wiederherstellung neu bewerten. Da Zugangsdaten während einer unentdeckten Kompromittierung verändert oder mitgelesen worden sein können, sollte eine Wiederherstellung grundsätzlich mit einem Zurücksetzen kritischer Zugangsdaten einhergehen, statt bestehende Anmeldeinformationen unverändert zu übernehmen.
RTO- und RPO-Planung um ein Unsicherheitsszenario erweitern. Notfallpläne sollten nicht nur den Fall eines bekannten Ausfallzeitpunkts abdecken, sondern auch das Szenario einer unklaren, rückwirkend zu bestimmenden Kompromittierungsdauer – mit entsprechend längeren, aber realistischen Zeitrahmen für die vollständige Wiederherstellung.
Expertensicht: Wiederherstellbar ist nicht gleichbedeutend mit sauber
Nach Einschätzung von Reinhard Quickstern, zertifizierter Business Continuity Manager bei Cristie Data, liegt die zentrale Fehlannahme vieler Notfallpläne darin, Wiederherstellbarkeit und Sauberkeit gleichzusetzen. Ein Backup, das sich technisch einwandfrei zurückspielen lässt, ist damit noch nicht zwangsläufig frei von den Spuren eines vorangegangenen Angriffs. Diese Verwechslung führt in der Praxis dazu, dass nach einem Vorfall zwar schnell wieder Systeme laufen, die eigentliche Bedrohung aber unbemerkt fortbesteht.
Besonders kritisch wird dies, wenn – wie im Berliner Fall – die Entdeckung eines Angriffs eher zufällig erfolgt und nicht durch ein gezieltes, kontinuierliches Monitoring der eigenen Backup- und Produktivumgebung. Je länger die tatsächliche Kompromittierungsdauer im Nachhinein unklar bleibt, desto größer wird der Kreis der potenziell betroffenen Sicherungsstände – und desto wichtiger wird eine systematische, nicht rein zeitbasierte Prüfung der verfügbaren Wiederherstellungspunkte.
Handlungsempfehlungen: So bestimmen Unternehmen einen sicheren Wiederherstellungspunkt
Die oben genannten Anforderungen lassen sich nicht alle gleichzeitig umsetzen. Sinnvoll ist ein gestaffeltes Vorgehen, das mit der Bestandsaufnahme beginnt und schrittweise in Prozesse und Governance überführt wird:
Sofort umsetzbar (Bestandsaufnahme):
1. Prüfen, wie viele Wiederherstellungspunkte aktuell vorgehalten werden und über welchen Zeitraum – reicht die Tiefe aus, um auch eine mehrwöchige unentdeckte Kompromittierung abzudecken?
2. Klären, welche Fachverfahren oder Anwendungen sicherheitskritische Inhalte wie Zugangsdaten in gewöhnlichen Dateiformaten speichern, statt in dafür vorgesehenen, besser geschützten Systemen – der Berliner Fall zeigt, dass genau solche Dateien beim Restore leicht übersehen werden.
Kurzfristig (Prozessdefinition):
3. Einen klar definierten Ablauf für die forensische Kurzprüfung eines Wiederherstellungspunkts festlegen, inklusive Verantwortlichkeiten und maximaler Zeitdauer, damit dieser Schritt im Ernstfall nicht improvisiert werden muss.
4. Den Prozess zum Zurücksetzen von Zugangsdaten und Zertifikaten als festen Bestandteil jeder größeren Wiederherstellung im Incident-Response-Runbook verankern.
Mittelfristig (Infrastruktur und Monitoring):
5. Die Backup-Infrastruktur selbst in das Sicherheits-Monitoring aufnehmen – nicht nur die Produktivsysteme. Ungewöhnliche Zugriffe auf Sicherungsspeicher sind ein eigenständiges Warnsignal, das in vielen Konzepten bislang fehlt.
Governance (vorab festlegen, nicht im Ernstfall entscheiden):
6. Entscheidungswege dafür definieren, wer im Ernstfall zwischen mehreren infrage kommenden Wiederherstellungspunkten abwägt und auf welcher Grundlage – damit diese Entscheidung nicht unter Zeitdruck und ohne klare Zuständigkeit getroffen werden muss.
Fazit: Wiederherstellungspunkte müssen geprüft, nicht nur vorgehalten werden
Der Cyberangriff auf die Berliner Landesverwaltung zeigt, dass zwischen dem eigentlichen Eindringen eines Angreifers und seiner Entdeckung erhebliche Zeit vergehen kann – mit direkten Konsequenzen für die Wahl eines vertrauenswürdigen Backup-Wiederherstellungspunkts. Eine moderne Recovery-Strategie kann sich nicht länger darauf verlassen, dass der jüngste verfügbare Sicherungsstand automatisch der sicherste ist. Stattdessen erfordert eine belastbare Cyber-Resilience-Praxis mehrere vorgehaltene Wiederherstellungspunkte, deren systematische Prüfung vor dem Restore sowie regelmäßig getestete, automatisierte Recovery-Prozesse, die im Ernstfall tatsächlich tragen.
Häufige Fragen zu Backup-Wiederherstellungspunkten nach Ransomware-Angriffen
Warum ist das letzte Backup nach einem Ransomware-Angriff nicht automatisch sicher?
Wenn ein Angreifer bereits vor der Entdeckung des Vorfalls über einen längeren Zeitraum Zugriff auf ein Netzwerk hatte, können auch Backups aus diesem Zeitraum bereits kompromittierte Elemente wie veränderte Zugangsdaten oder manipulierte Konfigurationen enthalten. Ein unkritisches Zurückspielen kann dazu führen, dass ein Angreifer trotz Wiederherstellung weiterhin Zugriff behält.
Was bedeutet Recovery Point Objective (RPO) im Kontext von Cyberangriffen?
RPO beschreibt den maximal tolerierbaren Datenverlust und damit indirekt, wie weit ein Wiederherstellungspunkt zeitlich zurückliegen darf. Bei Cyberangriffen mit unklarer Kompromittierungsdauer muss die RPO-Planung um die Frage ergänzt werden, ob der gewählte Zeitpunkt tatsächlich vor Beginn der Kompromittierung liegt.
Wie lange bleiben Angreifer typischerweise unentdeckt in einem Netzwerk?
Die tatsächliche Dauer variiert stark je nach Angriffsart, eingesetzter Erkennungstechnologie und Organisation. Der Berliner Fall zeigt beispielhaft eine Lücke von rund einer Woche zwischen erstem Zugriff und Isolierung der betroffenen Systeme; in anderen Fällen können es deutlich längere Zeiträume sein.
Was ist ein sauberer Wiederherstellungspunkt (Clean Recovery Point)
Ein sauberer Wiederherstellungspunkt ist ein Sicherungsstand, der nachweislich vor Beginn einer Kompromittierung liegt und keine manipulierten Konfigurationen, Zugangsdaten oder eingebettete Schadsoftware enthält. Die Bestimmung erfolgt in der Regel durch forensische Prüfung und automatisierte Scans in isolierten Testumgebungen.
Reichen regelmäßige Backups allein als Schutz vor Ransomware aus?
Regelmäßige Backups sind eine notwendige, aber keine hinreichende Voraussetzung. Ohne eine Prüfung der Integrität und Sauberkeit der Wiederherstellungspunkte besteht das Risiko, dass auch gesicherte Daten bereits kompromittierte Elemente enthalten.
Sollten nach einer Wiederherstellung grundsätzlich alle Zugangsdaten geändert werden?
Ja, dies gilt als bewährte Vorgehensweise, da Zugangsdaten während einer unentdeckten Kompromittierung mitgelesen oder verändert worden sein können. Ein Zurücksetzen kritischer Zugangsdaten im Rahmen der Wiederherstellung verringert das Risiko einer erneuten Kompromittierung über bereits bekannte Anmeldeinformationen.
Jetzt handeln – wir sind Ihr Partner für Cyber-Resilienz und Recovery
Cristie Data unterstützt Sie mit langjähriger Expertise in den Bereichen Backup, Recovery und Cyber-Resilienz – damit Sie sich im Ernstfall nicht nur auf die Wiederherstellung, sondern auch auf die Sauberkeit Ihrer Wiederherstellungspunkte verlassen können. Sprechen Sie uns an – ein Telefonkontakt oder eine Mail genügt.
