Backup-Sicherheit unter Beschuss: Warum Ransomware-Gangs zuerst die Disaster Recovery zerstören

Ransomware-Gangs haben ihre Taktik verschoben: Erst die Backups killen, dann die Produktivdaten verschlüsseln. Wer glaubt, ein Klick auf „Restore“ rette ihn nach dem Angriff, hat die neue Realität der Backup-Sicherheit nicht verstanden – und genau das macht Disaster-Recovery-Systeme zum lukrativsten Angriffsziel der Stunde.

Es gab mal eine Zeit, da war ein Backup die Lebensversicherung gegen Ransomware. Verschlüsselte Daten? Kein Problem, einfach zurückspielen, Mittelfinger Richtung Erpresser, Feierabend. Diese Zeit ist vorbei. Ransomware-Gangs haben mitgelesen und ihre Playbooks angepasst: Zuerst wird die Backup-Infrastruktur zerstört, dann erst die Produktivsysteme verschlüsselt. Das Pikante daran: Genau die Systeme, die als letzte Verteidigungslinie gelten, sind inzwischen das erste Ziel.

Diese Verschiebung ist kein Gerücht aus dem Darknet-Forum, sondern eine dokumentierte Beobachtung aus der Backup-Branche selbst. Anbieter wie Nakivo beschreiben Backup-Systeme mittlerweile explizit als Hauptziel moderner Ransomware-Operationen. Der Grund ist simpel und ziemlich zynisch: Ein Unternehmen ohne funktionierendes Backup zahlt schneller. Disaster Recovery wird so vom Rettungsanker zum ersten Sprengsatz im Angriffsablauf.

Der neue Lieblingsziel: Warum Backups zuerst fallen

Der klassische Ransomware-Ablauf sah so aus: Eindringen, sich lateral bewegen, verschlüsseln, Lösegeldforderung stellen. Der moderne Ablauf hat einen zusätzlichen Zwischenschritt, und der ist brisant. Zuerst kompromittieren Angreifer die Identitätsverwaltung, meist über Active Directory. Dann suchen sie gezielt nach Backup-Servern, Replikationszielen und Snapshot-Speichern. Erst wenn diese gelöscht, verschlüsselt oder manipuliert sind, folgt der finale Schlag gegen die Produktivdaten.

Wenig überraschend, dass diese Reihenfolge funktioniert. Backup-Server laufen in vielen Unternehmen im selben Netzwerksegment wie alles andere, verwaltet von denselben Admin-Konten, geschützt durch dieselbe schwache Multi-Faktor-Authentifizierung – oder gar keine. Wer einmal Domain-Admin-Rechte hat, hat auch Zugriff auf die Backup-Konsole. Der Angreifer muss also nicht zwei Systeme knacken, sondern nur eines gründlich.

Das BSI hat diesen Mechanismus in seinem Maßnahmenkatalog zu Ransomware bereits dokumentiert: Angreifer greifen gezielt Sicherungsdaten an oder löschen sie, um jede Möglichkeit der Wiederherstellung zu kappen. Klingt nach Lehrbuch, ist aber gelebte Praxis in unzähligen Vorfällen der letzten Jahre. Der Maßnahmenkatalog der Behörde liest sich streckenweise wie eine Gebrauchsanweisung für genau jene Fehler, die Angreifer heute ausnutzen.

Ein typisches Szenario aus dem Alltag vieler IT-Abteilungen

Um sich die Dynamik konkret vorzustellen, lohnt sich ein illustratives, aber realistisches Szenario, wie es sich in vielen Vorfallberichten in ähnlicher Form wiederholt: Ein mittelständisches Unternehmen wird über eine Phishing-Mail kompromittiert. Die Angreifer bewegen sich zunächst unauffällig, tagelang, manchmal wochenlang, durch das Netzwerk, bevor sie überhaupt aktiv werden. Sie identifizieren die Backup-Konsole, stellen fest, dass diese über dasselbe Admin-Konto erreichbar ist wie der Fileserver, und beginnen, Retention-Richtlinien zu verkürzen und ältere Sicherungspunkte zu löschen. Erst danach starten sie die Verschlüsselung der Produktivsysteme. Wenn die IT-Abteilung den Vorfall bemerkt, ist die vermeintlich sichere Rückversicherung bereits Geschichte – übrig bleiben oft nur Fragmente, aus denen sich kein vollständiger Betrieb mehr wiederherstellen lässt. Genau dieses Muster ist es, das Sicherheitsdienstleister inzwischen als Standardvorgehen beschreiben, nicht als Ausnahme.

Encryption-Gaps und die Immutability-Illusion

Der Clou an vielen Backup-Strategien: Sie fühlen sich sicher an, sind es aber nicht. „Unveränderliche“ Backups gelten als Goldstandard der Backup-Sicherheit, doch Immutability ist nicht gleich Immutability. Logische Unveränderlichkeit, die über dieselben Zugangsdaten verwaltet wird wie der Rest der Infrastruktur, ist im Ernstfall so stabil wie ein Kartenhaus im Windkanal. Wer die Admin-Konsole übernimmt, kann Retention-Policies verkürzen, Löschsperren aufheben oder Snapshot-Ketten kappen – ganz ohne die Verschlüsselung selbst zu brechen.

Snapshots werden gerne mit echten Backups verwechselt. Sind sie aber nicht. Ein Snapshot innerhalb derselben Storage-Plattform oder VM-Umgebung teilt sich häufig dieselben Berechtigungsstrukturen wie die Produktivsysteme. Fällt die Plattform, fällt der Snapshot gleich mit. Speicherguide bringt es in einer Analyse zur Ransomware-Abwehr auf den Punkt: Backups sind nur dann ein ausreichender Schutz, wenn sie air-gapped oder offline liegen und organisatorisch eingebettet sind – alles andere ist Kosmetik.

Auch Cloud-Backups sind keine automatische Versicherung. Ohne strikte Trennung von Identitäts- und Zugriffsmanagement, eigene Rollen und getrennte Tenants können Angreifer auch Cloud-gehostete Sicherungen löschen oder verschlüsseln, sobald sie die zentralen Zugangsdaten in der Hand haben. Der Cloud-Anbieter schützt die Infrastruktur, nicht automatisch die Konfiguration – diese Verantwortung bleibt beim Kunden. Wer seine Sicherungen etwa über eine vollautomatische Datensicherung ins Rechenzentrum auslagert, sollte genau diese Verantwortungsteilung vertraglich und technisch doppelt prüfen, statt sich blind auf den Anbieter zu verlassen.

Selbstüberschätzung als Sicherheitsrisiko

Hier wird es persönlich unangenehm für viele IT-Abteilungen: Eine Befragung des Datensicherungsspezialisten Veeam, über pressetext verbreitet, zeigt, dass ein Großteil der befragten Unternehmen sich selbst als gut vorbereitet einschätzt – und trotzdem nicht in der Lage ist, Daten nach einem Angriff innerhalb der geforderten Zeit vollständig wiederherzustellen. Im Schnitt dauerten Wiederherstellungen nach schweren Cyberangriffen rund drei Wochen, deutlich länger als die intern geplanten Zeitfenster.

Das ist die Sorte Zahl, die man zweimal lesen muss. Nicht weil sie überraschend wäre, sondern weil sie so banal vorhersehbar ist. Meine persönliche Einschätzung nach Jahren im Beobachten solcher Vorfälle: Die Lücke zwischen gefühlter und tatsächlicher Disaster Recovery entsteht fast immer aus demselben Grund – niemand testet die Wiederherstellung unter echtem Druck. Backup-Jobs laufen grün, das Häkchen ist gesetzt, das Thema abgehakt. Bis zum Tag, an dem es zählt.

Genau diese Selbstsicherheit ist der eigentliche Angriffsvektor. Nicht die Schwachstelle im Code, sondern die Lücke zwischen Theorie und geprüfter Praxis. Wer nie eine vollständige Systemwiederherstellung unter realistischen Bedingungen geprobt hat, weiß im Ernstfall nicht, ob die Backup-Kette überhaupt konsistent ist – und das ist der Moment, in dem Ransomware-Prävention zur reinen Glaubensfrage verkommt.

Die 3-2-1-Regel, neu gedacht für Unternehmen

Die 3-2-1-Regel ist der Klassiker unter den Backup-Grundsätzen: drei Kopien der Daten, zwei unterschiedliche Speichermedien, eine Kopie extern gelagert. Für Privatpersonen reicht das oft. Für Unternehmen, die sich gegen moderne Ransomware-Operationen wappnen wollen, ist es die Untergrenze, nicht das Ziel.

Fachartikel wie der von Informatik Aktuell zu Cyber-Angriffen und der passenden Backup- und Desaster-Recovery-Strategie ergänzen die Regel sinnvoll: eigene physische Systeme für Backup-Infrastruktur, getrennte Netzwerksegmente, dedizierte Admin-Konten ohne Querverbindung zur Produktivumgebung. Aus 3-2-1 wird damit praktisch 3-2-1-1-0: eine zusätzliche air-gapped oder offline Kopie, und null Fehler bei der Verifizierung der Wiederherstellbarkeit.

Der Unterschied zwischen Air-Gap und Immutability wird dabei häufig verwechselt. Air-Gap bedeutet physische oder logische Trennung vom Netzwerk – kein permanenter Zugriff, kein Angriffspfad über bestehende Verbindungen. Immutability bedeutet technische Unveränderbarkeit der Daten innerhalb eines Speichersystems, unabhängig von der Netzwerktopologie. Beides ergänzt sich, ersetzt sich aber nicht gegenseitig. Wer nur eines von beiden umsetzt, hat die halbe Miete gezahlt und die andere Hälfte der Wohnung offen gelassen. Spezialisierte Konzepte für digital Recovery als Schutz vor Cyberangriffen zeigen recht anschaulich, wie sich diese doppelte Absicherung technisch abbilden lässt, ohne den laufenden Betrieb unnötig zu verkomplizieren.

Hardening-Strategien: Air-Gap, Zero Trust, Aufgabentrennung

Konkrete Handlungsschritte klingen in der Theorie langweilig, retten in der Praxis aber den Laden. Erstens: Aufgabentrennung zwischen Backup-Administration und allgemeiner IT-Administration. Wer alles darf, kann auch alles zerstören – ein einziges kompromittiertes Konto darf niemals gleichzeitig Zugriff auf Produktivsysteme und Backup-Konsole haben.

Zweitens: konsequente Multi-Faktor-Authentifizierung für jeden Zugriff auf Backup-Systeme, ohne Ausnahme für „vertrauenswürdige“ Legacy-Zugänge. Drittens: physische oder logische Netzwerksegmentierung, damit Backup-Server nicht im selben Broadcast-Domain-Chaos hängen wie die Buchhaltungs-VLAN. ComputerWeekly.de hat dazu Expertenmeinungen gesammelt, die Air-Gap-Kopien als absolutes Muss bezeichnen, ergänzt durch starke Verschlüsselung und regelmäßig geübte Notfallpläne.

Viertens: Google Cloud beschreibt in seinen Best Practices zum Schutz vor Ransomware ein Set an Maßnahmen, das sich eins zu eins auf lokale Umgebungen übertragen lässt – strikte Zugriffstrennung, Monitoring von Backup-Aktivitäten und konsequente Immutability-Konfiguration statt bloßer Herstellerversprechen. Wer glaubt, „Cloud“ sei automatisch gleich „sicher“, hat die Konfigurationsverantwortung schlicht ignoriert.

Fünftens, und das ist der am häufigsten übersprungene Punkt: regelmäßige, vollständige Wiederherstellungstests. Nicht der Klick auf „einzelne Datei zurückspielen“, sondern die komplette Systemwiederherstellung unter Zeitdruck, inklusive Messung von tatsächlicher Recovery Time und Recovery Point. Ohne diesen Test ist jede Backup-Strategie reine Theorie mit hübschem Dashboard.

Gegenargumente: Ist totale Trennung für jedes Unternehmen praktikabel?

So klar diese Maßnahmen auf dem Papier wirken, so berechtigt ist der Einwand aus vielen kleineren und mittleren Unternehmen: Nicht jede Organisation hat das Budget oder das Personal, um eine vollständig getrennte Backup-Infrastruktur mit eigenen Admin-Teams zu betreiben. Ein Ein-Mann-IT-Betrieb kann schlicht keine strikte Aufgabentrennung umsetzen, wenn dieselbe Person für Server, Netzwerk und Backup zuständig ist. Diese Realität darf in der Diskussion nicht unter den Tisch fallen, so unbequem sie auch ist.

Die pragmatische Antwort darauf ist nicht Resignation, sondern Priorisierung. Wenn schon keine vollständige organisatorische Trennung möglich ist, dann sollte zumindest technisch dafür gesorgt werden, dass ein kompromittiertes Administratorkonto nicht automatisch auch die Backup-Konsole öffnet – etwa durch separate Zugangsdaten mit eigener Multi-Faktor-Authentifizierung, auch wenn dieselbe Person sie bedient. Ebenso lässt sich eine einzelne air-gapped Kopie, etwa auf externen Datenträgern, die nach der Sicherung physisch getrennt werden, auch mit begrenztem Budget realisieren. Perfektion ist selten erreichbar, aber jeder zusätzliche Schritt erhöht die Kosten für Angreifer und die Chancen auf eine erfolgreiche Wiederherstellung im Ernstfall.

Backups als Frühwarnsystem statt nur als Rettungsboot

Der Plot Twist: Backup-Infrastruktur kann mehr, als nur Daten zu sichern. Moderne Ansätze nutzen Backup-Jobs und Änderungsraten aktiv zur Erkennung von Ransomware-Aktivität. Wenn plötzlich massenhaft Dateitypen wechseln oder das Änderungsvolumen explodiert, ist das ein Indikator, der weit vor der eigentlichen Erpressungsnachricht auftaucht. Wird dieser Indikator konsequent in SIEM- oder EDR-Systeme eingespeist, verschiebt sich Backup-Sicherheit von der reinen Absicherung zur aktiven Früherkennung. Die Einbindung solcher Signale passt zu aktuellen Cybersecurity-Trends rund um BEC und Ransomware, die zunehmend auf frühzeitige Erkennung statt reiner Nachsorge setzen.

Das ist der Teil, der in vielen Unternehmen komplett ungenutzt bleibt. Backup-Software erzeugt täglich Telemetriedaten – Änderungsraten, Fehlermeldungen, ungewöhnliche Zugriffszeiten. Diese Daten landen oft in einem isolierten Dashboard, das niemand außerhalb des Backup-Teams je öffnet. Dabei wäre genau hier ein früher Alarm möglich, bevor die eigentliche Verschlüsselung überhaupt beginnt. Wer diese Signale ignoriert, verschenkt einen der wenigen echten Zeitvorteile gegen Ransomware-Operationen.

Was tun, wenn der Ernstfall schon läuft?

Ist die Backup-Infrastruktur bereits kompromittiert, zählt jede Minute. Erste Regel: Netzwerkverbindungen zu Backup-Systemen sofort trennen, bevor weitere Zerstörung stattfindet. Zweite Regel: forensische Sicherung vor jedem Wiederherstellungsversuch, sonst verschwinden wertvolle Spuren zur Angriffsanalyse. Dritte Regel: Wiederherstellung ausschließlich aus nachweislich nicht kompromittierten, idealerweise offline gelagerten Kopien – niemals aus dem zuletzt manipulierten Snapshot, egal wie verlockend die kurze Downtime klingt.

In der Praxis bedeutet das auch, dass eine klare Kommunikationskette vorbereitet sein muss, bevor der Vorfall eintritt: Wer entscheidet über die Abschaltung von Systemen? Wer informiert Kunden, Behörden und gegebenenfalls Aufsichtsstellen? Ein Unternehmen, das diese Fragen erst während des laufenden Angriffs klärt, verliert wertvolle Zeit, in der Angreifer weiterhin aktiv sein können. Ein schriftlicher, regelmäßig aktualisierter Notfallplan mit klaren Verantwortlichkeiten ist deshalb genauso wichtig wie die technische Absicherung der Backups selbst.

Zur Frage, ob im Ernstfall gezahlt werden sollte, wenn selbst die Backups betroffen sind: Das BSI rät klar von Lösegeldzahlungen ab und setzt stattdessen auf Prävention sowie Wiederherstellung aus geprüften, nicht kompromittierten Sicherungen. Diese Empfehlung ist keine akademische Position, sondern eine ziemlich pragmatische Reaktion darauf, dass Zahlungen keine Garantie für funktionierende Entschlüsselung bieten und das Geschäftsmodell der Angreifer weiter füttern.

Meine persönliche Meinung dazu: Die Debatte um Backup-Sicherheit wird zu oft als reines IT-Thema abgehandelt, dabei ist es längst eine Führungsfrage. Wenn die Geschäftsleitung nicht versteht, dass eine ungetestete Disaster-Recovery-Strategie ein finanzielles Risiko in Millionenhöhe ist, wird sich am Investitionsverhalten nichts ändern. Backup-Sicherheit braucht Budget, nicht nur gute Absichten im IT-Sicherheitskonzept.

Konkrete Checkliste für den Unternehmensalltag

Für alle, die jetzt handeln wollen, statt nur zu nicken: Prüfen Sie zuerst, ob Backup-Administration und allgemeine IT-Administration getrennte Konten mit getrennter Multi-Faktor-Authentifizierung nutzen. Kontrollieren Sie danach, ob mindestens eine Backup-Kopie tatsächlich air-gapped oder offline liegt, nicht nur „logisch getrennt“ im selben Rechenzentrum. Testen Sie eine vollständige Systemwiederherstellung mindestens vierteljährlich unter realistischem Zeitdruck, nicht nur die Rückholung einzelner Testdateien.

Überprüfen Sie außerdem, ob Ihre Immutability-Konfiguration wirklich unabhängig von den zentralen Admin-Zugangsdaten funktioniert. Und binden Sie Backup-Telemetrie in bestehende Monitoring-Systeme ein, damit ungewöhnliche Änderungsraten nicht erst auffallen, wenn die Lösegeldforderung schon im Postfach liegt. Diese Punkte sind keine Raketenwissenschaft, sie kosten aber Zeit, Personal und die Bereitschaft, sich unbequeme Wahrheiten über die eigene Wiederherstellungsfähigkeit einzugestehen.

Ergänzend lohnt sich ein Blick auf die vertragliche Seite: Wer Backup- oder Disaster-Recovery-Dienstleistungen an externe Anbieter auslagert, sollte in Service-Level-Vereinbarungen konkrete Wiederherstellungszeiten und regelmäßige, dokumentierte Testläufe verbindlich festschreiben lassen. Ein Vertrag, der nur die Sicherung selbst beschreibt, aber keine Aussage zur tatsächlichen Wiederherstellungsgeschwindigkeit im Angriffsfall trifft, ist im Ernstfall wenig mehr als ein Stück Papier. Gerade bei ausgelagerter Infrastruktur ist Transparenz über die eingesetzten Schutzmechanismen kein nettes Extra, sondern eine Grundvoraussetzung für belastbare Ransomware-Prävention.

Was bleibt also von dieser Entwicklung? Die Erkenntnis, dass Backup- und Disaster-Recovery-Systeme längst keine stille Nebenrolle mehr spielen, sondern im Zentrum jeder ernsthaften Ransomware-Prävention stehen müssen. Die Frage ist nicht mehr, ob Angreifer die Backups ins Visier nehmen. Sie tun es bereits. Die eigentliche Frage lautet: Wann testen Sie zuletzt eine vollständige Wiederherstellung unter echtem Druck – und sind Sie sich wirklich sicher, dass das Ergebnis Ihren Erwartungen entspricht?