CASE FILE #01: Berlin: 5.8 TB on the Dark Web

Why Access Protection Alone Is Not Enough

1.44 million files. Approximately 5.8 terabytes of data. In the cyberattack on parts of the Berlin administration, large amounts of information were copied in August 2026 and later published on the dark web.

The incident highlights a key limitation of traditional cybersecurity: Organizations and public authorities must prevent attacks while also being prepared for the possibility that security mechanisms may be overcome.

The crucial question then becomes: What can an attacker do with the stolen data?

1. What Happened?

Between August 7 and 12, 2026, attackers were able to copy data from parts of Berlin’s state network. Two Senate administrations in particular were affected.

On August 14, the affected systems were disconnected from the network. The group Rhysida claimed responsibility for the attack and demanded a ransom of 30 Bitcoin. Berlin did not pay.

On September 4, 2026, the attackers published the copied data on the dark web. Media reports put the volume at approximately 1.44 million files, or 5.8 terabytes.

2. How Did It Happen?

The full technical cause was still subject to forensic investigation after the incident became known.

What is clear is that the attackers were able to copy large amounts of data over several days before the affected systems were isolated.

Without conclusive forensic findings, it would not be reliable to identify a specific attack vector as the cause.

3. What Data Was Affected?

According to the State of Berlin, the data consisted primarily of unstructured data from shared and personal directories used by employees.

This included personal information relating to employees, citizens, and organizations.

The incident therefore highlights the particular risk posed by large collections of files and documents: Over many years, information with very different protection requirements can accumulate in shared storage locations.

4. What Consequences and Risks Arise?

A compromised password can be changed. A published document, by contrast, cannot be reliably taken back.

Stolen information can be used over the long term for phishing, social engineering, identity theft, or to prepare further attacks.

The more sensitive and extensive the published information, the greater the risk that different data sets can also be linked and combined.

5. Which Traditional Security Measures Are Necessary?

A layered security strategy includes measures such as patch and vulnerability management, multi-factor authentication, least privilege, network segmentation, endpoint security, and continuous monitoring.

These should be complemented by anomaly detection and effective incident response.

Such measures reduce both the likelihood of a successful attack and an attacker’s ability to move within the infrastructure.

6. Why Are These Measures Alone Not Enough?

None of these measures can guarantee that an attacker will never gain access to a system.

Once the access layer has been overcome, a second security question therefore arises: Does access to the system automatically mean that the information available there is accessible in plaintext?

This is precisely where the limitation of a security architecture focused exclusively on systems, networks, identities, and access rights becomes apparent.

7. How Does Data-Centric Security Help?

Data-Centric Security is an approach in which sensitive information itself is protected, for example through encryption, tokenization, or masking.

Protection is therefore implemented as close to the data as possible, complementing the security of networks, applications, and user accounts.

The goal is simple: Successful access to a system should not automatically mean access to usable plaintext.

8. How Could eperi sEcure Have Protected the Data?

eperi sEcure can encrypt, tokenize, or mask sensitive information in supported applications and data flows before it is transferred to cloud applications or external systems.

The cryptographic keys can remain under the customer’s control.

If particularly sensitive data within suitable data flows had already been protected before entering an environment that was later compromised, an attacker there would not necessarily have found usable original information.

9. What Is the Key Lesson from the Incident?

The Berlin cyberattack is an example of the Assume-Breach principle.

Cybersecurity must, on the one hand, prevent attackers from compromising systems. At the same time, the architecture should account for what happens if that nevertheless succeeds.

The lesson from CASE FILE #01: Protect not only systems, but the data itself.

The eperi Lesson: Assume Breach. Protect the Data.