Claerchen #stand with ukraine #teamhabeck

BERLIN-HACK: DAS TECHNISCHE BILD WIRD KLARER – UND KOMPLIZIERTER Update zum Cyberangriff auf die Berliner Verwaltung, Stand 6. September 2026 Seit der Veröffentlichung der gestohlenen Berliner Verwaltungsdaten verdichtet sich das technische Bild des Angriffs. Eine vollständige forensische Rekonstruktion liegt weiterhin nicht öffentlich vor. Neue Informationen erlauben jedoch erstmals, einzelne Phasen des Incidents genauer einzuordnen. Gleichzeitig wird deutlich, dass zwischen bestätigten Tatsachen, Aussagen beteiligter Personen und technischen Hypothesen weiterhin sauber unterschieden werden muss. Fest steht zunächst, dass der Vorfall noch nicht abgeschlossen ist. Die Berliner Senatskanzlei bestätigte am 6. September die Veröffentlichung eines weiteren Datenpakets durch die Angreifer. Darin befinden sich ausdrücklich Zugangsdaten. Die zuständige Senatsverwaltung für Stadtentwicklung, Bauen und Wohnen hat daraufhin ihre bereits eingeleiteten Sicherheitsmaßnahmen erneut verschärft. Dadurch können einzelne Fachverfahren vorübergehend eingeschränkt sein. Damit ist auch klar: Die erste Veröffentlichung am 4. September stellte offenbar nicht zwingend den vollständigen kompromittierten Datenbestand dar. Die häufig genannten rund 5,8 Terabyte bleiben zwar eine Größenangabe der Angreifer, die Veröffentlichung erfolgt jedoch nachweislich in mehreren Paketen. Interessanter wird inzwischen die Frage des Initial Access. Der Tagesspiegel berichtet nach Gesprächen mit Beteiligten, ein Mitarbeiter der Verkehrsverwaltung habe eine Phishing-Mail nicht erkannt und einen darin enthaltenen Link geöffnet. Sollte sich diese Rekonstruktion bestätigen, wäre der erste Schritt des Angriffs zunächst bemerkenswert unspektakulär. Das wäre allerdings keine Entschuldigung für den weiteren Verlauf. Phishing gehört seit Jahren zum normalen Bedrohungsmodell großer Organisationen. Bei mehreren tausend Mitarbeitern muss eine Sicherheitsarchitektur grundsätzlich davon ausgehen, dass irgendwann ein Benutzer eine überzeugend gestaltete Phishing-Mail öffnet. Moderne IT-Sicherheit soll deshalb nicht ausschließlich verhindern, dass der erste Fehler geschieht. Sie soll verhindern, dass aus einem einzelnen kompromittierten Arbeitsplatz ein organisationsweiter Incident entsteht. Genau hier liegen inzwischen die entscheidenden Fragen. Nach der Rekonstruktion des Tagesspiegels wurde der Angriff offenbar nicht durch die Erkennung eines ungewöhnlich großen Datenabflusses entdeckt. Am 13. August wurde zunächst eine vermeintlich gewöhnliche Störung eines Domain Controllers gemeldet. Das CERT des ITDZ untersuchte den Vorgang und stellte dabei Auffälligkeiten fest, die schließlich auf größere Probleme innerhalb der Verkehrs- und Stadtentwicklungsverwaltung hindeuteten. Am folgenden Tag wurden beide Verwaltungen vom Netz getrennt. Sollte diese Timeline forensisch bestätigt werden, wäre sie sicherheitstechnisch außerordentlich relevant. Denn nach bisherigem Kenntnisstand sollen bereits seit dem 7. August Daten abgeflossen sein. Damit stellt sich nicht nur die Frage, wie die Täter Zugang erhielten. Es stellt sich vor allem die Frage, warum die nachfolgenden Aktivitäten über mehrere Tage nicht ausreichend erkannt wurden. Nach einem erfolgreichen Initial Access folgen bei professionellen Angriffen typischerweise weitere Phasen: Persistence, Discovery, Credential Access, Privilege Escalation, Lateral Movement, Collection, Staging und schließlich Exfiltration. Jede dieser Phasen kann Telemetrie erzeugen. Ungewöhnliche Authentifizierungen, Active-Directory-Abfragen, Massenzugriffe auf Dateien, auffällige Service Accounts, neue Prozesse, Archive, ungewöhnlicher East-West-Traffic oder externe Verbindungen sind genau die Ereignisse, für deren Erkennung EDR, NDR, SIEM und SOC-Strukturen existieren. Der momentan vielleicht wichtigste technische Punkt lautet deshalb: Der erste Klick ist nicht das zentrale Problem. Entscheidend ist der Blast Radius danach. Auch die inzwischen bekannt gewordenen Hinweise auf den Umgang mit Zugangsdaten sind relevant. Der Tagesspiegel berichtet von Dateien mit Bezeichnungen wie „Passwort.txt“ und „Zugangsdaten“, in denen Mitarbeiter Zugangsinformationen gespeichert haben sollen. Ein Mitarbeiter berichtet außerdem, verpflichtende Passwortmanager und flächendeckende Zwei-Faktor-Authentifizierung seien in den betroffenen Senatsverwaltungen nicht vorhanden gewesen. Diese Aussagen sind bislang keine abschließenden forensischen Feststellungen. Sollten sie sich bestätigen, würde dies allerdings erklären, wie ein initial kompromittiertes Konto relativ schnell Zugang zu weiteren Ressourcen ermöglichen konnte. Credentials sind bei solchen Angriffen ein Multiplikator. Ein einzelner kompromittierter Benutzer ist ein lokales Problem. Ein Benutzer, der Zugriff auf weitere Credentials besitzt, kann zum Ausgangspunkt einer wesentlich größeren Bewegung innerhalb des Netzes werden. Parallel dazu tritt inzwischen ein zweites Problem deutlich hervor: die heterogene IT-Landschaft Berlins. Das Land verfügt mit dem ITDZ über einen zentralen IT-Dienstleister und arbeitet seit Jahren an der Standardisierung und Migration seiner IT. Gleichzeitig existieren weiterhin dezentrale Netze, Fachverfahren, unterschiedliche technische Plattformen und verschiedene Betriebsverantwortungen. Diese Struktur erschwert nicht nur Prävention. Sie erschwert auch Incident Response. Ein besonders anschauliches Beispiel ist der derzeitige Streit um CrowdStrike. Die Senatskanzlei hat das Unternehmen mit der technischen Spurensuche beauftragt. Der Bezirk Lichtenberg lehnt den Einsatz des entsprechenden Agents auf seinen Systemen bislang ab und verweist unter anderem auf Datenschutz, bestehende eigene Sicherheitslösungen und die weitreichenden Zugriffsrechte der Software. Die technischen und datenschutzrechtlichen Einwände müssen selbstverständlich geprüft werden. Aus Sicht der Incident Response zeigt der Vorgang jedoch ein grundsätzliches Problem: Bei einem potenziell organisationsübergreifenden Cyberangriff benötigt die Forensik möglichst schnell konsistente Telemetrie und ein gemeinsames Evidence-Modell. Wenn unterschiedliche Organisationseinheiten unterschiedliche Security-Stacks betreiben und zunächst geklärt werden muss, wer welchen Sensor installieren darf, wird genau diese einheitliche Sicht schwieriger. Ein Angreifer kennt diese organisatorischen Grenzen nicht. Ein Incident-Response-Team dagegen muss sie offenbar berücksichtigen. Auch bei der Auswertung der gestohlenen Daten wird die Größenordnung des Problems sichtbar. Nach Tagesspiegel-Recherchen war das Team des Landesbevollmächtigten für Informationssicherheit sehr klein und wurde durch weitere Beschäftigte unterstützt. Teile der Dokumente wurden demnach zunächst manuell gesichtet. Bei rund 1,4 Millionen Dateien ist eine ausschließlich manuelle Analyse nicht skalierbar. Eine vollständige inhaltliche und forensische Bewertung jedes Dokuments benötigt selbstverständlich Zeit. Eine erste technische Triage sollte jedoch automatisiert erfolgen: Hashing, Indexierung, OCR, Entity Extraction, Secret Scanning, Klassifizierung und risikobasierte Priorisierung sind etablierte Verfahren. Gerade bei einem Leak dieser Größenordnung muss zwischen zwei Aufgaben unterschieden werden: vollständige forensische Analyse und schnelle Identifikation besonders kritischer Informationen. Beide Prozesse müssen parallel laufen. Eine weitere technische Spur sollte derzeit aufmerksam beobachtet, aber noch nicht mit dem Berliner Angriff gleichgesetzt werden: TerminalFix. Microsoft hat Ende August eine aktuelle TerminalFix-Kampagne beschrieben. Dabei werden Nutzer über gefälschte CAPTCHA-Seiten dazu gebracht, PowerShell-Befehle auszuführen. Anschließend folgen unter anderem DLL-Sideloading, Persistence, umfangreiche Active-Directory-Reconnaissance und der Aufbau eines Reverse Tunnels, über den ein kompromittierter Arbeitsplatz als Zugangspunkt zum internen Netz genutzt werden kann. Die Angriffskette ist deshalb interessant, weil sie zeigt, wie aus einer einzelnen Benutzerinteraktion ein weitreichender interner Zugang entstehen kann. Es gibt derzeit jedoch keinen öffentlich bestätigten Beleg dafür, dass TerminalFix beim Berliner Angriff eingesetzt wurde. Bis ein DFIR-Bericht oder entsprechende Indicators of Compromise vorliegen, bleibt dies eine technische Vergleichsspur und keine festgestellte Ursache. Damit lässt sich der aktuelle Erkenntnisstand relativ klar zusammenfassen. Wir wissen inzwischen mehr über den möglichen Anfang des Angriffs. Wir wissen weiterhin nicht abschließend, welche technische Angriffskette danach tatsächlich verwendet wurde. Aber der Fokus verschiebt sich. Der entscheidende Fehler muss nicht im ursprünglichen Phishing-Klick gelegen haben. Ein solcher Fehler ist in großen Organisationen statistisch kaum vollständig auszuschließen. Die entscheidende Frage lautet vielmehr, weshalb ein erfolgreicher Initial Access offenbar zu einer so großen Reichweite führen konnte und warum Collection und Exfiltration möglicherweise über mehrere Tage nicht ausreichend erkannt wurden. Dafür müssen sechs Punkte rekonstruiert werden: Initial Access. Credential Access. Privilege Escalation. Lateral Movement. Collection und Staging. Exfiltration und Detection. Erst eine vollständige Timeline dieser sechs Bereiche wird zeigen, welche technischen Kontrollen versagt haben, welche überhaupt vorhanden waren und an welchem Punkt der Angriff hätte unterbrochen werden können. Der bislang sichtbarste Befund geht jedoch bereits über eine einzelne Schwachstelle hinaus. Der Berliner Vorfall zeigt die Risiken einer heterogenen IT-Landschaft, in der zentrale und dezentrale Systeme, unterschiedliche Security-Produkte, verschiedene Zuständigkeiten und historisch gewachsene Fachverfahren parallel existieren. Das betrifft nicht nur die Prävention. Der aktuelle CrowdStrike-Konflikt zeigt, dass dieselbe Fragmentierung inzwischen sogar die gemeinsame Untersuchung des Angriffs berührt. Genau deshalb sollte die technische Aufarbeitung des Berliner Vorfalls nicht bei der Frage enden: „Wer hat auf den Phishing-Link geklickt?“ Die wichtigere Frage lautet: Wie war die Architektur beschaffen, die aus diesem einen Fehler einen Incident dieser Größenordnung werden ließ? Diese Frage ist wesentlich schwieriger. Aber für zukünftige Sicherheit ist sie die entscheidende.