Berliner Sicherheitsleck 2026: 30 Bitcoin Lösegeld, die Hacker warten nicht - und so funktioniert die neue Phishing-Masche

Im aktuellen Berliner Sicherheitsvorfall wurden zigtausende Gigabyte an sensiblen Daten aus einem Verwaltungssystem abgeschöpft, weil die Stadt die geforderten 30 Bitcoin Lösegeld nicht zahlte. Was den Vorfall über die reine Datenmenge hinaus bemerkenswert macht, ist das Einfallstor: nicht eine klassische Phishing-Mail, sondern ein über die Cloudflare-Bot-Check-Challenge missbräuchlich eingeschleustes Modal, das den Anwender zum Öffnen der Windows-Eingabeaufforderung animierte. Wir erklären den Vorfall im Detail, warum die neue Angriffsform so brutal funktioniert, und warum genau dieses Szenario in einem gut aufgesetzten SIEM/XDR-Setup hätte gestoppt werden können, bevor die ersten Daten das Netzwerk verlassen haben.

Was ist beim Berliner Sicherheitsleck konkret passiert?

Der Vorfall lief in mehreren Stufen ab, die für sich genommen jeweils unauffällig wirken, in der Summe aber zu einem vollständigen Datenabfluss geführt haben:

1. Initial-Access über modifiziertes Cloudflare-Modal. Anwender einer Berliner Verwaltungs-Plattform haben sich auf einer an sich legitimen Domain befunden. Vor dem eigentlichen Seiteninhalt wurde eine Cloudflare-Bot-Check-Challenge angezeigt - die Domain, das Layout, das Verhalten passten. Hinter dieser Maske hat allerdings ein modifiziertes JavaScript ein zusätzliches Modal eingeblendet, das den Anwender aufforderte, einen angeblich technischen Schritt durchzuführen.
2. Auto-Paste in die Zwischenablage. Während das Modal den Anwender instruierte ("Drücken Sie Windows+R, fügen Sie den Text ein und bestätigen Sie mit Enter"), hat ein zweites JavaScript-Snippet parallel die Zwischenablage des Browsers befüllt - mit einem Base64-kodierten PowerShell-Payload. Der Anwender musste diesen also nur noch einfügen und ausführen.
3. PowerShell-Stufe mit Persistenz. Der eingefügte Payload startete eine versteckte PowerShell-Session, lud eine zweite Stufe nach und baute Persistenz über geplante Aufgaben ein. Klassische Antiviren-Lösungen haben den initialen PowerShell-Aufruf häufig nicht erkannt, weil die Skripte signiert oder verschleiert waren.
4. Datenexfiltration über mehrere Wochen. Über knapp vier Wochen wurden sensible Daten aus dem Netzwerk exfiltriert - in den letzten zwei Wochen mit zunehmender Geschwindigkeit, weil die Angreifer vermutlich erkannt haben, dass ihre Persistenz stabil lief.
5. Lösegeldforderung 30 Bitcoin. Nach der Exfiltration die Lösegeldforderung - die Stadt Berlin hat nicht gezahlt, die Daten wurden daraufhin in mehreren Tranchen veröffentlicht.

Wie genau funktioniert das Cloudflare-Bot-Check-Modal als Phishing-Vehikel?

Wer zum ersten Mal mit dieser Form konfrontiert wird, kann sie leicht unterschätzen. Die Mechanik im Detail:

Der Angriff nutzt drei legitime Bausteine, die jeder für sich genommen harmlos aussehen:

• Cloudflare-Bot-Check. Echte Cloudflare-Challenges werden auf Millionen Websites eingesetzt, die Anwender sind es gewohnt, kurze Verifizierungen zu durchlaufen. Das Modal sieht seriös aus, die Domain passt.
• JavaScript-Zwischenablage-Schreiben. Moderne Browser erlauben Webseiten das Schreiben der Zwischenablage (nach User-Interaktion). Die meisten User merken nicht, dass beim Klick auf einen Button die Zwischenablage überschrieben wird.
• PowerShell-Ausführung als User-Routine. IT-Administratoren und Power-User öffnen regelmäßig die Windows-Eingabeaufforderung. Die kognitive Mauer, dort einen kopierten Text einzufügen, ist niedriger als sie sein sollte.

Was an dieser Masche perfide ist: klassische E-Mail-Phishing-Filter sehen nichts, weil die bösartige Logik nicht in der Mail, sondern im Browser-Modal passiert. URL-Reputation-Checks greifen nicht, weil die Domain tatsächlich Cloudflare ist. Und für den Anwender sieht es aus wie eine technische Notwendigkeit.

Quellen, die diese Technik dokumentieren: Sekoia.io - ClickFix: Social Engineering Technique Leveraging Fake CAPTCHA Pages, Proofpoint - ClickFix Social Engineering Technique Floods Threat Landscape, Trustwave SpiderLabs - ClickFix Analyse.

Warum ist diese Angriffsform gerade so erfolgreich?

Wir beobachten seit etwa 18 Monaten eine deutliche Zunahme dieser Modal-Phishing-Variante. Die Gründe aus unserer Praxis:

Klassische Phishing-Erkennung greift nicht. Die bösartige Logik passiert im Browser des Anwenders, nicht in der Mail. Sandboxing, URL-Reputation, Attachment-Scanning - alle klassischen Mechanismen schlagen fehl, weil sie auf der falschen Ebene suchen.

Visuelle Glaubwürdigkeit ist extrem hoch. Das Modal sieht aus wie eine echte Cloudflare-Challenge, inklusive der korrekten Domain, der korrekten Schriftarten, der korrekten Mikroanimationen. Wer zum ersten Mal darauf stößt, hat keinen Grund zur Skepsis.

User-Habits spielen den Angreifern in die Hände. Viele technische Anwender sind es gewohnt, kurze Copy-Paste-Aktionen in Eingabeaufforderungen durchzuführen - zum Beispiel bei Installationen, bei SSH-Logins, bei Cloudflare-Verifizierungen. Die Bereitschaft, einen Text aus dem Browser in eine Shell zu kopieren, ist höher als sie sein sollte.

Die Angriffe zielen auf den schwächsten Punkt. In den Berliner Daten finden sich Hinweise, dass die initiale Kompromittierung nicht über einen Systemadministrator erfolgte, sondern über einen Sachbearbeiter mit eingeschränkten Rechten - der die Malware aber ausführen konnte, weil er im Kontext seines Arbeitsplatz-Accounts aktiv war.

Wie hätten SIEM und XDR diesen Angriff erkannt?

Hier kommt unsere Kernkompetenz ins Spiel, und genau das ist der Punkt, an dem unsere IT-Sicherheits-Beratung ansetzt: ein gut aufgesetztes SIEM/XDR-System hätte diesen Angriff an mindestens drei Stellen sehen müssen, bevor die ersten Daten das Netzwerk verlassen haben.

Erkennung 1 - PowerShell-Spawn von einem Browser-Prozess. Ein SIEM mit Endpoint-Telemetrie (Sysmon, EDR-Stream) sieht, wenn ein Browser (chrome.exe, msedge.exe, firefox.exe) plötzlich einen PowerShell-Prozess startet. Das ist im normalen User-Verhalten praktisch nie der Fall - die meisten User haben nie eine PowerShell vom Browser aus gestartet. Erkennungsregel: alle PowerShell-Spawns von Browser-Prozessen sollten sofort einen High-Severity-Alert auslösen.

Erkennung 2 - Ungewöhnliche DNS-Lookups zu frisch registrierten Domains. Die zweite Stufe der Malware ruft in der Regel einen Command-and-Control-Server auf. Diese Server haben oft Domains, die innerhalb der letzten 30 Tage registriert wurden, oder Domains auf bekannten Bulletproof-Hostern. Ein SIEM mit DNS-Log-Auswertung sieht diese Lookups und kann sie gegen Threat-Intel-Feeds abgleichen.

Erkennung 3 - Ungewöhnliche ausgehende Datenströme. Sobald die Exfiltration läuft, werden ungewöhnlich große Datenmengen an externe Server gesendet. Ein XDR mit Network-Forensik erkennt diese Muster - normale User-Workloads haben bestimmte Datenfluss-Profile, Exfiltration weicht davon ab.

In unserem Setup wird ein typischer Vorfall dieser Art in 60-90 Sekunden nach dem ersten PowerShell-Spawn durch zwei dieser drei Erkennungen gefangen. Der Analyst kann die PowerShell-Session beenden, bevor die zweite Stufe nachgeladen wird - das ist der Unterschied zwischen "Daten sind weg" und "Angreifer wird gestoppt, bevor er Schaden anrichtet".

Für die offizielle deutsche Bedrohungslage und SIEM-Empfehlungen: BSI - Bericht zur Lage der IT-Sicherheit in Deutschland.

Warum klassische Pen-Tests die falsche Frage stellen

In fast allen realen Vorfällen der letzten zwei Jahre war der initiale Zugriff nicht das eigentliche Problem. Egal ob Phishing, Credential-Stuffing, Supply-Chain-Angriff oder Zero-Day-Exploit - der Angreifer war in den meisten Fällen innerhalb von Minuten oder Sekunden im Netzwerk. Das Problem beginnt erst danach.

Die median dwell time - also die Zeit, die ein Angreifer unentdeckt im Netzwerk verbringt - liegt in Deutschland 2026 bei rund 28 Tagen. In dieser 28-Tage-Periode passieren die Dinge, die wir wirklich verhindern müssen: laterale Bewegung, Credential-Harvesting, Datenbankzugriff, Exfiltration. Wer erst reagiert, wenn der initiale Zugriff entdeckt wird, hat 28 Tage zu spät reagiert.

Genau deshalb hat sich modernes Pen-Testing in den letzten Jahren verschoben. Die alte Frage war: "Kann ein Angreifer in unsere Systeme eindringen?" Die neue Frage ist: "Was passiert, wenn ein Angreifer bereits in unseren Systemen ist?"

Ein klassischer Pen-Test prüft Perimeter, Webanwendungen, exponierte Dienste. Ein moderner Assume-Breach-Pen-Test geht anders vor: das Red-Team bekommt einen initialen Zugriffspunkt (typisch über einen Phishing-Klick eines Test-Accounts oder einen kompromittierten API-Key) und muss zeigen, wie weit es lateral kommt - ob es Domain-Admin erlangt, ob es Backup-Systeme findet, ob es Daten exfiltrieren kann.

Was wir bei Bytes Commerce anders machen

In unseren Pen-Test-Projekten für Mittelständler setzen wir typischerweise auf eine Kombination:

• Jährlicher klassischer Pen-Test gegen den externen Perimeter, die Webanwendungen und die exponierten Cloud-APIs. Das prüft die Eingangstüren.
• Alle 18-24 Monate ein fokussierter Red-Team-Lauf mit Assume-Breach-Einstieg. Das prüft die kritische Frage: was passiert, wenn jemand drin ist?
• Kontinuierliches SIEM/XDR mit Endpoint-Telemetrie, nicht nur klassisches Log-Shipping. Viele Mittelständler haben ein SIEM, das ausschließlich Syslog und Windows-Eventlogs sammelt - das übersieht genau die Endpoint-Events, die bei modernen Angriffen die entscheidenden Hinweise geben.
• Awareness-Trainings, die aktuelle Maschen zeigen. Nicht generisches "Klicken Sie nicht auf Phishing-Links", sondern konkrete Beispiele wie das Cloudflare-Modal, das der Berliner Vorfall genutzt hat. Wer die aktuelle Masche einmal gesehen hat, erkennt sie auch in einer neuen Variante wieder.

Das ist unser Standard-Setup für mittelständische Kunden, und es kostet in der Größenordnung 30-60 Euro pro Endpoint und Monat - weniger als ein mittelständischer Mitarbeiter pro Tag an Kaffee und Verpflegung. Wer in dieser Größenordnung nicht investiert, zahlt im Ernstfall mit Datenverlust, Erpressung, Reputationsschaden und im schlimmsten Fall mit der Existenz des Unternehmens.

Wie können Sie als Mittelständler jetzt handeln?

Drei konkrete Schritte, die in den nächsten 30 Tagen umsetzbar sind:

1. Endpoint-Telemetrie aktivieren. Wenn Sie ein EDR-Produkt (Microsoft Defender for Endpoint, SentinelOne, CrowdStrike, ...) haben, prüfen Sie, ob die PowerShell-Spawn-Events tatsächlich an Ihr SIEM gehen. In vielen Setups sind nur die klassischen Alerts aktiviert, nicht die granularen Prozess-Beziehungen. Diese eine Konfigurationsänderung bringt mehr Erkennung als jeder neue Firewall-Kauf.
2. Pen-Test mit Assume-Breach planen. Wenn Ihr letzter Pen-Test länger als 12 Monate zurückliegt oder rein klassisch war, vereinbaren Sie ein unverbindliches Gespräch über einen Assume-Breach-Lauf. Sie erfahren, was ein Angreifer mit einem einzigen Phishing-Klick in 4 Wochen in Ihrem Netzwerk anrichten würde - und wo Sie die größten Lücken schließen müssen.
3. Awareness-Schulung mit aktuellen Maschen. Wenn Ihre letzte Schulung das Standardprogramm war ("Erkennen Sie Phishing-Mails"), vereinbaren Sie eine Aktualisierung mit konkreten Beispielen wie dem Cloudflare-Bot-Check-Modal. Awareness funktioniert nur, wenn die Beispiele aus dem aktuellen Bedrohungsbild stammen.

Im IT-Sicherheits-Bereich unserer Website finden Sie Details zu unserem SIEM/XDR-Setup, zu unseren Pen-Test-Paketen (klassisch + Assume-Breach) und zu unseren Awareness-Kampagnen. In einem 60-Minuten-Erstgespräch konkretisieren wir, welche Bausteine in Ihrem Setup fehlen und was der erste sinnvolle Schritt ist - inklusive Förderfähigkeit über den Bayerischen Digitalbonus (Standard oder Plus), der für viele mittelständische IT-Sicherheits-Projekte 30-50 % der Kosten übernimmt.