Am 10. April 2026 nahm die finnische Polizei einen 19-Jährigen fest, als er versuchte, einen Flug nach Japan zu besteigen. Er hatte zwei Festplatten mit einer Speicherkapazität von jeweils zwei Terabyte bei sich. Laut einer im Northern District of Illinois veröffentlichten, die ursprüngliche Anzeige ersetzenden Strafanzeige handelt es sich bei dem Reisenden um Peter Stokes, einen Doppelstaatsbürger der USA und Estlands, und die Festplatten waren noch das geringste Problem. Das FBI wirft ihm vor, Mitglied von Scattered Spider, einer Gruppe, die Microsoft unter dem Namen „Octo Tempest“ verfolgt, und dass er bei der Durchführung von Hackerangriffen mitgewirkt habe, die die Regierung mit mehr als 100 Netzwerkkompromittierungen und Lösegeldzahlungen in Höhe von über 100 Millionen Dollar in Verbindung bringt .
Ich habe die Klage vollständig gelesen. Sie umfasst 35 Seiten und ist die klarste Schilderung aus erster Hand eines Angriffs Scattered Spider , die ich bisher in der Öffentlichkeit gesehen habe. Das meiste, was wir über diese Gruppe wissen, stammt aus Blogs von Anbietern und nachträglich verfassten Zusammenfassungen von Vorfällen. Dies ist anders. Es handelt sich um eine eidesstattliche Erklärung vor einem Bundesgericht, die den Angriff Schritt für Schritt nachzeichnet, die verwendeten Tools nennt und auf die Protokolle verweist.
Bevor ich fortfahre, möchte ich zwei Vorbehalte anmerken. Eine Anzeige ist eine Anschuldigung, keine Verurteilung, und die Regierung hat nichts davon vor Gericht bewiesen. Außerdem sind die Opfer anonymisiert, daher werde ich keine Vermutungen darüber anstellen, wer „Unternehmen F“ ist. Was hier zählt, ist die Vorgehensweise, und diese ist dokumentiert.
Der Angriff, in der Reihenfolge, in der er sich ereignete
Im Mittelpunkt steht ein Hackerangriff auf das Unternehmen F im Mai 2025, das in der eidesstattlichen Erklärung als Luxus-Einzelhändler mit einem Umsatz in Milliardenhöhe beschrieben wird. Hier ist die Kette der Ereignisse, die direkt aus den vom FBI angeführten Netzwerkprotokollen entnommen wurde.
Es begann mit Telefonanrufen. Am oder um den 12. Mai 2025 riefen Angreifer den IT-Helpdesk des Unternehmens F von zwei Google-Voice-Nummern aus an, gaben sich als Mitarbeiter aus und baten darum , ihre Zugangsdaten zurückzusetzen, darunter das Passwort und das für die Multi-Faktor-Authentifizierung verwendete Mobilgerät. Innerhalb von etwa zwei bis drei Stunden hatten sie drei Benutzerkonten kompromittiert. Kein Exploit. Keine malware. Ein Telefonanruf und ein Reset.
Zwei dieser drei Konten gehörten IT-Administratoren. Die Angreifer nutzten die Standardkonten, die sie gerade gestohlen hatten, um an die Zugangsdaten der Administratoren mit hohen Berechtigungen zu gelangen, und gelangten damit zu den Plattformen, über die die virtuellen Server und cloud von Unternehmen F gesteuert werden.
Von da an brauchten sie Ausdauer und einen Ausweg. Sie installierten „ngrok“ auf einem Server der Firma F – ein legitimes Entwicklertool, das einen sicheren Tunnel vom Inneren eines privaten Netzwerks ins Internet eröffnet und so eine saubere Möglichkeit bietet, die Perimeter-Abwehr zu umgehen, ohne diese auszulösen. Anschließend nutzten sie „Teleport.sh“, ein weiteres legitimes Fernzugriffsprogramm, zusammen mit Amazon S3-Speicher, um die Daten herauszuschleusen. Innerhalb von drei Tagen exfiltrierten sie mindestens 77 Gigabyte.
Sie versuchten, die Aktion mit ransomware abzuschließen. Das Sicherheitsteam von Unternehmen F konnte diesen Teil jedoch verhindern und vertrieb die Angreifer schließlich. Doch zu diesem Zeitpunkt waren die Daten bereits verloren. Am 15. Mai schickten die Angreifer eine Lösegeldforderung von einem von ihnen kompromittierten E-Mail-Konto mit dem Betreff „WICHTIG: WIR HABEN DIE DATEN GESTOHLEN, BITTE SOFORT KONTAKT AUFNEHMEN [sic]“. Verhandlungen über einen Dritten führten zu einer Forderung: „8 Millionen Dollar scheinen ein guter Preis zu sein.“ Unternehmen F zahlte nicht. Die gemeldeten Verluste durch Betriebsunterbrechungen und Schadensbegrenzung beliefen sich auf rund 2 Millionen Dollar.
Die Anzeige ordnet die Gruppe zudem in die ransomware Wirtschaft ein. Auf einem mit Stokes in Verbindung stehenden Server fanden die Ermittler Chats in einem Fenster mit der Bezeichnung „DragonForce“ – einer RaaS-Marke –, darunter einen Partner, der sich darüber beschwerte, dass ihm 500 Dollar für einen neuen Login in Rechnung gestellt wurden, „nachdem wir euch über 1 Million eingebracht haben“. DragonForce ist keine feste Gruppe, sondern besteht aus Code und Infrastruktur, die Partner mieten – aufgebaut auf derselben Conti- und Black Basta , die ich in „Von Conti über Black Basta DevMan: Die endlose Ransomware “ nachgezeichnet habe.
Das Logo auf der Lösegeldforderung ändert sich. Das Verhalten bleibt jedoch dasselbe.
Warum die Prävention nichts zu melden hatte
Gehen Sie diese Kette noch einmal zurück und achten Sie darauf, was nie passiert ist. Kein fehlgeschlagener Anmeldeversuch. Keine malware . Kein Exploit gegen einen nicht gepatchten Dienst. Jede Tür, die sich geöffnet hat, wurde mit einem gültigen Schlüssel geöffnet.
Der Angreifer meldet sich als Mitarbeiter an, und der Helpdesk setzt die Anmeldedaten zurück, sodass sich bei der nächsten Anmeldung ein echter Benutzer mit einem echten Passwort und einem echten MFA-Gerät anmeldet. Die Authentifizierung gelingt. Die Berechtigungserweiterung nutzt den legitimen Pfad des Kontos zu einem temporären Passwort, sodass das Identitätssystem eine autorisierte Berechtigungserweiterung protokolliert. Der Tunnel nach außen läuft über ngrok und Teleport – Tools, die ein Entwickler an jedem beliebigen Dienstag nutzen könnte. Die Daten landen in Amazon S3, einem endpoint , mit dem endpoint von Unternehmen den ganzen Tag über kommunizieren. Dies ist Lücke 2: Die Authentifizierung gelingt und geht nahtlos in Lücke 3 über – die Aktivität ist nicht sichtbar. Das Audit-Protokoll hat sie durchgewunken, und die Exfiltration versteckte sich in Datenverkehr, der ganz normal aussah.
Das ist der Punkt, über den sich Sicherheitsverantwortliche Gedanken machen sollten. Das Team von Unternehmen F hat nicht geschlafen. Es hat die ransomware erkannt und die Angreifer vertrieben. Präventionsmaßnahmen und endpoint haben in der Phase, für die sie ausgelegt sind, ihre Aufgabe erfüllt. Der Schaden entstand bereits früher, in dem Zeitfenster zwischen einem erfolgreichen Reset durch den Helpdesk und dem Moment, als der Upload von 77 Gigabyte abgeschlossen war. Dieses Zeitfenster hängt vom Verhalten ab. Sowohl eine gestohlene als auch eine echte Identität werden authentifiziert. Das Einzige, was sie voneinander unterscheidet, ist das, was sie als Nächstes tun: ein Administratorkonto, das auf Systeme zugreift, mit denen es sonst nie in Berührung kommt, ein erstmals aufgesetzter ngrok-Tunnel von einem Produktionsserver, ein plötzlicher S3-Upload im Umfang von mehreren zehn Gigabyte. Nichts davon ist eine Signatur. All das sind Muster.
Das „Hardening Playbook“ von 2024 ist nach wie vor gültig, deckt diesen Zugriffsweg jedoch nicht mehr ab. Phishing MFA ist wichtig. Doch durch eine Zurücksetzung durch den Helpdesk erhält der Angreifer eine neue, legitime MFA-Registrierung, sodass die Sicherheitsmaßnahme, die ein gestohlenes Passwort eigentlich hätte blockieren sollen, auf Anfrage an die falsche Person neu vergeben wird. Ich habe bereits zuvor darüber geschrieben, warum MFA-Zurücksetzungen und SMS-Codes die Schwachstelle eines ansonsten gut gesicherten Identitätsstacks darstellen.
Die Schwachstelle ist nicht das MFA. Die Schwachstelle ist der Reset und alles, was der Angreifer tut, sobald der Reset erfolgreich war.
Die Tools waren alle legitim
In dieser Geschichte kommt kein maßgeschneidertes Implantat vor. Ngrok, Teleport.sh und Amazon S3 sind Tools, die für Entwickler entwickelt wurden – und genau deshalb eignen sie sich auch für Angreifer. Nichts, was gescannt werden müsste, nichts, was auf einer Sperrliste steht, nichts, was nach malware schreit.
Beobachten Sie das Verhalten, nicht die Marke.
Die Frage ist nicht, ob ngrok bösartig ist, denn das ist es nicht. Die Frage ist vielmehr, ob Sie eine Tunnelverbindung, die von einem Server, der dies zuvor noch nie getan hat, aus dem Inneren Ihres Rechenzentrums ins öffentliche Internet führt, rechtzeitig bemerken und hinterfragen würden.
Wie ein Teenager erwischt wurde
Die andere Hälfte der Beschwerde betrifft die Ermittlungen, und diese ist schon für sich genommen lesenswert, da die vom FBI angewandte Methode genau der entspricht, die Verteidiger benötigen.
Stokes hat laut der eidesstattlichen Erklärung kein Geheimnis aus dem Geld gemacht. Snapchat- und Facebook-Bilder zeigen ihn im Alter von 17 bis 18 Jahren in Paris, New York, Bangkok und Dubai, wo er in Luxushotels wohnte, Geldbündel und Uhren in den Händen hielt und eine Diamantkette mit der Aufschrift „HACK THE PLANET“ trug . An seinem Geburtstag verschickte er eine Nachricht über eine Datenbank, die er gerade abgegriffen hatte und die Daten zu Überweisungen an Krypto-Börsen enthielt; das Datum dieser Nachricht stimmte mit seinem Geburtsdatum in den Unterlagen des Außenministeriums überein. Er fotografierte eine estnische Polizeistation mit einer Bildunterschrift, in der er sich mit einer Figur verglich, die sich dem FBI stellt.
Das sind die Fehler im Bereich der operativen Sicherheit, die den Verteidigern ihre Vorsprünge verschaffen – dasselbe Muster, das ich bei OPSEC-Versagen festgestellt habe : Wie Fehler von Angreifern den Verteidigern helfen.
Der interessante Teil ist jedoch die technische Zuordnung. Das Konto, über das der bei dem Angriff auf Unternehmen F verwendete ngrok eingerichtet wurde, war mit einer Microsoft Global Device ID verknüpft, einer dauerhaften Kennung für eine Windows-Installation. Das FBI verglich die IP-Aktivitäten dieses Geräts im Zeitverlauf mit den IP-Adressen, die für die Anmeldung bei Konten verwendet wurden, die sie bereits mit Stokes in Verbindung gebracht hatten: Snapchat, Apple, Facebook.
Dieselben Adressen in Tallinn, in New York, in Thailand, an denselben Tagen, manchmal im Abstand von nur wenigen Stunden. Für die Angriffsinfrastruktur nutzte er einen VPN-Proxy. Das spielte jedoch keine Rolle, da die Korrelation über sein gesamtes digitales Leben hinweg hergestellt wurde und nicht anhand einer einzelnen Verbindung.
Das Detail, das am meisten ins Gewicht fällt: Am 8. Januar 2025 hat sich dieses Gerät über ein Ubisoft-Konto von einer IP-Adresse in Tallinn aus beim Online-Spiel „Growtopia“ angemeldet, und am Tag zuvor hatte dieselbe IP-Adresse im Abstand von zwei Minuten auf eines seiner Apple-Konten und auf dieses Ubisoft-Konto zugegriffen.
Eine IP-Adresse ist nur Rauschen. Ein VPN verbirgt eine Verbindung. Was nach der Logik des Ermittlers als Beweis dient, ist das Muster vieler Signale, die über verschiedene Ebenen und Zeiträume hinweg miteinander korrelieren. Das ist dieselbe Logik , mit der innerhalb eines Netzwerks eine gestohlene Identität von einer echten unterschieden wird.
Das FBI ging bei Stokes genau so vor, wie es eine gute Ermittlungsstrategie bei einem Eindringling vorsieht: Es hörte auf, nach einem einzigen eindeutigen Beweis zu suchen, und begann stattdessen, Verhaltensweisen miteinander in Zusammenhang zu bringen.
Das ist keine ferne Bedrohung
Eines macht die Anklageschrift noch deutlich: Scattered Spider kein weit entferntes staatliches Programm. Stokes ist 19 Jahre alt. Der in der Anklageschrift neben ihm genannte Mitverschwörer war zum Zeitpunkt der Tat ein in den USA lebender Minderjähriger, gegen den vor Ort Anklage erhoben wurde. Ein weiteres Mitglied, auf das sich die Anklageschrift bezieht, Noah Urban, bekannt als „Sosa“ und „King Bob“, wurde wegen eines SIM-Swapping-Betrugs zu 120 Monaten Haft verurteilt.
Es handelt sich um junge, englische Muttersprachler, die sehr gut am Telefon sind und sich in den Systemen, die sie angreifen, bestens auskennen. Genau das macht den Helpdesk-Angriffsweg so effektiv. Die Person, die Ihren Service Desk anruft, klingt genau wie der Mitarbeiter, als der sie sich ausgibt.
Und Stokes ist nicht der Letzte von ihnen. Im April 2026 bekannte sich Tyler „Tylerb“ Buchanan im Zusammenhang mit derphishing der Gruppe aus dem Jahr 2022 schuldig. Im Juni 2026 bekannten sich Thalha Jubair und Owen Flowers in London am ersten Tag ihres Prozesses schuldig, wegen des Angriffs vom August 2024, der den Nahverkehr in London lahmgelegt hatte. Jubair, der laut Staatsanwaltschaft einen auf SIM-Swapping spezialisierten Kanal namens „Star Chat“ mitbetrieben haben soll, über den Zugangsdaten von Mitarbeitern von Mobilfunkbetreibern abgefangen wurden, ist in New Jersey separat wegen 120 Einbrüchen bei 47 US-Unternehmen und Lösegeldzahlungen in Höhe von mindestens 115 Millionen Dollar angeklagt. Gleiche Marke, viele Akteure, eine Methode: den Menschen überreden, dann den gültigen Zugang nutzen.
Ich habe in dem Artikel Scattered Lapsus$ Hunters “ darüber geschrieben, in welchem größeren Ökosystem sich diese Akteure bewegen – „The Com“ – und warum es jede einzelne Festnahme überdauert: Hunters Scattered Lapsus$ Hunters , sich zurückzuziehen, doch die Bedrohung bleibt bestehen.
Was ist zu überprüfen?
Wenn Sie ein Sicherheitsprogramm betreiben, bietet die Stokes-Beschwerde eine kostenlose Simulationsübung. Hier sind einige Fragen, die Sie in Bezug auf Ihre eigene Umgebung stellen sollten:
- Wenn heute jemand Ihren Helpdesk durch Social Engineering dazu gebracht hätte, das Passwort und die MFA eines Mitarbeiters zurückzusetzen, was würde Sie alarmieren, da die nächste Anmeldung problemlos verläuft?
- Verfügen Sie über eine Verhaltensbasislinie pro Identität, sodass es als ungewöhnlich auffällt, wenn ein Standardbenutzer privilegierte Anmeldedaten abruft und anschließend auf neue Systeme zugreift?
- Würde ein erstmals eingerichteter ngrok- oder Teleport-Tunnel von einem Produktionsserver oder eine umfangreiche ausgehende Übertragung an S3 bereits vor Abschluss des Uploads als Grund für eine Überprüfung auffallen?
Dies ist dasselbe Muster nach der Authentifizierung, das ich in den ShinyHunters-Kampagnen in „ShinyHunters ist keine Gruppe. Es ist ein Muster“ nachverfolgt habe: anderer Akteur, anderer Einstiegspunkt, dieselbe Abfolge aus Zugriff, Persistenz, Erkundung und Datenexfiltration, sobald die Anmeldung funktioniert. Die Klage von Stokes ist ein weiterer Beleg für dieselbe These, diesmal unter Eid niedergeschrieben.
Bei Vectra AI konzentrieren wir uns auf folgende Aufgaben: das Verhalten nach einer erfolgreichen Anmeldung – über Identitätsmanagement, SaaS und cloud hinweg –, wo Signaturen und Präventionsmaßnahmen nichts mehr aufspüren können.
Wenn Sie einen umfassenden Überblick über Scattered Spider erhalten und erfahren möchten, wo die ersten Verhaltenssignale auftreten, finden Sie dies in Kapitel 2 von „Mind Your Attack Gaps“, unter Lücke 2: Authentifizierung gelingt.