Cyberangriff auf Berlin: Nicht zu zahlen war richtig. Was sich ändern muss.

Stand: Oktober 2026

Berlin hat nicht gezahlt. Am 4. September 2026 veröffentlichten die Täter gestohlene Daten, und nach der hier geprüften amtlichen Darstellung ist die Bewertung der betroffenen Daten nicht abgeschlossen. Die Entscheidung war richtig. Die Frage, die ich jeder Leitungsrunde stellen würde, ist aber eine andere: Was verhindert, dass aus einem kompromittierten Arbeitsplatz ein großflächiger Verlust vertraulicher Informationen wird? Wer sie beantworten will, muss auseinanderhalten, was die Berliner Behörden bestätigt haben und welche technischen Einzelheiten noch offen sind.

Was die amtliche Darstellung belegt

Nach Berlins offizieller Darstellung floss der Großteil der Daten zwischen dem 7. und 12. August 2026 ab. Am 14. August wurden zwei betroffene Senatsverwaltungen vom Landesnetz getrennt, die eine zuständig für Stadtentwicklung, die andere für Mobilität und Umwelt. Am 4. September veröffentlichten die Täter gestohlene Daten, nachdem Berlin die Zahlung verweigert hatte.[1]

Die Senatskanzlei berichtete, Rhysida habe sich zur Tat bekannt. In ihrer Mitteilung vom 3. September ist von einer Datenversteigerung mit einem Mindestgebot von 30 Bitcoin die Rede. Das ist ein Auktionsminimum. Ein unabhängiger Beleg für den Preis, zu dem die Angreifer auf die Veröffentlichung verzichtet hätten, ist es nicht.[2]

Am 6. September meldete Berlin eine weitere Veröffentlichung, diesmal mit Zugangsdaten, und kündigte zusätzliche Schutzmaßnahmen an.[3] Der belegte Ablauf ist damit kurz: Zugriff, Kopieren, Erpressung, Veröffentlichung. Eine vollständige technische Angriffskette geben die geprüften Behördenangaben nicht her. Und dass eine Ransomware-Gruppe beteiligt war, beweist für sich genommen nicht, dass in Berlin irgendein System verschlüsselt wurde.

Wie kann ein solcher Angriff beginnen?

Ein einschlägiges Beispiel ist die Kampagne TerminalFix. Microsoft beschreibt, wie ein gefälschtes CAPTCHA den Nutzer auffordert, einen Befehl im Windows-Terminal oder in der PowerShell einzufügen und auszuführen. Weitere Stufen installieren Schadkomponenten und richten einen Fernzugriff ein.[4] Aus einer vermeintlichen Browserprüfung wird Codeausführung auf dem Arbeitsplatzrechner.

Microsoft beschreibt eine Kampagne, nicht die Forensik des Berliner Falls. Die hier geprüfte amtliche Berliner Darstellung benennt nicht jeden Schritt vom Einstieg bis zum Abfluss. Es wäre leicht, die Lücken zu füllen: ein unachtsamer Mitarbeiter, eine fehlende Schutzmaßnahme, ein sauberer Ausbreitungsweg. Ich tue das nicht.

Die Schutzfolgerung gilt trotzdem. Eine Webseite, die zur Ausführung eines Terminalbefehls auffordert, führt keine gewöhnliche Prüfung durch, ob ein Mensch vor dem Bildschirm sitzt. Schulungen sollten genau dieses Muster behandeln. Die technischen Maßnahmen müssen damit rechnen, dass ein Mensch getäuscht werden kann: Eine Fehlhandlung darf nicht automatisch weitreichenden Zugriff auf sensible Ablagen und Administrationssysteme ermöglichen.

Warum Nichtzahlen richtig war

Eine Zahlung bringt dem Angreifer Geld. Dem Opfer bringt sie die Kontrolle über die gestohlenen Kopien nicht zurück. Ein Löschversprechen sagt nichts darüber, ob eine Kopie behalten, verkauft oder weitergegeben wurde. Das FBI rät von Lösegeldzahlungen ab und warnt davor, eine Zahlung als Garantie für die Wiederherstellung anzusehen.[5]

Darauf beruht meine Bewertung der Berliner Entscheidung. Sie braucht keine erfundene Erfolgsquote und keine Behauptung, jeder zahlende Geschädigte erlebe dasselbe. Umgekehrt macht die Weigerung den Vorfall nicht ungeschehen: Eindämmung, Wiederherstellung, Untersuchung und Hilfe für die Betroffenen stehen weiter an.

Backups lösen ein anderes Problem. Sie können helfen, Daten und Dienste wieder verfügbar zu machen. Einen Angreifer können sie nicht dazu bringen, bereits kopierte Informationen zu vergessen. Jede Organisation braucht deshalb einen Plan für den Betriebsausfall und einen zweiten für den Verlust der Vertraulichkeit. Wer sich nur auf die Verschlüsselung vorbereitet, hat auf den zweiten Erpressungshebel keine Antwort.

Fünf Empfehlungen

Nichts von dem, was folgt, ist eine Feststellung, dass in Berlin eine bestimmte Maßnahme gefehlt hätte. Es sind Empfehlungen. Keine Empfehlung verhindert einen Angriff mit Sicherheit. Es geht darum, die Kette irgendwo zu unterbrechen und den Schaden zu begrenzen.

1. Gefährliche Ausführung erschweren. Prüfen Sie, welche Beschäftigten tatsächlich uneingeschränkt Skripte ausführen müssen und ob Anwendungskontrollen die Ausführung nicht freigegebener Programme und Skripte blockieren können. Halten Sie Endgeräteschutz und Softwarepflege wirksam. Testen Sie die Einschränkungen dann an echten Arbeitsabläufen. Gehen Sie nicht davon aus, dass ein pauschales Verbot überall praktikabel oder für sich allein ausreichend ist; Sensibilisierung und technische Durchsetzung gehören zusammen.

2. Die Reichweite eines kompromittierten Kontos begrenzen. Zugriffe müssen zur Aufgabe passen, privilegierte Administration ist von der Alltagsarbeit zu trennen, und übernommene Rechte werden nach jedem Rollenwechsel überprüft. Testen Sie die Segmentierung mit einer konkreten Frage: Welche sensiblen Dateien und welche Administrationsdienste sind von diesem Arbeitsplatz aus tatsächlich erreichbar? Beantworten Sie sie an einem echten Arbeitsplatz; das Netzwerkdiagramm zeigt nur, was geplant war.

3. Auffällige Kombinationen erkennen. Ungewöhnliches massenhaftes Lesen, Zugriffe auf fremde Ablagen, unerwartete Archiverstellung und ein neues externes Ziel sind zusammen zu betrachten und im Kontext zu prüfen. Eine reine Volumenschwelle kann langsamen Diebstahl übersehen oder berechtigte Übertragungen melden. Jede relevante Warnung braucht eine zuständige Person und einen Eskalationsweg, der auch außerhalb der Bürozeiten funktioniert.

4. Wiederherstellung nachweisen. Schützen Sie die Backup-Administration gesondert und testen Sie die Wiederherstellung in einer bereinigten Umgebung. Dokumentieren Sie, ob wesentliche Dienste ihre Wiederanlaufziele wirklich erreichen; ein abgeschlossener Sicherungslauf belegt weniger als das. Das britische NCSC betont getrennte Sicherungen und Wiederherstellungstests.[6] Das hilft gegen Ausfälle; eine bereits erfolgte Offenlegung macht es nicht rückgängig.

5. Die erste Stunde üben. Legen Sie vorab fest, wer Geräte oder Netzbereiche isolieren, Beweise sichern, kompromittierte Zugänge sperren und forensische Unterstützung hinzuziehen darf. Klären Sie, wie Recht, Datenschutz, Kommunikation und Betrieb mit demselben geprüften Lagebild arbeiten. Üben Sie bei noch unklarer Ursache. Vor jeder Schutzhandlung auf Gewissheit zu warten, kann Zeit kosten; ohne dokumentierte Begründung zu handeln, kann neue Probleme schaffen.

Mit der technischen Isolierung ist die Übung nicht zu Ende. Fragen Sie anschließend, welche Abhängigkeiten den Notbetrieb behindern, ob die Ersatzkommunikation funktioniert und wer über die Wiederanbindung entscheidet. Halten Sie Beobachtungen, Verantwortliche und Nachprüftermine fest. Erst eine Lücke, die gefunden, behoben und erneut getestet wurde, macht aus der Übung eine Verbesserung; die unterschriebene Teilnehmerliste allein belegt das nicht.

Auch die Menschen, deren Daten abgeflossen sind, brauchen konkrete Hilfe. Die Berliner Datenschutzbehörde empfiehlt Wachsamkeit bei betrügerischer Kontaktaufnahme, die Prüfung finanzieller Aktivitäten und die Absicherung betroffener Zugänge.[7] Die nächste glaubwürdig wirkende Nachricht kann echte gestohlene Angaben enthalten. Bieten Sie den Betroffenen einen überprüfbaren Kontaktweg an, statt sie mit unaufgeforderten Hilfsangeboten allein zu lassen.

Die Frage für die nächste Leitungssitzung

Berlin hat zu Recht kein unüberprüfbares Versprechen von denen gekauft, die es gerade bestohlen haben. Die längerfristige Aufgabe ist, Erpressung weniger wirksam zu machen: Zugriffe begrenzen, schädliche Aktivität erkennen, wesentliche Dienste wiederherstellen und als eine Organisation reagieren.

Nehmen Sie eine Frage mit: Wenn heute ein Arbeitsplatz kompromittiert würde, was würde den Angreifer stoppen, bevor sensible Informationen die Organisation verlassen, und wann haben wir das zuletzt getestet?

Quellen

1. Senatskanzlei Berlin – Vorfallinformationen, aktualisiert am 29. September 2026.
2. Senatskanzlei Berlin – Lagebericht vom 3. September 2026.
3. Senatskanzlei Berlin – weiteres Datenpaket, 6. September 2026.
4. Microsoft – TerminalFix-Kampagnenanalyse, 28. August 2026. Kampagnenbeleg, kein Berliner Forensikbericht.
5. FBI – Ransomware.
6. NCSC – Mitigating malware and ransomware attacks.
7. Berliner Datenschutzbehörde – Hinweise für Betroffene.

Quellenprüfung am 2. Oktober 2026. Redaktionelle Analyse, kein forensischer Befund und keine Rechtsberatung im Einzelfall. Untersuchung und Bewertung der betroffenen Daten sind nach der geprüften amtlichen Darstellung nicht abgeschlossen. Stand: Oktober 2026.