Die Figure-Datenpanne illustriert ein grundlegendes Missverständnis in der Cybersicherheitsbranche. Wenn Medien und Sicherheitsteams von Breaches berichten, endet die Analyse häufig bei der Anzahl der betroffenen Datensätze. Das ist der falsche Ansatzpunkt. Die 967.200 geleakten E-Mail-Adressen sind nicht das Ereignis selbst – sie sind das Startinventar für die Angriffskettendie danach folgt.
Unmittelbar nach einer solchen Datenpanne starten Angreifer parallel mehrere Workflows. Der erste ist Credential Stuffing: Mit automatisierten Tools kombinieren sie die geleakten E-Mail-Adressen mit Passwörtern aus früheren Breaches (LinkedIn, Dropbox, RockYou2024) und testen sie gegen Unternehmensportale, VPN-Gateways, Microsoft 365 und Okta-Instanzen im großen Stil. Bei einer typischen Erfolgsquote von 2-3 Prozent entstehen daraus Zehntausende gültiger Zugangsdaten.
Der zweite Workflow nutzt KI-generiertes, gezieltes Phishing. Moderne Tools erstellen in Minuten personalisierte Phishing-Kampagnen basierend auf geleakten Listen – mit Organisationsnamen, imitierten internen Kommunikationen und einer visuellen Authentizität, die Laien nicht erkennen. Hinzu kommt Recipient-Targeting mit öffentlich verfügbaren Informationen wie Jobtitel oder LinkedIn-Profilen.
Der dritte Ansatz ist Social Engineering gegen Help Desks. Mit einer gültigen E-Mail-Adresse und grundlegenden Recherchen geben sich Angreifer als Mitarbeiter aus und fordern Passwort-Resets oder MFA-Device-Resets an – ein Angriff, der die Authentifizierungstechnologie völlig umgeht.
Hier zeigt sich das zentrale Problem: Moderne Angreifertools nutzen Real-Time-Phishing-Relays, auch Adversary-in-the-Middle (AiTM) genannt. Ein Angreifer baut einen Reverse Proxy zwischen Opfer und legitimem Service auf. Wenn das Opfer Credentials auf der gefälschten Seite eingibt, leitet der Proxy diese in Echtzeit an den echten Service weiter. Dessen MFA-Challenge wird an das Opfer zurückgespielt, dessen Antwort wieder an den echten Service – und der Angreifer erhält eine authentifizierte Sitzung.
Push-Benachrichtigungen, SMS-Einmalcodes und TOTP-Authenticator-Apps sind alle anfällig für solche Relays, weil sie einen Code authentifizieren, nicht den Menschen dahinter. Öffentlich verfügbare Toolkits wie Evilginx oder Modlishka automatisieren diese Angriffe vollständig.
Die Sicherheitsindustrie antwortet auf solche Authentifizierungsausfälle typischerweise mit Benutzerschulung: Phishing erkennen, verdächtige MFA-Prompts hinterfragen, unerwartete Genehmigungsanfragen ablehnen. Das ist nicht falsch – nur unzureichend. Der Grund ist strukturell: Ein Relay-Angriff braucht kein erkanntes Phishing. Der MFA-Prompt ist echt, stammt vom echten Service und kommt durch die App, die der Nutzer täglich verwendet. Es gibt nichts Anomales zu entdecken.
Das tiefere Problem liegt in der Authentifizierungsarchitektur selbst. Sie beantwortet nicht die entscheidende Frage in einer Post-Breach-Welt: War die autorisierte Person biometrisch verifiziert und physisch anwesend zum Zeitpunkt der Authentifizierung? Push-Benachrichtigungen, SMS-Codes und TOTP beantworten diese Frage nicht. Sie verifizieren Geräte, nicht Menschen.
Regulieren, Auditer und Cyber-Versicherer fordern zunehmend diese Unterscheidung explizit ein. CMMC-Assessments und NYDFS-Prüfungen stellen inzwischen die Frage: “Können Sie nachweisen, dass die autorisierte Person anwesend war?” Gerätenanwesenheit reicht nicht mehr als Proxy für menschliche Präsenz.
