Ransomware-resiliente Backups aufbauen

Warum Ransomware Backups zum Ziel macht und nicht zum Sicherheitsnetz

Jahrelang war das Backup die Ausnahme, die Ransomware überlebbar machte: Produktion verschlüsselt, aus dem Backup wiederhergestellt, weiter geht's. Die Angreifer haben aufgeholt. Veeams 2025 Ransomware Trends Report befragte 1.300 Organisationen, von denen 900 in den vorangegangenen 12 Monaten mindestens einen Ransomware-Angriff erlitten hatten. Veeam berichtet, dass es der Angreifer bei 89 % der Organisationen auf die Backup-Repositories abgesehen hatte und dass im Durchschnitt 34 % der Backup-Repositories verändert oder gelöscht wurden. Wer das Rückfallnetz zerstört oder beschädigt, nimmt dem Opfer seinen Verhandlungsspielraum, noch bevor die Lösegeldforderung überhaupt eintrifft.

Das Ergebnis zeigt sich in den Wiederherstellungszahlen. Sophos' State of Ransomware 2025 befragte 3.400 IT- und Security-Verantwortliche, deren Organisationen im Vorjahr von Ransomware getroffen worden waren. Von den Organisationen, deren Daten verschlüsselt wurden, stellten nur 54 % sie mithilfe von Backups wieder her, die niedrigste Quote in den sechs Jahren, in denen Sophos die Umfrage durchführt. Von den 151 Organisationen, die am Ende mehr als die ursprüngliche Forderung des Angreifers zahlten, gaben 38 % an, ihre Backups seien ausgefallen oder hätten nicht richtig funktioniert (die Befragten nannten typischerweise zwei Gründe). Ein Backup, das auf dem Papier existiert, ist nicht dasselbe wie ein Backup, das sich unter Druck sauber wiederherstellen lässt.

Diese Lücke zwischen „wir haben Backups" und „wir haben ransomware-resiliente Backups" lässt sich auf drei Säulen zurückführen: Immutability, Isolation und getestete Wiederherstellung. Sie sind keine unabhängigen Kontrollen, die man nach Belieben kombinieren kann. Fehlt eine davon, gleichen die anderen beiden das nicht aus. Ein unveränderliches Backup, das ein Angreifer nicht erreichen kann, nützt nur, wenn es sich tatsächlich wiederherstellen lässt, und ein gut getesteter Wiederherstellungsplan ist wertlos, wenn das Backup, auf das er sich stützt, gelöscht wurde, bevor die Übung überhaupt begann.

Die drei Säulen im Einzelnen

1. Immutability: Backups, die ein Angreifer nicht anrühren kann

Immutability bedeutet, dass ein Backup innerhalb seines Aufbewahrungszeitraums weder verändert noch gelöscht werden kann: nicht durch ein falsch konfiguriertes Aufbewahrungsskript, nicht durch ein kompromittiertes Administratorkonto und nicht durch einen Angreifer, der bereits Domain-Admin-Zugangsdaten besitzt. In der Praxis wird sie über Object Lock auf Objektspeicher, WORM-Hardware (Write Once Read Many) oder ein gehärtetes Linux-Repository durchgesetzt, dessen Aufbewahrung auf der Speicherebene erzwungen wird, unabhängig von den Zugriffskontrollen der Backup-Anwendung selbst.

Die Unterscheidung ist wichtig, weil Ransomware-Betreiber gezielt nach Backups suchen, die sie mit gestohlenen Zugangsdaten erreichen können. Der #StopRansomware Guide der CISA sagt das direkt: "Ransomware actors often hunt for and collect credentials stored in the targeted environment and use those credentials to attempt to access backup solutions." (Ransomware-Akteure suchen und sammeln häufig die in der angegriffenen Umgebung gespeicherten Zugangsdaten und versuchen, mit diesen Zugangsdaten auf Backup-Lösungen zuzugreifen.) Wenn dasselbe Administratorkonto, das Ihre Backup-Software verwaltet, auch die Wiederherstellungspunkte des letzten Monats löschen kann, ist Immutability in Wahrheit nicht umgesetzt. Sie ist dann eine Einstellung, die ein ausreichend privilegierter Angreifer in Minuten abschalten kann.

Die CISA selbst rät, "maintain offline, encrypted backups of critical data, and regularly test the availability and integrity of backups in a disaster recovery scenario." (offline gehaltene, verschlüsselte Backups kritischer Daten vorzuhalten und die Verfügbarkeit und Integrität der Backups regelmäßig in einem Disaster-Recovery-Szenario zu testen). Derselbe Leitfaden ist bei unveränderlichem Cloud-Speicher für sich genommen zurückhaltend: "Use immutable storage with caution as it does not meet compliance criteria for certain regulations and misconfiguration can impose significant cost." (Unveränderlichen Speicher mit Vorsicht einsetzen, da er die Compliance-Kriterien bestimmter Vorschriften nicht erfüllt und Fehlkonfigurationen erhebliche Kosten verursachen können.) Immutability ist eine starke Kontrolle. Sie ersetzt weder eine Offline-Kopie noch einen getesteten Restore.

2. Isolation: eine separate Identitätsebene und eine Kopie, die Angreifer überhaupt nicht erreichen

Immutability schützt ein Backup davor, verändert zu werden. Isolation schützt es davor, überhaupt erreicht zu werden. Beide ergänzen sich, sind aber nicht austauschbar, und Unternehmen, die nur eine davon umsetzen, entdecken die Lücke meist während eines echten Vorfalls statt bei einem Design-Review.

Isolation hat zwei Komponenten. Die erste ist eine separate Identitätsebene: Backup-Infrastruktur sollte nicht derselben Active-Directory-Domäne, denselben administrativen Zugangsdaten oder demselben flachen Netzwerksegment vertrauen wie die Produktion. Ein kompromittierter Domain Controller sollte nicht automatisch eine kompromittierte Backup-Umgebung bedeuten; tut er es doch, musste der Angreifer nur eine Sache kompromittieren, nicht zwei. Die zweite ist eine wirklich offline gehaltene oder per Air-Gap getrennte Kopie: mindestens eine Kopie kritischer Daten, zu der aus der Produktion überhaupt kein dauerhafter Netzwerkpfad besteht. Das kann eine Offline-Bandrotation sein, ein getrenntes Replikationsziel, das nur kurz online ist, um Daten zu empfangen, oder eine Cloud-Ebene, für die nirgends im Erreichbarkeitsbereich der Produktionsumgebung dauerhafte Zugangsdaten zwischengespeichert sind.

Veeams Bericht 2025 besagt, dass Organisationen, die Datenresilienz priorisieren, "can recover from attacks up to seven times faster and experience significantly lower data loss rates." (sich bis zu siebenmal schneller von Angriffen erholen können und deutlich geringere Datenverluste erleiden). Veeam schreibt das der Datenresilienz insgesamt zu (Backup und Wiederherstellung, proaktive Sicherheit, Incident Response), nicht der Isolation allein. Isolation ist dennoch ein großer Teil des Bildes: Sie macht den Unterschied zwischen einem Angreifer, der echte zusätzliche Arbeit leisten muss, um Ihren Wiederherstellungspunkt zu erreichen, und einem, der bereits eine offene Sitzung dorthin hat, weil er eine Identitätsebene mit den Systemen teilt, die er gerade kompromittiert hat.

3. Getestete Wiederherstellung: Wiederherstellbarkeit nachweisen, bevor Sie sie brauchen

Die am wenigsten glamouröse der drei Säulen ist zugleich die, die man am leichtesten halb erledigt liegen lässt. In Veeams Bericht 2025 verfügten 98 % der Befragten über ein Ransomware-Playbook, aber nur 44 % hatten darin Backup-Verifizierungen und deren Häufigkeit festgelegt. Veeams 2024 Ransomware Trends Report, basierend auf 1.200 Organisationen, die 2023 von mindestens einem Angriff getroffen wurden, stellte fest, dass 63 % der Organisationen Gefahr liefen, bei der Wiederherstellung Infektionen erneut einzuschleusen, weil Teams unter dem Druck, schnell wiederherzustellen, Schritte wie das erneute Scannen der Daten in Quarantäne auslassen.

Ungetestete Restores scheitern auf eine Weise, die unsichtbar bleibt, bis zu dem Moment, in dem es am meisten darauf ankommt: unterbrochene Backup-Ketten, fehlende Abhängigkeiten für Anwendungskonsistenz, Zugangsdaten von Dienstkonten, die schon vor Monaten abgelaufen sind, oder Runbooks, die für eine Infrastrukturtopologie geschrieben wurden, die es nicht mehr gibt. Wer Integritäts- und Malware-Scans überspringt, riskiert mehr als Ausfallzeit: die Wiederherstellung genau der Payload, die den Ausfall überhaupt erst verursacht hat.

Ein echtes Programm für getestete Wiederherstellung bedeutet geplante, vollständige Restore-Übungen in eine isolierte Wiederherstellungsumgebung, nicht nur Benachrichtigungen vom Typ „Backup-Job erfolgreich". Messen Sie diese Übungen an den RTOs, die das Geschäft tatsächlich braucht, nicht an Zahlen, die in einer Präsentation lediglich beruhigend aussehen.

Was die Wiederherstellungszahlen tatsächlich sagen

Sophos' Daten von 2025 haben eine Schlagzeile, die beruhigend wirkt: 97 % der Organisationen, deren Daten verschlüsselt wurden, konnten sie zurückgewinnen. Die Aufschlüsselung ist weniger tröstlich. Etwas mehr als die Hälfte (54 %) stellte aus Backups wieder her, 49 % zahlten das Lösegeld und bekamen Daten zurück, und 29 % nutzten andere Mittel; viele beschritten mehr als einen Weg. Daten zurückzubekommen und sie aus den eigenen Backups zurückzubekommen, sind unterschiedliche Ergebnisse. In dem Abstand zwischen beiden zeigen sich schwache Säulen: eine Aufbewahrungssperre, die die falsche Rolle aufheben konnte, ein „separates" Backup-Netz, das weiterhin derselben Domäne vertraute, oder ein Restore, der nie von Anfang bis Ende geübt worden war.

Was Fehler hier kosten

Die drei Säulen sind keine abstrakte Best-Practice-Checkliste. Sie wirken sich direkt darauf aus, wie viel ein Ransomware-Vorfall kostet und wie lange er dauert. Sophos' Bericht 2025 beziffert die durchschnittlichen Kosten für die Wiederherstellung nach einem Ransomware-Angriff, ohne gezahltes Lösegeld, auf 1,53 Mio. US-Dollar, gegenüber 2,73 Mio. US-Dollar im Jahr 2024. 53 % der Opfer hatten sich innerhalb einer Woche vollständig erholt, gegenüber 35 % ein Jahr zuvor. Die übrigen verbrachten mehr als sieben Tage in einem Zustand der Beeinträchtigung, in dem sich Ausfallzeit, Produktivitätsverlust und Aufwand für die Incident Response Tag für Tag summierten.

Die Backup-Aufstellung ist eine der wenigen Variablen in dieser Gleichung, die eine Organisation vollständig selbst steuert. Ob der erste Schritt eines Angreifers gegen Ihr Backup-Repository gelingt oder scheitert, entscheidet sich größtenteils durch Entscheidungen, die Monate zuvor getroffen wurden, nicht während des Vorfalls selbst. Wenn ein Angreifer Domain-Admin-Zugangsdaten besitzt und nach Ihrer Backup-Plattform sucht, sind Immutability, Isolation und getestete Wiederherstellung entweder bereits umgesetzt oder nicht; unter Druck lassen sie sich nicht mehr nachrüsten.

Häufige Fehler, die alle drei Säulen unbemerkt untergraben

Einige Muster tauchen in Post-Incident-Reviews immer wieder auf:

• Snapshots mit Backups verwechseln. Ein VMware-Snapshot ist ein Änderungsprotokoll der ursprünglichen virtuellen Festplatte, keine unabhängige Kopie. Broadcoms Artikel zu Best Practices für Snapshots ist unmissverständlich: "Do not use VMware snapshots as backups." (Verwenden Sie VMware-Snapshots nicht als Backups.) Die Snapshot-Datei wächst, je länger sie aufbewahrt wird, was den Datastore füllen und die Performance beeinträchtigen kann, und wenn die Basisfestplatten verloren gehen, "the snapshot files alone are not sufficient to restore a virtual machine." (reichen die Snapshot-Dateien allein nicht aus, um eine virtuelle Maschine wiederherzustellen). Snapshots sind eine Komfortfunktion für kurzfristige Rollbacks (Broadcom rät, einen einzelnen Snapshot nicht länger als 72 Stunden zu behalten), keine Wiederherstellungsstrategie.
• „Unveränderlich" als abzuhakendes Kästchen statt als verifizierte Eigenschaft behandeln. Object Lock und Aufbewahrungsrichtlinien müssen gegen genau die administrative Rolle getestet werden, die die Backup-Plattform verwaltet, und dürfen nicht nur in einem Konfigurationsleitfaden dokumentiert sein.
• Eine zweite Kopie in derselben Identitätsdomäne als „isoliert" bezeichnen. Wenn sich dieselben Zugangsdaten, die in der Produktion kompromittiert wurden, auch am Backup-Repository authentifizieren können, bietet eine geografische oder plattformseitige Trennung keine echte Isolation.
• Erfolg an abgeschlossenen Backups messen statt an verifizierten Restores. Ein grüner Haken beim Job der letzten Nacht sagt Ihnen, dass Daten irgendwohin geschrieben wurden. Er sagt Ihnen nicht, dass diese Daten abrufbar, anwendungskonsistent und frei von der Malware sind, die den Restore überhaupt erst notwendig gemacht hat.

Wo BackupSec ins Spiel kommt

BackupSec ersetzt Ihre Backup-Plattform nicht. Drei unserer Services lassen sich den oben beschriebenen Säulen zuordnen:

• ZeroMON überwacht Veeam Backup & Replication. Es läuft on-premises als OVA, verbindet sich mit einem Read-only-Konto und sendet nichts an BackupSec oder Dritte. Es verfolgt den Zustand der Jobs, zeichnet Konfigurationsänderungen in seinem Modul Forensic & Audit auf (wer was wann geändert hat), führt eine Security-Analyzer-Checkliste aus, erstellt Berichte und alarmiert per E-Mail und In-App-Benachrichtigung. Es zeigt den Immutability-Status jedes Repositorys so an, wie ihn Veeams eigene Repository-Einstellungen melden, und weist darauf hin, wenn sich diese Einstellung ändert. Es liest Veeams Konfiguration aus; die Sperren auf Objektebene im Speicher selbst verifiziert es nicht.
• ZeroTAM ist ein dedizierter Backup-Security-Berater, keine Software: Architektur- und Isolationsdesign, Kapazitätsplanung, Planung der Ransomware-Wiederherstellung und priorisierter Support während einer Krise.
• ZeroPEN ist ein bedrohungsorientierter Penetrationstest von Veeam Backup & Replication, Veeam ONE und Enterprise Manager. Er simuliert eine auf MITRE ATT&CK abgebildete Ransomware-Kill-Chain in acht Phasen: Erstzugriff, Discovery und Inventarisierung, Missbrauch von Zugangsdaten, Kompromittierung des Veeam-Servers, Zugriff auf Repositories, Neutralisierung von Backups, Simulation der Exfiltration und Nachweis der Verschlüsselungsfähigkeit. Er löscht niemals echte Backups, führt keine echte Verschlüsselung durch und stoppt weder Produktions- noch Backup-Dienste. Sie erhalten auditfähige Nachweise, und kritische Befunde werden erneut getestet. Das Engagement umfasst außerdem die Verifizierung der Restore-Integrität und der Immutability. Es handelt sich um einen Test zu einem bestimmten Zeitpunkt, daher müssen die regelmäßigen Restore-Übungen aus Säule 3 weiterhin stattfinden.

Sprechen Sie mit BackupSec über Ihre Backup-Sicherheitslage →

Möchten Sie sehen, wie gut Ihre eigenen Backups standhalten würden? Das kostenlose Backup Security Assessment stellt 28 Fragen in sieben Bereichen, von der Backup-Strategie und Zugriffskontrolle bis zu Recovery-Tests.