Aktiv ausgenutzte Schwachstellen häufen sich: Sicherheitslage verschärft sich quer durch die IT-Infrastruktur

Browser, VPNs, SD-WAN, Domain-Controller, MFT-Server und Mobile-Plattformen: In den letzten vier Wochen haben sich die Meldungen zu bereits aktiv ausgenutzten Schwachstellen auffällig verdichtet. Bemerkenswert ist, dass die in den Quellen beschriebenen Fälle unterschiedliche Produktkategorien betreffen, darunter Browser, VPN-/Firewall-Produkte, SD-WAN-Management, Domain-Controller, MFT-Server sowie Android- und Linux-Systeme. Betroffen sind ausgerechnet die Systeme, die in Unternehmen als besonders kritische Kontrollpunkte gelten.

Mehrere Herstellerwarnungen, Medienberichte und neue bzw. aktualisierte Einträge im CISA-KEV-Katalog zeigen, dass zuletzt mehrere Schwachstellen als aktiv ausgenutzt gemeldet wurden. Dieser Eindruck wird durch den Known Exploited Vulnerabilities Catalog der US-Behörde CISA gestützt, der genau solche Fälle bündelt und ausdrücklich als Priorisierungsgrundlage für das Schwachstellenmanagement empfiehlt.

Auffällig ist vor allem, wie breit die aktuelle Welle streut. Google hatte am 9. Juni 2026 eine weitere aktiv ausgenutzte Chrome-Zero-Day in der V8-Engine geschlossen; laut SecurityWeek ist es bereits die fünfte aktiv ausgenutzte Chrome-Zero-Day des Jahres 2026. Fast zeitgleich warnte Check Point vor einer kritischen VPN-/Firewall-Schwachstelle, die laut SecurityWeek von Akteuren rund um Qilin-Ransomware als Zero-Day ausgenutzt wurde und umgehend im CISA-KEV-Katalog landete.

Hinzu kommen mehrere Fälle in klassischer Unternehmensinfrastruktur. Cisco warnte Anfang Juni vor der aktiv ausgenutzten Schwachstelle CVE-2026-20245 in Catalyst SD-WAN Controller, Manager und Validator. Laut Cisco kann ein authentifizierter Angreifer unter bestimmten Voraussetzungen durch das Hochladen einer präparierten Datei Befehle mit Root-Rechten ausführen. Wichtig für die Einordnung: Die Lücke wurde zunächst als Zero-Day bekannt, die inzwischen aktualisierte Cisco-Advisory nennt jedoch verfügbare Software-Updates und empfiehlt eine zeitnahe Aktualisierung sowie die Prüfung möglicher Kompromittierungsindikatoren.

BleepingComputer berichtet, dass die belgische Cybersicherheitsbehörde CCB vor einer aktiven Ausnutzung von CVE-2026-41089 in Windows Netlogon warnt. Microsoft erklärte gegenüber BleepingComputer jedoch, man habe derzeit keine eigenen Erkenntnisse, die diese Einschätzung bestätigen. Für Unternehmen bleibt die Schwachstelle dennoch relevant, da sie Domain Controller betrifft und laut Microsoft ohne vorherige Anmeldung zur Remote-Code-Ausführung ausgenutzt werden kann.

Auch bei exponierten Dateiübertragungs- und Plattformdiensten häufen sich die Warnungen. SecurityWeek und Help Net Security berichteten Anfang Juni über die aktive Ausnutzung von CVE-2026-28318 in SolarWinds Serv-U; CISA setzte für US-Bundesbehörden eine Frist bis zum 19. Juni 2026, um den Fall zu adressieren. Gleichzeitig warnte BleepingComputer unter Berufung auf CISA vor aktiven Angriffen auf Android und Linux, darunter eine Android-Schwachstelle, die laut Google ohne Nutzerinteraktion ausnutzbar ist, sowie eine Linux-Kernel-Lücke mit Privilegieneskalation.

Die genannten Fälle betreffen Systeme, die in vielen Unternehmen für Webzugriff, Remote-Zugänge, Netzwerkverwaltung, Dateiübertragung und Identitätsdienste eingesetzt werden.

Die betroffenen Produkte liegen in den berichteten Fällen unter anderem im Bereich Browser, Remote-Zugriff, Netzwerkverwaltung, Dateiübertragung, mobile Plattformen und Identitätsinfrastruktur. Welche Auswirkungen eine Ausnutzung im Einzelfall hat, hängt jedoch vom betroffenen Produkt, der konkreten Schwachstelle und der jeweiligen Umgebung ab.

Die aktuellen Herstellerwarnungen und CISA-KEV-Einträge sprechen dafür, aktiv ausgenutzte Schwachstellen in Patch- und Mitigationsprozessen kurzfristig zu prüfen und gegebenenfalls priorisiert zu behandeln. Wer sich im Patch- und Exposure-Management noch stark an CVSS-Werten oder festen Wartungsfenstern orientiert, läuft Gefahr, auf reale Angriffsmuster zu spät zu reagieren. Der KEV-Katalog und die jüngsten Herstellerwarnungen zeigen, dass die relevanten Fälle derzeit oft genau dort auftauchen, wo schnelle Entscheidungen über Abschottung, Mitigations und Notfall-Patching nötig sind.

https://api.msrc.microsoft.com/sug/v2.0/en-US/vulnerability/CVE-2026-41089

https://chromereleases.googleblog.com/2026/06/stable-channel-update-for-desktop_0153744567.html

https://documentation.solarwinds.com/en/success_center/servu/content/release_notes/servu_15-5-4-hotfix-1_release_notes.htm

https://msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2026-41089

https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-sdwan-privesc-4uxFrdzx

https://source.android.com/docs/security/bulletin/2026/2026-06-01

https://www.bleepingcomputer.com/news/microsoft/critical-windows-netlogon-remote-code-execution-flaw-now-exploited-in-attacks

https://www.bleepingcomputer.com/news/security/cisa-warns-of-active-attacks-exploiting-android-linux-bugs/amp

https://www.bleepingcomputer.com/news/security/google-patches-fifth-chrome-zero-day-bug-exploited-in-attacks-this-year/amp

https://www.bleepingcomputer.com/news/security/new-cisco-sd-wan-flaw-exploited-in-zero-day-attacks-to-gain-root/amp

https://www.cisa.gov/known-exploited-vulnerabilities-catalog

https://www.cisa.gov/news-events/alerts/2026/06/08/cisa-adds-two-known-exploited-vulnerabilities-catalog

https://www.cisa.gov/resources-tools/resources/kev-catalog

https://www.helpnetsecurity.com/2026/06/08/cisa-patch-actively-exploited-solarwinds-serv-u-dos-vulnerability-cve-2026-28318

https://www.securityweek.com/check-point-vpn-zero-day-exploited-in-qilin-ransomware-attacks

https://www.securityweek.com/google-patches-5th-chrome-zero-day-exploited-in-2026

https://www.securityweek.com/solarwinds-patches-exploited-serv-u-vulnerability

Meta-Fehler bei KI-Support: Angreifer kapern Instagram-Konten über automatisierte Kontowiederherstellung

Mehrere Quellen zeichnen ein konsistentes Bild: Angreifer nutzten Ende Mai und Anfang Juni 2026 eine Schwachstelle in Metas KI-gestütztem Account-Recovery- und Support-System für Instagram aus. Im Zentrum stand das interne bzw. erweiterte Support-Werkzeug „High Touch Support“ (HTS), das laut Meta als AI-assisted account recovery system fungierte. Statt eine klassische Sicherheitslücke in der Instagram-App selbst auszunutzen, zweckentfremdeten die Täter also den automatisierten Account-Wiederherstellungsprozess des KI-Chatbots.

Laut TechCrunch und 404 Media ließen sich die Angriffe offenbar dadurch durchführen, dass Metas AI-Support-Chatbot dazu gebracht wurde, eine neue E-Mail-Adresse zu einem Zielkonto hinzuzufügen beziehungsweise den Reset-Prozess anzustoßen. BleepingComputer berichtet ergänzend, dass HTS dabei unzureichend prüfte, ob die angegebene E-Mail-Adresse tatsächlich mit dem betroffenen Instagram-Konto verknüpft war. Das Problem lag also nicht nur in fehlender Verifikation, sondern in der Automatisierung einer hochsensiblen Entscheidung, die traditionell stärker abgesichert oder menschlich geprüft würde.

Der Vorfall fällt deshalb aus der Reihe, weil er weniger ein klassischer „Exploit“ als ein Beispiel für prozessuale Sicherheitsrisiken durch KI-gestützte Support-Automation ist. Wenn ein KI-System nicht nur informiert, sondern aktiv sicherheitsrelevante Kontofunktionen wie E-Mail-Änderungen oder Passwort-Resets anstoßen kann, wird der Support-Workflow selbst zur Angriffsfläche. Genau darin liegt die eigentliche sicherheitstechnische Relevanz des Falls: Nicht die KI „hackt“ das Konto, sondern sie wird zum fehlbaren Gatekeeper in einem Identity-Recovery-Prozess. Diese letzte Einordnung ist eine Schlussfolgerung aus den berichteten Abläufen. Ein schönes Bespiel für „Excessive Agency“ aus den „OWASP Top 10 LLM“.

Die Auswirkungen waren erheblich. Laut Meta wurden mehr als 20.000 Instagram-Konten kompromittiert; erste Berichte betrafen auch prominente oder begehrte Handles. BleepingComputer beschreibt zudem, dass betroffene Nutzer teils in automatisierten Recovery-Schleifen festhingen, weil auch die Wiedererlangung des Kontos stark auf automatisierte- und KI-gestützte Prozesse setzte. Meta erklärte, das Problem sei inzwischen behoben und betroffene Konten würden abgesichert.

Der Meta/Instagram-Fall ist vor allem deshalb bemerkenswert, weil er zeigt, dass KI-unterstützte Support- und Recovery-Systeme selbst zu einem sicherheitskritischen Vertrauensanker werden können. Für IT- und Security-Teams ist das ein Warnsignal: Sobald automatisierte Assistenten in Identitäts- oder Recovery-Prozesse eingebunden werden, müssen deren Prüfmechanismen genauso streng modelliert, getestet und abgesichert werden wie klassische Authentifizierungs- und Helpdesk-Prozesse.

https://www.bleepingcomputer.com/news/security/meta-ai-support-data-breach-affects-20-000-instagram-accounts/amp

https://www.404media.co/hackers-are-using-meta-ai-to-hijack-instagram-accounts

Claude Mythos / Project Glasswing: Anthropic erweitert stark eingeschränktes Cyber-Modell auf kritische Infrastrukturen

Anthropic hat Claude Mythos Preview im April 2026 als besonders leistungsfähiges, aber nicht allgemein freigegebenes Modell für cybersicherheitsbezogene Aufgaben vorgestellt. Der Zugang erfolgt über Project Glasswing, ein Programm, in dem ausgewählte Partner das Modell für defensive Sicherheitsarbeit wie Schwachstellenanalyse und Absicherung kritischer Software einsetzen. Anthropic begründet die restriktive Freigabe ausdrücklich mit dem Missbrauchsrisiko solcher Cyber-Fähigkeiten.

Anfang Juni 2026 hat Anthropic Project Glasswing deutlich ausgeweitet: Nach Angaben des Unternehmens erhalten rund 150 weitere Organisationen in mehr als 15 Ländern Zugang, darunter Akteure aus Bereichen wie Energie, Wasser, Gesundheitswesen, Kommunikation und Hardware. Anthropic gibt an, dass jede neue Organisation vor dem Zugang zu Claude Mythos Preview interne Sicherheitsanforderungen erfüllen muss. Worin diese konkret bestehen, legt das Unternehmen jedoch nicht offen.

Für die Einordnung ist vor allem die strategische Bedeutung relevant: Anthropic beschreibt Mythos nicht als gewöhnliches Produkt-Update, sondern als Modellklasse, die die bestehenden Annahmen in der Cybersicherheit verändert. Das Unternehmen betont, dass die eigentliche Herausforderung nicht nur im Auffinden zusätzlicher Schwachstellen liegt, sondern zunehmend auch in deren Verifikation, Offenlegung und Behebung, also in den nachgelagerten Prozessen des Sicherheitsökosystems.

Die bisher kommunizierten Ergebnisse unterstreichen diesen Anspruch: Anthropic berichtet, dass die ersten Project‑Glasswing‑Partner bereits mehr als 10.000 hoch- oder kritisch eingestufte Sicherheitslücken identifiziert hätten. Fachmedien nennen dazu Beispiele einzelner Partner, bei denen die Zahl gefundener Schwachstellen deutlich gestiegen sei; diese Angaben stammen jedoch im Kern aus Unternehmens- und Partnerberichten und sind daher eher als starke Indikation denn als unabhängig auditierte Gesamtbilanz zu lesen.

Der Fall ist damit weniger wegen einer einzelnen CVE relevant als wegen der Governance-Frage, die er aufwirft: Wenn KI-Modelle sicherheitsrelevante Analyse- und Patch-Prozesse spürbar beschleunigen, werden Zugangskontrolle, Schutzmaßnahmen und verantwortliche Bereitstellung selbst zu einem sicherheitspolitischen Thema. Anthropic stellt dabei die kontrollierte Freigabe und den defensiven Einsatzzweck in den Mittelpunkt – das ist die offizielle Begründung. Aus Sicherheitssicht entsteht so aber auch ein abgestuftes Zugangsmodell: Mit dem am 9. Juni 2026 veröffentlichten Claude Fable 5 brachte Anthropic erstmals ein öffentlich verfügbares Modell seiner Mythos-Klasse auf den Markt, dessen Leitplanken Antworten in Hochrisikobereichen wie Cybersicherheit und Biologie blockieren. Konkret werden bei Fable Anfragen zu Cybersicherheit, Biologie und Chemie sowie Distillation automatisch vom schwächeren Claude Opus 4.8 beantwortet. Die ungebremste Variante ist hingegen nicht allgemein zugänglich: Dasselbe Modell ohne diese Beschränkungen ist Claude Mythos 5, das nur einer kleinen Gruppe geprüfter Kunden zur Verfügung steht – im Rahmen von Project Glasswing. Hinzu kommen Preis und Datenauflagen: Fable 5 und Mythos 5 kosten das Doppelte von Claude Opus 4.8. Anthropic koppelte an beide Modelle eine verpflichtende 30-tägige Datenspeicherung, die bestehende Zero-Retention-Vereinbarungen außer Kraft setzt. Damit verschiebt sich „Sicherheit“ tendenziell von einer Grundeigenschaft hin zu einem gestuften Leistungsmerkmal – eine Entwicklung, vor der auch Beobachter warnen: Die Vorgabe könnte einen Branchenpräzedenzfall schaffen, bei dem der Zugang zu Frontier-Modellen an eine als Sicherheitsmaßnahme gerahmte Pflichtspeicherung gekoppelt wird. Ob Anthropics gestaffeltes Modell langfristig der erklärten Mission – dem Nutzen für die Allgemeinheit – dient oder vor allem eine Gatekeeper-Position absichert, wird sich daran messen lassen müssen, wie schnell und breit die Schutzfähigkeiten tatsächlich verfügbar werden.

https://www.anthropic.com/news/expanding-project-glasswing

https://www-cdn.anthropic.com/8b8380204f74670be75e81c820ca8dda846ab289.pdf

https://www.anthropic.com/system-cards

https://coursiv.io/blog/claude-fable-5

https://yellow.com/news/claude-fable-5-free-until-june-22

https://www.cfr.org/articles/six-reasons-claude-mythos-is-an-inflection-point-for-ai-and-global-security

https://www.techradar.com/pro/security/anthropic-to-present-exposed-mythos-flaws-to-global-watchdog-claims-critical-vulnerabilities-found-in-every-major-operating-system-and-web-browser

https://www.tomshardware.com/tech-industry/artificial-intelligence/nsa-using-clause-mythos-for-offensive-cyber-operations-report-claims-says-half-a-dozen-anthropic-engineers-embedded-inside-the-agency

https://www.theneuron.ai/explainer-articles/everything-to-know-about-claude-fable-5-anthropics-new-and-first-public-release-of-its-mythos-model

Weitere News im Juni

Dashlane-Angriff: Hacker erbeuten verschlüsselte Passwort-Tresore einzelner Nutzer

Dashlane ist ein Passwortmanager, der Passwörter, Passkeys, Zahlungsdaten und andere sensible Informationen in einem verschlüsselten digitalen Tresor speichert. Nutzer können damit Anmeldedaten geräteübergreifend verwalten und sich bei Websites und Apps sicher anmelden.

Mehrere Berichte zeichnen ein konsistentes Bild: Dashlane wurde Ende Mai 2026 Ziel einer Brute-Force-Kampagne gegen bestimmte Nutzerkonten, bei der Angreifer offenbar versuchten, 2FA-Codes bzw. Registrierungsprozesse für neue Geräte zu missbrauchen. Infolge der Attacke sperrte Dashlane zahlreiche Konten vorsorglich automatisch, um unbefugte Zugriffe zu unterbinden.

Laut den übereinstimmenden Berichten gelang es den Angreifern bei weniger als 20 Personal-Plan-Konten, ein neues Gerät zu registrieren und Kopien der verschlüsselten Passwort-Vaults herunterzuladen. Dashlane betont jedoch, dass es keine Hinweise auf eine Kompromittierung interner Systeme gebe und die gestohlenen Tresore weiterhin durch das Master-Passwort verschlüsselt seien.

Selbst bei Passwortmanagern zählt nicht nur die Sicherheit des Anbieters, sondern auch die Stärke des Master-Passworts, robuste MFA-Mechanismen und eine sichere Gerätebindung bleiben entscheidend.

https://www.helpnetsecurity.com/2026/06/05/dashlane-brute-force-attack-vaults-customer-accounts

https://www.securityweek.com/dashlane-brute-force-attack-leads-to-limited-encrypted-vault-downloads

Let‘s Encrypt plant Post-Quantum-Zertifikate ohne aufgeblähte TLS-Handshakes

Let‘s Encrypt bereitet den Übergang zu post-quantenfester Web-Authentifizierung vor und setzt dabei nicht auf klassische, deutlich größere PQ-Zertifikate, sondern auf sogenannte Merkle Tree Certificates (MTCs). Ziel ist es, das Web gegen künftige Quantenangriffe abzusichern, ohne TLS-Verbindungen durch zu große Zertifikatsketten und langsamere Handshakes unpraktisch zu machen.

Let’s Encrypt sieht bei der PQ-Umstellung vor allem ein Problem auf der Authentifizierungsseite der Web-PKI und bevorzugt mit MTCs einen Ansatz, der öffentliche Nachweisstrukturen per Merkle-Baum nutzt. Das passt auch technisch zu bestehenden Transparenzmechanismen im Zertifikatsökosystem und wird bereits im IETF-Umfeld als konkreter Standardisierungsansatz beschrieben.

Kurzfristig ändert sich für Website-Betreiber noch nichts, denn Let‘s Encrypt spricht eher von einem mehrstufigen Fahrplan als von einer sofortigen Umstellung.

Laut Let‘s Encrypt ist für Ende 2026 eine Staging-Umgebung geplant; heise fasst das als Teststart Ende 2026 zusammen. Eine produktionsreife Umgebung peilt Let’s Encrypt für 2027 an.

Wer tiefer in das Thema einsteigen möchte, findet im HiSolutions-Research-Blog weiterführende Beiträge zur Post-Quanten-Migration, zu Post-Quantum Cryptography (PQC) sowie zu den organisatorischen Voraussetzungen wie Krypto-Agilität und Kryptoinventarisierung bzw. einem Kryptokataster.

https://letsencrypt.org/2026/06/03/pq-certs

https://www.heise.de/news/Post-Quantum-ohne-aufgeblaehte-Handshakes-Let-s-Encrypts-neuer-Weg-11318855.html

Die Uhr läuft: Warum die Post-Quanten-Migration jetzt beginnen muss

Be liberal in what you accept – don’t trust anything. Das Thema Vertrauen in Netzwerken hat einen radikalen Wandel vollzogen. Wo es in den Anfangszeiten der modernen IT noch mit einer guten Portion Vertrauensvorschuss voranging, ist heute große Skepsis angebracht. Und mit Quantencomputern steht bereits der nächste Paradigmenwechsel bevor.

Vertrauen im Wandel – eine kurze Geschichte der Netzwerksicherheit

In general, an implementation should be conservative in its sending behavior, and liberal in its receiving behavior.” Diesen Satz formulierte Jon Postel in den Anfangstagen des Internets. Mit diesem Satz in seinem RFC 760 zum Internet-Protokoll im Jahr 1980 sollte er die Netzwerkentwicklung nachhaltig prägen. Nur ein Jahr später, im RFC 793 zur Spezifikation des TCP, erhob er diesen Gedanken explizit zum Robustheitsprinzip: „Be conservative in what you do, be liberal in what you accept from others.

Zum damaligen Zeitpunkt galt dies als pragmatische Ingenieursweisheit. Es entsprach dem Geist einer Zeit, in der das Netz eine überschaubare Gemeinschaft von Universitäten und Forschungseinrichtungen verband. Man kannte sich. Man vertraute sich. Und genau dieses Grundvertrauen wurde zum Fundament eines Netzwerks, das nie für das gebaut wurde, was es heute ist: Ein globales Netzwerk, wo die nächste Gefahr fürs eigene Netzwerksegment nur einen Hop entfernt ist.

Als das Internet in den 1990er-Jahren seinen Weg in Unternehmen fand, wurde schnell klar, dass Postels großzügiges Prinzip allein nicht ausreichen würde. Nicht jeder Teilnehmende im Netz hatte gute Absichten. Die Antwort der IT-Sicherheit folgte einer Logik, die so alt ist wie die Zivilisation selbst: Man baute eine Mauer. Das Modell des Perimeterschutzes war geboren – eine klare Grenze zwischen Innen und Außen. Firewalls filterten den Datenverkehr an den Toren. Was innerhalb der Mauern lag, galt als vertrauenswürdig. Postels Prinzip der Großzügigkeit lebte dort weiter – aber nur noch im geschützten Inneren.

Doch Mauern haben ein grundsätzliches Problem: Sie schützen nur, solange niemand sie überwindet. Wer einmal drinnen ist – ob berechtigt oder nicht – genießt volles Vertrauen. Und die Welt jenseits der Mauern wurde größer, feindseliger, unübersichtlicher.

Parallel dazu reiften kryptografische Verfahren heran, die eine fundamental andere Art von Vertrauen ermöglichten: nicht mehr Vertrauen durch Zugehörigkeit zu einem Netzwerk, sondern Vertrauen durch mathematisch überprüfbare Identität. SSL und sein Nachfolger TLS sicherten die Kommunikation zwischen Endpunkten. VPNs schufen verschlüsselte Tunnel zwischen perimetergeschützten Umgebungen über unsicheres Terrain. Public-Key-Infrastrukturen etablierten Vertrauensketten, die an keine physische Netzwerkgrenze gebunden waren. Was als Ergänzung zum Perimeterschutz begann, wurde zunehmend zu einer eigenständigen Sicherheitsschicht – und schließlich zu einer Alternative.

Nach der Jahrtausendwende formulierte John Kindervag bei Forrester Research im Jahr 2010 den konsequenten Schluss aus dieser Entwicklung: Zero Trust. Das Prinzip ist in seiner Radikalität bemerkenswert einfach: Vertraue niemandem. Verifiziere immer alles.  Kein Netzwerkstandort, keine IP-Adresse, keine Firewall-Regel gewährt Vertrauen – nur die kryptografisch gesicherte, kontinuierlich überprüfte Identität eines Akteurs und der Kontext seiner Anfrage.

Zero Trust ist damit nicht nur eine technische Architektur. Es ist die konsequente Umkehrung von Postels Erbe. Wo das Robustheitsprinzip noch sagte “Sei großzügig in dem, was du akzeptierst”, antwortet Zero Trust “Akzeptiere nichts, was sich nicht zweifelsfrei ausweisen kann”. Aus implizitem Vertrauen wurde explizite Verifikation. Was einst als Tugend galt – Offenheit, Toleranz gegenüber dem Unbekannten – wurde in einer feindlichen Umgebung zur Schwachstelle.

Die Geschichte der Netzwerksicherheit ist damit auch eine Geschichte darüber, wie sich der Begriff des Vertrauens selbst gewandelt hat: vom sozialen Grundkonsens einer akademischen Gemeinschaft über die territoriale Logik befestigter Grenzen hin zu einem System, in dem Vertrauen nicht vorausgesetzt, sondern in jedem einzelnen Moment mathematisch bewiesen werden muss. Postel entwarf sein Prinzip für eine Welt, in der guter Wille die Regel war. Zero Trust wurde für eine Welt gebaut, in der man sich diesen guten Willen nicht mehr leisten kann.

Die vier Bedrohungsachsen der Kryptografie

Heute ist die Netzwerksicherheit fundamental von der Sicherheit der eingesetzten kryptografischen Verfahren abhängig. Diese Verfahren sehen sich vier zentralen Bedrohungsachsen ausgesetzt:

  1. Kontinuierliche Steigerung der Rechenleistung – was heute als sicher parametrisiert gilt, kann morgen durch brute-force-fähige Hardware fallen.
  2. Protokoll- und Implementierungsfehler – von Heartbleed (CVE-2014-0160) über ROBOT (CVE-2017-17382, CVE-2017-6168) bis hin zu Timing-Seitenkanalangriffen. Die Lücke liegt oft nicht im Algorithmus, sondern im Code.
  3. Mathematische Fortschritte – neue analytische Methoden können die effektive Sicherheit eines Verfahrens über Nacht reduzieren, wie zuletzt die Diskussionen um Angriffe auf gitterbasierte Verfahren zeigten.
  4. Quantencomputer – ein kryptografisch relevanter Quantencomputer (CRQC) würde RSA, ECDSA und Diffie-Hellman mittels Shors Algorithmus in polynomialer Zeit brechen.

Die strategische Antwort auf diese Bedrohungen trägt einen Namen: Kryptoagilität – die architektonische Fähigkeit, kryptografische Verfahren in bestehenden Systemen zügig und ohne disruptive Umbaumaßnahmen austauschen zu können (vgl. Fraunhofer SIT: Kryptoagilität). Kryptoagilität ist keine Option mehr. Sie ist eine Überlebensfähigkeit.

Die Quantenbedrohung: Näher als viele glauben

Lange Zeit galt ein kryptografisch relevanter Quantencomputer (CRQC) als akademische Spekulation. Doch die Faktenlage hat sich verdichtet:

  • 2015 veröffentlichte Prof. Michele Mosca, Mitgründer des Institute for Quantum Computing an der University of Waterloo, eine vielbeachtete Risikoabschätzung: Die Wahrscheinlichkeit, dass die heute eingesetzte Public-Key-Kryptografie durch einen Quantencomputer gebrochen wird, liege bei ca. 14 % bis 2026 und bei 50 % bis 2031 (Mosca 2015, eprint.iacr.org/2015/1075).
  • 2016 rief das NIST den Standardisierungsprozess für Post-Quantum Cryptography (PQC) ins Leben. In der Begründung (NIST IR 8105) hieß es unmissverständlich: Ein CRQC könne innerhalb von ein bis zwei Jahrzehnten zur realen Bedrohung werden.
  • August 2024 veröffentlichte das NIST die finalen PQC-Standards: FIPS 203 (ML-KEM, basierend auf CRYSTALS-Kyber), FIPS 204 (ML-DSA, basierend auf CRYSTALS-Dilithium) und FIPS 205 (SLH-DSA, basierend auf SPHINCS+). Der Werkzeugkasten für die Post-Quanten-Ära existiert. Die Standards sind da.
  • 2025 und darüber hinaus setzt sich die Standardisierungsdynamik fort: Mit FIPS 206 (FN-DSA, basierend auf FALCON) steht ein weiterer NIST-Standard für digitale Signaturen kurz vor der Veröffentlichung – ein Verfahren, das insbesondere durch kompakte Signaturen bei gleichzeitig moderaten Schlüsselgrößen besticht. Parallel dazu treibt die ISO die Standardisierung zweier Verfahren voran, die bewusst auf konservativere – und damit besser verstandene – mathematische Grundlagen setzen: FrodoKEM, dessen Sicherheit auf dem allgemeinen Learning-with-Errors-Problem (LWE) ohne Gitterstruktur basiert, sowie Classic McEliece, ein codebasiertes Verfahren mit über 40 Jahren kryptoanalytischer Resistenz (vgl. BSI TR-02102-1, Kryptografische Verfahren: Empfehlungen und Schlüssellängen, Version 2026-01, Abschnitte 2.4.1 & 2.4.2). Damit zeichnet sich ein diversifiziertes PQC-Ökosystem ab – eines, das nicht von einer einzelnen mathematischen Annahme abhängt und der Forderung nach Kryptoagilität auch auf Verfahrensebene Rechnung trägt.

Ein bemerkenswertes Detail verdient besondere Aufmerksamkeit: Anders als bei der Kernfusion, die stets „in 50 Jahren“ einsatzbereit sein soll – egal, wann man fragt –, hat sich die Einschätzung der Krypto-Community zum Zeithorizont eines CRQC über das letzte Jahrzehnt nicht nach hinten verschoben. Die Prognosen konvergieren beständig auf den Zeitraum 2030 bis 2035. Das ist keine vage Zukunft. Das ist dieses Jahrzehnt.

Harvest Now, Decrypt Later – die Bedrohung von heute

Die Quantenbedrohung ist keine Zukunftsmusik – sie materialisiert sich bereits. Unter dem Paradigma „Harvest now, decrypt later“ (HNDL) werden heute verschlüsselt übertragene Daten von staatlichen Akteuren und nachrichtendienstlichen Einheiten systematisch abgefangen und gespeichert, um sie zu einem späteren Zeitpunkt mit einem CRQC zu entschlüsseln.

Betroffen sind alle Daten, deren Vertraulichkeit über den Zeitpunkt der Übertragung hinaus Bestand haben muss: Staatsgeheimnisse, medizinische Daten, Geschäftsgeheimnisse, Verhandlungspositionen, Quellenschutz. Wer heute verschlüsselt kommuniziert, aber klassische Verfahren nutzt, gewährt retrospektive Einsicht, sobald ein CRQC verfügbar ist.

Die Bedrohung durch Quantencomputer ist daher nicht erst in zehn Jahren relevant. Sie ist es bereits jetzt.

Moscas Ungleichung: Warum die Schere bereits aufgegangen ist

Die eigentliche Eskalation liegt nicht im Quantencomputer selbst – sie liegt in der Asymmetrie zwischen Angriffs- und Verteidigungstempo.

Filippo Valsorda, einer der profiliertesten Stimmen im Bereich angewandter Kryptografie, hat diese Dynamik in einer vielbeachteten Analyse (words.filippo.io/crqc-timeline) auf den Punkt gebracht: Mit jedem Durchbruch in der Quantenfehlerkorrektur komprimiert sich die prognostizierte Zeitlinie für einen CRQC, während sich gleichzeitig die für eine vollständige kryptografische Migration benötigte Zeit als erschreckend lang erweist.

Das formalisiert Moscas Ungleichung:

x + y < z

x = benötigte Migrationszeit, y = geforderte Schutzfrist der Daten, z = verbleibende Zeit bis zum CRQC

Sobald x + y > z (die Summe aus Migrationszeit und Schutzbedarf die verbleibende Zeit bis zum CRQC übersteigt) ist das Zeitfenster für eine rechtzeitige Absicherung unwiderruflich geschlossen. Jeder Tag ohne begonnene Migration ist ein Tag, an dem die Schere weiter aufgeht. Es gibt keinen Weg, verlorene Zeit zurückzugewinnen.

Die konvergierenden Signale sind eindeutig: Google demonstrierte im Dezember 2024 mit dem Quantenprozessor Willow erstmals eine skalierende Quantenfehlerkorrektur unterhalb der Fehlerschwelle, wie sie seit den 1990er‑Jahren theoretisch vorhergesagt wurde. Die Ergebnisse, veröffentlicht in der wissenschaftlichen Fachzeitschrift Nature, zeigen, dass logische Qubits mit wachsender Größe exponentiell zuverlässiger werden. Ein Durchbruch, der Quantencomputing von einem physikalischen Experiment zu einer ingenieurtechnisch beherrschbaren Technologie und damit das Narrativ „Quantencomputer sind noch Jahrzehnte entfernt“ endgültig obsolet macht.

IBM, Google und Microsoft haben in den Jahren 2024–2025 konsistente Roadmaps veröffentlicht, die jeweils explizit auf fehlerkorrigierte (fault‑tolerante) Quantensysteme abzielen (Roadmap IBM, Roadmap Google, Roadmap Microsoft). Obwohl sie unterschiedliche Hardware‑Ansätze verfolgen, konvergieren ihre Zeitpläne auf die späten 2020er Jahre, mit ersten großskaligen, logisch geschützten Quantensystemen bis zum Ende dieses Jahrzehnts.

Nationale Sicherheitsbehörden gehen heute explizit davon aus, dass staatliche Akteure bereits verschlüsselten Datenverkehr massenhaft erfassen und langfristig speichern, um ihn mit zukünftigen kryptografischen Durchbrüchen – insbesondere durch Quantencomputer – nachträglich zu entschlüsseln. Dieses bereits weiter oben benannte Vorgehen ist als Harvest Now, Decrypt Later (HNDL) bekannt und wird in aktuellen Regierungs‑, Industrie‑ und Aufsichtsberichten als gegenwärtige, operative Realität beschrieben (stateofsurveillance.org, federalreserve.gov).

Damit hat sich die zentrale Frage verschoben: Es geht nicht mehr darum, ob die heutige Public-Key-Kryptografie fällt, sondern ob unsere Infrastrukturen schnell genug umgerüstet sein werden, wenn es so weit ist.

Was jetzt zu tun ist

Das klingt düster, ist aber kein Grund zur Resignation. Es ist ein Grund zum Handeln. Der Werkzeugkasten existiert. Die Standards sind verabschiedet. Die Migrationspfade werden klarer. Was fehlt, ist nicht Technologie. Was fehlt, ist Entschlossenheit und begonnene Arbeit.

Fünf Schritte, die Sie diese Woche anstoßen können:

  1. Kryptografisches Inventar erstellen: Sie können nicht migrieren, was Sie nicht kennen. Erfassen Sie systematisch, wo in Ihrer Infrastruktur welche kryptografischen Verfahren im Einsatz sind – von TLS-Konfigurationen über VPN-Tunnel bis hin zu Signaturverfahren in CI/CD-Pipelines und Firmware-Updates. Das BSI bezeichnet diesen Schritt als unverzichtbare Grundlage jeder Migrationsstrategie.
  2. Daten nach Schutzfrist klassifizieren: Nicht alle Daten sind gleich betroffen. Identifizieren Sie Assets, deren Vertraulichkeit oder Integrität über 2030 hinaus gewährleistet sein muss. Diese Daten stehen unter akuter HNDL-Bedrohung und erfordern priorisierte Migration.
  3. Kryptoagilität architektonisch verankern: Kryptografische Verfahren dürfen nicht hart in Anwendungen und Protokolle eingebrannt sein. Abstraktionsschichten, konfigurierbare Cipher-Suites und modulare Kryptobibliotheken sind die Voraussetzung dafür, dass die PQC-Migration nicht zum Großprojekt mit Zeithorizont 2035 wird.
  4. Hybride Ansätze jetzt evaluieren und pilotieren: Die NIST-Standards (ML-KEM, ML-DSA, SLH-DSA) sind final. Große Anbieter wie Cloudflare, Google und Signal setzen bereits hybride Verfahren (klassisch + PQC) in Produktion ein. Pilotieren Sie hybride TLS-Konfigurationen und Key-Encapsulation in Ihren kritischsten Kommunikationskanälen.
  5. Migration als strategisches Programm aufsetzen – nicht als Technikprojekt: Selbst bei guter Kryptoagilität bleibt die PQC-Migration mehr als ein Algorithmentausch. Sie betrifft Procurement-Anforderungen, Compliance-Nachweise, Partnerkommunikation, Zertifikats-Lifecycles und Legacy-Systeme, die sich nicht per Konfigurationsänderung umstellen lassen. Diese organisatorische Breite erfordert ein Mandat auf Leitungsebene, ein dediziertes Budget und einen realistischen, aber ambitionierten Zeitplan. Kryptoagilität verkürzt die technische Migrationszeit erheblich. Aber nur ein strategisches Programm stellt sicher, dass auch alles drumherum rechtzeitig mitkommt.

Moscas Ungleichung ist keine Abstraktion. Sie ist eine Stoppuhr – und sie läuft. Jeder Tag, an dem Ihre Organisation die Post-Quanten-Migration nicht aktiv vorantreibt, ist ein Tag, an dem sich das Zeitfenster für eine geordnete Transition weiter schließt. Die gute Nachricht: Wer heute beginnt, hat noch die Chance, vor der Kurve zu sein statt hinter ihr. Die Standards stehen. Die Werkzeuge reifen. Die Early Movers haben angefangen.

Die Frage ist nicht mehr, ob Sie migrieren müssen. Die Frage ist, ob Sie es rechtzeitig tun.

Fangen Sie an. Heute.

Stryker-Breach: Wenn das eigene MDM zur Waffe wird

Am 11. März 2026 löschte die iranisch-verlinkte Hacktivistengruppe Handala über Microsofts Intune-Wipe-Funktion nahezu 80.000 Geräte des Medizintechnik-Konzerns Stryker. Stryker meldete keine Hinweise auf Ransomware/Malware in der eigenen Umgebung. Der Angriff erfolgte durch den Missbrauch von cloud-basierten Diensten zur Administration der Endgeräte. Für die destruktive Phase war keine zusätzliche Malware auf den Endpoints nötig. Der Angriff missbrauchte legitime Intune‑Wipe‑Funktionen. Der initiale Angriffsweg, mit dem sich die Täter Zugang zur Cloud verschafften (Credential Theft), bleibt jedoch unklar.

Der Fall illustriert ein strukturelles Risiko, das viele Organisationen unterschätzen: Wenn eine einzelne Steuerungsebene Code ausrollen, Konfigurationen ändern oder Geräte auf Unternehmensebene löschen kann, ist sie kein „einfaches Endpoint-Management“ mehr, sondern verhält sich wie kritische Infrastruktur. Ein Angreifender mit Intune-Administrator-Zugang braucht keine Malware – er kann Konfigurationsänderungen verteilen, die VPN oder WLAN lahmlegen, Skripte laufen lassen, die Sicherheitsfunktionen deaktivieren, den Compliance-Status manipulieren – sodass Conditional-Access-Nutzer aussperrt werden – und gleichzeitig Endpoints aus der Ferne löschen, um die Recovery zu verlangsamen.

CISA reagierte am 18. März mit einem Alert und forderte US-Organisationen auf, ihre Intune-Umgebungen gegen ähnliche Angriffe zu härten. Die Kernempfehlungen: Einen Least-Privilege-Ansatz über Intunes RBAC realisieren, bei dem nur die tatsächlich benötigten Berechtigungen vergeben werden. Dazu kommen Multi-Faktor-Authentisierung (MFA) und privilegierte Zugriffshygiene über Conditional Access, Risk Signals und Microsoft Entra ID sowie Multi-Admin-Approval für sensible Aktionen wie Device Wipes, Anwendungsänderungen und RBAC-Modifikationen.

Das reicht allerdings nicht. Diese Empfehlungen härten zwar den administrativen Zugang, adressieren aber nicht die tieferliegende Architektur-Realität: Intune fungiert inzwischen als Teil der Identity Control Plane und muss wie Identity-Infrastruktur geplant, betrieben und überwacht werden. Konkret bedeutet das eine Tier-0-Behandlung: Für administrative Zugänge müssen phishing-resistente MFA-Verfahren wie FIDO2 oder Hardware-Token verbindlich sein; zugleich sollte der Zugriff auf die Intune-Administrationsoberfläche auf gemanagte und konforme Geräte beschränkt werden. Privilegierte Rollen dürfen nicht dauerhaft zugewiesen sein, sondern sollten über Privileged Identity Management (PIM) nur zeitlich begrenzt und nachvollziehbar aktiviert werden. Ebenso wichtig ist ein aktives Monitoring mit Alarmierung auf sicherheitskritische Ereignisse – insbesondere auf Anmeldungen privilegierter Konten sowie auf die Anlage, Änderung oder Rechteausweitung administrativer Identitäten. Schließlich müssen Audit- und Sign-in-Logs über die standardmäßigen Aufbewahrungsfristen hinaus gesichert werden, damit auch verzögert erkannte Kompromittierungen forensisch belastbar rekonstruierbar bleiben.

Das Fazit ist unbequem: Wenn eine Plattform Policies durchsetzen, Zugriff entziehen und den Betrieb auf Unternehmensebene mit Admin-Aktionen stören kann, verdient sie dieselbe architektonische Disziplin wie Identity-Systeme. Der Stryker-Breach ist der Proof of Concept dafür, dass MDM-Plattformen Tier-0-Assets sind – ob Organisationen sie so behandeln oder nicht.

https://www.bleepingcomputer.com/news/security/cisa-warns-businesses-to-secure-microsoft-intune-systems-after-stryker-breach

https://therecord.media/stryker-cyberattack-iran-hackers

https://petri.com/why-microsoft-intune-belongs-in-the-tier-0-identity-control-plane

Weitere News im April

BrowserGate: Clientseitige Telemetrie trifft Compliance

Die Webseite BrowserGate der Organisation Fairlinked wirft LinkedIn vor, beim Aufruf der Website systematisch auf installierte Browser-Erweiterungen zu prüfen und dabei zusätzliche Browser- bzw. Geräteinformationen zu erfassen und daraus ein weitreichendes Nutzerprofil abzuleiten. BleepingComputer hat wesentliche Teile der technischen Praxis unabhängig nachvollzogen. Demnach wurde beim Seitenaufruf ein Script geladen, das in Tests 6.236 Extensions per Resource-Probing prüfte und weitere Merkmale wie CPU-Kerne, Speicher, Bildschirmauflösung, Zeitzone, Spracheinstellungen und Batteriestatus erfasste. Nicht unabhängig verifiziert wurden dagegen die von Fairlinked behauptete konkrete Weitergabe der Ergebnisse an Dritte oder deren spezifische Nutzung.

LinkedIn bestreitet die Missbrauchs- bzw. „Spionage“-Deutung und erklärt, die Erkennung bestimmter Extensions diene dem Schutz der Plattform, der Durchsetzung der Nutzungsbedingungen, der Abwehr von Scraping sowie der Stabilität des Dienstes. Das Unternehmen erklärte außerdem, die Daten nicht zur Ableitung sensibler Eigenschaften von Mitgliedern zu verwenden.

In Europa wird in diesem Zusammenhang vor allem die Frage aufgeworfen, ob LinkedIn nach dem Digital Markets Act als „Gatekeeper“, also als Technologiekonzern mit besonderer Marktmacht, einzustufen ist, für den besondere regulatorische Vorgaben gelten. Diese Einordnung stammt bislang insbesondere aus dem Fairlinked/BrowserGate-Umfeld. Ob und in welchem Umfang daraus formelle Verfahren oder weitergehende Klagen entstehen, geben die Quellen nicht her.

Aus Compliance- und Security-Sicht zeigt der Fall, dass Extension-Scanning und Browser-Fingerprinting auch dann erhebliche Privacy-, Transparenz- und Governance-Risiken erzeugen können, wenn sie technisch mit Anti-Abuse-Zielen begründet werden. Ähnliche Techniken können zur Profilbildung und zum Tracking beitragen.

https://browsergate.eu

https://www.bleepingcomputer.com/news/security/linkedin-secretly-scans-for-6-000-plus-chrome-extensions-collects-data

https://www.linkedin.com/pulse/linkedin-accused-extensive-browser-surveillance-pdfze

https://www.msn.com/en-us/news/technology/browsergate-report-alleges-linkedin-scans-extensions-and-devices/ar-AA20kK5c

https://pipelab.org/blog/linkedin-browsergate-agent-fingerprinting

Quanten-Computer: Der Wendepunkt für Public-Key-Kryptografie ist erreicht

Noch vor wenigen Jahren galt der „quantum break of ECC“ als theoretisches Langzeitrisiko. Diese Einschätzung hat sich im März und April 2026 grundlegend geändert.

Auslöser ist eine ungewöhnlich dichte Abfolge belastbarer Signale aus Forschung und Industrie, zusammengefasst und klar eingeordnet von Filippo Valsorda (Kryptografie-Pionier und Betreuer der Kryptografie-Standardbibliothek der Programmiersprache Go). Seine zentrale Botschaft ist unmissverständlich: Die Migration zu Post‑Quantum‑Kryptografie ist kein strategisches Planungsprojekt mehr, sondern ein akutes Shipping‑Problem.

Nach Einschätzung von Filippo Valsorda erleben wir einen Risikokipppunkt. Selbst wenn sich einzelne Prognosen im Rückblick als zu pessimistisch erweisen sollten, ist Untätigkeit inzwischen die riskantere Entscheidung. Post‑Quantum‑Kryptografie ist seit 2026 weder Forschungs‑ noch Vorbereitungsthema – sie ist operative Sicherheitsarbeit.

https://words.filippo.io/crqc-timeline

Aktive Ausnutzung der Langflow-Schwachstelle CVE-2026-33017

In der Open-Source-Plattform Langflow, einem weitverbreiteten Werkzeug zum visuellen Erstellen und Betreiben von KI-Agenten und KI-Workflows, wurde im März 2026 eine kritische Sicherheitslücke unter der Kennung CVE-2026-33017 öffentlich bekannt. Die Schwachstelle ermöglicht es Angreifenden, ohne jegliche Authentifizierung beliebigen Programmcode auf betroffenen Servern auszuführen – ein Szenario, das in der Informationssicherheit als unauthentifizierte Remote Code Execution (RCE) klassifiziert wird und die höchste Risikostufe darstellt. Die US-amerikanische Cybersicherheitsbehörde CISA hat die Schwachstelle in ihren Katalog der nachweislich aktiv ausgenutzten Sicherheitslücken (Known Exploited Vulnerabilities, KEV) aufgenommen, was bedeutet, dass reale Angriffe in freier Wildbahn beobachtet wurden, und nicht lediglich ein theoretisches Risiko besteht.

Der technische Kern der Schwachstelle liegt in einem fundamentalen Design- und Implementierungsfehler im Zusammenspiel zwischen öffentlich zugänglichen Funktionen und der internen Code-Ausführung. Langflow bietet einen sogenannten „Public Flow Build“-Endpunkt an, der bewusst ohne Anmeldung erreichbar ist, damit öffentliche Flows – also vorgefertigte KI-Workflows – von externen Nutzern angestoßen werden können. Der Endpunkt ist absichtlich öffentlich gestaltet, weil er eine legitime Geschäftsfunktion – das Teilen und Ausführen öffentlicher Flows – bedient. Das eigentliche Versäumnis liegt darin, dass eine öffentlich zugängliche Funktion ausführbare, von außen kontrollierbare Definitionen annimmt und diese ohne ausreichende Validierung oder Isolation zur Ausführung bringt. Es handelt sich also um ein architektonisches Problem an der Schnittstelle zwischen Offenheit und Sicherheit.

Öffentlich zugängliche Funktionen, die „Code als Daten“ entgegennehmen und verarbeiten, stellen ein inhärent hohes Risiko dar. Die Kombination aus einem unauthentifizierten Endpunkt, der Annahme ausführbarer Definitionen von außen und einer fehlenden Sandbox bei der Code-Ausführung bildet genau jenes toxische Muster, das CVE-2026-33017 so gefährlich und so einfach ausnutzbar macht.

https://www.heise.de/news/Jetzt-patchen-Schadcode-Attacken-auf-KI-Tool-Langflow-beobachtet-11226852.html

https://www.cve.org/CVERecord?id=CVE-2026-33017

https://github.com/langflow-ai/langflow/security/advisories/GHSA-vwmf-pq79-vjvx

https://github.com/advisories/GHSA-rvqx-wpfh-mfx7

Iranische Hacker veröffentlichen private E-Mails von FBI-Direktor Kash Patel

Eine dem iranischen Staat zugerechnete Hackergruppe hat private E-Mail-Konten von FBI-Direktor Kash Patel kompromittiert und Teile der erbeuteten Korrespondenz öffentlich ins Netz gestellt. Das FBI hält technische Details zum konkreten Vorfall bislang zurück. Das US-Außenministerium reagierte mit einer öffentlichen Auslobung einer Belohnung von bis zu zehn Millionen US-Dollar für Hinweise, die zur Identifizierung oder Lokalisierung der verantwortlichen iranischen Cyber-Akteure führen.

Der Vorfall unterstreicht, wie staatlich gesteuerte Hackergruppen zunehmend persönliche Kommunikationskanäle hochrangiger Beamter ins Visier nehmen, um politischen Druck auszuüben. Selbst private Accounts von Entscheidungsträgern sind inzwischen ein erstrangiges Ziel geopolitisch motivierter Cyberoperationen.

https://therecord.media/fbi-confirms-theft-of-directors-personal-emails-iran-group

https://therecord.media/iran-hackers-state-department-reward

EU Top Officials & Signal

Politico berichtet, dass die Kommission eine Signal‑Gruppe hochrangiger Beamter auflösen ließ – präventiv, ohne bestätigte Kompromittierung.

Doch warum ist ausgerechnet Signal ein Problem – ein Messenger, der für seine starke Verschlüsselung bekannt ist? Die Antwort gilt nicht nur für Signal, sondern für nahezu alle privaten Messenger-Apps: Sie wurden für den persönlichen Gebrauch entwickelt und optimiert. Für den Einsatz in institutionellen Umgebungen – insbesondere in Regierungen und Behörden – fehlen ihnen entscheidende Funktionen:

  • zentrales User Management – Es gibt kein Onboarding/Offboarding durch IT-Administratoren.
  • Audit Trail – Es besteht keine nachvollziehbare Protokollierung von Aktivitäten.
  • Compliance-Archivierung – Es existiert keine rechtskonforme Aufbewahrung dienstlicher Kommunikation.
  • MDM-Integration – Private Messenger-Apps lassen sich als App per MDM verteilen, bieten aber keine nativen Enterprise‑Admin‑Funktionen wie zentrales User‑Management, Audit/Archive oder eDiscovery.
  • Geräte-Policy-Enforcement – Private Messenger-Apps selbst erzwingen keine institutionellen Richtlinien. Diese lassen sich nur über Geräte‑ und App‑Policies der MDM/EMM‑Plattform abbilden.
  • Sicherheitsfreigabe-Verknüpfung – Es erfolgt keine Kopplung an Freigabestufen oder Berechtigungskonzepte.
  • Kontrollierte Gruppenverwaltung – Es liegt keine abgesicherte Steuerung von Gruppenmitgliedschaften vor.
  • Forensische Auditierbarkeit – Es fehlt eine zentrale Auditierbarkeit/Archivierung. Forensik ist auf Endpoint‑Ebene möglich, aber stark vom Gerät und den Governance‑Rahmenbedingungen abhängig.

Kurz gesagt: Das Signal-Protokoll ist nicht das Problem. Das Problem ist, dass ein Werkzeug, das Einzelpersonen vor Überwachung schützen soll, für die gesteuerte und rechenschaftspflichtige Kommunikation einer Institution schlicht nicht vorgesehen ist.

https://www.politico.eu/article/top-eu-officials-signal-group-chat-hacking-fears

OpenClaw: Die Real‑World‑Bestätigung der MCP‑Risikoachsen

TL;DR: In meinem Beitrag „Die dunkle Seite des Model Context Protocols (MCP)“ habe ich vier Risikoachsen beschrieben: Tool Poisoning, Prompt Injection, Sampling Abuse/Autonomie, Composability und Chaining. Die jüngsten Vorfälle rund um OpenClaw zeigen diese Risiken in der Praxis: hunderte bösartige Skills in ClawHub, eine 1‑Klick‑RCE‑Schwachstelle (CVE‑2026‑25253), zehntausende fehlkonfigurierte, öffentlich erreichbare Instanzen sowie ein rasantes Wachstum eines offenen Ökosystems, das Produktivität und Missbrauch gleichermaßen skaliert.

Was ist OpenClaw?

OpenClaw ist ein selbst gehostetes KI-Agent-Framework (umgangssprachlich “Gateway” genannt) für agentische KI. Es verknüpft Chat‑Kanäle (u. a. WhatsApp, Telegram, Slack/Discord, iMessage) mit „händischen“ Fähigkeiten (vom Ausführen von Shell‑Befehlen und Dateizugriff über Browser‑Automatisierung, bis zu E‑Mail‑Handling) und lässt sich per Web‑UI und CLI steuern. Es läuft lokal (oder im eigenen Server/Container), kann verschiedene Modelle ansprechen und ist über Plugins/Skills erweiterbar.

Das Projekt startete auf GitHub am 24.11.2025 und die Popularität explodierte Ende Januar 2026. Die Bewertung des GitHub‑Repositorys erreichte binnen Wochen die Marke von 150.000 Stars (Stand: 11.02.2026 > 180.000), begleitet von rasantem Ökosystem‑Wachstum rund um den Skill‑Marktplatz ClawHub.

Anmerkungen zur Begrifflichkeit von Skills, Plugins und Tools

Die aktuelle KI‑Agenten‑Landschaft verwendet die Begriffe Skills, Plugins und Tools uneinheitlich und häufig synonym, obwohl sie technisch unterschiedliche Rollen einnehmen können. Ein Skill ist eine konkrete, installierbare Fähigkeit; ein Plugin ist das Erweiterungsmodul, das diese Fähigkeit bereitstellt; ein Tool ist die standardisierte technische Schnittstelle, über die ein Agent solche Fähigkeiten aufruft. Jeder Skill ist in der Regel ein Plugin. Jedes Plugin stellt ein oder mehrere Tools bereit.

Aktueller Missbrauch: Von „ClawHavoc“ bis 1‑Klick‑RCE

Supply‑Chain-Angriffe über Skills

Koi Security hat in einem vollständigen ClawHub‑Audit 341 (von 2.857) bösartige bzw. unsichere Skills identifiziert, die teils als Krypto‑Tools, YouTube‑Utilities oder Typosquats (Tippfehler‑Ausnutzung) getarnt sind. Die Kampagne „ClawHavoc“ setzt u. a. auf passwortgeschützte ZIPs und Base64‑Skripte (glot.io) zur Stager‑Ausführung, mit Payloads wie Atomic macOS Stealer (AMOS) und Keyloggern. SC‑Medien und THN bestätigen die Befunde.

1‑Klick‑RCE (CVE‑2026‑25253)

Ein Kopplungsfehler zwischen User Interface und Gateway erlaubte Token‑Exfiltration via Cross‑Site WebSocket Hijacking. Der Besuch eines präparierten Links genügte, um Konfigurationen zu ändern und Befehle auszuführen („1‑Klick‑RCE“). Der Fix erfolgte am 30. Januar in v2026.1.29. Detaillierte technische Beschreibungen und die in der NVD‑Notiz aufgeführten Links erläutern den Exploit‑Pfad.

Fehlkonfigurationen & Exponierung

Internetweite Scans fanden über 21. 000 öffentlich erreichbare OpenClaw‑Instanzen, teils ohne hinreichende Absicherung. Ursache sind u. a. falsches Binding/Reverse‑Proxy‑Setups und Shadow‑Deployments.1

Gegenmaßnahmen im Ökosystem

Als Reaktion darauf integriert OpenClaw den Dienst VirusTotal Code Insight in den ClawHub, in das Skill-/Plugin-Verzeichnis ClawHub. Beim Upload von Skills wird automatisch ein Hash aus den hochgeladenen Dateien erzeugt, abgeglichen und bei Bedarf gescannt. Zusätzlich werden die Skills täglich neu gescannt, um neu gefundene Schwachstellen abzuwehren. Das reduziert Supply‑Chain‑Risiken, ist aber keine Abwehr gegen Prompt‑Injection oder logisch verpackte „Payload‑Prompts“.

Betrachtung durch die MCP‑Linse: Vier Risikoachsen, live am Beispiel OpenClaw

  • Tool Poisoning: Veröffentlichte Skills/Plugins werden zum Distributionskanal für Stealer, Backdoors oder „Install‑Anleitungen“ mit verschleierten Stagern. ClawHavoc zeigt, wie „wiederverwendbare Verknüpfungen“ einer offenen Plattform zur Lieferkette für Malware werden.
    (LLM03 Supply Chain, LLM04 Data & Model Poisoning)
  • Prompt Injection (auch indirekt): Agenten, die E‑Mails, Webseiten oder Docs lesen, lassen sich über eingebettete Instruktionen manipulieren, inkl. Secret‑Leakage oder gefährlicher Tool‑Aufrufe.
    (LLM01 – Prompt Injection, LLM07 – System Prompt Leakage)
  • Sampling Abuse/Autonomie: Wiederkehrende Automationen (Cron/Jobs, Heartbeats) können stille Kostenlawinen und unbeaufsichtigte Aktionen auslösen; Medienberichte dokumentieren Fehlkonfigurationen mit erheblichen API‑Token‑Kosten.
    (LLM06 Excessive Agency, LLM10 Unbounded Consumption)
  • Composability & Chaining: Mehrstufige Install‑Workflows (Markdown‑Schritte → externer Downloader → Umgehung von Quarantänen) schaffen schwer überschaubare Wirkungsketten, ähnlich klassischen Kill‑Chains, nur in Agenten‑Ökosystemen.
    (LLM06 Excessive Agency, LLM05 Improper Output Handling, LLM03 Supply Chain)

Standardisierung als Hebel

Was MCP als „USB‑C für Agenten“ standardisiert (Tools/Ressourcen/Prompts/Sampling), skaliert auch die Angriffsfläche. Meine ursprüngliche MCP‑Analyse skizzierte genau diese Trade‑Offs.

Empfehlungen

Grundsätzlich sollte OpenClaw niemals auf produktiven Endpunkten betrieben werden. Wenn OpenClaw dennoch eingesetzt werden soll, dann sollte es auf Basis der drei ineinandergreifenden Leitplanken gehärtet werden:

  1. Sandbox (in welcher Umgebung laufen die Tools/Skills)
  2. Tool-Policy (welche Skills darf der Agent überhaupt aufrufen)
  3. Elevated (enger, protokollierter Notausstieg für Host‑Exec‑Befehle)

Aber auch eine konsequente Skill- bzw. Tool-Hygiene muss gewahrt bleiben.

Aus Sicht der MCP‑Linse ergeben sich dann folgende Punkte:

  1. Isolieren & nur lokal binden
    • Sandbox konsequent aktivieren und „dicht“ konfigurieren.
    • Betrieb in VM/Container, ohne Produktions‑Secrets; Gateway ausschließlich auf 127.0.0.1 binden. Für Remote‑Zugriff Tunnel mit starker Authentisierung wie bei SSH oder WireGuard, statt Public Ports und Weiterleitungen verwenden (wie es auch der Hersteller empfiehlt).Datei‑/Workspace‑Zugriff minimieren.
    • Eingebaute Security Audit Funktion regelmäßig ausführen und Befunde beheben.
  2. Patch‑Stand des Gateways erzwingen (Empfehlungsstand: 10.02.2026)
    • Mindestens v2026.1.29 (Fix für CVE‑2026‑25253),
      idealerweise neuere v2026.2‑Releases.
    • Nach der Installation Token rotieren und Logs auf verdächtige WebSocket‑Ereignisse prüfen.
  3. Skill‑Hygiene (Default‑Deny)
    • ClawHub‑Skills sowie deren Updates standardmäßig blocken und nur kuratiert/signiert zulassen
    • Skill‑Bundles vor Installation (Virus Total Code Insight, Sandbox) prüfen.
    • Vorsicht: Virus Total erfasst keine Prompt‑Injection‑Payloads.
    • Policy‑Tipp: Verbieten Sie Markdown‑„Install‑Schritte“ (harmlos wirkende Copy&Paste Anleitungen, die dann schadhafte Befehle z. B. in Base64‑Skripte oder passwortgeschützte ZIPs verstecken) organisatorisch und technisch. Die ClawHavoc‑Kette nutzte exakt solche Muster.
  4. EDR & Netzwerk‑Kontrollen
    • Detektion für Shell‑Aufrufe aus Gateway/Agent heraus, Least‑Privilege‑Policies für Tools (exec/fs nur bei Bedarf) und DPI/Netzwerkregeln gegen verdächtige Fetch‑Muster (z. B. glot.io‑Snippets, atypische GitHub‑Fetches).
    • Enterprise‑Sicht: Sichtbarkeit und Laufzeitschutz für Agenten, u. a. Erkennen von OpenClaw‑Nutzung, Filterung von Zugriffen aus dem Internet (einschließlich Tunnel- und VPN-Nutzung) und Filterung gegen Prompt‑Injection vor Aktionsausführung.
  5. Kosten‑/Autonomie‑Guardrails
    • Harte Token‑Budgets (analog zu Prepaid-Handyverträgen), Rate‑Limits und Freigabe‑Workflows für periodische Tasks. Autonomie/Sampling nur nach expliziter Freigabe, mit Telemetrie/Alarmierung bei Überschreitung von explizit vorab gesetzten Budgetgrenzen.
  6. Governance (MCP‑Leitplanken übertragen)
    • Leicht verständliche Freigabe‑Workflows und -Oberflächen, explizite Tool‑Freigaben, Kompositionsbarrieren, Logging aus dem MCP‑Kontext 1:1 auf OpenClaw oder ähnliche Frameworks übertragen. Die Risikoachsen sind identisch.
  7. Weitere Quellen:

Einordnung: Von Hype zu Härtung

OpenClaw hat gezeigt, wie schnell agentische KI vom Produktivitäts‑Booster zur Supply‑Chain‑Angriffsfläche werden kann: standardisierte Tool‑Zugriffe + Autonomie + offene Marktplätze eröffnen neue Initial‑Access‑Pfade auf Endpunkte und in Netze. Wer Agenten einsetzen will, braucht eine gewissenhafte Prüfung statt Hype, einschließlich betrieblicher Disziplin (Isolierung, Patchen, Kuratieren), technischer Härtung (Audit, Tool‑Least‑Privilege) und organisatorischer Governance.

Für eine umfassende Sicherheitsbetrachtung von OpenClaw über die MCP-Perspektive hinaus lohnt sich zudem ein Blick auf den bald ebenfalls hier im Blog erscheinenden Beitrag von Volker Tanger.


  1. Shadow‑Deployments testen neue Softwareversionen im Hintergrund mit realem Traffic, ohne dass ein Nutzer etwas mitbekommt. Damit kann Performance, Fehler und Verhalten unter Realbedingungen beobachten werden. ↩︎

Weitere News im Februar

Aktuelle Datenleaks I: Offene Credential-Sammlung mit fast 150 Mio. Log-ins

Eine ungeschützte Datenbank mit 149.404.754 Nutzer‑/Passwort‑Kombinationen wurde öffentlich zugänglich aufgefunden. Die Datensätze stammen überwiegend aus Infostealer‑Malware (historische Stealer‑Logs) und enthalten u. a. ca. 48 Mio. Gmail‑Konten. Es besteht eine hohe Gefahr für Credential‑Stuffing und Folgeangriffe; der Hoster nahm die Daten nach Hinweis offline.

https://www.wired.com/story/149-million-stolen-usernames-passwords/

https://cybernews.com/security/credential-leak-facebook-instagram-passwords-exposed/

Aktuelle Datenleaks II: Update zum Panera-Bread-Leak

Am 27. Januar 2026 behauptete die Gruppe ShinyHunters, in das System von Panera Bread eingedrungen zu sein. Panera Bread ist eine große amerikanische Kette von Fast-Casual-Restaurants mit Bäckerei-Cafés. Angeblich umfassten die kompromittierten Daten mehr als 14 Millionen Einträge. Die Webseite „Have I Been Pwned“ beziffert das Leck am 02.02.2006 jedoch auf „nur“ noch 5,1 Mio. eindeutige Accounts. Laut der Darstellung von ShinyHunters erfolgte der Zugang über SSO‑Missbrauch (Microsoft Entra) und Voice Phishing (Vishing).

https://dailydarkweb.net/panera-bread-data-breach-shinyhunters-claims-14-million-records-stolen/

https://www.bleepingcomputer.com/news/security/panera-bread-data-breach-impacts-51-million-accounts-not-14-million-customers/

Aktuelle Datenleaks III: Schwachstelle im Browser-Game

Das browserbasierte Regierungssimulationsspiel NationStates hat einen Datenvorfall bestätigt und die Website vorübergehend abgeschaltet. Ein Spieler mit Bug-Hunter-Historie konnte beim Testen einer kritischen Schwachstelle in der neuen „Dispatch Search“-Funktion unbefugt Code auf dem Produktionsserver ausführen und Quellcode sowie Nutzerdaten kopieren.  Dabei wurden unter anderem E-Mail-Adressen, als MD5-Hashes gespeicherte Passwörter (MD5 gilt schon seit sehr langem als unsicher für Passwörter), Log-in-IP-Adressen und Browser-User-Agent-Strings offengelegt. Außerdem gilt es als wahrscheinlich, dass Teile der internen „Telegram“-Nachrichten betroffen sind.

https://www.bleepingcomputer.com/news/security/nationstates-confirms-data-breach-shuts-down-game-site/

Es gilt weiter hin

  1. Nutzen Sie nie das gleiche Passwort bei unterschiedlichen Diensten. Wird ein Dienst kompromittiert, bleiben die Auswirkungen auf die anderen Dienste gering.
  2. Es ist nie zu spät, aber auch nie zu früh, um seine Identitäten zu härten. Verwenden Sie phishing‑resistente MFA (FIDO2/WebAuthn), eliminieren Sie SMS/Telefon‑MFA, nutzen Sie Conditional Access für riskobasierte Prüfungen und härten Sie SSO (Token‑Widerruf, Geo/ASN‑Kontrollen).

BfV und BSI warnen vor Phishing über Messengerdienste

Aktuell warnen das BfV und das BSI vor einer laufenden Kampagne eines mutmaßlich staatlich gesteuerten Akteurs. Über den Messenger Signal führt dieser gezielte Phishing-Angriffe auf hochrangige Personen aus Politik, Militär und Diplomatie sowie auf Investigativjournalisten und -journalistinnen in Deutschland und Europa aus. Auffällig ist, dass weder Malware noch Zero-Days zum Einsatz kommen. Stattdessen werden legitime Sicherheitsfunktionen der Apps mit Social Engineering verknüpft. Besonders gefährlich sind das Abfragen von PIN/Verifizierungscodes durch angebliche „Signal-Support“-Konten (was zur vollständigen Kontoübernahme führt) sowie das Ausnutzen der Gerätekopplung via QR-Code (was unbemerktes Mitlesen inkl. Zugriff auf Nachrichten der letzten 45 Tage ermöglicht). Diese Taktiken sind auch auf WhatsApp übertragbar, da die App eine vergleichbare Funktionsweise aufweist. Aus sicherheitstechnischer Sicht ist die Kampagne besonders heikel, da der erfolgreiche Zugriff nicht nur Einzelchats, sondern auch ganze Kommunikationsnetze über Gruppenchats und Kontaktlisten kompromittiert. Dadurch ist es möglich, Kontaktstrukturen zu kartieren und glaubwürdige Folgeangriffe zu starten. Die geringen technischen Hürden könnten zur Nachahmung durch Cyberkriminelle führen.

Die Behörden empfehlen als pragmatische Gegenmaßnahmen: Nicht auf vermeintliche Support-Chats reagieren, keine PINs oder SMS-Codes herausgeben, die Registrierungssperre (Registration Lock) in Signal aktivieren, QR-Codes nur bei eigener Gerätekopplung scannen, verknüpfte Geräte regelmäßig prüfen und unbekannte entfernen sowie Sicherheitsnummer-Änderungen out-of-band verifizieren. Bei Anzeichen einer Kompromittierung sollen Betroffene das BfV/BSI umgehend kontaktieren.

https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2026/202602_BfV_BSI.pdf?__blob=publicationFile

Ähnlich wie beim „Signalgate” erfolgen Angriffe auf sichere Messenger-Dienste nicht an den Stellen, an denen die Hersteller technische Sicherheitsmaßnahmen implementiert haben, sondern an den Stellen, für die die Anwender die Verantwortung tragen. Bei „Signalgate” fehlte beispielsweise die Überprüfung durch den Benutzer, ob der Gesprächspartner tatsächlich die Person ist, die er in die Chatgruppe einladen wollte. Bei den neuen Angriffen liegt es in der Verantwortung der Benutzer, nur die Geräte zu koppeln, die sich unter ihrer Kontrolle befinden, bzw. die PIN für die Accountwiederherstellung nicht weiterzugeben.

https://research.hisolutions.com/2025/04/signalgate/

Bedrohte Sicherheitsforschende

Zack Whittaker hat gemeinsam mit DataBreaches eine Umfrage unter Sicherheitsforschenden und Journalisten über Drohungen aufgrund ihrer Arbeit durchgeführt.

Dabei geht es einerseits um rechtliche Drohungen, beispielsweise im Rahmen des sogenannten „Hackerparagraphen“ § 202c StGB, aber auch um Drohungen von Kriminellen, welche die Forschenden einzuschüchtern versuchen.

Diese Umfrage ermöglicht einen Einblick in das bisher noch recht unerforschte Feld und ist als Startpunkt einer tieferen, empirischen Untersuchung gedacht.

https://databreaches.net/wp-content/uploads/security-researcher-journalist-threats-survey-2026.pdf

Der Streit um die Chatkontrolle in der EU

Seit mehreren Jahren wird das Thema Chatkontrolle innerhalb der EU diskutiert. Wir berichteten im Oktober 2025, dass die umstrittene verpflichtende Chatkontrolle verworfen wurde.  Davon nicht betroffen ist jedoch die 2021 eingeführte und 2024 verlängerte freiwillige Chatkontrolle. Diese ermöglicht das verdachtsunabhängige Durchsuchen von Medien und insbesondere Chats durch Anbieter wie Microsoft und Google. Diese freiwillige Kontrolle gilt trotz Kritik zur Verhältnismäßigkeit aufgrund einer Ausnahme, die nun wieder verlängert werden soll.

https://www.heise.de/news/Freiwillige-Chatkontrolle-EU-Parlament-plant-naechste-Frist-Verlaengerung-11169062.html

Weitere News im Oktober

Meldepflicht in der Schweiz für IT-Sicherheitsvorfälle

Sechs Monate nach Einführung der Meldepflicht für IT-Sicherheitsvorfälle bei kritischen Infrastrukturen in der Schweiz zieht das BACS (Bundesamt für Cybersicherheit) Bilanz. Insbesondere hebt es die gut funktionierende Zusammenarbeit und die größere Teilnahme am Informationsaustausch hervor. In Deutschland regelt bereits seit längerer Zeit das BSI-Gesetz in § 8b Absatz 4 eine ähnliche Meldepflicht. Die Einführung von NIS-2, und damit die deutliche Erweiterung der meldepflichtigen Stellen, bringt hoffentlich ähnlich positive Resultate.

https://www.news.admin.ch/de/newnsb/gezctyF6KYR7UkCjXBC5s

https://www.bsi.bund.de/DE/Themen/Regulierte-Wirtschaft/Kritische-Infrastrukturen/KRITIS-FAQ/FAQ-zur-Meldepflicht/faq-zur-meldepflicht_node.html

Datenreichtum bei Sonicwall

Einige unserer IR-Fälle der letzten Wochen standen im Zusammenhang mit dem Incident bei Sonicwall, bei dem Cloud- Back-ups durch Dritte einsehbar waren. Diese enthalten für Angreifende spannende Daten, um einen initialen Angriffsvektor in einer Umgebung zu finden. Es gab durchaus bereits einige solcher Lücken bei Firewall-Herstellern –Was diesen Vorfall aber so spannend macht, ist die weitere Entwicklung nach der Veröffentlichung: Während am 17. September noch von Auswirkungen für weniger als fünf Prozent der Anwender die Rede war, stellte sich nach umfassender Analyse heraus, dass Alle betroffen waren. Wichtige Erkenntnis: Schwachstellenmanagement hört nicht nach der initialen Meldung auf.

https://www.sonicwall.com/support/knowledge-base/mysonicwall-cloud-backup-file-incident/250915160910330

Wenn Kriminelle Exploits veröffentlichen

Dass eine Sicherheitslücke genutzt wird, um Ransomware zu verteilen, ist leider keine Seltenheit, in diesem Fall CVE-2025-61882 bei Oracle. Wenn aber die Existenz und das Ausmaß klar werden, weil eine andere kriminelle Organisation den genutzten Einfallsvektor veröffentlicht, dann lohnt sich ein Blick hinter die Kulissen.

https://www.bleepingcomputer.com/news/security/oracle-zero-day-exploited-in-clop-data-theft-attacks-since-early-august

https://www.bleepingcomputer.com/news/security/oracle-patches-ebs-zero-day-exploited-in-clop-data-theft-attacks/#:~:text=Exploit%C2%A0leaked%20by%C2%A0Scattered%20Lapsus%24%20Hunters

SaaS-Integrationen als Schwachstelle: Discord und Zendesk

Ein aktueller Sicherheitsvorfall bei Discord, ausgelöst durch eine Kompromittierung der Zendesk-Integration, demonstriert die Risiken privilegierter API-Zugriffe. Zendesk, als Customer-Support-Plattform, operiert mit OAuth-Tokens, die oft weitreichende Rechte auf Kundendaten gewähren. Das erfolgreiche Abgreifen eines solchen Tokens oder eine unzureichend abgesicherte API-Routine können ausreichen, um Zugriff auf sensible Dokumente wie Regierungs-IDs zu erlangen. Auch wenn ein Cross-Tenant-Angriff über gemeinsam genutzte Cloud-Ressourcen (z. B. AWS) weniger wahrscheinlich ist, bleibt er technisch denkbar.

https://firecompass.com/discord-zendesk-support-system-data-breach

https://discord.com/press-releases/update-on-security-incident-involving-third-party-customer-servicelinks

CRM-Systeme als Single Point of Failure: Qantas und Allianz Life

CRM-Plattformen wie Salesforce sind zentrale Datensilos – und damit hochattraktive Ziele. Im Fall Qantas nutzte die Gruppe „Scattered Spider“ Social Engineering gegen Administratoren, kombiniert mit SIM-Swapping zur Umgehung einer Multi-Faktor-Athentisierung. Nach Erlangung von Admin-Zugängen konnten über legitime Funktionen wie den Salesforce Data Loader große Datenmengen extrahiert werden – unauffällig und effizient.

Ein anderer Vorfall bei Allianz-Life zeigt, wie schwache Datenbanksegmentierung zu massiven Datenverlusten führen können. Moderne CRM-Systeme nutzen oft „Data Lakes“ mit schwacher Access Control, die über ETL-Pipelines zusätzliche Angriffsflächen bieten.

https://www.obsidiansecurity.com/blog/shinyhunters-and-scattered-spider-a-merger-of-chaos-in-the-2025-salesforce-attacks

https://www.9news.com.au/national/qantas-data-breach-salesforce/cc149e0a-3ba5-4235-8c22-1c855e2ade01

https://databreach.com/news/21-28m-allianz-life-customer-records-stolen-in-salesforce-hack

https://eu.usatoday.com/story/tech/2025/07/28/us-customers-data-stolen-cyberattack-allianz-life/85406949007

https://www.cbsnews.com/news/allianz-life-insurance-data-breach

Fintech-Exposition: Bonify und die Identitätsdaten

Bonify, als Schufa-Tochter, verarbeitet hochsensible Identitätsdokumente. Diese werden typischerweise in Object-Storage-Systemen wie S3 oder Azure Blob gespeichert. Fehlkonfigurierte Bucket-Permissions oder kompromittierte IAM-Rollen können dann einen direkten Zugriff ermöglichen. Das Angebot des Unternehmens für Betroffene, für sechs Monate kostenlos den Identitätsschutz des Unternehmens zu nutzen, deutet auf eine längerfristige Exposition hin – möglicherweise durch undetektierte APTs.

https://www.heise.de/news/Datenschutzvorfall-Identitaetsdaten-bei-Schufa-Tochter-Bonify-abgeflossen-10689766.html

https://www.computerbild.de/artikel/News-Internet-Etliche-Kundendaten-von-Schufa-Tochter-Bonify-gestohlen-40400105.html