Berlin's government detected data exfiltration on August 7. However, the affected network wasn't isolated until August 17. During those ten days, Rhysida ransomware operators continued extracting data from the Senate Department for Mobility, Transport, Climate Protection, and Environment, ultimately claiming 5.79 TB across 1.44 million files before Berlin cut the connection.
This isn't about a sophisticated zero-day or an unstoppable threat actor. It's about the gap between knowing you have a problem and acting decisively to contain it.
What Happened
On August 7, staff at one of Berlin's Senate departments flagged unusual data movement. Between August 7 and August 12, Rhysida exfiltrated data that included personnel files, administrative records, plaintext credentials, and personal information on 12,076 individuals. Berlin isolated the compromised department on August 17 and disclosed the breach publicly. On August 28, Rhysida posted the breach to their leak site, demanding ransom. Berlin refused to pay.
The attack occurred weeks before Berlin's September 20 state parliament election. Interior Senator Iris Spranger confirmed no election-related data was compromised, and security officials assessed that the vote itself remained secure.
Timeline
- August 7: Internal teams detect unusual data outflow
- August 7-12: Data exfiltration continues
- August 17: Network isolated; breach disclosed publicly
- August 23: All Senate departments reconnected after initial forensic review
- August 28: Rhysida claims responsibility on leak site, posts ransom demand
- Late August: Berlin publicly refuses to pay ransom
Which Controls Failed or Were Missing
The ten-day gap between detection and isolation points to breakdowns in several areas:
Incident response execution speed. Detecting a problem means nothing if your team can't move from observation to containment. Berlin's internal teams saw the data movement on August 7 but didn't isolate the network until August 17. This reflects a decision-making and authority failure.
Network segmentation and containment boundaries. If one department's compromise required ten days to isolate, your segmentation isn't effective. Proper segmentation means you can cut off a compromised segment within hours, not days, without waiting for executive sign-off or cross-departmental coordination.
Access controls and credential management. A joint advisory from CISA, the FBI, and MS-ISAC published in November 2023 documented Rhysida's typical entry methods: compromised VPN credentials at organizations without multi-factor authentication, exploitation of Zerologon (a vulnerability Microsoft patched in 2020), and phishing. Berlin's breach suggests at least one of these known vectors remained open.
Privileged access monitoring. The attackers moved 5.79 TB of data over multiple days. That volume doesn't leave quietly. If you're not monitoring privileged account activity and large data transfers in near-real-time, you're relying on users to notice problems, which is exactly what happened here.
What the Relevant Standards Require
ISO/IEC 27001:2022, Annex A 5.24 (Information Security Incident Management Planning and Preparation) requires you to plan and prepare for handling information security incidents. That includes defining roles, establishing communication channels, and documenting escalation procedures. A ten-day gap suggests these weren't sufficiently clear or weren't followed.
ISO/IEC 27001:2022, Annex A 5.26 (Response to Information Security Incidents) requires you to respond to detected incidents according to documented procedures. The standard expects timely action. If your incident response plan doesn't include decision trees for immediate containment, you're not meeting this control's intent.
SOC 2 Common Criteria CC7.3 addresses how you detect, mitigate, and respond to security incidents. Auditors will ask: How quickly can you move from detection to containment? What's your documented timeline? Berlin's case would raise questions about whether escalation paths were clear and whether containment authority was appropriately delegated.
SOC 2 Common Criteria CC6.1 covers logical and physical access controls, including network segmentation. If compromising one department means you need ten days to isolate it, your segmentation isn't meeting the control objective of limiting the blast radius.
ISO/IEC 27001:2022, Annex A 5.23 (Information Security for Use of Cloud Services) and Annex A 8.20 (Networks Security) both touch on segmentation and boundary controls. If your architecture requires executive-level approval to isolate a compromised segment, you've built a bureaucratic bottleneck into a process that needs to be technical and immediate.
Lessons and Action Items for Your Team
Map your containment decision tree now. Who has authority to isolate a network segment without waiting for a committee meeting? If the answer involves more than two people or requires sign-off from someone in a different time zone, fix that. Document the threshold: What observable indicators trigger immediate isolation? Make it a checklist, not a judgment call.
Test your segmentation under pressure. Run a tabletop exercise where you simulate detecting exfiltration at 4 p.m. on a Friday. Can you isolate the affected segment within two hours? If not, identify what's blocking you: technical architecture, approval processes, or unclear ownership. Then fix it.
Audit your VPN and remote access configurations. Rhysida's known tactics include exploiting VPN credentials without MFA and leveraging Zerologon, patched in 2020. If you're still running VPN access without enforcing MFA, or if you haven't verified that Zerologon patches are deployed across your environment, you're leaving the same doors open that Berlin's attackers likely used.
Monitor privileged account activity and large data transfers in real time. Configure alerts for unusual data movement from privileged accounts. Define "unusual" with specifics: transfers over a certain size, connections to external IPs outside normal business hours, or access to file shares that account doesn't typically touch. Tune these alerts so your team can act on them, not ignore them.
Document your "refuse to pay" position before you need it. Berlin's refusal to pay ransom aligns with guidance from CISA and the FBI, but that decision is easier to make if you've already established the policy. Decide now, document it in your incident response plan, and make sure your executive team understands the implications: You will not pay, which means you need resilient backups and a tested recovery process.
Review your backup and recovery architecture. If refusing to pay ransom is your policy, your backups need to be immutable, tested regularly, and stored offline or in a way that ransomware can't reach them. Schedule quarterly recovery drills. Measure your recovery time objective and make sure it's realistic.
Berlin's breach won't be the last time a government or enterprise detects a problem and then takes days to act. The gap isn't about technology. It's about whether your incident response plan gives your team the authority, the tools, and the clarity to move from detection to containment in hours, not days.
