Kommentar Was der Hackerangriff auf Berlin am letzten Wochenende lehrt: Warum dieser Fall anders ist als ein typischer Ransomware-Angriff

Am 4. September 2026 hat die Ransomware-Gruppe Rhysida rund 1,44 Millionen Dateien aus dem Berliner Landesnetz im Darknet veröffentlicht – Personalakten, gescannte Ausweise, Krankmeldungen, Passwortlisten im Klartext und - auf den ersten Blick  - auch Unterlagen mit Sicherheitsbezug. Letzteres wurde vom Berliner Senat inzwischen ausgeschlossen.

Der Fall ist kein klassischer Verschlüsselungsangriff, sondern ein Datenabfluss mit Veröffentlichung. Und genau deshalb lohnt sich aus unserer Sicht ein ehrlicher Blick darauf, was moderne Cyber-Resilience-Plattformen hier tatsächlich leisten können – und was nicht.

Was in Berlin passiert ist: Der Cyberangriff

Wer die Berichterstattung der letzten vier Wochen verfolgt hat, kennt die Eckpunkte. Für die Einordnung lohnt es sich trotzdem, sie in Reihenfolge zu sehen:

• 7. bis 12. August 2026: Angreifer verschaffen sich unbemerkt Zugang zu Teilen des Berliner Landesnetzes. Betroffen sind die Senatsverwaltung für Stadtentwicklung, Bauen und Wohnen sowie die Senatsverwaltung für Mobilität, Verkehr, Klimaschutz und Umwelt. In diesen sechs Tagen fließen die Daten ab.
• 14. August: Der Angriff wird erkannt. Beide Senatsverwaltungen werden vom Landesnetz getrennt und sind faktisch arbeitsunfähig.
• 17. August: Die Senatskanzlei informiert öffentlich über einen „IKT-Vorfall". Krisenstab, LKA, BKA und BSI sind eingebunden.
• 23. August: Die Verwaltungen sind wieder am Netz. Neun Tage Ausfall.
• 28. August: Rhysida bekennt sich, fordert 30 Bitcoin (rund 2 Millionen Euro) und setzt einen Countdown von sieben Tagen. Der Regierende Bürgermeister von Berlin erklärt: „Das Land Berlin lässt sich nicht erpressen."
• 1. September: Die Senatsverwaltung bestätigt, dass auch Passwörter abgeflossen sind. Der VPN-Zugang wird gekappt, Homeoffice ist für die Beschäftigten der betroffenen Häuser nicht mehr möglich. Alle rund 12.000 Systeme des Landes werden geprüft.
• 4. September: Nach Ablauf des Ultimatums veröffentlicht die Gruppe die Daten vollständig – 1.439.893 Dateien, je nach Zählung 5,26 bis 5,8 Terabyte.
• 6./7. September: Das Land richtet eine Steuerungseinheit ein, um Betroffene zu kontaktieren. Das BSI bestätigt als ersten Angriffsvektor eine sogenannte TerminalFix-Kampagne – eine Weiterentwicklung der ClickFix-Methode, bei der Nutzer über ein gefälschtes Captcha dazu gebracht werden, einen Befehl aus der Zwischenablage im Windows-Terminal auszuführen. Der Zugang ins interne Netz erfolgte nach BSI-Einschätzung vermutlich über einen externen Fernzugang.

Warum dieser Fall anders ist als ein typischer Ransomware-Angriff

In unseren Kundengesprächen fällt beim Stichwort „Cyberangriff" fast reflexartig der Begriff Ransomware. Gemeint ist damit in der Regel: "Systeme verschlüsselt, Betrieb steht, Backup rettet uns".

Rhysida arbeitet zwar als Ransomware-as-a-Service mit doppelter Erpressung - im Berliner Fall steht aber nach allem, was öffentlich bekannt ist, der Datenabfluss im Vordergrund – nicht die Verschlüsselung.

Datenabfluss statt Verschlüsselung: Was ist der Unterschied?

Nach einer Verschlüsselung ist ein sauberes, unveränderliches Backup die Lösung. Nach einem Datenabfluss ist es das nicht: Die Daten sind weg, sie sind öffentlich, sie kommen nicht zurück. Kein Restore der Welt macht einen Reisepass-Scan wieder privat. Wir halten es für wichtig, das als Anbieter von Cyber-Resilience-Lösungen unmissverständlich zu sagen. Kein Backup hätte den Berliner Datenabfluss abwenden können.

Verhindert hätte ihn eine Kombination aus Endpoint-Schutz, Netzsegmentierung, Least-Privilege-Berechtigungen, MFA am Fernzugang, Schulung gegen Social Engineering und – ganz banal – dem Verzicht auf Passwortlisten in Word-Dateien.

Deshalb gehört Data Resilience aus unserer Sicht in genau diese Diskussion:

Denn die Frage, die Berlin seit dem 14. August nicht beantworten kann, lautet nicht „Wie stellen wir wieder her?", sondern: „Was genau ist eigentlich abgeflossen, wem gehört es, und wen müssen wir informieren?" Und diese Frage beantwortet man am besten aus dem Backup heraus.

Was uns der Fall über Datenhygiene lehrt

Bevor wir über Werkzeuge sprechen, ein Punkt zur Organisation. 5,8 Terabyte in 1,44 Millionen Dateien aus zwei Fachverwaltungen – darunter Bewerbungsunterlagen, Krankmeldungen und Ausweiskopien – sind kein Zeichen für ein Datenschutzproblem, sondern für ein Datenmengenproblem. Vieles davon hätte nach Löschkonzept längst nicht mehr existieren dürfen. Was nicht mehr da ist, kann nicht abfließen.

Das ist keine Berlin-spezifische Beobachtung. Wir sehen in fast jedem Health Check dieselben Muster: Fileshares, die seit 15 Jahren wachsen, weil niemand die Verantwortung für das Löschen trägt. Exporte und Kopien, die „nur mal kurz" abgelegt wurden. Und ja, auch Passwortlisten in Excel – bei Behörden wie bei DAX-Konzernen. Der Unterschied ist nur, ob jemand sie findet, bevor ein Angreifer sie findet. 

Daten proaktiv präventiv schützen: Was Cyber Resilience heute leistet

Führende Plattformen, mit denen wir schwerpunktmäßig arbeiten, haben sich in den letzten drei Jahren vom Backup-Werkzeug zur umfassenden Cyber Resilience-Plattform entwickelt. Der gemeinsame Gedanke: Das Backup ist die einzige Stelle im Unternehmen, an der der komplette Datenbestand regelmäßig, vollständig und ohne Last auf der Produktion durchgesehen werden kann.

Herstellerneutral lassen sich fünf Fähigkeits-Klassen unterscheiden, die im Berliner Szenario einen Unterschied gemacht hätten.

1. Wissen, was man hat: Data Discovery und Klassifizierung

Die Plattformen bieten inzwischen – in unterschiedlicher Tiefe und teils über Zusatzmodule oder Partnerintegrationen – die Möglichkeit, gesicherte Daten automatisiert nach sensiblen Inhalten zu durchsuchen:

• Personenkennzeichen
• Ausweisnummern
• Gesundheitsdaten
• Kreditkartennummern
• Frei definierbare Muster.

Das Ergebnis ist eine fortlaufend aktualisierte "Datenkarte": Wo liegen personenbezogene Daten? Wo liegen Daten mit Sicherheitsbezug? Wo liegen Dateien, die aussehen wie Zugangsdaten?

Wer diese Informationen hat, kann drei Dinge tun, die Berlin gerade unter enormem Zeitdruck nachholen muss: Altbestände gezielt löschen, überexponierte Verzeichnisse absichern – und im Ernstfall binnen Stunden statt Wochen sagen, welche Betroffenen nach DSGVO zu informieren sind.

2. Anomalien erkennen – auch die "leisen Töne"

Die Anomalieerkennung der Plattformen arbeitet auf Backup-Metadaten: Sie erkennt, wenn zwischen zwei Sicherungspunkten ungewöhnlich viele Dateien geändert, gelöscht, verschlüsselt oder neu angelegt wurden. Doch: Reines Lesen und Kopieren erzeugt keine solche Signatur. Exfiltration verläuft "leise".

Die gute Nachricht: Sie ist selten vollständig stumm. Angreifer, die Terabytes ausleiten, "stagen" Daten typischerweise vorher – d.h., sie legen Archive an, komprimieren, verschieben in Sammelverzeichnisse. Genau solche Muster – plötzlicher Datenzuwachs auf einem Server, neue große Archivdateien, ungewöhnliche Aktivität zu Nachtzeiten – lassen sich aus dem Vergleich von Sicherungspunkten erkennen und als Indicator of Compromise an SIEM oder SOC melden.

Um ein konkretes Beispiel für die Genauigkeit diese Erkennung heute zu nennen: IBM bspw. geht aktuell mit IBM Storage Defender noch einen Schritt weiter und kombiniert Sensoren auf Backup-Ebene mit Inline-Erkennung direkt im Primärspeicher, sodass Anomalien bereits auf Block-Ebene auffallen können. Sieben Tage unbemerkter Aufenthalt sind ein Zeitfenster, in dem ein solcher Hinweis den Unterschied gemacht hätte.

3. Threat Hunting im Backup

Alle heute führenden Plattformen können Sicherungspunkte gegen Threat-Intelligence-Feeds, Malware-Scanner oder eigene YARA-Regeln scannen. Damit lassen sich zwei Fragen beantworten, die im Berliner Fall wochenlang offen blieben: Seit wann ist der Angreifer im System – also welcher Sicherungspunkt ist der letzte saubere? Und wo hat er sich bewegt? Das Backup wird zur forensischen Zeitmaschine, ohne dass Produktionssysteme angefasst werden müssen.

4. Die Backup-Umgebung selbst als Festung

Der Berliner Fall zeigt, was passiert, wenn Zugangsdaten quasi "herumliegen": Der Angreifer hatte relativ leichtes Spiel. Für Backup-Infrastrukturen gilt das doppelt, denn wer die Backup-Konsole kontrolliert, kontrolliert die letzte Verteidigungslinie. Unveränderliche Speicherung (Immutability), logische oder physische Trennung (Air Gap), MFAund Vier-Augen-Prinzip für kritische Aktionen sowie rollenbasierte Zugriffe sind heute Standard – aber sie müssen aktiviert, konfiguriert und regelmäßig geprüft werden. 

5. Isolierte Wiederherstellung statt neun Tage Stillstand

Berlin hat neun Tage gebraucht, um zwei Verwaltungen wieder ans Netz zu bringen, und prüft seither 12.000 Systeme. Cleanroom- beziehungsweise Clean-Room-Recovery-Konzepte, wie sie Cyber Resilience-Plattformen wie Commvault, Cohesity, IBM, Rubrik und Veeam in unterschiedlicher Ausprägung anbieten, ermöglichen es, Systeme in einer isolierten Umgebung wiederherzustellen, dort zu scannen und erst nach Freigabe zurück in die Produktion zu übernehmen. Das verkürzt nicht nur die Ausfallzeit – es beantwortet auch die Frage, ob man überhaupt wieder anfahren darf.

Reaktiv: Die ersten 72 Stunden nach einem Datenabfluss

Was hätten wir konkret getan, wenn am 14. August ein Kunde mit diesem Befund angerufen hätte? Die DSGVO gibt in Artikel 33 eine Frist von 72 Stunden für die Meldung an die Aufsichtsbehörde vor. Realistisch lässt sich in dieser Zeit aus einer gut gepflegten Resilience-Umgebung Folgendes ableiten:

• Stunde 0–12: "Blast Radius" (die Reichweite des Vorfalls) bestimmen. Welche Systeme und Shares (Dateifreigaben) waren im Zeitfenster 7. bis 12. August für die kompromittierten Konten erreichbar? Die Sicherungspunkte dieser Systeme werden "eingefroren" – sie sind Beweismittel und Referenz zugleich.

• Stunde 12–36: Inhalt bestimmen. Ein Klassifizierungslauf über die betroffenen Sicherungspunkte liefert die jetzt wichtigsten Informationen: Welche Kategorien personenbezogener Daten lagen dort? Wie viele Betroffene? Gibt es Dateien mit Zugangsdaten? Aus dieser Liste entsteht sowohl die Meldung an die Aufsichtsbehörde als auch die Rotationsliste für alle betroffenen Passwörter und Zertifikate – bevor die Angreifer sie nutzen oder veröffentlichen.

• Stunde 36–72: Sauber wiederanlaufen. Zunächst wird ein Threat-Scan der letzten Sicherungspunkte gegen aktuelle IOCs, Identifikation des letzten sauberen Punkts, Wiederherstellung in isolierter Umgebung, Freigabe, und die Rückführung der Daten veranlasst. Parallel dazu geht es dann um Wiederherstellung der Fachanwendungen in einer Reihenfolge, die im BCM vorher festgelegt wurde. Diese sollte möglichst nicht vom Krisenstab "improvisiert" werden, sondern planvoll durchdacht verlaufen.

Herstellerneutral bedeutet nicht beliebig

Wir werden regelmäßig gefragt, welche der führenden Cyber Resilience-Plattformen „die beste" sei. Die ehrliche Antwort: Es hängt davon ab, was Sie schon haben, welche Workloads Sie schützen, welche Regulatorik für Sie gilt und wie Ihr Betriebsmodell aussieht.

Die Top-5 Hersteller, mit denen wir zusammenarbeiten, setzen zudem unterschiedliche Schwerpunkte: der eine stärker bei Datenklassifizierung und Data Security Posture, der andere bei Cleanroom-Automatisierung, der dritte bei Cyber-Vaulting, der vierte bei Inline-Erkennung und Deployment-Flexibilität, der fünfte bei der Verzahnung von Primärspeicher, Backup und Recovery-Orchestrierung. Wir kennen alle fünf aus dem täglichen Betrieb, nicht aus der Produktbroschüre.

Unsere Rolle ist deshalb nicht, Kunden ein Produkt zu verkaufen, sondern die Fähigkeitsklassen von oben auf die jeweilige Umgebung abzubilden: Was ist da, was ist konfiguriert, was ist nur lizenziert, was fehlt?

Diese Fragen enden nicht bei Strategie oder Technik, sondern erörtern die organisatorischen Fragen in ISMS, Risk und Business Continuity Management: wie die Rahmenbedingungen, ob Löschkonzept, Meldeprozess und Recovery-Reihenfolge dokumentiert und geübt sind.

Fazit

Der Berliner Fall wird uns noch lange beschäftigen – wegen seiner Größe, wegen der Brisanz der Inhalte und wegen der Abgeordnetenhauswahl am 20. September, vor deren Hintergrund das BSI bereits vor Hack-and-Leak-Operationen warnt.

Für IT-Verantwortliche in Behörden und Unternehmen lassen sich drei Lehren jetzt schon ziehen

1. Backup schützt nicht vor Datenabfluss. Aber die Backup-Umgebung ist der beste Ort, um zu wissen, was man hat, zu erkennen, dass etwas passiert, und im Ernstfall schnell und belastbar zu antworten. Das ist der Unterschied zwischen Backup und Data Resilience.
2. Datenhygiene ist Sicherheitsarbeit: Was gelöscht ist, kann nicht abfließen. Was klassifiziert ist, kann geschützt werden.
3. Die ersten 72 Stunden nach einem Vorfall entscheiden über Meldepflichten, Reputationsschaden und Betroffenenschutz. Wer sie nicht vorbereitet hat, verliert sie.

Nach BSI-Angaben setzen Erpressergruppen ihre Veröffentlichungsdrohung in 92 Prozent der Fälle auch um. Es gibt also keinen Grund anzunehmen, dass es beim nächsten Mal anders läuft. Die Frage ist nur, ob Sie dann wissen, was abgeflossen ist – oder es aus dem Darknet erfahren.

Quellen

Zum Vorfall

1. heise online: „Cyberattacke auf Berlin könnte größere Folgen haben als bisher gedacht", 6. September 2026. https://www.heise.de/news/Cyberangriff-Berlin-mit-Steuerungseinheit-will-Betroffene-kontaktieren-11442896.html

2. Land Berlin, Presse- und Informationsamt: „Angriff auf Landesnetz: Daten werden möglicherweise veröffentlicht", 3./4. September 2026. https://www.berlin.de/aktuelles/10611709-958090-cyberangriff-auf-landesnetz-daten-werden.html

3. Behörden Spiegel: „Cyber-Angriff trifft zwei Berliner Senatsverwaltungen", 18. August 2026. https://www.behoerden-spiegel.de/2026/08/18/cyber-angriff-trifft-zwei-berliner-senatsverwaltungen/

4. IT-BUSINESS: „Hackerangriff auf Berlin: Ultimatum für 30 Bitcoins läuft ab", September 2026. https://www.it-business.de/cyberangriff-berliner-landesnetz-rhysida-zugangsdaten-a-1075a37146a5e21701176d1024021794/

5. heise online: „BSI erklärt ersten Angriffsvektor auf Berliner Behörden", 7. September 2026. https://www.heise.de/news/BSI-erklaert-ersten-Angriffsvektor-auf-Berliner-Behoerden-11444072.html

6. Euronews: „Hacker-Attacke auf Berlin: Hochsensible Daten schon überall im Darknet", 5. September 2026. https://de.euronews.com/next/2026/09/05/mega-datenleck-berlin-hochsensible-staatsdaten-darknet

7. CISA: „#StopRansomware: Rhysida Ransomware", Cybersecurity Advisory AA23-319A. https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-319a

Zu den Plattformfähigkeiten (Herstellerangaben)

8. Rubrik: Data Discovery and Classification / Sensitive Data Monitoring. https://www.rubrik.com/products/data-discovery-and-classification

9. Cohesity: Threat Protection & Data Classification (ehem. DataHawk, jetzt Teil der Data Cloud Enterprise Edition). https://www.cohesity.com/platform/datahawk/

10. Commvault: Cleanroom Recovery und Threat Scan (Produktvergleichsseite). https://www.commvault.com/cohesity-vs-commvault

11. Rubrik: Data Threat Analytics – Anomaly Detection, Threat Hunting, Threat Monitoring. https://www.rubrik.com/products/data-threat-analytics

12. Cohesity: „Cohesity DataHawk updates: What you need to know", Mai 2026. https://www.cohesity.com/blogs/cohesity-datahawk-updates-what-you-need-to-know/

13. Cohesity: Clean Room Data Recovery and Incident Response. https://www.cohesity.com/solutions/clean-room/

14. Cohesity: „Leading the charge: First-to-market with hyper-accelerated threat scanning", September 2025. https://www.cohesity.com/blogs/threat-hunting/

15. Eon: „Cohesity vs Veeam: The Decision Guide for Cloud Teams" (Veeam Data Platform v13, Recon Scanner 3.0, Threat Hunter, Secure Restore), Juni 2026. https://www.eon.io/blog/cohesity-vs-veeam

16. Blocks & Files: „CrowdStrike's security agents can trigger Commvault, Rubrik and VAST Data cyber-recovery", 2. September 2026. https://www.blocksandfiles.com/security/2026/09/02/crowdstrikes-security-agents-can-trigger-commvault-rubrik-and-vast-data-cyber-recovery/5293928

17. IBM: „IBM Storage Defender Sensors: Smarter Protection for Your Data", IBM Community, Dezember 2025. https://community.ibm.com/community/user/blogs/vadzim-piletski/2025/12/12/ibm-storage-defender-sensors

18. IBM Redbooks: „IBM Storage Defender: Cyber Resiliency and Scanning with IBM Storage Sentinel powered by Index Engines CyberSense", SG24-8599, Juni 2026. https://www.redbooks.ibm.com/abstracts/sg248599.html

19. IBM: „Maximize the power of your lines of defense against cyber-attacks with IBM Storage FlashSystem and IBM Storage Defender", November 2025. https://www.ibm.com/new/product-blog/maximize-the-power-of-your-lines-of-defense-against-cyber-attacks-with-ibm-storage-flashsystem-and-ibm-storage-defender

Regulatorik

20. Verordnung (EU) 2016/679 (DSGVO), Art. 33 und 34 – Meldung von Verletzungen des Schutzes personenbezogener Daten. https://eur-lex.europa.eu/eli/reg/2016/679/oj

Stand der Faktenlage

8. September 2026, aktualisiert am 9. September 2026. Der Vorfall wird weiterhin untersucht; Angaben zu Umfang und Inhalt der veröffentlichten Daten können sich ändern.*