„Wir haben doch ein Backup“ reicht 2026 als Ransomware-Strategie nicht mehr aus. Moderne Angreifer versuchen zunehmend nicht nur produktive Daten zu verschlüsseln, sondern auch die Wiederherstellung selbst zu sabotieren.
Im M-Trends-2026-Bericht beschreibt Google Threat Intelligence einen klaren Trend hin zu sogenanntem Recovery Denial: Angreifer zielen auf Backup-Infrastruktur, Identity-Dienste und Virtualisierungs-Management, um Unternehmen die Rückkehr in einen funktionierenden Betrieb möglichst schwer zu machen.
Ransomware greift nicht mehr nur Dateien an
Früher konzentrierte sich die Wahrnehmung von Ransomware stark auf verschlüsselte Windows-Dateien und Netzlaufwerke. Heute betrachten professionelle Angreifer die gesamte Wiederherstellungskette.
Dazu gehören unter anderem:
- Backup-Server und Backup-Administrationskonten
- Cloud-Backup-Objekte und deren Löschschutz
- Active Directory und andere Identity-Systeme
- Hypervisoren und Virtualisierungsplattformen
- Storage-Systeme und zentrale Management-Oberflächen
Wenn ein Angreifer beispielsweise einen Hypervisor oder dessen Storage-Ebene kompromittiert, können viele virtuelle Maschinen gleichzeitig ausfallen – selbst wenn die einzelnen Server innerhalb der VMs gut geschützt waren.
Warum ein normales Online-Backup nicht genügt
Ein Backup, das dauerhaft mit derselben Administrationsumgebung verbunden ist, kann im Ernstfall ebenfalls erreichbar sein. Werden Backup-Konten, Management-Systeme oder Cloud-Berechtigungen übernommen, kann ein Angreifer versuchen, Sicherungen zu löschen oder unbrauchbar zu machen.
Die zentrale Frage lautet deshalb nicht nur: „Haben wir ein Backup?“, sondern: „Kann ein Angreifer unser Backup mit denselben kompromittierten Konten ebenfalls zerstören?“
Die 3-2-1-1-0-Strategie als Orientierung
Eine praxistaugliche Backup-Architektur orientiert sich häufig an der 3-2-1-1-0-Regel:
- 3 Kopien der Daten
- 2 unterschiedliche Speichermedien oder Speicherarten
- 1 Kopie außerhalb des primären Standorts
- 1 zusätzliche offline oder immutable geschützte Kopie
- 0 ungeprüfte Fehler – Backups müssen regelmäßig verifiziert und Restore-Tests durchgeführt werden
Die konkrete Umsetzung hängt von Infrastruktur, Datenmenge, RTO/RPO und Budget ab. Das Grundprinzip bleibt: Eine Wiederherstellungskopie sollte nicht mit einem einzigen kompromittierten Administratorkonto zerstörbar sein.
Identitäten sind Teil der Backup-Strategie
Recovery hängt nicht nur von Dateien ab. Wenn Active Directory, Entra ID, lokale Admin-Konten oder Service Accounts kompromittiert sind, kann auch nach einer technischen Wiederherstellung weiterhin ein Sicherheitsrisiko bestehen.
Deshalb sollten besonders privilegierte Konten getrennt, stark authentifiziert und möglichst nicht für tägliche Arbeit verwendet werden. Backup-Administratoren sollten nicht automatisch dieselben Rechte wie Domain- oder Virtualisierungsadministratoren besitzen.
Virtualisierung als kritische Tier-0-Komponente behandeln
Hypervisoren und zentrale Virtualisierungsplattformen verwalten häufig Dutzende oder Hunderte Systeme. Ein erfolgreicher Angriff auf diese Ebene kann deshalb einen wesentlich größeren Schaden verursachen als die Kompromittierung eines einzelnen Servers.
Management-Zugänge sollten nur aus definierten Admin-Netzen erreichbar sein. Starke Authentifizierung, getrennte Administrationskonten, aktuelle Patches und lückenloses Logging sind hier besonders wichtig.
Sieben Schritte für eine belastbare Recovery-Strategie
- Immutable oder Offline Backup einführen.
- Backup-Administrationskonten von normalen Domain-Admins trennen.
- MFA beziehungsweise phishing-resistente Anmeldung für kritische Management-Systeme einsetzen.
- Hypervisor, Storage und Backup-Systeme in das Tier-0-Sicherheitskonzept aufnehmen.
- Restore-Tests regelmäßig durchführen und dokumentieren.
- RTO und RPO für kritische Systeme definieren.
- Ein Ransomware-Runbook erstellen: Wer entscheidet, wer isoliert Systeme, wer sperrt Konten und in welcher Reihenfolge wird wiederhergestellt?
Ein Backup ist erst dann gut, wenn ein Restore funktioniert
Viele Organisationen überwachen erfolgreiche Backup-Jobs, testen aber nur selten die vollständige Wiederherstellung. Im Notfall zeigt sich dann, ob Abhängigkeiten dokumentiert sind, Datenbanken konsistent starten, Zugangsdaten verfügbar sind und das Team die richtige Reihenfolge kennt.
Ein technischer Restore-Test ist deshalb gleichzeitig ein Security-Test und ein Business-Continuity-Test.
FAQ
Reicht ein Cloud-Backup gegen Ransomware?
Nicht automatisch. Entscheidend sind unter anderem Löschschutz, Versionierung, Unveränderbarkeit, getrennte Berechtigungen und die Frage, ob kompromittierte Administratoren das Backup verändern können.
Wie oft sollte ein Restore getestet werden?
Das hängt von Kritikalität und Änderungsrate ab. Kritische Systeme sollten nach einem definierten Plan regelmäßig getestet werden, nicht erst nach einem Sicherheitsvorfall.
Sollte das Backup in derselben Domain verwaltet werden?
Eine vollständige Abhängigkeit von derselben Identity- und Administrationsstruktur erhöht das Risiko. Für besonders kritische Backup-Komponenten sind getrennte Identitäten und zusätzliche Schutzmechanismen sinnvoll.
Fazit
Ransomware ist 2026 nicht nur ein Malware-Problem, sondern ein Resilience-Problem. Unternehmen müssen davon ausgehen, dass professionelle Angreifer auch die Systeme angreifen, die für die Wiederherstellung benötigt werden.
Das Ziel ist nicht lediglich ein Backup. Das Ziel ist eine Wiederherstellung, die auch dann noch funktioniert, wenn produktive Systeme, Administrator-Konten oder Teile der Virtualisierung kompromittiert wurden.
Autor: Salman Dolatpanah Gortlar
Quelle: Google Cloud – M-Trends 2026
Bildnachweis: Taylor Vick / Unsplash