Skip to content

Cyberattack

The cyberattack on Berlin's state network: seven days undetected, five days of data outflow

Attackers were undetected in Berlin's state network for seven days. What is documented, who bears the damage once operations resume, and what other organisations can check for themselves.

By · Published 19 August 2026 · Updated 5 September 2026 · 20 min read

This analysis first appeared on 18 August 2026 as a provisional assessment, when almost nothing about the incident was documented. Official accounts of the sequence are now available, and the situation has turned repeatedly: first over the data outflow, then an extortion attempt, most recently a sale offer from the perpetrators. This version, from 4 September 2026, adds the sale offer and the question of who bears the damage once operations resume, and settles which of our earlier assumptions held.

The author is founder and managing director of KaitoSec.

In brief

  • Attackers had access to Berlin's state network from at least 7 to 14 August 2026. This was noticed on 14 August, when both affected senate departments were disconnected from the network.
  • From 7 to 12 August, data flowed out of the remit of the Senate Department for Mobility, Transport, Climate Protection and the Environment. The Senate no longer rules out personal and other non-public data, correcting its earlier account.
  • The way in was a phishing email opened by a member of staff.
  • Since 23 August both departments have been back on the state network, the specialist procedures are running in principle, and housing benefit for more than 50,000 households could be paid out.
  • On 28 August the state confirmed an extortion attempt and rejected the demand. It concerns 30 bitcoin, around two million euros. Since then, the haul has been up for auction on the perpetrators' leak site.
  • Operations have resumed, but the situation has not: after a data outflow, the damage migrates to people who had no part in the incident, and returns from there as a duty to respond to inquiries and as preparation for the next attack.

What happened

According to the Senate Chancellery, access began no later than Friday, 7 August 2026. From that day, the attackers copied data from the transport and environment department's remit until 12 August. None of it was noticed at the time. 6

On 14 August, forensic investigations established that the state network had been compromised. That same day, two senate departments were disconnected for security reasons: Urban Development, Building and Housing, and Mobility, Transport, Climate Protection and the Environment. On 17 August the Senate Chancellery informed the public and confirmed the involvement of the State Criminal Police Office, the public prosecutor's office and the Federal Office for Information Security. A crisis team led by the state commissioner for information security coordinated the work. 1, 9

In the days that followed, it became clear what the disconnection meant in practice. Staff described themselves to the press as effectively unable to work. Housing entitlement certificates, misappropriation checks, land registry inquiries, and applications for housing benefit and education-and-participation benefits went unprocessed. 2, 3

By 23 August, according to the Senate Chancellery, both departments were back on the state network, and the payment of housing benefit to more than 50,000 households was secured. A good two weeks had passed since initial access, nine days from detection to reconnection. For an incident that took two administrations off the network, that is fast. 4

Then the situation turned twice. On 26 August the Senate corrected its statement on the data outflow: initially it said the data affected was geodata, already freely accessible through open government data; now personal and other non-public data could no longer be ruled out. 5 On 28 August the state confirmed an extortion attempt. The Governing Mayor Kai Wegner stated publicly that Berlin would not be blackmailed. According to media reports, the perpetrators are demanding 30 bitcoin, around two million euros. 6, 7

Since 28 August, the haul has been up for auction on the group's leak site, with excerpts as a sample. The perpetrators put it at 5.79 terabytes across around 1.44 million files, and cite figures of 12,076 individuals, 16,389 email addresses, 11,963 phone numbers and 148 IBANs, along with more than 5,000 personnel files and 124,823 map and geodata files. No authority has confirmed this inventory. 11

How the attack ran

The path has four stations. The first two are reported and not officially confirmed; the last two the state disclosed itself, though not the volume of data.

It starts with a mailbox. A member of staff opened a phishing email carrying malware, and it executed on the workstation. That is everyday life in any organisation with email, and on its own it is not what is remarkable here. 7

From the compromised workstation, access reached further, into the shared state network and the remit of a second senate department. What the authorities have confirmed is that the data outflow hit the remit of Mobility, Transport, Climate Protection and the Environment. No authority names where access began; a broadcast report places the starting point in non-migrated specialist IT at the building administration, unconfirmed and not denied. That stretch is what this case is about. 6, 10

Over five days, data then left the environment. Tagesspiegel put the volume at 5.7 terabytes on 28 August; on their own leak site, they have since put it at 5.79 terabytes across around 1.44 million files, listing contracts, personnel files, passwords, and map and geodata files. That inventory is the perpetrators advertising their own haul, and we carry it as their claim. What the authorities have named is the period, not the volume. 7, 11

At the end comes the demand. No encryption has been reported anywhere; the extortion rests solely on the threat of reselling and publishing the copied data. For those affected, that shifts the incident from an outage that is over to an open question nobody in Berlin decides. 6

Whether access existed before 7 August, nobody has said. The seven days are therefore a lower bound.

Where it could have been broken

What protection was in place in the two departments, nobody outside the forensic investigation still knows. For part of the chain, though, the official accounts now support a statement about the time after the first click.

The incident was detected on 14 August, access had existed since 7 August, and in between, according to the perpetrators' own inventory, a terabyte-scale volume of data left the environment. So detection existed; it took effect only after the outflow. Two measures work against that: a central evaluation of security-relevant events that decentrally operated systems are connected to as well, and network flow data on which an unusual exfiltration stands out while it is happening.

Network separation addresses the spread. Separation was in place, since both departments could be taken off the network within a day; but by then access had already reached beyond its starting department. It is the most demanding of the measures named here, and the only one that confines an incident to a single department.

Against delivery, malware filtering at the mail gateway helps, because it catches the attachment before anyone can open it. Behind that sits endpoint protection noticing the execution. Alongside that, staff awareness counts, above all through the reporting route: someone who speaks up within minutes of a click shortens the seven days at issue here.

When specialist procedures fail, the administration's planning decides. During the disconnection, applying for and paying out housing benefit was not possible, and by its own account the payment was secured under considerable pressure. A prepared fallback procedure for deadline-critical services, that is, a planned and rehearsed way to deliver the service without the usual technology, does not stop the attack. It keeps the consequences away from people who have nothing to do with any of it. 2, 3

On the way out, one measure works that is rarely discussed: restricting outbound traffic to approved destinations. Five days of outflow need a route out, and as a rule that route does not run through an address the administration otherwise exchanges data with. The rule itself is quickly set; the work sits in the list of permitted destinations.

Everything named so far concerns the time in which something can still be prevented. In the situation Berlin has been in since 28 August, that is over: the data is out of the building, and a deadline is running. What still works now limits the consequences.

What counts most then is a decision made before the emergency strikes: who decides on a payment, by what criteria, who checks its legal permissibility, and who speaks to the outside world. Berlin rejected the demand publicly the day after it arrived. That sounds self-evident, and it is not. Without a prepared line, that decision falls under a visible countdown, made by people thinking about it for the first time that night, often without the legal review it requires: a payment can be impermissible under sanctions law, and a promise by the perpetrators to delete the data afterward is backed by nothing.

Alongside that, the reporting and communication routes count. In this case the State Criminal Police Office, the public prosecutor's office and the Federal Office for Information Security were involved from the outset, the data protection supervisory authority is kept informed on an ongoing basis per the Senate Chancellery, and the public learned of the extortion from those affected themselves. Anyone who first looks for these routes during an incident loses days the reporting deadlines do not allow for. 1, 6

And what to do after a publication counts too. According to the perpetrators' inventory, files containing credentials are among the haul. Whether that is true, nobody currently knows; anyone who assumes it is true rotates the affected credentials before they go public, and prepares the notification of data subjects under Art. 34 GDPR rather than starting it on the day of publication. 7

What the outage costs

Nobody has put a figure on the damage, and it cannot be responsibly estimated at present. What is measurable are the durations and the consequences.

For nine days, two departments were in a state of exception: no internet, no outbound email, no remote work, reachable only by phone, several specialist procedures fully suspended. On top of that comes the tied-up capacity that appears in no invoice and, in long-running cases, is the largest item: crisis team, weeks of forensic work, federal and state security authorities. 2

Financially, the housing benefit payment to more than 50,000 households was at risk, since it usually falls at month's end. It held, because reconnection succeeded in time. 3, 4

Legally, the part that will take longest is under way. The deadline for a notification under Art. 33 GDPR starts with knowledge of the incident, not with clarity about its scope. Anyone waiting for the forensic result reports too late. The Senate Chancellery states it is keeping the state data protection commissioner informed on an ongoing basis. 6

The administration carried the exceptional operation itself. The visible part was carried by applicants, while the specialist procedures were down. With the publication threat, a third group joins them: people whose data, according to the perpetrators' inventory, sits in a regulatory offence file or a contract, and who will only find out once it is published.

Who bears the damage once operations resume

The resumption of operations ends one half of the situation. Its costs fall where the incident happened, and end with it: exceptional operation, forensics, tied-up working hours.

The second half leaves the building. What was copied affects people who did not cause the incident, did not notice it, and did not fend it off. For them there is no resumption. A backup restores availability; it has no effect on confidentiality. This burden ends only once the information is worthless to third parties, and that point rarely comes.

From there it comes back by two routes, neither documented for this case and both reconstructed from the pattern of comparable incidents. The first is legal. Every request for information under Art. 15 GDPR, every notification under Art. 34, and every claim under Art. 82 is a case-by-case review against a dataset the affected body can barely survey after an outflow of this size. On top of that comes the parliamentary inquiry, which carries no legal obligation and ties up the same people who just handled the resumption.

The second route back weighs more heavily. Anyone who knows an administration's processes and the people behind them needs no technical vulnerability for the next access attempt. An approach that correctly names the case and its status works better than a technical tool. The outsourced damage thereby becomes preparation for the next incident, and that one hits the department again.

Part of this burden falls through the cracks here. Some administrative records protect no individual. They describe a procedure: how warnings and evacuations happen in an emergency, who alerts whom, where a responsibility hands over. Art. 34 does not apply here, because it presupposes a risk to natural persons. Anyone who works through only the data protection track after an outflow never evaluates this part. It belongs in a track of its own, with the security authorities and the affected third parties.

What other organisations can check now

The case transfers to any organisation with a shared network and decentrally operated specialist IT: state and municipal administrations, corporate groups with organically grown subsidiaries, any organisation with a centralisation still under way. And it applies to any organisation holding large volumes of personal data whose publication would cost more than its unavailability.

These questions can be answered without a project:

  • How long would access have gone unnoticed here, and who can show that figure from data rather than estimate it?
  • What volume of data can leave our environment without triggering a rule, and who sees that rule?
  • At what duration of outage does one of our services become expensive or legally sensitive, and how is it delivered then?
  • Who would we have to notify if our files were exposed tomorrow, and where would we get the addresses? For our own staff, that is solved. For rejected applicants, closed proceedings and second-tier service providers, rarely.

From the answers follows a short list of measures, ordered by the earliest station of the attack path. It spreads across several areas of responsibility, and none of them closes the chain alone.

  1. Record every operated system in an inventory, including those never migrated to central operations; a job for IT operations together with the specialist departments. It is the cheapest measure on the list and the precondition for all the others, because what is in no inventory is not monitored. Visible in the inventory's coverage.
  2. Connect the decentrally operated systems to the central evaluation of security-relevant events, through security monitoring. The effort sits in the connection, not in the platform; measurable in log coverage of critical systems and time to detection.
  3. Separate specialist procedures from the shared network, in network operations together with the specialist administration. This takes years. Anyone taking it on defines beforehand what counts as separated, and tracks the share of procedures meeting that criterion; otherwise the undertaking peters out between two budget years.
  4. Collect and evaluate network flow data, in network operations together with security monitoring. An outflow spanning days should trigger a rule while it runs; visible in the active detection rules.
  5. Restrict outbound traffic to approved destinations, in network operations. There is no established metric for this, but the figure can be tracked in-house: the share of network segments with an enforced allow list, and every exception documented and time-limited.
  6. Plan and rehearse emergency operation for deadline-critical services, in the specialist administration together with business continuity management. Visible in how many critical processes have a tested fallback route, and when it was last rehearsed.
  7. Decide the handling of extortion demands in advance, in leadership together with the legal department. This is the cheapest measure on the list and the only one that takes effect only after the attack: it costs one meeting, and it decides whether the response to a demand takes hours or days. It is tested in the crisis exercise, and that is where it is measurable too.
  8. Define and record the reporting and communication routes, in business continuity management together with data protection. Anyone who first looks for the supervisory authority during an incident loses time the reporting deadlines do not allow for; measurable in the punctuality of notifications.

The measures interlock: what the inventory makes visible, the central evaluation has to see and the flow data has to report; what flows out anyway, the outbound limit has to slow and network separation has to contain; and whatever is left after that meets an organisation that knows who decides and whom to call. Distribute the list across separate departments, working it separately, and the result is eight green ticks and the same gap.

A comparable case from the same summer shifts the question outward. In the cyberattack on a small power station in the United Kingdom, the incident stayed publicly unknown for four weeks because the plant fell below the UK reporting threshold. In Berlin, detection took too long; there, it was visibility to the outside.

How we arrive at this assessment

We work through every case using the same procedure: state of the sources, attack path, where it could have been broken, causes, business consequences, measures, transferability, limits. Every statement carries an evidence level. Documented means an authority, a court or the affected organisation itself has published it. Reported means several independent media outlets or a forensics provider. Reconstructed means derived from the pattern and not confirmed in this case.

The first version of this article worked in remote mode, because the incident was a few days old. Four disclosed assumptions carried it, each with its basis, its counter-assumption and the observation that would overturn it. Here is how they settled.

Initial access via a mail attachment has been confirmed. That the access was not confined to a single department has been confirmed. That data flowed out has been confirmed, and the data that left is more sensitive than first stated. The fourth remains open: whether an area never migrated to central operations stood along the path. A report by the public broadcaster named this, and nobody has confirmed or denied it. 10 It would be overturned by a forensic account routing the path exclusively through centrally operated systems. So three of four assumptions held, and the open one is exactly the one for which there was never an official source.

What we weighted wrongly at the time is the core statement itself. It held that an opened attachment only becomes an incident for the whole state through a network that does not end there. That still holds, but it does not name the most expensive part. That lies in the seven days in between.

Limits and open questions

Initial access via a phishing email comes from an authority briefing and is reported through the media, not from a published forensic result. The scope and nature of the copied data, in their figures, come from the perpetrators themselves; what the authorities have named is the period. Whether access began before 7 August is unknown, which makes the dwell time a lower bound. Whether and when a notification under Art. 33 GDPR was made is not publicly known.

The forensic investigations are ongoing. 6 Later publications may shift individual statements in this article; we will add them here when they do.

On the question of attribution, we hold back. There is a demand with a deadline and a threat of publication, so a profit motive, and per the reporting, the authorities involved name no indications of state actors. A group has claimed the attack; no attribution by a competent authority exists. Either way, the attribution question changes nothing about the measures.

Sources

  1. Senate Chancellery Berlin, press release on the ICT incident in Berlin's state network, 17.08.2026. berlin.de
  2. Tagesspiegel, reports on ability to work and the endangered housing benefit payment, 18.08.2026. tagesspiegel.de
  3. Berliner Zeitung, consequences for housing benefit and education-and-participation benefits, 18.08.2026. berliner-zeitung.de
  4. Tagesspiegel, reconnection of both senate departments and secured housing benefit payment, 23.08.2026. tagesspiegel.de
  5. Berliner Zeitung, Senate concedes a possible outflow of personal data, 26.08.2026. berliner-zeitung.de
  6. Senate Chancellery Berlin, press release on the extortion, with the outflow period of 7 to 12 August, 28.08.2026. berlin.de
  7. Tagesspiegel, timeline of the undetected access, initial access via a phishing email, and the size of the demand, 28.08.2026. tagesspiegel.de
  8. WirtschaftsWoche, carrying a Reuters report from security circles on initial access via a malware attachment, 18.08.2026. wiwo.de
  9. heise online, investigations and isolation from the state network, 17.08.2026. heise.de
  10. Report by the public broadcaster (rbb) on the starting point in non-migrated specialist IT of the affected administration, referenced in follow-up reports; no findable individual article is available, hence no deep link. rbb24.de
  11. Tagesspiegel and trade press on the leak-site auction offer, with the perpetrators' figures on scope and content, 31.08.2026. tagesspiegel.de

Status and updates

As of: 04.09.2026 · Status: under observation, next review on 15.09.2026.

18.08.2026: First published as a provisional assessment. All stations of the path were reconstructed.

24.08.2026: Two internal references added, the address in the review questions changed to the neutral form, source references added in the text, and the text edited against the style rules for external writing. Substantively unchanged.

29.08.2026: Fully revised following new facts. Newly documented are the timeline of access from 7 to 14 August, the data outflow from 7 to 12 August together with the Senate's correction on sensitivity, the reconnection on 23 August, and the extortion confirmed on 28 August. The attack path has gained a fourth station. The core statement has changed: dwell time weighs more heavily than lateral spread. The four assumptions of the first version are resolved and settled in the section on method. Also added is what works within the extortion situation itself: the decision on handling demands made in advance, the reporting and communication routes, and the restriction of outbound traffic.

31.08.2026: Details on the sale offer added. The haul has been up for auction on the leak site since 28 August; the perpetrators put it at 5.79 terabytes across around 1.44 million files and cite figures for 12,076 individuals. This inventory is unconfirmed and marked as the perpetrators' claim.

04.09.2026: Added the consequences after the resumption of operations. New is the section on who bears the damage once operations resume, with a fourth review question on notification. The sequence of the attack remains unchanged.

05.09.2026: Added one internal reference: the passage on the decision that must be made in advance (who decides, by what criteria) now links to our in-depth analysis of that decision. Otherwise unchanged.

At the next review date we will look at three points: the outcome of the extortion deadline, including any publication, an answer to a parliamentary inquiry with details on initial access and detection, and any indication of a notification under Art. 33 GDPR or a notification of data subjects. We update this article even when our assessment turns out to be wrong.

This analysis also appeared as a post on LinkedIn, there with the summary graphic for the case.

How we work. KaitoSec analyses cyberattacks using a fixed procedure and derives from them measures with demonstrated effect, for organisations with organically grown IT and regulatory pressure. The procedure is disclosed, and so are the case analyses. Talk to us about it.

Professional assessment, not legal advice.

  • Cyberattack
  • Case Analysis
  • Public Administration
  • Attack Detection
  • Extortion
  • Network Segmentation
  • BCMS
  • NIS2
  • GDPR
  • Berlin
  • Compensation Claims

Back to the blog