Der Berliner Vorfall vom August 2026 ist kein Beleg dafür, dass das BSI „nichts empfohlen“ hätte. Er ist ein Beleg dafür, dass das BSI-Modell – IT-Grundschutz, Passwortrichtlinien, Patchen, Virenschutz, Protokollierung – gegen die Angriffsklasse, die Behördennetze 2026 tatsächlich trifft, weder präventiv noch detektivisch greift. Das gilt in zwei Schichten: erstens, weil zentrale BSI-Anforderungen in der Praxis nicht umgesetzt waren; zweitens, weil selbst eine vollständige Umsetzung gegen Zero-Days, Ring-0-Kontrolle und fileless/Living-off-the-Land-Ketten strukturell unzureichend ist.
1. Der Vorfall – was faktisch feststeht
Zwischen mindestens 7. und 12./14. August 2026 hatten Angreifer unbemerkten Zugriff auf Systeme der Senatsverwaltung für Mobilität, Verkehr, Klimaschutz und Umwelt sowie der Senatsverwaltung für Stadtentwicklung, Bauen und Wohnen. Isoliert wurden die Häuser erst am 14. August. Die Senatskanzlei sprach am 17. August öffentlich von einem IKT-Vorfall im Landesnetz. BSI, LKA und Staatsanwaltschaft waren eingebunden.
Die Gruppe Rhysida (Ransomware-as-a-Service, Doppelte Erpressung) forderte 30 Bitcoin (rund zwei Millionen Euro). Berlin zahlte nicht. Am 4. September 2026 wurde das Paket veröffentlicht: nach Angaben der Täter rund 1,44 Millionen Dateien / 5,7–5,8 Terabyte. Darunter Personalakten, Gesundheitsdaten (Reha, Atteste, AU-Bescheinigungen), Ausweisscans, Geburtsurkunden, Klartext-Passwörter, Verträge, Bußgeldvorgänge, Unterlagen aus Bundesratsausschüssen, Schwachstellenanalysen zur Trinkwasserversorgung und der „Leitfaden Zivile Verteidigung im Land Berlin“.
Die genaue Initial-Access-Methode für Berlin ist öffentlich nicht bestätigt. Forensik läuft. Was feststeht: Es gab tagelange, unbemerkte Exfiltration im Terabyte-Bereich, Klartext-Zugangsdaten in Dateien wie Passwort.docx (Beispiele in der Berichterstattung: „Sonnenschein13“, „Ahabostsee123“) und erst nach dem Leak eine Anweisung an alle Behörden zu „vorsorglich verschärften Passwortregeln“. Homeoffice-Zugriff der betroffenen Häuser wurde gekappt. Rund 12.000 Systeme des Landes wurden nachträglich gescannt. Digitalstaatssekretär Florian Hauer räumte „strukturelle Defizite in der IT“ ein und war „überrascht, wie groß“ das Landesnetz sei.
Das BSI war nicht der Betreiber des Landesnetzes. Betreiber/Dienstleister ist das ITDZ Berlin; die Fachverfahren liegen bei den Senatsverwaltungen. Das ITDZ hält ein ISO-27001-Zertifikat auf Basis von IT-Grundschutz für ISMS und Basisinfrastruktur. Das EGovG Berlin verpflichtet Behörden zum ISMS nach BSI-Grundschutz. Das BSI berät, warnt nach dem Leak vor Phishing, Identitätsmissbrauch und Hack-and-Leak vor der Abgeordnetenhauswahl am 20. September 2026 – und stuft die Motive als finanziell, nicht politisch ein.
Die institutionelle Lage ist damit klar: Grundschutz war Pflicht, ein Grundschutz-Zertifikat für die Basisinfrastruktur existierte, das BSI war im Vorfall eingebunden – und trotzdem lagen Tage lang unbemerkt Terabyte-Daten, inklusive Geheimschutz-relevanter Unterlagen, offen.
2. Was das BSI tatsächlich empfiehlt (und was das technisch bedeutet)
Die relevanten BSI-Vorgaben sind kein Geheimwissen. Für Behörden verdichten sie sich auf:
Identitäten (ORP.4, Verbraucherleitlinien, MFA-Checklisten)
Sichere Passwörter (lang oder komplex; keine leicht erratbaren Wörter; keine Wiederverwendung), keine Speicherung im Klartext, MFA möglichst phishing-resistent (FIDO2/Smartcard vor SMS-OTP), Least Privilege, getrennte Admin-Konten.
Systeme (SYS.2.1 / SYS.2.2.3 Windows-Client, Patchmanagement)
Härtung, zeitnahes Einspielen bekannter Patches, Einschränkung von Skript- und Admin-Werkzeugen, Antivirus/EDR, Application Control wo möglich.
Detektion (Grundschutz DER.1 / OPS.1.1.5; für den Bund der Mindeststandard „Protokollierung und Detektion“ v2.1)
Zentrale Erfassung von Protokoll- und Protokollierungsdaten, Korrelation zu sicherheitsrelevanten Ereignissen, definierte Speicherfristen, Reaktionsprozesse. Der Mindeststandard gilt rechtlich für die Bundesverwaltung, nicht 1:1 für Länder – der Grundschutz-Baustein Detektion gilt aber auch dort als Soll.
Organisation
ISMS, Schutzbedarfsfeststellung, Netzsegmentierung, Backup/Notfall, Awareness.
Das ist Hygiene. Hygiene verhindert opportunistische Angriffe und einige dokumentierte Rhysida-Einstiege. Sie verhindert nicht die Klasse von Operationen, um die es hier geht.
3. Schicht 1: Die Tipps greifen nicht, weil sie nicht umgesetzt waren
Bevor man über Zero-Days spricht, muss man den banalen Befund festhalten. Mehrere beobachtete Artefakte verletzen elementare BSI-Anforderungen direkt:
- Klartext-Passwörter in Office-Dokumenten widersprechen ORP.4 in jeder Fassung. Ein Passwort, das in
Passwort.docxliegt, ist kein Authentisierungsgeheimnis mehr, sondern eine Datei. Sobald ein Account mit Leserecht auf Fileshares oder Mail-Postfächer kompromittiert ist, ist die gesamte Passwortpolitik wertlos. - Passwörter vom Typ
Sonnenschein13erfüllen weder die Längen- noch die „nicht leicht erratbar“-Anforderung des BSI. Sie stehen in Wörterbuch- und Leak-Listen. Credential Stuffing und Password Spraying brauchen dann keinen Zero-Day. - Die reaktive Passwortverschärfung nach dem Leak und nach der Veröffentlichung von Klartextlisten ist kryptographisch und organisatorisch zu spät: kompromittierte Sessions, Kerberos-Tickets, Cached Credentials, VPN-Tokens und Wiederverwendung auf Fachverfahren bleiben bestehen, bis jedes betroffene System neu authentisiert und jedes Geheimnis rotiert ist – inklusive Dienstkonten, die niemand in der Word-Datei stehen hatte.
- Sieben Tage unbemerkte Exfiltration bedeutet: weder Netzübergangs-DLP noch Volumenanomalien (mehrere Terabyte) noch Endpoint-Telemetrie haben rechtzeitig zur Isolation geführt. Der BSI-Detektionsbaustein ist genau dafür da. Wenn er in einem Landesnetz mit ~600 Standorten und 12.000 zu scannenden Systemen nicht greift, ist das kein Randproblem, sondern ein Versagen der angenommenen Kontrollwirkung.
- Hauer sprach von strukturellen Defiziten und fehlender Übersicht über die Größe des Netzes. Parallel berichtete das ITDZ im Juni 2026, dass Hard- und Software (Fachverfahren) nicht zentral inventarisiert sind. Ohne Asset-Inventar sind Patchmanagement, Segmentierung und Detektionsabdeckung nicht operationalisierbar – unabhängig davon, was im ISMS-Handbuch steht.
Rhysidas dokumentiertes Standardrepertoire seit 2023 passt zu genau dieser Lücke: gültige Konten gegen internetseitige Remote-Dienste (VPN/RDP) ohne flächendeckende MFA, Phishing, Gootloader, Living-off-the-Land (PowerShell, RDP, PsExec), Credential Dumping (ntdsutil/NTDS.dit), Abschalten von AV-Prozessen (SILENTKILL), Exfiltration vor Verschlüsselung. CISA/FBI/MS-ISAC listen das seit dem Advisory AA23-319A; Updates 2025 ergänzen Gootloader. Für Berlin ist das kein Beweis des Einstiegs, aber es ist der empirische Normalfall derselben Tätergruppe.
Fazit Schicht 1: Ein Teil der „BSI-Tipps“ ist nicht nutzlos, weil falsch, sondern nutzlos, weil Behörden sie als Dokumentationspflicht behandeln. Ein ISMS-Zertifikat auf der Basisinfrastruktur sagt nichts über Klartext-Passwortdateien in Fachverfahren, MFA auf jedem VPN-Konzentrator oder die Fähigkeit, 5 TB Outbound in fünf Tagen zu sehen.
4. Schicht 2: Warum die Empfehlungen auch umgesetzt gegen moderne Angriffe versagen
Hier liegt der technische Kern. BSI-Empfehlungen sind überwiegend bekannte-Schwachstelle- und bekannte-Malware-zentriert. Die relevante Bedrohung 2026 ist das nicht.
4.1 Zero-Day-Lücken
Ein Zero-Day ist eine Schwachstelle, für die zum Zeitpunkt der Ausnutzung kein Patch und keine Signatur existieren. Grundschutz und Mindeststandards setzen implizit voraus:
- die Lücke wird bekannt,
- der Hersteller liefert zeitnah,
- die Behörde inventarisiert das betroffene Produkt,
- Change-/Freigabeprozesse erlauben das Einspielen,
- Kompatibilität mit Fachverfahren ist gegeben.
Jeder dieser Schritte bricht in der öffentlichen Verwaltung regelmäßig. Selbst N-Days (bekannte CVEs) bleiben Monate offen, weil Fachverfahren an alten Citrix-, Fortinet-, Exchange-, VPN- oder Java-Stacks hängen. Rhysida hat historisch unter anderem Zerologon (CVE-2020-1472, gepatcht 2020) genutzt, wo es noch unpatched war – also keinen Zero-Day, sondern Patch-Lag. Das ist die häufigere Variante: der „Tipp patch zeitnah“ scheitert an der Inventar- und Freigaberealtät, nicht an Unwissen.
Gegen echte 0-Days in Perimeter-Appliances (SSL-VPN, Mail-Security, File-Transfer, Hypervisor-Management) hilft kein Passwort und kein Windows-Defender. Der initiale Exploit läuft auf dem Gerät, oft als unauthentifizierte RCE, schreibt eine Webshell oder injiziert in einen privilegierten Dienst. Ab da gilt: gültige Sitzung, nicht „Hacker knackt Passwort“.
Hinzu kommt die Signatur- und Trust-Ebene. Rhysida-nahe Cluster (u. a. Vanilla Tempest / OysterLoader / Broomstick) haben 2024/2025 missbräuchlich kurzlebige Microsoft Trusted Signing-Zertifikate genutzt, um Loader als vertrauenswürdig zu signieren. Antivirus, das auf Authenticode-Reputation setzt, lässt signierte Binaries passieren. Das ist kein klassischer 0-Day im Code, aber ein 0-Day im Vertrauensmodell, auf dem BSI-übliche „nur signierte Software zulassen“-Empfehlungen beruhen.
Zero-Days machen außerdem MFA nicht irrelevant, aber umgehbar: Token-Theft (Cookie, PRT, Kerberos), Adversary-in-the-Middle-Phishing gegen Push-MFA, Session-Hijacking nach dem Login. BSI empfiehlt zu Recht phishing-resistente MFA (FIDO2). Flächendeckend in Länderverwaltungen mit hunderten Fachverfahren, die oft nur User/Pass oder Legacy-RADIUS sprechen, ist das nicht der Ist-Zustand.
4.2 Ring 0
x86/x64-Schutzringe:
- Ring 3: Usermode. Office, Browser, die meisten EDR-Agenten-UI, PowerShell-Host.
- Ring 0: Kernel. Treiber, Speicherverwaltung, Syscall-Gate. Wer Ring 0 hat, liest und schreibt den Adressraum jedes Usermode-Prozesses, hängt Callbacks aus, fälscht Telemetrie.
Typische Wege nach Ring 0 in aktuellen Ransomware-/APT-Ketten:
- Ausnutzung eines Kernel-Bugs (win32k, Dateisystemfilter, VPN-Client-Treiber, Drucker-Spooler in älteren Varianten).
- BYOVD (Bring Your Own Vulnerable Driver): ein legitim signierter, aber verwundbarer Treiber wird geladen; über dessen IOCTL-Schnittstelle wird beliebiger Kernel-Speicher geschrieben. HVCI/Memory Integrity blockiert viele bekannte anfällige Treiber, ist in heterogenen Behörden-Images mit Spezialhardware und alter VPN-/Scan-Software oft deaktiviert oder im Compatibility-Modus.
- Vulnerable Antivir-/EDR-Treiber selbst – historisch mehrfach vorgekommen. Der Schutzprozess wird zum Angriffsvektor.
Ist Ring 0 erreicht:
- Usermode-AV/EDR kann beendet, der Minifilter umgangen, ETW-Provider stumm geschaltet werden.
- LSASS-Dump umgeht PPL, wenn der Angreifer Kernel-Read hat (Credential Guard hilft nur, wenn VBS wirklich an ist und nicht durch Legacy-Anforderungen ausgehebelt).
- Fileless Payloads leben als Kernel-Callbacks oder injizierter Thread; „Datei scannen“ findet nichts.
BSI-Client-Härtung (AppLocker/WDAC, eingeschränkte Treiberliste, VBS, Credential Guard) ist die richtige Richtung. Sie ist in der Fläche der Länder-IT nicht der Default, weil Fachverfahren Kernel-Treiber, alte .ocx-Steuerungen, Scanner und Signaturanwendungen verlangen. Ein Grundschutz-Baustein, der „sofern technisch möglich“ sagt, wird genau dort zur Leerformel, wo der Schutzbedarf am höchsten ist.
Ring 0 macht außerdem Netzsegmentierung porös: ein kompromittierter Client mit Kernel-Malware kann NDIS-Filter setzen, lokale Firewall-Regeln umschreiben und C2 als HTTPS zum CDN tarnen. Der BSI-Tipp „Firewall und Proxy“ sieht dann legitimen Traffic.
4.3 Fileless Attacks / Living off the Land
„Fileless“ heißt nicht „keine Spuren“, sondern: kein persistentes, signaturbasierter Scanner-treffendes Artefakt auf Disk als primäres Werkzeug.
Dokumentierte Rhysida-Werkzeuge sind genau das: PowerShell, RDP, PsExec, Scheduled Tasks, Cobalt Strike Beacons im Speicher, ntdsutil, WMI, legitimes AnyDesk, WinSCP/AzCopy zur Exfiltration. SILENTKILL terminiert AV-Dienste per Skript, löscht Schattenkopien, passt RDP-Einstellungen an.
Warum BSI-Standardratschläge hier leer laufen:
| BSI-nahe Kontrolle | Warum sie fileless nicht zuverlässig stoppt |
|---|---|
| Signatur-AV | Es gibt keine oder nur kurzlebige Dateien; Payload sitzt in powershell.exe -enc, WMI-Event-Subscription oder einem injizierten rundll32. |
| „Keine fremde Software installieren“ | Es wird keine fremde Software installiert. Es werden Microsoft-Binaries missbraucht (LOLBins). |
| Passwortpolitik | Nach Initial Access werden Tickets und Hashes genutzt (Pass-the-Hash, Pass-the-Ticket), nicht das Benutzerpasswort. |
| Awareness/Phishing-Schulung | Hilft gegen den ersten Klick, nicht gegen den Operator, der bereits fünf Tage im Netz PowerShell nutzt. |
| Klassisches Logging ohne Verhalten | powershell.exe und mstsc.exe sind Normalbetrieb einer Verwaltung. Ohne baseline + Anomalie (Encoded Command, Unusual Parent, Volume Exfil) versinkt das Signal. |
Technisch wirksame Gegenmaßnahmen existieren: Constrained Language Mode, WDAC im Enforce-Mode, Abschalten von Office-Makros ohne Ausnahme-Wildwuchs, LSA Protection, Restricted Admin RDP, Privileged Access Workstations, Canary-Files, Netflow-Schwellen für Outbound, Immutable Backups, MFA phish-resistant auf jedem Remote-Zugang. Das sind nicht die Tipps, die nach einem Leak als „Passwortregeln verschärfen“ verschickt werden. Sie sind teuer, brechen Fachverfahren und erfordern ein SOC, das PowerShell-Transkript und ETW-TI in Echtzeit liest.
Genau dieses SOC hat in Berlin über Tage Multi-Terabyte-Abfluss nicht zur Isolation geführt. Der Mindeststandard Detektion beschreibt den Soll-Zustand. Der Ist-Zustand war: Entdeckung über Datenabflussmeldung, Isolation mit Verzögerung, öffentliche Unsicherheit über Umfang, nachträgliches Scannen von 12.000 Systemen.
5. Detektion ist die eigentliche Sollbruchstelle
Prävention gegen 0-Day und Ring 0 ist unvollständig. Deshalb ist Zeit-bis-Erkennung die entscheidende Metrik. Der Berliner Fall zeigt:
- Exfiltrationsfenster in der Größenordnung mehrerer Werktage.
- Isolation nicht am ersten Indikator, sondern Tage später.
- Zunächst politische Kommunikation, es seien „keine sensiblen Daten“ abgeflossen – später Klartext-Passwörter, Personalakten, Zivilschutzleitfaden.
Das ist mit einem funktionierenden Detection-and-Response-Prozess unvereinbar. Gründe, die unabhängig von einzelnen Tipps sind:
- Zu wenig instrumentierte Fachverfahren. Grundschutz-Detektion auf dem Client nützt nichts, wenn die Daten auf Fileservern und Fachanwendungen liegen, deren Zugriffe nicht als SRE modelliert sind.
- False-Positive-Angst und Change-Kultur. Große Landesnetze drosseln EDR-Blöcke, weil „die Anwendung sonst nicht geht“.
- Keine harte Segmentierung. Dokumente der Inneren Verwaltung und Zivilverteidigung tauchen im Beutesatz von Bau- und Verkehrsverwaltungen auf. Das ist ein Berechtigungs- und Speicherortproblem, kein Passwortproblem. Daten, die auf demselben Share wie Alltagsakten liegen, werden mitexfiltriert.
- BSI-Mindeststandard Detektion bindet den Bund, nicht Berlin. Kooperation ja, Durchgriff nein. Anfang September 2026 wurde zudem der Plan aufgegeben, das BSI per Grundgesetzänderung zur echten Zentralstelle auszubauen. Beratung ohne Betriebsverantwortung erzeugt genau die Lage: Warnung nach dem Leak.
6. Warum ausgerechnet die sichtbaren BSI-Tipps nach dem Vorfall nutzlos sind
Nach dem Angriff folgen typischerweise: Passwörter ändern, Homeoffice kappen, scannen, Warnung vor Phishing. Technisch:
- Passwortwechsel ohne Session-Invalidierung, Kerberos-Reset, Anwendungsschlüssel-Rotation und MFA-Erzwingung auf allen Remote-Pfaden rotiert nur das eine Geheimnis, das der Angreifer vielleicht schon nicht mehr braucht.
- Homeoffice-Stopp reduziert die Angriffsfläche nach Compromitierung, ändert nichts am bereits kopierten 5,8-TB-Satz und nichts an internem Lateral Movement.
- Signatur-Scans von 12.000 Systemen finden Rhysida-Payloads, wenn sie noch auf Disk liegen. Fileless-Beacons und gestohlene Tickets finden sie nicht zuverlässig.
- BSI-Warnung vor Folphishing ist korrekt, aber nachgelagert. Sie adressiert den Second-Order-Schaden des Leaks, nicht den First-Order-Fehler (ungehinderte Exfiltration).
Das Muster ist: Maßnahmen, die sich als Rundschreiben formulieren lassen, ersetzen Maßnahmen, die Architektur ändern (Identitätsmodell, Segmentierung, Privileged Access, WDAC, VBS, detektierbare Exfiltrationspfade, Datenminimierung).
Der Satz des IT-Sicherheitsberaters Manuel Atug zum Leak – grob fahrlässiger Umgang mit Geheimschutzgut, „Daten, die nirgendwo gespeichert sind, können auch nicht gehackt werden“ – trifft den Punkt, den kein Passwort-Tipp heilt: Schutzbedarf und Speicherort waren falsch gewählt. Ein Zivilverteidigungsleitfaden und Wasser-Schwachstellenanalysen gehören nicht in dasselbe, tagelang unüberwachte Verwaltungsnetz wie Alltagsakten.
7. Synthese
Drei Aussagen halten einer technischen Prüfung stand:
Erstens: Mehrere BSI-Kernanforderungen (keine Klartext-Geheimnisse, keine trivialen Passwörter, MFA an Remote-Zugängen, belastbare Detektion, Inventar) waren im Berliner Umfeld erkennbar nicht wirksam implementiert. Insofern sind die Tipps nicht „falsch“, sondern ohne Vollzug wirkungslos. Ein Grundschutz-Zertifikat der Basisinfrastruktur ändert das nicht.
Zweitens: Selbst bei Vollzug bleiben Zero-Days am Perimeter, Kernel-/BYOVD-Pfade und fileless LotL-Ketten außerhalb des Wirkungsradius der Ratschläge, die öffentlich als „BSI-Tipps“ zirkulieren (Passwortlänge, Virenscanner, Updates, Schulung). Diese Ratschläge adressieren 2010er-Bedrohungen: unsichere Passwörter, bekannte Malware-Dateien, bekannte CVEs mit vorhandenem Patch. Rhysida und vergleichbare RaaS-Gruppen operieren 2026 mit gültigen Konten, signierten Loadern, Microsoft-Binaries und Speicher-Payloads.
Drittens: Das BSI kann den Senat nicht „absichern“, weil es das Landesnetz nicht betreibt, Länder-ISMS nicht erzwingt und Detektion nicht zentral schaltet. Nach dem Leak warnt es vor Folgerisiken – das ist Lagekommunikation, keine technische Kontrolle. Die politische Erwartung, BSI-Empfehlungen würden ein 600-Standorte-Netz gegen eine professionelle Doppel-Erpressungsgruppe halten, überschätzt das Instrument.
Was gegriffen hätte, steht in denselben BSI-Dokumenten im Kleingedruckten und in den CISA-Mitigations zu Rhysida – nur nicht als Flyer: phishing-resistente MFA auf jedem internetseitigen Login; Abschaltung von LotL-Missbrauch (WDAC, eingeschränktes PowerShell, kein breites PsExec); VBS/HVCI und Treiberblocklisten; Segmentierung und Datenminimierung für Verschlusssachen; Exfiltrationsdetektion mit harten Schwellen; Isolation in Stunden, nicht Tagen. Das sind keine Tipps. Das ist Betrieb. Der Berliner Fall zeigt die Differenz.
