Comment What the hacker attack on Berlin last weekend teaches us: Why this case differs from a typical ransomware attack.

On September 4, 2026, the ransomware group Rhysida published approximately 1.44 million files from the Berlin state network on the darknet—including personnel records, scanned ID cards, sick notes, plaintext password lists, and—at first glance—documents related to security. The Berlin Senate has since ruled out the latter.

This case is not a classic encryption attack, but rather a data leak involving public disclosure. That is precisely why, in our view, it is worth taking an honest look at what modern cyber-resilience platforms can actually achieve in this context—and what they cannot.

What happened in Berlin: The cyberattack

Anyone who has followed the news coverage over the past four weeks is familiar with the key details. Nevertheless, it is worth reviewing the sequence of events to put them in perspective:

• August 7–12, 2026: Attackers gain undetected access to parts of the Berlin state network. The affected agencies are the Senate Department for Urban Development, Building and Housing and the Senate Department for Mobility, Transport, Climate Action and the Environment. Data exfiltration occurs during these six days.
• August 14: The attack is detected. Both Senate departments are disconnected from the state network and are effectively unable to operate.
• August 17: The Senate Chancellery publicly announces an "ICT incident." A crisis management team, the State Criminal Police Office (LKA), the Federal Criminal Police Office (BKA), and the Federal Office for Information Security (BSI) are involved.
• August 23: The departments are back online. A nine-day outage.
• August 28: Rhysida claims responsibility, demands 30 Bitcoin (approximately 2 million euros), and sets a seven-day countdown. The Governing Mayor of Berlin declares: "The State of Berlin will not submit to extortion."
• September 1: The Senate administration confirms that passwords have also been compromised. VPN access is cut off, and remote work is no longer possible for employees of the affected departments. All of the state's approximately 12,000 systems undergo checks.
• September 4: After the ultimatum expires, the group releases the data in full—1,439,893 files, amounting to between 5.26 and 5.8 terabytes, depending on the counting method.
• September 6/7: The state establishes a coordination unit to contact affected individuals. The BSI confirms that the initial attack vector was a so-called "TerminalFix" campaign—an evolution of the "ClickFix" method, in which users are tricked via a fake CAPTCHA into executing a command from their clipboard in the Windows terminal. According to the BSI's assessment, access to the internal network was presumably gained via an external remote access connection.

Why this case differs from a typical ransomware attack

In conversations with our customers, the mention of a "cyberattack" almost reflexively brings up the term "ransomware." This usually implies a scenario where systems are encrypted, operations grind to a halt, and backups save the day.

Although Rhysida operates as a "ransomware-as-a-service" provider employing double extortion, everything publicly known about the Berlin case suggests that data exfiltration—rather than encryption—is the primary focus.

Data exfiltration versus encryption: What is the difference?

After an encryption incident, a clean, immutable backup is the solution. After data exfiltration, it is not: —it is public, the data is gone and it cannot be retrieved. No restore process in the world can make a passport scan private again. As a provider of cyber resilience solutions, we believe it is crucial to state this unequivocally. No backup could have prevented the data exfiltration incident in Berlin.

What *would* have prevented it was a combination of endpoint protection, network segmentation, least-privilege access rights, MFA for remote access, training to counter social engineering, and—quite simply—avoiding the use of password lists in Word documents.

That is why, in our view, data resilience belongs at the heart of this discussion:

After all, the question Berlin has been unable to answer since August 14 is not "How do we restore the data?" but rather: "What exactly was exfiltrated, who does it belong to, and whom do we need to notify?" And the best way to answer that question is by using the backup.

What this case teaches us about data hygiene?

Before discussing tools, a point regarding organization: 5.8 terabytes comprising 1.44 million files from two specialized administrative departments—including job applications, sick notes, and copies of ID documents—represent not a data protection problem, but a data volume problem. Much of this material should have been deleted long ago in accordance with the retention and disposal policy. Data that no longer exists cannot be leaked

This is not an observation specific to Berlin. We see the same patterns in almost every health check file shares that have been growing for 15 years because no one is responsible for deleting data; exports and copies saved "just for a moment"; and yes, even password lists in Excel—at government agencies and DAX-listed corporations alike. The only difference is whether someone finds them before an attacker does. 

Proactive, preventive data protection: What cyber resilience delivers today

The leading platforms we primarily work with have evolved over the past three years from simple backup tools into comprehensive cyber resilience platforms. The underlying concept is that the backup represents the only point within an organization where the entire dataset can be examined regularly and comprehensively—without placing a load on production systems.

Regardless of the specific vendor, five categories of capabilities can be identified that would have made a difference in the Berlin scenario.

1. Knowing what you have: Data discovery and classification

These platforms now offer the ability—with varying degrees of depth and sometimes via add-on modules or partner integrations—to automatically scan stored data for sensitive content:

• Personal identifiers
• ID card numbers
• Health data
• Credit card numbers
• Custom-defined patterns.

The result is a continuously updated "data map": Where is personal data located? Where is security-related data stored? Where are files that resemble access credentials?

Having this information enables three actions that Berlin is currently having to catch up on under immense time pressure: selectively deleting legacy data, securing over-exposed directories, and—in the event of an incident—identifying within hours rather than weeks which affected individuals must be notified under the GDPR.

2. Detecting anomalies – even the "quiet signals"

The platforms' anomaly detection operates based on backup metadata: it identifies instances where an unusually high number of files have been modified, deleted, encrypted, or created between two backup points. However, simple read and copy operations do not generate such a signature; data exfiltration tends to occur "quietly."

The good news is that it is rarely completely silent. Attackers exfiltrating terabytes of data typically "stage" it beforehand—creating archives, compressing files, or moving them into aggregation directories. Patterns such as a sudden surge in data volume on a server, the appearance of large new archive files, or unusual activity during off-hours can be detected by comparing backup points and reported to a SIEM or SOC as an Indicator of Compromise.

To cite a concrete example of current detection accuracy: IBM, for instance, is taking things a step further with IBM Storage Defender by combining backup-level sensors with inline detection directly within primary storage, allowing anomalies to be spotted at the block level. A seven-day period of undetected presence represents a window of time where such an alert could have made all the difference.

3. Threat Hunting in Backups

All leading platforms today can scan backup points against threat intelligence feeds, malware scanners, or custom YARA rules. This makes it possible to answer two questions that remained unresolved for weeks in the Berlin incident: How long has the attacker been in the system—in other words, which backup point is the last clean one? And where did they move within the system? The backup becomes a forensic time machine, without the need to touch production systems.

4. The backup environment itself as a fortress

The Berlin incident illustrates what happens when access credentials are essentially left lying around: the attacker had an easy time of it. This applies doubly to backup infrastructures, as whoever controls the backup console controls the final line of defense. Immutable storage, logical or physical separation (air gap), MFA, the "four-eyes principle" for critical actions, and role-based access are standard today—but they must be activated, configured, and regularly audited.

5. Isolated recovery instead of nine days of downtime

Berlin took nine days to bring two administrative systems back online and has been examining 12,000 systems ever since. "Clean-room recovery" concepts—offered in various forms by cyber resilience platforms such as Commvault, Cohesity, IBM, Rubrik, and Veeam—make it possible to restore systems in an isolated environment, scan them there, and return them to production only after they have been cleared. This not only reduces downtime but also answers the question of whether it is safe to restart operations at all.

Reactive: The first 72 hours following a data breach

What specific actions would we have taken if a customer had called with this finding on August 14? Article 33 of the GDPR mandates a 72-hour window for notifying the supervisory authority. Realistically, within this timeframe, the following steps can be derived from a well-maintained resilience environment:

• Hours 0–12: Determine the "blast radius" (the scope of the incident). Which systems and file shares were accessible to the compromised accounts during the window of August 7–12? The backup points for these systems are "frozen"—serving as both evidence and a reference point.
• Hours 12–36: Determine the content. A classification run across the affected backup points yields the most critical information: What categories of personal data were present? How many data subjects were affected? Are there files containing access credentials? This list forms the basis for both the notification to the supervisory authority and the rotation schedule for all affected passwords and certificates—before the attackers can use or publish them.
• Hours 36–72: Clean restart. The process begins with a threat scan of the latest backup points against current Indicators of Compromise (IOCs), identification of the last clean point, restoration in an isolated environment, validation/release, and data reintegration. In parallel, business applications are restored according to a sequence pre-established in the Business Continuity Management (BCM) plan. Ideally, this sequence should be executed systematically rather than being "improvised" by the crisis management team on the fly.

"Vendor-neutral" does not mean "arbitrary"

We are frequently asked which of the leading cyber resilience platforms is "the best." The honest answer is: it depends on what you already have, the workloads you need to protect, the regulations that apply to you, and your operating model.

Moreover, the top five vendors we work with have different areas of focus: one emphasizes data classification and data security posture; another, cleanroom automation; a third, cyber vaulting; a fourth, inline detection and deployment flexibility; and the fifth, the integration of primary storage, backup, and recovery orchestration. We are familiar with all five through day-to-day operations, not just from product brochures.

Our role, therefore, is not to sell a product to customers, but to map the aforementioned capability categories to their specific environments: What is in place? What is configured? What is merely licensed? What is missing?

These questions go beyond strategy or technology to address organizational aspects within ISMS, risk management, and business continuity management—such as the underlying frameworks and whether data deletion policies, incident reporting processes, and recovery sequences are documented and regularly practiced

Conclusion

The Berlin incident will occupy us for a long time to come—due to its scale, the sensitive nature of the compromised content, and the House of Representatives election on September 20, against the backdrop of which the BSI is already warning of "hack-and-leak" operations.

For IT decision-makers in government agencies and companies, three lessons can already be drawn:

1. Backups do not prevent data exfiltration. However, the backup environment is the best place to maintain an inventory of your data, detect when an incident is occurring, and respond quickly and robustly in an emergency. That is the difference between simple backup and data resilience.
2. Data hygiene is a security task: Data that has been deleted cannot be exfiltrated. Data that has been classified can be protected.
3. The first 72 hours following an incident determine reporting obligations, the extent of reputational damage, and the protection of affected parties. If you haven't prepared for this phase, you lose it.

According to the BSI, extortionist groups carry out their threats to publish stolen data in 92 percent of cases. There is therefore no reason to assume things will play out differently next time. The only question is whether you will know what data was exfiltrated—or find out via the darknet.

Sources

Regarding the incident

1. heise online: "Cyberattack on Berlin could have greater consequences than previously thought," September 6, 2026. https://www.heise.de/news/Cyberangriff-Berlin-mit-Steuerungseinheit-will-Betroffene-kontaktieren-11442896.html

2. State of Berlin, Press and Information Office: “Attack on State Network: Data May Be Published,” September 3/4, 2026. https://www.berlin.de/aktuelles/10611709-958090-cyberangriff-auf-landesnetz-daten-werden.html

3. Behörden Spiegel: "Cyber-attack hits two Berlin Senate departments," August 18, 2026. https://www.behoerden-spiegel.de/2026/08/18/cyber-angriff-trifft-zwei-berliner-senatsverwaltungen/

4. IT-BUSINESS: "Hacker attack on Berlin: Ultimatum for 30 bitcoins expires," September 2026. https://www.it-business.de/cyberangriff-berliner-landesnetz-rhysida-zugangsdaten-a-1075a37146a5e21701176d1024021794/https://www.it-business.de/cyberangriff-berliner-landesnetz-rhysida-zugangsdaten-a-1075a37146a5e21701176d1024021794/

5. heise online: "BSI explains initial attack vector against Berlin authorities", September 7, 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

About the platform's capabilities (manufacturer specifications)

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

9. Cohesity: Threat Protection & Data Classification (former DataHawk, now part of Data Cloud Enterprise Edition). https://www.cohesity.com/platform/datahawk/

10. Commvault: Cleanroom Recovery and Threat Scan (comparison of products). 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", May 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), June 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", September, 2nd, 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, December 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, June 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

Regulation

20. EU Regulation 2016/679 (DSGVO) of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation) (Text with EEA relevance), Art. 33 and 34, Document 32016R0679 – Reporting Breaches of Personal Data Protection. https://eur-lex.europa.eu/eli/reg/2016/679/oj

Current State of the Facts

September 8, 2026, updated on September 9, 2026. The incident is still under investigation; details regarding the scope and content of the disclosed data are subject to change.*