Berlin’s Cyberattack: Why Refusing the Ransom Was Right, and What Must Change

As of October 2026

Berlin did not pay. On 4 September 2026 the attackers published stolen data, and in the official account reviewed here, the assessment of the affected data is still not finished. The refusal was right. The question I would put to any management board is a different one: what should prevent a compromised workstation from becoming a large-scale loss of confidential information? Answering it means keeping what the Berlin authorities have established apart from the technical details that remain unknown.

What the official account establishes

Berlin’s official account puts most of the data theft between 7 and 12 August 2026. On 14 August two affected Senate departments, one responsible for urban development, the other for mobility and the environment, were cut off from the state network. Publication followed on 4 September, after Berlin had refused to pay.[1]

The Senate Chancellery reported that Rhysida claimed the attack. Its statement of 3 September mentions a data auction with a minimum bid of 30 bitcoin. That is an auction floor. It is not independent evidence of the price at which the attackers would have called off publication.[2]

On 6 September Berlin reported a further release, this one including access credentials, and announced additional protective measures.[3] So the documented sequence is short: access, copying, extortion, publication. What the reviewed official accounts do not give is a complete technical attack chain. And the involvement of a ransomware group, on its own, is no proof that any Berlin system was encrypted.

How can an attack like this begin?

One relevant example is the TerminalFix campaign. Microsoft describes how a fake CAPTCHA tells the user to paste a command into Windows Terminal or PowerShell and run it. Later stages install malicious components and open remote access.[4] What looks like a browser check becomes code execution on the workstation.

Microsoft is describing a campaign, not reconstructing the Berlin attack. The official Berlin account reviewed here does not identify every step from entry to theft. It would be easy to fill the gaps with a careless employee, a missing control and a tidy lateral-movement path. I will not.

The defensive lesson holds either way. A web page that asks you to run a terminal command is not doing a human-verification check. Training should cover exactly that situation, by name. The technical controls must assume that a person may be deceived: one wrong action should not open unrestricted access to sensitive repositories or administrative systems.

Why refusing to pay was right

A ransom payment moves money to the attacker. It does not move control of the stolen copies back to the victim. A promise to delete proves nothing about copies already kept, sold or passed on. The FBI advises against paying and warns that payment does not guarantee recovery.[5]

That is the whole basis of my view on Berlin’s decision. It needs no invented success rate and no claim that every victim who pays ends up in the same place. Nor does refusing make the breach go away: containment, recovery, investigation and support for the people affected still have to happen.

Backups solve a different problem. They can support the restoration of backed-up data and services. They cannot make an attacker forget what has already been copied. An organisation therefore needs a plan for a service outage and a separate plan for a loss of confidentiality. Prepare only for the encryption scenario, and the second lever of extortion remains unaddressed.

Five recommendations

None of the following is a finding that a particular control was absent in Berlin. These are recommendations. No single recommendation guarantees prevention. The aim is to break the chain somewhere and limit what gets out.

1. Make dangerous execution harder. Check whether ordinary users need unrestricted scripting and whether application-control rules can block unapproved execution. Keep endpoint protection and software maintenance in working order. Test the restrictions against real work. Do not assume a blanket ban is either practical or sufficient; awareness and technical enforcement have to support each other.

2. Limit what one compromised identity can reach. Give people the access their role needs, separate privileged administration from everyday work, and review inherited rights after every role change. Test segmentation with one concrete question: from this workstation, which sensitive files and which administrative services can actually be reached? Answer it from a real workstation; the network diagram only shows what was intended.

3. Detect suspicious combinations. Unusual bulk reading, access to repositories a user never touches, unexpected archive creation and a new outbound destination deserve to be investigated together, in context. A volume threshold on its own can miss slow theft or flag legitimate transfers. Every alert needs a named responder and an escalation path that works outside office hours too.

4. Prove that recovery works. Protect backup administration separately and test restoration in a clean environment. Record whether essential services actually meet their recovery objectives; a finished backup job proves less than that. The UK NCSC’s guidance stresses separate backups and tested restoration.[6] This helps against disruption; it does not reverse a disclosure that has already happened.

5. Rehearse the first hour. Decide in advance who may isolate a device or a network segment, preserve evidence, disable compromised access and call in forensic support. Agree how legal, privacy, communications and operations work from the same verified facts. Then run the exercise with the cause still unknown. Waiting for certainty before every protective step can lose time; acting without writing down the reasoning can create new problems.

The exercise does not end with technical isolation. Ask afterwards which dependencies hamper emergency operations, whether the fallback communication works and who decides on reconnection. Record observations, owners and follow-up dates. Only a gap that has been found, fixed and tested again turns the exercise into an improvement; a signed attendance list alone does not show that.

People whose data has leaked need practical help too. Berlin’s data protection authority recommends watching for fraudulent contact attempts, checking financial activity and securing affected accounts.[7] The next convincing message they receive may contain genuine stolen details. Give them a verified contact route instead of leaving them to judge unsolicited offers of help.

The question to take away

Berlin was right not to buy an unverifiable promise from the people who had just robbed it. The longer task is to make extortion less effective: restrict access, spot malicious activity, recover essential services and respond as one organisation.

Take one question into the next management meeting: If an employee’s workstation were compromised today, what would stop the attacker before sensitive information left the organisation, and when did we last test it?

Sources

1. Berlin Senate Chancellery — incident information, updated 29 September 2026.
2. Berlin Senate Chancellery — situation statement, 3 September 2026.
3. Berlin Senate Chancellery — further data release, 6 September 2026.
4. Microsoft — TerminalFix campaign analysis, 28 August 2026. General campaign evidence, not a Berlin forensic report.
5. FBI — Ransomware.
6. NCSC — Mitigating malware and ransomware attacks.
7. Berlin data protection authority — guidance for affected people.

Sources checked on 2 October 2026. This is editorial analysis, not a forensic determination and not individual legal advice. In the official account reviewed here, the investigation and the assessment of the affected data are still incomplete. As of October 2026.