Le 4 avril 2026, Anodot a signalé des pannes généralisées affectant ses connecteurs Snowflake, Amazon S3 et Amazon Kinesis. Dès le 7 avril, BleepingComputer rapportait que des jetons d'authentification volés à Anodot étaient utilisés pour accéder aux données de plus d'une douzaine d'environnements clients d'Anodot. Le 11 avril, ShinyHunters avait mentionné Rockstar Games sur son site de fuites, avec une date limite fixée au 14 avril. La date limite a expiré. Une partie des données a fuité.
Il s'agissait de la deuxième campagne majeure de vol de données liée à Snowflake en deux ans, et le point d'entrée n'était ni un utilisateur compromis ni des identifiants divulgués. Un fournisseur d'intégrations SaaS a été piraté, des jetons d'authentification ont été dérobés, puis utilisés pour accéder aux données de plusieurs environnements clients.
Vu de l'extérieur, tout semble fonctionner normalement. Les systèmes concernés ont réagi comme prévu. L'accès a été accordé par des moyens valides, et les activités se sont déroulées par des voies légitimes. C'est pourquoi ce type d'incident ne cesse de se reproduire sans déclencher la réaction qu'il devrait.
Il ne s'agit pas de Snowflake
Si l'on revient sur l'incident de 2024 que Mandiant a répertorié sous le nom d'UNC5537, le schéma est déjà bien connu. Les pirates ont utilisé des identifiants volés, récupérés à partir des journaux d'un logiciel de vol de données, pour accéder à des instances Snowflake et s'emparer directement des données. Aucun des comptes ciblés n'avait activé l'authentification à deux facteurs (MFA). 79,7 % des identifiants utilisés avaient déjà été exposés par un logiciel de vol de données.
Ce qui a changé en 2026, ce n'est pas le résultat, mais le chemin parcouru.
Lors de l'incident précédent, les pirates ont utilisé des identifiants pour s'introduire dans le système et des jetons pour y rester. Dans le cas d'Anodot, ils ont commencé par les jetons.
L'accès direct a été remplacé par un accès indirect via des intégrations. L'attaquant n'a plus besoin d'interagir avec l'environnement d'une manière qui génère des signaux évidents. La plateforme devient le dernier maillon de la chaîne, et non plus le point de départ du problème.
Cela correspond à ce que nous avons déjà observé lors des récents incidents touchant la chaîne d'approvisionnement, où la compromission initiale importe bien moins que la manière dont cet accès est exploité par la suite.
Considérer cela comme un problème propre à Snowflake, c'est passer à côté de l'évolution sous-jacente. Le même schéma se retrouve dans les secteurs du SaaS, cloud et des plateformes de données. Le dénominateur commun n'est pas le fournisseur, mais la manière dont les accès sont accordés et réutilisés d'un système à l'autre.
La chaîne d'approvisionnement est désormais opérationnelle
Autrefois, les intégrations étaient considérées comme de la « plomberie ». Elles permettent de transférer des données, d'automatiser les flux de travail et de relier des systèmes qui, sans cela, resteraient isolés.
Dans la pratique, elles font désormais office de couches d'accès distribuées.
Une seule intégration peut contenir des jetons à longue durée de vie, fonctionner dans plusieurs environnements et exécuter des actions au nom d'utilisateurs ou de services. Lorsque cette intégration est compromise, l'attaquant n'a pas besoin de s'implanter. Il hérite d'un point d'ancrage qui existe déjà et qui bénéficie d'une confiance établie.
Nous avons observé un schéma similaire dans les cas de compromission de la chaîne logistique, où une opération menée au sein d'un environnement de confiance se traduit immédiatement par un accès exploitable, qui est ensuite réutilisé sur l'ensemble des systèmes.
Cet accès couvre souvent :
- plateformes de données
- systèmes de stockage
- Applications SaaS
La circulation au sein de ces systèmes ne nécessite pas de nouvelles techniques. Elle emprunte les mêmes voies que celles utilisées quotidiennement par l'entreprise.
À ce stade, l'attaquant n'a plus besoin de se déplacer latéralement. C'est l'architecture qui s'en charge à sa place.
Les jetons ont discrètement éliminé le dernier obstacle
Le passage des identifiants aux jetons est subtil, mais il modifie le fonctionnement de l'accès.
Les jetons sont conçus pour assurer la persistance et l'automatisation. Ils sont émis une seule fois et réutilisés sans nécessiter d'authentification répétée. Ils fonctionnent via des API, souvent sans intervention de l'utilisateur, et ont généralement une durée de vie supérieure à celle des rotations de mots de passe ou des réinitialisations de session.
Dans de nombreux environnements, ils font également l'objet d'un suivi insuffisant. Les événements de connexion sont surveillés de près. L'utilisation des jetons est souvent considérée comme une activité secondaire.
Lors des intrusions liées à Snowflake en 2024, l'un des pirates a décrit la situation en des termes qu'il est difficile d'ignorer :
Je peux toujours exécuter des commandes, car j'ai le « masterToken » pour chaque compte 🤣
Ellyel8
Ce qui importe, ce n'est pas la citation en soi, mais la manière dont cet accès a été maintenu. En consultant la documentation accessible au public, le pirate a compris le fonctionnement des jetons et s'en est servi pour rester actif même après la sécurisation des comptes.
Le fait d'avoir neutralisé l'attaquant n'a pas mis fin à l'accès.
Cela conduit à une situation où l'accès peut se poursuivre même après la mise en œuvre de mesures correctives. Le compte utilisateur peut être sécurisé, tandis que le jeton associé à une intégration reste actif et continue d'offrir le même niveau d'accès.
Du point de vue d'un pirate, il s'agit d'une méthode de persistance plus propre et plus fiable que tout ce qui implique l'utilisation de malware.
Ce compte (celui à l'origine de la citation « Je peux toujours exécuter des commandes » mentionnée plus haut) était géré par Connor Riley Moucka, qui a été arrêté au Canada en novembre 2024. Son procès est prévu pour le 19 octobre 2026. L'accès dont il se vantait a perduré malgré son arrestation, car les jetons ne dépendent pas de l'opérateur qui les a créés.
Pourquoi cette activité s'intègre parfaitement
Du point de vue de la détection, cela n'a pratiquement rien à voir avec une intrusion classique.
Ce que montre l'environnement correspond à un fonctionnement normal :
- les événements d'authentification sont valides
- Les appels API suivent les schémas attendus
- les intégrations fonctionnent conformément à leur champ d'application prévu
Ce qui manque, c'est le contexte qui relie ces actions d'un système à l'autre.
Un accès aux données qui semble normal pris isolément peut devenir suspect lorsqu'il est mis en parallèle avec l'activité sur une autre plateforme. Un jeton utilisé par une intégration peut paraître inoffensif jusqu'à ce qu'il commence à accéder aux données d'une manière qui ne correspond pas au comportement observé par le passé.
La plupart des outils ne sont pas conçus pour établir cette vue d'ensemble entre les différents systèmes. Ils fonctionnent au sein d’un seul domaine, ce qui signifie qu’ils valident des actions individuelles mais s’interrogent rarement sur la manière dont ces actions s’articulent les unes avec les autres.
C'est dans cette faille que ce type d'attaque s'introduit.
Une tendance récurrente, et non un incident isolé
Cette activité a été associée au groupe de cybercriminels ShinyHunters, qui tire profit de données volées à grande échelle grâce à plusieurs équipes fonctionnant de manière indépendante. L'identité des opérateurs importe moins que la cohérence de la technique employée.
Le rapport de Resecurity de janvier 2026 décrit « ShinyHunters » comme un pseudonyme utilisé de manière collaborative — le rapport précise que « ce nom change très fréquemment et de manière intentionnelle, généralement par les acteurs eux-mêmes, qui souhaitent brouiller les pistes quant à leur identification ». GTIG suit l'activité actuelle à travers au moins trois groupes distincts : UNC6240 gère les extorsions sous cette marque ; UNC6661 et UNC6671 ont mené en janvier 2026 des campagnes parallèles de vishing contre des fournisseurs d'identité, avec des bureaux d'enregistrement distincts (NICENIC et Tucows) et des tonals d'extorsion distincts suggérant des opérateurs distincts. L'activité Anodot/Snowflake est à nouveau distincte sur le plan opérationnel. Même marque. Équipes différentes.
Ce qui les caractérise tous, c'est ce qui définit le mode opératoire : l'authentification des cibles, et non l'infrastructure. Tout opérateur ayant accès à des jetons provenant d'une plateforme d'intégration largement utilisée peut reproduire le même résultat. À mesure que de plus en plus d'organisations s'appuient sur des services SaaS interconnectés, le nombre de voies d'accès indirectes ne cesse d'augmenter.
Nous avons également constaté que ce type de réutilisation des accès peut évoluer vers un système plus automatisé et auto-propagateur, dans lequel des relations de confiance compromises sont utilisées pour étendre la portée sans interaction directe.
Parallèlement, les pirates informatiques se tournent vers des méthodes qui demandent moins d'efforts et génèrent moins de traces. Compromettre un fournisseur tiers ou collecter des jetons à grande échelle offre un rendement plus élevé que de tenter de s'introduire dans des environnements individuels. C'est pourquoi les incidents liés à la chaîne d'approvisionnement se multiplient. Ils offrent une portée, une cohérence et un niveau de discrétion qui correspondent à la manière dont les environnements modernes sont conçus.
L'attaque n'est pas dissimulée. Elle est fragmentée.
Les équipes de sécurité ne sont pas aveugles à cette activité. Elles en constatent des manifestations chaque jour :
- Une plateforme d'identité enregistre une authentification réussie.
- Une application SaaS enregistre les utilisations valides de l'API.
- Une plateforme de données affiche les requêtes et les exportations prévues.
Chaque système valide ce qu'il observe. Aucun d'entre eux ne fait le lien entre ces actions.
C'est là que ce modèle commence à montrer ses limites.
L'attaquant n'a pas besoin d'échapper à la détection à chaque étape du contrôle. Il suffit que chaque contrôle valide sa propre partie de l'activité. Les jetons facilitent cette tâche. Les intégrations permettent d'étendre ce processus à l'ensemble des systèmes. Lorsque le schéma se met en place, il s'étend à des domaines qui sont rarement analysés conjointement.
C'est pourquoi on a l'impression que ce genre d'incidents est maîtrisé alors que des données continuent de sortir de l'environnement.
Que faire à ce sujet ?
Les mesures de protection classiques contre la campagne « Snowflake » de 2024 (application de l'authentification multifactorielle sur cloud , rotation des identifiants volés, mise sur liste blanche du data warehouse au niveau du réseau) restent valables, mais ne couvrent plus cette voie d'accès. Les jetons de service émis par les fournisseurs ne comportent pas de facteurs d'authentification multifactorielle. Les clients ne peuvent pas les renouveler ; seul le fournisseur en a la possibilité. Le guide de renforcement de la sécurité 2024 protège contre le mode opératoire de 2024. Le mode opératoire de 2026 nécessite une couche de protection différente.
Cette couche définit les comportements de base de chaque entité – utilisateur, entité de service, client OAuth – au fil du temps, et se déclenche lorsque ce schéma évolue simultanément sur plusieurs axes.
Trois questions à vous poser concernant votre propre environnement :
- Pour chaque intégration SaaS tierce impliquant un accès en lecture authentifié inter-locataires, connaissez-vous la fréquence normale des appels API et le profil de consommation des ressources, définis par entité ?
- À quand remonte la dernière vérification de chaque jeton de fournisseur ?
- Quand chacun d'entre eux a-t-il été remplacé pour la dernière fois – par le fournisseur ?
L'ebook « Mind Your Attack Gaps » Vectra AI aborde la faille « Authentication succeeds » exploitée par cette campagne. Si vous souhaitez une présentation concise, en un seul entretien, de la manière dont le mode opératoire de la chaîne d'approvisionnement s'applique à votre infrastructure spécifique, n'hésitez pas à nous contacter.