Le 11 avril 2026, un message publié sur un site de fuites sous le pseudonyme ShinyHunters a revendiqué la divulgation d'environ 80 millions d'enregistrements provenant de Rockstar Games. La source de l'accès n'était pas Rockstar. Il s'agissait Anodot, un fournisseur d’analyses SaaS faisant partie de la chaîne d’approvisionnement de Rockstar. Des jetons d’authentification Anodot volés ont été utilisés pour interroger les plateformes de données en aval. Une autre victime.
Un autre fournisseur. Même schéma.
Ce qui importe, ce n'est pas la plateforme sur laquelle l'impact s'est finalement produit. Ce qui compte, c'est la manière dont l'accès a été obtenu et détourné.
Tous les quelques mois, un nouveau titre fait la une
Les gros titres le répètent :
- 2024 : clients de Snowflake, via des identifiants récupérés à partir des journaux d'un logiciel de vol d'informations remontant jusqu'à 2020.
- Août 2025 : des clients de Salesforce , via des jetons OAuth volés à Salesloft Drift. Google a estimé que plus de 700 organisations en aval auraient pu être exposées à la suite de cette attaque ciblant un seul fournisseur.
- Novembre 2025 : nouvelle faille chez Salesforce , via des jetons OAuth Gainsight, touchant plus de 200 instances.
- Avril 2026 : Snowflake à nouveau, via les jetons Anodot.
- Juin 2026 : à nouveau des clients de Salesforce , via le backend d’intégration de Klue. Des identifiants de compte de service périmés et jamais renouvelés ont été utilisés pour s’authentifier sur les systèmes de Klue ; une mise à jour de code malveillante a ensuite permis de récupérer des jetons OAuth reliant Klue aux instances Salesforce, Gong, HubSpot et Slack des clients. Des scripts automatisés ont interrogé l’API REST de Salesforce à un rythme d’environ 1 000 appels toutes les 15 minutes pendant 24 heures d’affilée. Salesforce a désactivé l’intégration Klue Battlecards le 11 juin 2026. Icarus a mené cette intrusion ; ShinyHunters en a revendiqué la responsabilité lors de la phase d’extorsion. Microsoft suit cette activité sous le nom de Storm-3138.
Différents points d'accès. Différentes plateformes.
Le schéma reste le même, car ShinyHunters n'est pas un groupe à proprement parler. Il s'agit d'une marque utilisée au moment de l'extorsion.
La violation de Klue en juin 2026 en est une illustration parfaite. C’est Icarus qui a mené cette intrusion. ShinyHunters a revendiqué la responsabilité de l’attaque au stade du chantage. Un opérateur différent, mais la même marque. Le journal d’audit de Salesforce a enregistré tout au long de l’incident des appels API légitimes provenant d’applications connectées. Rien dans l’environnement du client n’indiquait qu’une compromission était en cours.
Si vous considérez cela comme un seul et même acteur malveillant, vous risquez de chercher au mauvais endroit. Concentrez-vous sur le comportement, pas sur la marque.
Le véritable fil conducteur
Quatre méthodes d'accès différentes reviennent régulièrement dans les campagnes attribuées à ShinyHunters :
- Identifiants volés utilisés pour se connecter
- Manipulation psychologique via le service d'assistance (vishing) visant à réinitialiser l'authentification multifactorielle (MFA) et à obtenir un accès
- Abus d'OAuth/de jetons via des fournisseurs de SaaS compromis
- Accès invité mal configuré aux points de terminaison SaaS (exploitation du framework Salesforce Aura via des requêtes GraphQL non authentifiées, documentée en juin 2026)
Des compétences différentes, mais un résultat identique : un accès valide qui se comporte comme un utilisateur ou une application légitime.
Les rapports publics mettent en avant Snowflake ou Salesforce, car c'est là que les données sont finalement acheminées. Mais c'est l'identité qui constitue la voie d'accès.
Dans la plupart des environnements d'entreprise, cette identité est fédérée vers des plateformes telles que Microsoft 365. C'est pourquoi M365 est l'un des premiers endroits où cette activité devient visible. Non pas parce qu'il s'agit de la cible, mais parce que c'est là que l'identité compromise est utilisée.
Analyse d'une attaque de type ShinyHunters
Quelle que soit la méthode d'intrusion, l'attaque suit un schéma similaire :
- Accès : connectez-vous à l'aide d'identifiants ou de jetons valides.
- Établir : rendre cet accès permanent.
- Développer : explorer les données dans toutes les applications SaaS.
- Exfiltrer : extraire des données des systèmes en aval.
Snowflake et les plateformes similaires constituent la dernière étape. Tout ce qui est essentiel pour la détection précoce se passe avant cela.
Ce que l'on peut réellement voir avant les étapes d'Impact
Accès initial : une connexion « normale » qui n'a rien de normal
La connexion s'effectue correctement. Mais :
- C'est un nouvel emplacement
- La connexion provient d'une infrastructure VPN ou proxy telle que Mullvad, Oxylabs, NetNut ou un nœud de sortie Tor.
- Les actions effectuées après la connexion ne correspondent pas au comportement habituel de l'utilisateur.
Au sein d'un fournisseur d'identité tel qu'Entra ID, cela semble être une connexion légitime et réussie. Mais lorsqu'on examine la situation dans son contexte, ce n'est pas le cas.
Persévérance : faire en sorte que l'accès soit durable
Une fois à l'intérieur, l'acteur s'assure de pouvoir en ressortir :
- Nouvelles méthodes MFA intégrées
- Nouveaux appareils enregistrés
- Applications OAuth autorisées à accéder
Prise isolément, chaque action est légitime. Mais prises ensemble, dans les minutes qui suivent une nouvelle connexion, elles révèlent une toute autre réalité.
Exploration : évoluer dans le domaine du SaaS
Avant d'accéder aux entrepôts de données, les pirates s'introduisent dans les systèmes que les employés utilisent au quotidien. Pour de nombreuses entreprises, cela concerne Microsoft 365 ou des plateformes SaaS similaires :
- Énumération des éléments SharePoint et OneDrive
- Accès aux bibliothèques de documents auxquelles l'utilisateur n'a jamais accédé
- Recherches par mots-clés de contenus sensibles
- Accès étendu aux fichiers
À ce stade, le pirate se pose une question simple : à quoi cette identité piratée donne-t-elle accès ?
Ils s'étendent ensuite à d'autres plateformes SaaS et aux systèmes de données en aval.
Des méthodes différentes, les mêmes signaux
Cette tendance se confirme pour les quatre approches :
- Identifiants volés (2024) : connexion inhabituelle mais réussie
- Hameçonnage vocal et contournement de l'authentification multifactorielle (2025-2026): connexion suivie d'une activité rapide visant à s'implanter durablement et d'une recherche de services SaaS.
- Compromission d'un fournisseur/d'OAuth (2025-2026) : comportement anormal de l'accès à une application de confiance.
- Configuration incorrecte de l'accès invité (2026) : appels API en grand nombre à partir d'un contexte d'invité non authentifié. Aucun événement de connexion ne justifie une alerte.
Le point d'entrée change. Le comportement après l'authentification reste le même.
Étude de cas : la violation de données chez Klue, juin 2026
La violation de Klue est l’exemple le plus parlant, parmi les plus récents , du parcours de la chaîne d’approvisionnement. Le pirate (identifié sous le nom d’Icarus, puis revendiqué par ShinyHunters dans le cadre d’une tentative d’extorsion) a utilisé des identifiants de compte de service périmés, qui n’avaient jamais été renouvelés, pour s’authentifier auprès du backend d’intégration de Klue. Aucune faille n’a été exploitée. Les identifiants étaient valides et avaient été émis par l’organisation. Aucune anomalie n’a été détectée lors de la connexion.
Une mise à jour de code malveillante a ensuite permis de récupérer des jetons OAuth reliant Klue aux instances Salesforce, Gong, HubSpot et Slack des clients. Ces jetons ont été transférés via des canaux chiffrés. Cela ressemblait à un déploiement de code de routine. Aucune malware n’a été détectée. À partir de là, des scripts Python automatisés ont interrogé l’API REST de Salesforce à un rythme d’environ 1 000 appels toutes les 15 minutes pendant 24 heures d’affilée. Chaque appel API était authentifié à l’aide d’un jeton valide, impossible à distinguer du trafic d’intégration normal. Les données CRM ont été exfiltrées à grande échelle.
Salesforce a désactivé l'intégration de Klue Battlecards le 11 juin. Recorded Future, Tanium, Jamf et Huntress figuraient parmi les organisations informées. Microsoft a répertorié ce groupe sous le nom de « Storm-3138 » dans son communiqué du 13 juillet 2026.
Concernant la question de l’attribution : l’analyse ci-dessus attribue à juste titre cette opération à Icarus en tant qu’opérateur. Le fait que ShinyHunters en revendique la paternité lors de l’extorsion ne constitue pas une correction de cette attribution. C’est justement là le point essentiel. La marque est attribuée au moment de l’extorsion, quelle que soit la personne qui mène l’opération. Laissez l’attribution à l’opérateur Icarus sur la diapositive et ajoutez une note indiquant que ShinyHunters s’est attribué le mérite lors de l’extorsion, car c’est précisément sur cette distinction que repose l’argument « suivre le comportement, pas la marque ».
Vectra AI
Les campagnes ShinyHunters réussissent parce qu’elles utilisent des moyens d’accès légitimes : de véritables identifiants, de véritables processus d’authentification multifactorielle, de véritables jetons OAuth, de véritables applications. La plupart des contrôles de sécurité sont conçus pour bloquer les attaquants avant l’authentification. Ces campagnes réussissent après.
Vectra AI les comportements malveillants après une authentification réussie, qu'il s'agisse de l'identité, des services SaaS, cloud ou du réseau. La question n'est pas «comment l'accès a-t-il été obtenu ? », mais : les actions de l'utilisateur correspondent-elles à son profil comportemental ?
Comment la détection correspond au schéma d'attaque
Accès : connexion réussie depuis un nouvel emplacement, via une infrastructure proxy, qui ne correspond pas au profil de référence de l'identité.
Configuration : ajout des méthodes d'authentification multifactorielle (MFA), enregistrement des appareils et autorisation des applications OAuth, immédiatement après la connexion.
Développer : mettre en corrélation les activités sur Microsoft 365, Salesforce et d'autres solutions SaaS, afin de mettre en évidence les comptes qui explorent de nouvelles pistes comme jamais auparavant.
Exfiltration : les téléchargements en masse et l'extraction via l'API sont apparus comme l'aboutissement d'une séquence, et non comme des événements isolés.
Pourquoi cela fonctionne-t-il avec toutes les méthodes ?
Peu importe la manière dont l'accès a été obtenu : identifiants volés, appel au service d'assistance ou jeton de fournisseur compromis. L'attaquant doit tout de même se connecter, s'implanter durablement, explorer le système et exfiltrer des données. Ce schéma comportemental est inévitable. C'est précisément ce que Vectra est conçu pour détecter.
Combler les lacunes en matière de détection
Les conseils classiques restent d'actualité : authentification multifactorielle (MFA) phishing, rotation des identifiants, vérification des périmètres OAuth, vérification d'identité par le service d'assistance (voir les recommandations de renforcement de sécurité UNC6040 du GTIG et l'avis FLASH du FBI). Mais cela ne suffit plus à lui seul. Les campagnes modernes sont conçues pour contourner ces contrôles.
La détection ne fonctionne pas mal. Elle est simplement incomplète.
ShinyHunters n'est pas un groupe à proprement parler. Il s'agit d'un modèle d'attaques articulé autour d'une idée centrale : si l'authentification aboutit, le pirate peut se faire passer pour une identité inoffensive.
Les premiers signaux n'apparaissent pas dans la plateforme de données mentionnée dans les gros titres. Ils apparaissent dans les plateformes d'identité et les plateformes SaaS, où l'attaquant doit d'abord agir. Le problème n'est pas le manque de visibilité. Il s'agit plutôt de commencer la détection au mauvais moment de l'attaque.
Dans mon ebook « Mind Your Attack Gaps », je décris trois failles de détection. ShinyHunters exploite la faille n° 2 : l'authentification aboutit. Des identifiants valides, de vrais codes à usage unique, de véritables jetons OAuth, de véritables cookies de session. Le journal d'audit enregistre une connexion réussie.
Le guide de renforcement de la sécurité pour 2024 reste valable, mais il ne traite plus de la voie d'accès.