1.4 million files, one leak, many open questions: The analysis of the RHYSIDA attack on Berlin

Key: [OBSERVED] evidenced and sourced | [ASSESSED] expert assessment | [SCENARIO] possible scenario, not evidenced as having occurred.

Rhysida Leak-Site

Title image – RHYSIDA leak site. Authentic screenshot excerpts of the “Berlin, Germany” entry (Tor network): window header, capacity figure (5.79 TB, as stated by the attackers) and data catalog line (5.26 TB / 1,439,893 files). The entry was published by the group itself; the file list and sensitive details are redacted. Retrieved as part of the analysis, as of 12 October 2026.

TL;DR

  • [OBSERVED] In 2026, the ransomware group RHYSIDA gained access to the networks of two Berlin Senate Departments. The exact time of initial access is not publicly known; the investigation is ongoing. [1]
  • [OBSERVED] Berlin dates the bulk of the data exfiltration to 7 to 12 August 2026. Two Senate Departments were disconnected from the state network as a precaution on 14 August; RHYSIDA published the data on 4 September. [1][11]
  • [OBSERVED] Media reported an extortion attempt with a demand of 30 Bitcoin (around two million euros at the exchange rate at the time); the State of Berlin stated it would not pay. [2][11][12]
  • [OBSERVED/ASSESSED] According to RHYSIDA, the data volume is 5.79 TB and around 1.44 million files. Der Tagesspiegel reported 5.26 TB and 1,439,893 files. Our own analysis shows 5.25 TB, 1,431,884 files, and 150,480 folders. [2][3]
  • [ASSESSED] A leak of this size cannot readily be analyzed: downloading over the Tor network, taking inventory, test runs, file-type-specific extraction, and human quality assurance are all very time-consuming.
  • [SCENARIO] Because of Berlin’s role as capital and seat of government, the incident could have critical consequences.
  • [SCENARIO] Indirectly affected third parties (organizations and individuals who worked with the Berlin Senate Departments) can be found in the data sets, which in some cases can mean critical risks for these entities.
  • Because some of our customers are also affected and have approached us, we downloaded the data and analyzed it on a customer-specific basis to determine the degree of exposure and the existing risk for our customers.

Status: Sources as of 13 October 2026; publication date 12 October 2026. Author: NSIDE.

Background: What Is Publicly Known

Berlin, two Senate Departments, one data leak: The case is publicly documented in its essentials, and the review is ongoing. The verifiable state of affairs:

[OBSERVED] Berlin confirms access to the administrative network and the publication of data on 4 September 2026. According to authorities, the bulk of the exfiltration falls in the period from 7 to 12 August; two Senate Departments were disconnected from the state network as a precaution on 14 August. The affected material is predominantly unstructured data from shared and personal directories – the full review is still ongoing. [1][11]

[OBSERVED] The case escalated publicly in late August: RHYSIDA claimed the attack and, according to consistent media reports, demanded 30 Bitcoin – around two million euros at the exchange rate at the time – with a deadline of about one week. The Governing Mayor confirmed the extortion attempt and stated that the State of Berlin would not give in to blackmail. No payment was made; in early September, the archive was published on the dark web. [2][11][12]

[OBSERVED] In the night leading up to 6 September, the group published another data package, according to the Senate; media reported that it contained access credentials, among other things. [14]

[OBSERVED/ASSESSED] According to RHYSIDA, the data volume is 5.79 TB and around 1.44 million files. Der Tagesspiegel reported 5.26 TB and 1,439,893 files. Our own analysis shows 5.25 TB, 1,431,884 files, and 150,480 folders. [2][3] How the remaining differences between the claim, the media report, and our own count can be explained is still open.

[OBSERVED] The public timelines do not align either. Berlin dates the bulk of the data exfiltration to 7 to 12 August. The Hacker News reported on 28 August, citing a statement from the Senate Chancellery, that the affected administration had already reported a data leak on 7 August; a Berlin.de/dpa report describes the attack as detected on 14 August. The sources do not explain in detail how this report, the detection of the attack, and the subsequent network disconnection relate to each other. [1][2][10][11]

[ASSESSED] The time gap is remarkable – but it proves neither seven days of unnoticed access nor any specific failure. It is not publicly documented what was verified, escalated, or decided when. Moreover, the official exfiltration window is not a verified time of intrusion: file timestamps alone would not prove when a copy was made, and an independent cross-check has not yet taken place.

Timeline Rhysida Berlin Attack

Figure 1 – Timeline. Separates the data leak report of 7 August from the official exfiltration window (7 to 12 August), the detection of the attack on 14 August, and the publication on 4 September. The public sources do not fully explain how these events relate. [1][2][10][11]

Rhysida Data Volume of the Attack

Figure 2 – Data Volume. Three figures on the scale – attacker claim, media report, and our own count: different bases, no forensic proof of the original exfiltration. [2][3]

Step 1 – Download: The Long Road Through Tor

Between “the group has published” and “we can evaluate the data set” lies a problem that is easy to underestimate when terabyte-scale leak data is provided exclusively over the Tor network – on infrastructure known for slow, unstable connections. A naive download fails at sheer size: connections drop, and simple tools start from scratch after every interruption. With several terabytes and more than one million files, this is not a nuisance but a project of its own.

[ASSESSED] Anyone who wants to evaluate such a data set therefore first needs a download process that survives interruptions and makes every download traceable. The difference between “it somehow worked” and a solid foundation is the proof of completeness, despite changing download mechanics on the RHYSIDA server: the same file, the same size, the same hash.

[ASSESSED] That is exactly why we at NSIDE built our own Tor downloader. Downloads are processed intelligently and harmonized across large container farms. The crawler distinguishes connection problems in the Tor network from outages of the RHYSIDA hidden service and, during confirmed disruptions, waits with increasing intervals instead of running into a void – then resumes exactly at the last position. It also automatically handles the download mechanics that changed several times (file trees vs. TGZ containers). A ledger in an SQLite database records the status of every file, so we never lose the thread and always know the state the downloads are in. Given frequent RHYSIDA server outages, very high demand for the files, limited bandwidth per user, and the slow Tor network, a conventional download would have taken months. Our downloader completed the download in around two and a half weeks.

Step 2 – Initial Review: What the Data Set Contains – and What It Means for Those Affected

Before the automated analysis, we deliberately looked inside the data set ourselves – samples instead of assumptions. What we saw was sobering.

First, though:

[OBSERVED] What the Senate Departments themselves disclosed: Berlin describes the leaked holdings as predominantly unstructured data from shared and personal directories – not an extract from specialized business applications. Personal data of employees, citizens, and companies may be among it; the full review is ongoing. The Berlin data protection supervisory authority also emphasizes: a blanket statement by attackers or media does not prove individual exposure. What matters is a robust case-by-case review – not the headline. [1][4]

[OBSERVED – our own review] What we saw:

Data Protection Notice: We do not show any individual findings, names, or example hits, because file names, subject lines, timestamps, or the combination of just a few characteristics can already allow conclusions about affected individuals.

We found, among other things:

  • Planning documents on critical infrastructure – including government buildings and energy and water supply facilities (without naming specific sites)
  • More than five million email messages from 1999-2026, including attachments (.pst, .ost, .msg, .eml, and others)
  • Participant lists and details of events classified as GEHEIM
  • Hundreds of access credentials for internal and external systems
  • Extensive documentation on the IT infrastructure of the Senate Departments
  • Personnel files with various personal details
  • Legal files and details on court proceedings
  • Extensive insights into internal procedures and processes with references to other authorities
  • and much more.

Step 3: Automated Analysis Pipeline for Purpose-Specific Review of Affected Customers

Analyses like this are not done out of curiosity but for a specific purpose: to answer critical questions for our customers – are we affected, and if so, where? Because personal data is involved, our analysis pipeline runs entirely locally: there is no cloud-based analysis of the data.

Our rhysida-analyzer pipeline essentially does the following:

  • Inventory and extraction: The raw data set yields analyzable content – archives, Office documents, PDFs, images (OCR), database exports. In the standard workflow, files are read, not executed.
  • Rules and prioritization: We develop the rule catalog together with the respective customer. A first pass flags all files that match a mention pattern; a second pass searches these hits for previously defined relevance patterns – such as personal data relevance, classification, access credentials, or contractual references – and prioritizes them for further review.
  • Email holdings: Supported mailbox formats are processed message by message; attachments and threads can thus be placed in context and also searched and prioritized according to rules and patterns.
  • Local second opinion: An initial, automated assessment by a local language model (LLM) supports prioritization and makes it easier for a reviewer on the customer side to evaluate the many hits.

A non-match on relevance patterns nevertheless remains an open point, not proof of absence; OCR coverage and special formats are workstreams of their own. Our tool separately reports skipped or unevaluated data: excluded formats, extraction errors, incomplete OCR coverage, duplicates, and false positives.

Quantity is no substitute for quality: a data set of this size does not become manageable by scanning everything, but by prioritizing correctly, incorporating context, and being able to substantiate every statement in the end. That is the difference between a data dump and a professional data analysis that genuinely helps those affected.

Analysis Rhysida Berlin Workflow

Figure 3 – Analysis Workflow. Intake with chain of custody > format triage > extraction & OCR > rules > email review > optional local second opinion > human QA > report with coverage limits. Content that was not extracted remains visible as open coverage, not as a negative finding.

Step 4: Report Generation

After the analysis, a structured HTML report is created: a table with risk prioritization, sorting and filtering options, and all details the reviewer on the customer side needs. Since all analysis data is available as structured JSON, the format can be adapted flexibly.

Threat Intelligence Assessment: RHYSIDA, Berlin and the Federal Dimension

[OBSERVED] In a joint advisory, CISA, the FBI, and MS-ISAC describe RHYSIDA as a ransomware-as-a-service operation: tools and infrastructure are shared under a profit-sharing model, and data exfiltration and extortion are among the group’s documented patterns. Since May 2023, the advisory names predominantly education, healthcare, manufacturing, IT, and government as target sectors – “targets of opportunity”. Among observed initial access vectors, it names compromised valid credentials at external VPN gateways, among others. [5]

[OBSERVED – media report] According to a report by heise online (7 September 2026), the BSI (Germany’s Federal Office for Information Security) has confirmed that the attackers gained access to the Berlin Senate’s networks via the TerminalFix method – a variant of the ClickFix campaign (fake captcha, PowerShell command). The BSI security advisory itself describes the compromise of a state institution without naming Berlin. [13]

[OBSERVED] On the question of who was behind the attack in the Berlin case, Berlin itself has so far said: a criminal attack. The reviewed FAQ does not contain a technical confirmation of attribution. A Senate spokesperson was quoted on 1 September as saying there were no findings of connections to Russia or the Russian state – but that they could not be ruled out. In its group overview, the BSI lists RHYSIDA in the context of the criminal actor Vice Spider (named by CrowdStrike); no state attribution is associated with this. [1][2][6][9]

[ASSESSED] The reviewed public sources contain no evidence of a Russian state contract or direct state control of the attack. Language and infrastructure indicators alone do not support such an attribution. Conversely, it remains a separate scenario if published information were later used by state or other actors – that says nothing about the authorship of the attack.

Why the Incident Is Not Just a Matter for the State of Berlin

[OBSERVED] Berlin is the capital and seat of government; central government functions converge here. The Berlin information page names the BSI and other federal and state security authorities as involved in the investigation. A compromise of federal IT has so far not been publicly confirmed. [1][7][8]

[ASSESSED] An incident of this kind in the Senate can also affect the federal level. Because of the capital city function and federal-state coordination, the incident is strategically relevant at the federal level – to be distinguished from the question of which systems were technically affected.

Rhysida Berlin Government Seat

Figure 4 – Why the Seat of Government Matters. Separates the evidenced location of the incident, the expert assessment of federal relevance, and unconfirmed points – a compromise of federal IT has not been publicly confirmed. [1][7][8]

[OBSERVED – our own review] In the data reviewed so far, we found, among other things, construction documents for buildings of federal agencies and contact details of employees – content that is likely to be of interest to attackers. The coming weeks and months will show which other critical federal information is affected.

[SCENARIO] Because the leak contains contacts, email conversations, and procedures involving federal agencies and other partners, threat actors and criminals could use them for targeted phishing or fraud attempts. No such follow-on operation has been evidenced so far. In our review, the available information provides a broad basis for targeted campaigns – such as spear phishing against federal agencies and other organizations.

[SCENARIO] Because this concerns a data leak from the capital-city administration of a G7 member, Chinese, Russian and other intelligence services will, with very high probability (Confidence HIGH), also seek to obtain the data set. For example: emails with an OPLAN DEU context that reveal which offices and persons are working on it could, in the future, be targeted individually or in groups by foreign intelligence services – digitally or in the physical world. The sheer mass of open or now leaked information that was nevertheless classified (VS) allows intelligence services to draw conclusions about data classified as VS-VERTRAULICH or GEHEIM that is NOT contained in the leak!

[SCENARIO] In addition, we were able to identify various access credentials for external, internet-reachable services of other organizations and companies. In our assessment, some of these accesses are still usable. Attackers must be expected to test them – follow-on compromises at the affected organizations are possible.

Outlook: Weeks, Months, Years

[OBSERVED] The Berlin information page warns against unsolicited offers of help – such as offers to check whether one is affected or to delete data from the dark web. It recommends verifying the authenticity of such contacts through official channels. [1]

[SCENARIO] In the first weeks, published contact data and administrative references could be used for credible-looking phishing and fraud attempts – such waves would be typical. So far, the warning notice is evidenced, not a specific campaign.

[SCENARIO] In the coming months, the data could serve as raw material for follow-on intrusions and further extortion attempts; at the same time, the case is likely to fuel the debate about segmentation and the operation of shared administrative networks. Binding measures or their timeline are not foreseeable.

[SCENARIO] Considered over years, a published data set remains permanently available: copyable, re-sortable, and linkable with other sources. Identity misuse, targeted OSINT analysis, and reputational damage are the most plausible long-term consequences. A publication cannot be taken back – only how it is handled can be shaped.

[ASSESSED] The response should be pursued on two tracks: technical containment and recovery on the one hand, assessment of the exposed data and communication on the other. A joint decision log records which measure is based on which verified indication, who is responsible, and when a reassessment takes place. This prioritizes confirmed risks without categorically classifying unreviewed data as compromised or harmless.

[ASSESSED – Recommendations at a Glance]

  • Use official information and contact channels; ignore unsolicited “dark web deletion services”.
  • For concrete indications of exposed access data: prioritize revoking or renewing the affected accounts, keys, and tokens – but do not categorically claim that every access is affected.
  • Enforce multi-factor authentication (MFA), especially for email, remote access, and privileged accounts; monitor for unusual logins and data exfiltration. [5]
  • Prepare communication and business partners for context-related phishing and business email compromise (BEC) attempts; confirm changes to payment or contact data through a second, known channel.
  • Regularly review network segmentation, privileged access, and offline/immutable backups – including tested recovery. Backups reduce outage impact but do not prevent the publication of already exfiltrated data. [5]

Figure 5 – Follow-On Use Scenarios. Possible follow-on use paths by cybercriminals, access brokers, politically motivated groups, foreign intelligence services, and other third parties – explicitly scenarios, no evidence of a concrete follow-on operation in the Berlin case.

Selected Sources

Note: This article reflects the state of public sources as of 13 October 2026. Assessments are marked as [ASSESSED] or [SCENARIO].

Would you like to check whether data that has become public could affect your company? NSIDE supports purpose-specific exposure analyses and preparation for possible follow-on attacks.