Hackerangriff Senatsverwaltung Berlin: Was wirklich passiert ist

Die offizielle Zeitlinie, rekonstruiert aus BSI-Angaben und Medienberichten:

• 7.–12. August 2026: Bei den Senatsverwaltungen für Stadtentwicklung, Bauen und Wohnen sowie für Mobilität, Verkehr, Umwelt und Klimaschutz beginnt der Datenabfluss — der eigentliche Einbruch liegt bereits deutlich davor.
• 14. August 2026: Beide Verwaltungen werden aus Sicherheitsgründen vom Landesnetz Berlin isoliert.
• 17. August 2026: Die Senatskanzlei informiert über einen „IKT-Vorfall”, ein Notfallkrisenstab wird eingerichtet, BKA und LKA ermitteln.
• 23./24. August 2026: Alle Systeme sind wieder am Netz und laut Regierendem Bürgermeister Kai Wegner „grundsätzlich arbeitsfähig”.
• 28. August 2026: Rhysida bekennt sich öffentlich zum Angriff und droht mit einer Datenauktion.
• 4. September 2026: Nach Ablauf des Ultimatums veröffentlicht die Gruppe den kompletten Datensatz frei zugänglich im Darknet.
• 5. September 2026: Das BSI warnt vor einer „erhöhten Bedrohungslage” für die Gesellschaft, insbesondere durch gezielte Phishing-Wellen mit den erbeuteten Echtdaten.

Diese Rekonstruktion stützt sich unter anderem auf die ausführliche Berichterstattung von heise online zum ersten Angriffsvektor sowie auf die Analyse der Dimension des Datenlecks bei Euronews. Beide Quellen zeichnen ein konsistentes Bild vom Hackerangriff Senatsverwaltung Berlin: Öffentliche Verwaltungen sind verwundbar, weil sie oft viele Standorte, viele Altsysteme und vergleichsweise wenig IT-Sicherheitspersonal auf einmal verwalten müssen.

So lief der technische Angriff ab

Besonders lehrreich ist der von BSI und Sicherheitsforschern rekonstruierte technische Ablauf — er zeigt: Der Hackerangriff Senatsverwaltung Berlin lief selten über eine einzelne Schwachstelle, sondern über eine Kette kleiner Fehler:

1. Einstieg über Social Engineering: Laut einer offiziellen BSI-Sicherheitsmitteilung vom 4. September 2026 deckt sich der Tathergang mit einer mehrstufigen Angriffstechnik, die Microsoft als „TerminalFix”-Kampagne beschrieben hat — eine Weiterentwicklung der breiter bekannten ClickFix-Masche. Nutzer wurden über eine gefälschte Verifizierungsseite dazu gebracht, selbst das Windows-Terminal zu öffnen und einen vorbereiteten Befehl auszuführen.
2. Aufklärungsphase im Netzwerk: Die Angreifer spähten anschließend gezielt Rechtevergaben, angeschlossene Server, Benutzerkonten und vor allem Backup-Prozesse aus.
3. Persistenz über eine Backdoor: Rhysida richtete einen Reverse-Tunnel zu einer Python-basierten Backdoor ein, um dauerhaften Zugriff auf das kompromittierte Netzwerk zu behalten.
4. Exfiltration über legitime Cloud-Tools: Die eigentliche Datenausleitung erfolgte über einen Cloud-Speicher, mit vom Cloud-Anbieter selbst bereitgestellten Kopierwerkzeugen.
5. Erpressung statt sofortiger Verschlüsselung: Weil die Backup-Wege bereits bekannt waren, verzichtete die Gruppe zunächst auf klassische Verschlüsselung und setzte auf reine Daten-Erpressung.

Wie groß ist das Risiko für andere Kommunen wirklich?

Der Hackerangriff Senatsverwaltung Berlin ist kein Ausreißer. Laut BSI-Lagebericht 2025 wurden im Berichtszeitraum Juli 2024 bis Juni 2025 in Deutschland 950 Ransomware-Fälle angezeigt, in 72 Prozent davon kam es zusätzlich zu einem Datenleck. Für die Rhysida-Gruppe konkret gilt laut BSI: In 92 Prozent der Fälle, in denen mit einer Veröffentlichung gedroht wird, wird diese auch umgesetzt. Rhysida konzentriert sich zwar primär auf Gesundheits- und Bildungseinrichtungen, öffentliche Verwaltungen gehören aber weiterhin zu den fünf meistgenannten Zieltypen der Gruppe.

Für Kommunen kommt eine strukturelle Besonderheit hinzu: Viele Standorte, gewachsene IT-Landschaften mit Altsystemen und ein im Vergleich zu Konzernen sehr kleines IT-Sicherheitsteam sorgen dafür, dass Vorfälle wie der Hackerangriff Senatsverwaltung Berlin Kommunen oft härter treffen als vergleichbar große Unternehmen. Genau deshalb ist die Verwaltung eine der Kernzielgruppen, für die wir unsere IT-Security-Beratung für Kommunen konzipiert haben — mit Blick auf begrenzte Budgets und die spezifischen Anforderungen des öffentlichen Sektors.

Warum Backups die Angreifer nicht aufhielten

Der auffälligste Punkt im BSI-Bericht zum Hackerangriff Senatsverwaltung Berlin: Rhysida hat sich gezielt Zeit genommen, um die Backup-Infrastruktur zu verstehen, bevor überhaupt Daten bewegt wurden. Backups sind für Ransomware-Gruppen das größte Hindernis auf dem Weg zum Lösegeld — und werden deshalb inzwischen als erstes Angriffsziel behandelt, nicht als letztes.

Klassische Backup-Konzepte, bei denen Sicherungen im selben Netzwerk und mit denselben Zugangsdaten wie die Produktivsysteme erreichbar sind, bieten kaum Schutz gegen einen Angreifer, der bereits Wochen im Netzwerk unterwegs war. Wirksam sind stattdessen unveränderliche (immutable) Backups, getrennte Zugangsdaten und Offsite-Kopien außerhalb der eigenen Infrastruktur — Themen, die wir im Beitrag zur 3-2-1-Regel und Immutable Backups vertieft haben.

8 kritische Lehren für Kommunen und Mittelstand

Aus dem Hackerangriff Senatsverwaltung Berlin lassen sich acht konkrete Lehren ziehen, die jede Kommune und jedes mittelständische Unternehmen auf den eigenen Reifegrad übertragen sollte:

1. MFA ist keine Option, sondern Pflicht. Auch technisch raffinierte Angriffe wie TerminalFix/ClickFix verlieren viel von ihrer Wirkung, wenn kompromittierte Zugangsdaten allein nicht ausreichen.
2. Ein gutes Phishing-/Spam-Gateway vorschalten. Ein modernes E-Mail-Security-Gateway mit URL-Rewriting, Sandboxing verdächtiger Links und konsequenter DMARC-/DKIM-/SPF-Prüfung fängt einen erheblichen Teil der TerminalFix-/ClickFix-Köder bereits ab, bevor sie überhaupt im Postfach landen — eine technische Ergänzung zur Awareness-Schulung, kein Ersatz dafür.
3. Mitarbeitende auf neue Maschen schulen, nicht nur auf klassisches Phishing. TerminalFix/ClickFix, Vishing und QR-Code-Phishing gehören inzwischen zum Standardrepertoire.
4. Backups isoliert und unveränderlich absichern. Wenn Angreifer Backup-Prozesse gezielt ausspähen können, ist die Backup-Strategie selbst ein Sicherheitsrisiko.
5. Netzwerksegmentierung konsequent umsetzen, damit sich Angreifer nach einem Erstzugriff nicht wochenlang unbemerkt bewegen können.
6. Anomalien im Cloud-Traffic überwachen — legitime Kopiertools sind ein beliebtes Exfiltrationswerkzeug, weil sie selten Alarm auslösen.
7. Reaktionsplan für den Ernstfall vorbereiten, inklusive Kommunikationsstrategie für Betroffene, Behörden und Presse.
8. NIS2-Pflichten nicht als Formalie behandeln, sondern als Blaupause für genau die Maßnahmen, die im Fall Berlin gefehlt haben.

Die letzte Lehre ist zugleich die wichtigste: Dass ein Hackerangriff Senatsverwaltung Berlin eine ganze Verwaltung so lange lahmlegen kann, liegt selten an einem einzelnen Fehler, sondern am Fehlen genau der strukturierten Prozesse, die NIS2 und BSI IT-Grundschutz ohnehin fordern. Wie sich das systematisch angehen lässt, beschreiben wir in unserem Beitrag zum BSI-konformen IT-Notfallmanagement. Wer noch nicht abschließend geprüft hat, ob und in welchem Umfang die eigene Organisation von NIS2 betroffen ist, findet einen strukturierten Einstieg in unserer NIS2-Beratung für die Region Rhein-Neckar.

Auch der zweite auffällige Fund aus dem Berliner Datenleak gehört in diese Liste: Unter den veröffentlichten Dateien fand sich ein Ordner mit sicherheitsrelevanten Planungsdokumenten zum Bevölkerungsschutz — ein Hinweis darauf, dass auch vermeintlich unauffällige Verwaltungsdaten im Ernstfall weitreichende Konsequenzen für die öffentliche Sicherheit haben können. Diese Tragweite lässt sich vorab kaum einschätzen, wenn nicht systematisch erfasst ist, wer worauf Zugriff hat und wo besonders sensible Dokumente liegen — auch das ist Teil eines belastbaren Schwachstellenmanagements nach NIS2.

Angriffsphase und Gegenmaßnahme im Überblick

Der Hackerangriff Senatsverwaltung Berlin lässt sich in fünf Phasen zusammenfassen:

Fazit

Der Hackerangriff Senatsverwaltung Berlin zeigt: Es braucht keinen Zero-Day-Exploit, um eine ganze Verwaltung tagelang lahmzulegen — ein kompromittiertes Benutzerkonto, unzureichend geschützte Backups und fehlende Netzwerksegmentierung reichen aus. Genau diese Kombination aus menschlichem Fehler und struktureller Nachlässigkeit ist es, die aus einem einzelnen Klick eine Krise mit bundesweiter Tragweite macht — nicht die technische Raffinesse der Angreifer. Die gute Nachricht: Genau diese drei Punkte lassen sich mit überschaubarem Aufwand deutlich verbessern, bevor der Ernstfall eintritt. Wer jetzt in MFA, isolierte Backups und eine saubere Netzwerksegmentierung investiert, schließt die Lücken, die Rhysida und vergleichbare Gruppen gezielt suchen — und verschafft sich die Zeit, die im Ernstfall über Schadensbegrenzung oder Kontrollverlust entscheidet.