Warum Ransomware das Backup zum Ziel macht, nicht zum Sicherheitsnetz
Jahrelang war das Backup die Ausnahme, die Ransomware überstehbar machte: Produktivsysteme verschlüsseln, aus dem Backup wiederherstellen, weitermachen. Die Angreifer haben aufgeholt. In Veeams 2025 Ransomware Trends Survey unter 1.300 betroffenen Organisationen wurden bei 89 % die Backup-Repositories gezielt angegriffen – nicht als Nebenschauplatz, sondern als vorrangiges Ziel innerhalb der Kill Chain. Das Zerstören oder Korrumpieren der Rückfallebene, bevor die Produktivdaten verschlüsselt werden, ist mittlerweile Standardvorgehen, weil es dem Opfer jeden Verhandlungsspielraum nimmt, noch bevor die Lösegeldforderung überhaupt eintrifft.
Das Ergebnis zeigt sich in den Recovery-Zahlen. Laut Sophos' State-of-Ransomware-2025-Bericht nutzten nach einem Angriff nur 54 % der Unternehmen ihre Backups zur Datenwiederherstellung – der niedrigste Wert in den sechs Jahren, seit die Umfrage läuft. Unter den Unternehmen, die am Ende mehr zahlten als die ursprüngliche Lösegeldforderung des Angreifers, nannten 38 % fehlgeschlagene oder funktionsunfähige Backups als Grund dafür, dass sie keine bessere Option hatten. Ein Backup, das nur auf dem Papier existiert, ist nicht dasselbe wie eines, 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: Unveränderlichkeit, Isolation und getestete Wiederherstellung. Das sind keine unabhängigen Kontrollen, die sich beliebig kombinieren lassen. Fehlt eine davon, gleichen die anderen beiden das nicht aus: Ein unveränderliches Backup, an das ein Angreifer nicht herankommt, nützt nur etwas, wenn es sich auch tatsächlich wiederherstellen lässt – und ein gut getesteter Restore-Plan ist wertlos, wenn das Backup, auf das er sich stützt, schon gelöscht wurde, bevor die Übung überhaupt begonnen hat.
Die drei Säulen im Detail
1. Unveränderlichkeit: Backups, an die Angreifer nicht herankommen
Unveränderlichkeit bedeutet, dass sich ein Backup innerhalb seines Aufbewahrungszeitraums nicht verändern oder löschen lässt – nicht durch ein falsch konfiguriertes Retention-Skript, nicht durch ein kompromittiertes Administratorkonto und nicht durch den Angreifer, der sich bereits Domain-Admin-Zugangsdaten verschafft hat. In der Praxis wird das über Object Lock auf Cloud- oder Objektspeichern, WORM-Hardware (Write Once, Read Many) oder ein gehärtetes Linux-Repository durchgesetzt, dessen Retention Locks auf Storage-Ebene greifen – unabhängig von den eigenen Zugriffskontrollen der Backup-Anwendung.
Diese Unterscheidung ist wichtig, weil moderne Ransomware-Gruppen aktiv nach Backup-Repositories suchen, die mit Produktivzugangsdaten erreichbar sind, und diese zuerst löschen oder verschlüsseln, bevor sie die Primärdaten überhaupt anfassen. Wenn dasselbe administrative Konto, das Ihre Backup-Software verwaltet, auch die Restore-Punkte des vergangenen Monats löschen kann, ist Unveränderlichkeit nicht wirklich gegeben – es handelt sich dann nur um eine Einstellung, die ein ausreichend privilegierter Angreifer in wenigen Minuten deaktivieren kann.
Die Ransomware-Richtlinien der CISA sind an dieser Stelle eindeutig: Offline gespeicherte, verschlüsselte, unveränderliche Backups vorhalten, sie regelmäßig verifizieren und sie als letzte Verteidigungslinie behandeln – nicht als das Erste, was ein Angreifer überwinden muss.
2. Isolation: eine getrennte Identitätsebene und eine Kopie, die Angreifer gar nicht erst erreichen
Unveränderlichkeit schützt ein Backup davor, verändert zu werden. Isolation schützt davor, dass es überhaupt erst erreicht wird. Beide ergänzen sich, sind aber nicht austauschbar – und Unternehmen, die nur eines von beiden umsetzen, entdecken die Lücke in der Regel während eines echten Vorfalls und nicht bei einer Architektur-Review.
Isolation besteht aus zwei Komponenten. Die erste ist eine getrennte Identitätsebene – die Backup-Infrastruktur sollte weder derselben Active-Directory-Domäne noch denselben administrativen Zugangsdaten oder demselben flachen Netzwerksegment wie die Produktivumgebung vertrauen. Ein kompromittierter Domain Controller darf nicht automatisch eine kompromittierte Backup-Umgebung bedeuten; ist das doch der Fall, musste der Angreifer nur eine einzige Instanz kompromittieren, nicht zwei. Die zweite Komponente ist eine wirklich offline oder air-gapped gespeicherte Kopie – mindestens eine Kopie der kritischen Daten, die überhaupt keinen dauerhaften Netzwerkpfad zur Produktivumgebung besitzt, sei es durch offline rotierte Bänder, ein getrenntes Replikationsziel, das nur kurz online geht, um Daten zu empfangen, oder eine Cloud-Ebene ohne dauerhaft hinterlegte Zugangsdaten, die irgendwo aus der Produktivumgebung erreichbar wären.
Veeams Untersuchungen zeigen, dass Unternehmen, die eine solche mehrschichtige, isolierte Resilienz priorisieren, sich nach Ransomware-Angriffen bis zu siebenmal schneller erholen als jene, die das nicht tun – bei deutlich geringerem Datenverlust. Isolation ist der Grund für diesen Unterschied: Sie entscheidet, ob ein Angreifer echte zusätzliche Arbeit leisten muss, um an Ihren Recovery Point zu gelangen, oder ob er bereits eine offene Sitzung dorthin hat, weil dieser dieselbe Identitätsebene teilt wie die Systeme, die er gerade kompromittiert hat.
3. Getestete Wiederherstellung: Restorefähigkeit beweisen, bevor man sie braucht
Die am wenigsten glanzvolle der drei Säulen ist zugleich diejenige, die Unternehmen am häufigsten vernachlässigen – und das zeigt sich in den Ergebnissen. Eine Branchenumfrage aus 2025 ergab, dass 62 % der Unternehmen keine regelmäßigen Backup-und-Restore-Tests durchführen, und 37 % gaben an, ihr Recovery Time Objective (RTO) nicht einhalten zu können – konkret, weil Backups fehlten oder schlicht nie validiert worden waren. Zwischen Selbsteinschätzung und Realität klafft hier eine deutliche Lücke: Mehr als 60 % der Unternehmen glauben, sich nach einem Ausfall innerhalb weniger Stunden erholen zu können, doch im Test schafft das nur etwa ein Drittel tatsächlich.
Ungetestete Restores scheitern auf eine Weise, die so lange unsichtbar bleibt, bis es wirklich darauf ankommt: unterbrochene Backup-Ketten, fehlende Abhängigkeiten für Anwendungskonsistenz, Service-Account-Zugangsdaten, die schon Monate zuvor abgelaufen sind, oder Runbooks, die für eine Infrastrukturtopologie geschrieben wurden, die längst nicht mehr existiert. Das Auslassen der Validierung birgt zudem ein schärferes Risiko als bloße Ausfallzeit: Schätzungen zufolge laufen 63 % der Unternehmen Gefahr, während der Wiederherstellung dieselbe Infektion erneut einzuschleppen, weil sie unter Zeitdruck auf Integritäts- und Malware-Scans verzichten – und stellen damit im Grunde genau die Payload wieder her, die den Ausfall überhaupt erst verursacht hat.
Ein echtes Testprogramm für die Wiederherstellung bedeutet planmäßige, vollständige Restore-Übungen in eine isolierte Recovery-Umgebung – nicht nur Benachrichtigungen à la „Backup-Job erfolgreich“ – und zwar validiert gegen die RTOs, die das Geschäft tatsächlich braucht, nicht gegen Zahlen, die nur in einer Präsentation beruhigend wirken.
Wie es aussieht, wenn alle drei Säulen tragen
Sophos' Daten aus 2025 liefern ein aufschlussreiches Gegenbeispiel zu den Schlagzeilen-Statistiken: Unter den Unternehmen, deren Daten von einem Angreifer verschlüsselt wurden, konnten 97 % sie trotzdem wiederherstellen. Der Unterschied zwischen dieser Gruppe und der kleinen Minderheit, der das nicht gelang, lässt sich fast immer darauf zurückführen, dass eine der drei Säulen in der Praxis schwächer war, als sie auf dem Papier wirkte – ein Retention Lock, der sich mit der falschen Rolle umgehen ließ, ein angeblich „getrenntes“ Backup-Netzwerk, das trotzdem derselben Domäne vertraute, oder ein Restore, der nie wirklich end-to-end geprobt worden war.
Was es kostet, wenn man das falsch macht
Die drei Säulen sind keine abstrakte Best-Practice-Checkliste – sie wirken sich direkt darauf aus, wie teuer ein Ransomware-Vorfall wird und wie lange er dauert. Die durchschnittlichen Kosten für die Wiederherstellung nach einem Ransomware-Angriff, ohne ein eventuell gezahltes Lösegeld, liegen bei rund 1,53 Millionen US-Dollar. Nur 53 % der Opfer waren innerhalb einer Woche vollständig wiederhergestellt; die übrigen befanden sich länger als sieben Tage in irgendeiner Form der Beeinträchtigung, wobei sich Ausfallzeit, Produktivitätsverlust und der Aufwand für die Incident Response Tag für Tag summierten.
Die eigene Backup-Sicherheit ist eine der wenigen Variablen in dieser Gleichung, die ein Unternehmen vollständig selbst in der Hand hat. Ob der erste Zug eines Angreifers gegen Ihr Backup-Repository gelingt oder scheitert, entscheidet sich vollständig durch Entscheidungen, die Monate zuvor getroffen wurden – nicht während des eigentlichen Vorfalls. Sobald ein Angreifer Domain-Admin-Zugangsdaten besitzt und nach Ihrer Backup-Plattform sucht, sind Unveränderlichkeit, Isolation und getestete Wiederherstellung entweder bereits vorhanden – oder eben nicht; unter Druck lässt sich das nicht mehr nachrüsten.
Häufige Fehler, die alle drei Säulen im Stillen untergraben
In Post-Incident-Reviews tauchen immer wieder dieselben Muster auf:
- Snapshots mit Backups verwechseln. Ein VMware-Snapshot ist ein Delta zu einem bestimmten Zeitpunkt, gespeichert auf demselben Datastore wie die VM, die er schützt – keine unabhängige Kopie. Er wächst unbegrenzt, beeinträchtigt die Performance und verschwindet in dem Moment, in dem der Datastore ausfällt. Snapshots sind ein Komfortfeature für kurzfristige Rollbacks, keine Recovery-Strategie.
- „Unveränderlich“ als Häkchen statt als verifizierte Eigenschaft behandeln. Object Lock und Retention-Richtlinien müssen gegen genau die administrative Rolle getestet werden, die die Backup-Plattform verwaltet – nicht nur in einem Konfigurationsleitfaden dokumentiert sein.
- Eine zweite Kopie in derselben Identitätsdomäne als „isoliert“ bezeichnen. Wenn sich mit denselben Zugangsdaten, die in der Produktivumgebung kompromittiert wurden, auch am Backup-Repository authentifizieren lässt, bietet geografische oder plattformseitige Trennung keine echte Isolation.
- Erfolg am Abschluss des Backups messen statt an der Restore-Verifizierung. Ein grüner Haken beim Job der letzten Nacht sagt nur, dass irgendwo Daten geschrieben wurden. Er sagt nichts darüber aus, ob diese Daten abrufbar, anwendungskonsistent und frei von der Malware sind, die den Restore überhaupt erst nötig gemacht hat.
Wo BackupSec ansetzt
Bei BackupSec helfen wir Enterprise-Teams dabei, ihre Backup-Umgebungen genau an diesen drei Säulen auszurichten – nicht indem wir die Backup-Plattform ersetzen, sondern indem wir Backup-Sicherheit beobachtbar, beratbar und nachweisbar machen.
Unser Ansatz kombiniert drei Ebenen:
- ZeroMON liefert kontinuierliche Observability über die gesamte Backup-Landschaft – Veeam-ready Monitoring mit Echtzeit-Job-Tracking, automatisierten Sicherheitsprüfungen, forensischen Audit-Trails für Configuration Drift und Compliance-Reports per Klick. Diese Ebene macht aus der Annahme „Unveränderlichkeit ist konfiguriert“ einen Nachweis.
- ZeroTAM bietet dedizierte Expertenberatung für Backup-Architektur, Isolationsdesign und Ransomware-Recovery-Planung – die menschliche Ebene, die die meisten Unternehmen brauchen, um zu verstehen, was ihre Backup-Umgebung ihnen tatsächlich sagt, und um eine Isolation zu entwerfen, die auch den Kontakt mit einem echten Vorfall übersteht.
- ZeroPEN pentestet Ihre Backup-Infrastruktur so, wie es ein echter Angreifer tun würde – mit Fokus auf Management-Ebenen, Zugriffskontrollen und Unveränderlichkeitseinstellungen – und führt anschließend reale Restore-Szenarien durch, um zu belegen, dass Sie sauber, vollständig und innerhalb Ihrer festgelegten RTO wiederherstellen können – nicht nur, dass ein Backup-Job Erfolg gemeldet hat.
BackupSec wird On-Premise betrieben, verbindet sich über einen reinen Lesezugriff (Read-only API) mit Ihren Backup-Anwendungen und verschiebt niemals Backup-Daten außerhalb Ihrer Umgebung.
Sprechen Sie mit BackupSec über die Sicherheit Ihrer Backup-Umgebung →
Möchten Sie wissen, ob Ihre eigenen Backups im Ernstfall standhalten würden? Bewerten Sie Ihre Umgebung mit dem kostenlosen Backup Security Assessment.
