Le 10 avril 2026, la police finlandaise a arrêté un jeune homme de 19 ans alors qu’il tentait de monter à bord d’un vol à destination du Japon. Il transportait deux disques durs d’une capacité de deux téraoctets chacun. Selon une plainte pénale modificative rendue publique par le district nord de l’Illinois, ce voyageur s’appelle Peter Stokes, un double national américain et estonien, et ces disques durs n’étaient que la partie émergée de l’iceberg. Le FBI l’accuse d’être membre de Scattered Spider, le groupe que Microsoft désigne sous le nom d’Octo Tempest, et qu’il a contribué à mener des intrusions que le gouvernement associe à plus de 100 compromissions de réseaux et à plus de 100 millions de dollars de rançons versées.
J'ai lu la plainte dans son intégralité. Elle compte 35 pages et constitue le récit de première main le plus clair que j'aie vu rendre public concernant une attaque Scattered Spider le Scattered Spider . La plupart des informations dont nous disposons sur ce groupe proviennent de blogs de fournisseurs et de résumés d'incidents rédigés a posteriori. Ce document est différent. Il s'agit d'une déclaration sous serment fédérale qui retrace l'attaque étape par étape, nomme les outils utilisés et cite les journaux d'activité.
Deux précisions avant d'aller plus loin. Une plainte est une allégation, pas une condamnation, et le gouvernement n'a rien prouvé de tout cela devant les tribunaux. De plus, l'identité des victimes a été anonymisée ; je ne me risquerai donc pas à deviner qui est la « société F ». Ce qui importe ici, ce sont les techniques d'espionnage, et celles-ci sont documentées.
L'attaque, dans l'ordre où elle s'est déroulée
Au cœur de l'affaire se trouve une intrusion survenue en mai 2025 chez la société F, décrite dans la déclaration sous serment comme un détaillant de produits de luxe dont le chiffre d'affaires s'élève à plusieurs milliards de dollars. Voici la chaîne d'événements, tirée directement des journaux réseau cités par le FBI.
Tout a commencé par des appels téléphoniques. Vers le 12 mai 2025, cybercriminels le service d'assistance informatique de la société F depuis deux numéros Google Voice, se faisant passer pour des employés, et ont demandé à réinitialiser leurs identifiants, notamment leur mot de passe et le numéro de téléphone mobile utilisé pour l'authentification multifactorielle. En l'espace de deux à trois heures environ, ils avaient compromis trois comptes d'utilisateurs. Pas d'exploitation de vulnérabilité. Pas malware. Un simple appel téléphonique et une réinitialisation.
Deux de ces trois comptes appartenaient à des administrateurs informatiques. Les pirates ont utilisé les comptes standard qu’ils venaient de voler pour récupérer les identifiants à privilèges élevés des administrateurs, ce qui leur a permis d’accéder aux plateformes contrôlant les serveurs virtuels et cloud de la société F.
À partir de là, il leur fallait de la persévérance et un moyen de s’en sortir. Ils ont installé ngrok sur un serveur de la société F, un outil de développement légitime qui ouvre un tunnel sécurisé depuis l’intérieur d’un réseau privé vers Internet, un moyen propre de contourner les défenses périmétriques sans les déclencher. Ils ont ensuite utilisé Teleport.sh, un autre utilitaire d’accès à distance légitime, associé au stockage Amazon S3, pour extraire les données. En trois jours, ils ont exfiltré au moins 77 gigaoctets.
Ils ont tenté de conclure en lançant un rançongiciel. L'équipe de sécurité de la société F a mis fin à cette tentative et a fini par les expulser. Mais à ce moment-là, les données avaient déjà disparu. Le 15 mai, les attaquants ont envoyé une demande de rançon depuis une boîte mail qu’ils avaient compromise, avec pour objet « IMPORTANT : NOUS AVONS VOLÉ LES DONNÉES, CONTACTEZ-NOUS IMMÉDIATEMENT [sic] ». Les négociations menées par l’intermédiaire d’un tiers ont abouti à une exigence : « 8 millions de dollars, ça nous semble être un bon prix. » La société F n’a pas payé. Les pertes déclarées liées à la perturbation et aux mesures d’atténuation se sont élevées à environ 2 millions de dollars.
La plainte situe également le groupe au cœur de l’économie du « ransomware-as-a-service » (RaaS). Sur un serveur lié à Stokes, les enquêteurs ont découvert des discussions dans une fenêtre intitulée « DragonForce », une marque de RaaS, dans lesquelles un affilié se plaignait de devoir payer 500 dollars pour un nouvel identifiant « alors qu’on vous a rapporté plus d’un million ». DragonForce n’est pas un groupe fixe ; il s’agit d’un code et d’une infrastructure que les affiliés louent, s’inscrivant dans la même Black Basta Conti et Black Basta , que j’ai retracée dans l’article « De Conti à Black Basta DevMan : le changement de nom sans fin des ransomwares ».
La marque figurant sur la demande de rançon change. Le comportement, lui, reste le même.
Pourquoi la prévention n'avait rien à signaler
Revenons en arrière dans cette chaîne d'événements et observons ce qui ne s'est jamais produit. Aucune tentative de connexion infructueuse. Aucune malware . Aucune exploitation d'une faille dans un service non mis à jour. Chaque porte qui s'est ouverte l'a été avec une clé valide.
L’attaquant appelle en se faisant passer pour l’employé et le service d’assistance réinitialise les identifiants ; ainsi, la connexion suivante est effectuée par un véritable utilisateur avec un véritable mot de passe et un véritable dispositif d’authentification multifactorielle (MFA). L’authentification aboutit. L’escalade de privilèges utilise le parcours légitime propre au compte pour obtenir un mot de passe temporaire, de sorte que le système d’identité enregistre une élévation autorisée. Le tunnel de sortie passe par ngrok et Teleport, des outils qu’un développeur pourrait utiliser n’importe quel mardi. Les données atterrissent sur Amazon S3, un endpoint auquel endpoint d’entreprises se connectent toute la journée. Il s’agit de la faille n° 2 : l’authentification réussit, ce qui mène directement à la faille n° 3, où le mouvement n’est pas visible. Le journal d’audit les a laissés passer, et l’exfiltration s’est dissimulée au sein d’un trafic d’apparence ordinaire.
C’est sur ce point que je souhaite que les responsables de la sécurité s’attardent. L’équipe de l’entreprise F n’était pas inerte. Elle a détecté la phase de rançongiciel et a repoussé les attaquants. La prévention et endpoint ont rempli leur rôle à l’étape pour laquelle ils avaient été conçus. La perte s’est produite plus tôt, dans l’intervalle entre une réinitialisation réussie effectuée par le service d’assistance et le moment où le téléchargement de 77 gigaoctets s’est achevé. Cet intervalle relève du comportement. Une identité volée et une identité authentique permettent toutes deux de s’authentifier. La seule chose qui les distingue, c’est ce qu’elles font ensuite : un compte administrateur accédant à des systèmes qu’il n’utilise jamais, un tout premier tunnel ngrok depuis un serveur de production, un téléchargement soudain vers S3 de plusieurs dizaines de gigaoctets . Rien de tout cela ne constitue une signature. Tout cela relève d’un schéma.
Le guide de renforcement de la sécurité de 2024 reste d'actualité, mais il ne couvre plus ce vecteur d'accès. L'authentification multifactorielle (MFA) Phishing est essentielle. Cependant, une réinitialisation effectuée par le service d'assistance fournit à l'attaquant une nouvelle inscription MFA légitime ; ainsi, le contrôle qui aurait dû bloquer l'utilisation d'un mot de passe volé est réattribué à la mauvaise personne sur simple demande. J'ai déjà expliqué pourquoi les réinitialisations MFA et les codes SMS constituent le talon d'Achille d'une infrastructure d'identité par ailleurs bien sécurisée.
La faille ne réside pas dans le MFA. La faille réside dans la réinitialisation, ainsi quedans toutes les actions menées par l'attaquant une fois que la réinitialisation a abouti.
Ces outils étaient tous légitimes
Il n'y a pas d'implant personnalisé dans cette histoire. Ngrok, Teleport.sh et Amazon S3 sont des outils conçus pour les ingénieurs, et c'est précisément pour cette raison qu'ils conviennent aux pirates. Rien à analyser, rien sur une liste noire, rien qui laisse penser à malware.
Suivez le comportement, pas la marque.
La question n'est pas de savoir si ngrok est malveillant, car ce n'est pas le cas. La question est de savoir si vous seriez en mesure de détecter à temps et de réagir face à l'ouverture d'un tunnel reliant l'intérieur de votre centre de données à l'Internet public, à partir d'un serveur qui n'avait jamais effectué cette opération auparavant.
Comment un adolescent s'est fait prendre
L'autre volet de la plainte concerne l'enquête, et il mérite d'être lu en soi, car la méthode utilisée par le FBI correspond à celle dont les défenseurs ont besoin.
Selon la déclaration sous serment, Stokes ne s’est pas caché de ses richesses. Des photos publiées sur Snapchat et Facebook le montraient à Paris, New York, Bangkok et Dubaï entre 17 et 18 ans, séjournant dans des hôtels de luxe, brandissant des liasses de billets et des montres, et portant une chaîne en diamants sur laquelle on pouvait lire « HACK THE PLANET ». Le jour de son anniversaire, il a envoyé un message concernant une base de données qu’il venait d’extraire et qui contenait des données de virements bancaires à destination de plateformes de cryptomonnaies ; la date de ce message correspondait à sa date de naissance telle qu’elle figure dans les registres du Département d’État. Il a photographié un commissariat estonien avec une légende dans laquelle il se comparait à un personnage qui se rend au FBI.
Ce sont là les erreurs de sécurité opérationnelle qui fournissent des pistes aux défenseurs; c'est le même schéma que j'ai mis en évidence dans les défaillances en matière d'OPSEC : comment les erreurs des acteurs malveillants aident les défenseurs.
Mais c'est l'attribution technique qui est la partie la plus intéressante. Le compte qui a configuré le ngrok utilisé lors de l'attaque contre la société F était lié à un « Microsoft Global Device ID », un identifiant permanent associé à une installation Windows. Le FBI a recoupé l'activité IP de cet appareil, au fil du temps, avec les adresses IP utilisées pour se connecter à des comptes qu'il avait déjà associés à Stokes : Snapchat, Apple, Facebook.
Les mêmes adresses à Tallinn, à New York, en Thaïlande, aux mêmes dates, parfois à quelques heures d'intervalle. Il a utilisé un proxy VPN pour l'infrastructure d'attaque. Cela n'avait aucune importance, car la corrélation a été établie à partir de l'ensemble de sa vie numérique, et non à partir d'une seule connexion.
Le détail le plus frappant : le 8 janvier 2025, cet appareil s'est connecté au jeu en ligne Growtopia via un compte Ubisoft depuis une adresse IP située à Tallinn, et la veille, cette même adresse IP avait accédé à l'un de ses comptes Apple puis à ce compte Ubisoft à deux minutes d'intervalle.
Une adresse IP, ce n'est qu'un bruit de fond. Un VPN masque une connexion. Ce qui permet de confondre un coupable, selon la logique de l'enquêteur, c'est la combinaison de nombreux signaux corrélés entre différents plans et à travers le temps. C'est cette même logique qui permet de distinguer une identité volée d'une identité réelle au sein d'un réseau.
Le FBI a appliqué à Stokes exactement ce qu'une bonne stratégie d'enquête fait face à un intrus : il a cessé de chercher une seule preuve irréfutable et a commencé à établir des liens entre les différents éléments de son comportement.
Il ne s'agit pas d'une menace lointaine
La plainte met également en évidence un autre point : Scattered Spider » Scattered Spider pas un programme d’État lointain. Stokes a 19 ans. Le complice cité à ses côtés dans la plainte était, au moment des faits, un mineur résidant aux États-Unis, qui a été inculpé au niveau local. Un autre membre mentionné dans la plainte, Noah Urban, connu sous les noms de « Sosa » et « King Bob », a été condamné à 120 mois de prison pour une escroquerie par usurpation de carte SIM.
Il s'agit de jeunes locuteurs natifs de l'anglais, très à l'aise au téléphone et qui maîtrisent parfaitement les systèmes qu'ils ciblent. C'est ce qui rend cette méthode d'attaque par le service d'assistance si efficace. La personne qui appelle votre service d'assistance a exactement la même voix que l'employé qu'elle prétend être.
Et Stokes n’est pas le dernier de la liste. En avril 2026, Tyler « Tylerb » Buchanan a plaidé coupable dans le cadre dephishing menée par le groupe en 2022. En juin 2026, Thalha Jubair et Owen Flowers ont plaidé coupable à Londres dès le premier jour de leur procès, pour l’attaque d’août 2024 qui avait paralysé Transport for London. Jubair, qui, selon les procureurs, codirigeait une plateforme de « SIM swapping » à la demande appelée Star Chat, qui hameçonnait les identifiants des employés d’opérateurs mobiles, est également poursuivi dans le New Jersey pour plus de 120 intrusions au sein de 47 entreprises américaines et au moins 115 millions de dollars de rançons versées. Même marque, de nombreux opérateurs, une seule méthode : contourner l’intervention humaine, puis utiliser un accès valide.
J'ai déjà évoqué l'écosystème plus large dans lequel évoluent ces acteurs, « The Com », et expliqué pourquoi il survit à toute arrestation individuelle, dans l'article « Scattered Lapsus$ Hunters » : Hunters qu'ils vont se faire discrets, mais la menace demeure.
Ce qu'il faut vérifier
Si vous gérez un programme de sécurité, la plainte Stokes constitue un exercice de simulation gratuit. Voici quelques questions qu'il serait utile de se poser au regard de votre propre environnement :
- Si quelqu'un parvenait aujourd'hui, par le biais d'une attaque d'ingénierie sociale, à convaincre votre service d'assistance de réinitialiser le mot de passe et l'authentification multifactorielle (MFA) d'un employé, qu'est-ce qui vous alerterait, sachant que la connexion suivante s'effectue sans problème ?
- Disposez-vous d'un profil comportemental de référence pour chaque identité, de sorte qu'un utilisateur standard qui obtient des identifiants privilégiés puis accède à de nouveaux systèmes soit considéré comme un cas inhabituel ?
- La création d'un tunnel ngrok ou Teleport pour la première fois à partir d'un serveur de production, ou un transfert sortant volumineux vers S3, serait-elle signalée comme un élément nécessitant une vérification avant la fin du téléchargement ?
Il s'agit là du même schéma post-authentification que j'ai observé dans les campagnes de ShinyHunters, comme je l'ai expliqué dans l'article « ShinyHunters n'est pas un groupe. C'est un schéma » : un acteur différent, un point d'entrée différent, mais la même séquence d'accès, de persistance, d'exploration et d'exfiltration une fois la connexion établie. La plainte de Stokes constitue un élément supplémentaire venant étayer cette même thèse, cette fois-ci consignée sous serment.
Chez Vectra AI, c'est sur ce type de travail que nous nous concentrons : le comportement qui suit une connexion réussie, qu'il s'agisse de gestion des identités, de solutions SaaS ou cloud, là où les signatures et les mesures préventives ne peuvent plus rien détecter.
Si vous souhaitez connaître en détail le déroulement d'une Scattered Spider » et savoir à quel moment les premiers signes comportementaux apparaissent, consultez le chapitre 2 de *Mind Your Attack Gaps*, consacré à la faille n° 2 : « l'authentification réussit ».