Des agents IA à bas coût transforment des intrusions chez des détaillants en filière de vol de cartes bancaires

Des dizaines d’entreprises compromises lors d’une campagne menée à grande échelle

Un acteur malveillant sinophone motivé par l’appât du gain utilise des outils d’IA autonomes pour repérer des failles, mener des attaques et conserver un accès aux sites de vente en ligne et à d’autres organisations.

La campagne a débuté en juillet 2026 et a touché depuis au moins plusieurs dizaines d’entreprises, selon le compte rendu de l’enquête de Gambit. Du 10 au 15 septembre, l’acteur a lancé 105 projets d’attaque. Au moins 27 entreprises ont été compromises à des degrés divers.

Les intrusions réussies ont généralement pris moins d’une journée. Dans certains cas, l’acteur a obtenu un accès en quelques heures.

L’opération a déjà eu des conséquences financières et opérationnelles importantes. Gambit attribue à des brèches chez deux entreprises le vol de plus de 600 000 numéros de cartes bancaires encore valides. Plus de 488 000 de ces cartes étaient américaines.

L’attaquant a également déployé des scripts de vol de données bancaires sur des boutiques en ligne et obtenu un certain niveau d’accès à une entreprise du secteur hôtelier figurant au classement Fortune 500. Parmi les autres victimes identifiées figuraient une compagnie aérienne américaine, un distributeur de fournitures industrielles et un détaillant de mode en ligne.

Le système ne fonctionnait pas entièrement sans intervention humaine. L’opérateur fournissait de brèves consignes, choisissait ses cibles et réorientait les agents après l’obtention d’un accès. Toutefois, une grande partie de la reconnaissance, de l’exploitation des failles et de la planification des attaques était confiée à trois outils open source : Strix, Cairn et Hermes.

Strix et Cairn ont automatisé la reconnaissance et l’exploitation des failles

La première étape reposait sur Strix, un outil open source de test d’intrusion utilisé pour rechercher des vulnérabilités. Du 23 au 31 août, l’acteur a exécuté Strix à 146 reprises en « mode approfondi » sur 138 hôtes.

L’attaquant a accédé à l’outil via OpenRouter, en utilisant les modèles GLM 5.2 et DeepSeek v4 Pro. Les rapports générés par Strix ont ensuite été transmis à Cairn, un moteur autonome de test d’intrusion.

Configuré avec DeepSeek v4.1 Flash, Cairn a lancé les 105 projets d’attaque observés du 10 au 15 septembre. Gambit a récupéré 48 rapports de Cairn ; les autres avaient été supprimés.

Au lieu d’appliquer une séquence d’exploitation fixe à toutes les cibles, Cairn choisissait ses méthodes d’attaque au fil des sondages et des tentatives d’exploitation. Les tactiques, techniques et procédures variaient donc pour la plupart des victimes.

Les informations disponibles ne précisent pas quelles vulnérabilités ont été exploitées, ni leur niveau de gravité ou leurs identifiants CVE. Les versions exactes des logiciels concernés n’ont pas non plus été communiquées. Les défenseurs ne peuvent donc rattacher cette campagne à aucune vulnérabilité particulière du catalogue des vulnérabilités exploitées connues de la Cybersecurity and Infrastructure Security Agency des États-Unis, et aucun délai fédéral de remédiation associé n’est connu.

L’absence de CVE divulgués signifie également que les organisations ne peuvent pas contrer cette campagne en installant un correctif précis. La détection doit porter sur les modifications non autorisées, les identifiants dérobés, les compromissions d’applications et les mécanismes de persistance observés chez chaque victime.

Hermes a fourni à l’opérateur une infrastructure d’attaque persistante

Pour orchestrer les attaques et mener des opérations interactives, l’acteur malveillant a utilisé Hermes, un agent autonome open source doté d’une mémoire persistante, d’un historique de sessions consultable, d’une console web, de tâches planifiées et de la capacité de créer ses propres compétences.

L’attaquant a configuré Hermes avec une persona système en chinois et 121 compétences, dont 78 conçues pour des activités offensives. L’agent fonctionnait avec le modèle opus-4.6 d’Anthropic.

Gambit a recensé 1 951 prompts saisis par un opérateur humain au cours de 260 sessions. Il s’agissait généralement de brèves consignes en chinois demandant à Hermes de lancer une attaque, de choisir une prochaine étape générale ou d’effectuer une action après l’obtention d’un accès.

Cette répartition des tâches est importante. L’opérateur n’avait pas à préciser chaque commande ni à définir à l’avance un parcours d’intrusion complet. L’humain fixait des objectifs, tandis que l’agent conservait le contexte, faisait appel à des compétences spécialisées et contribuait aux différentes étapes de l’attaque.

Daniel Wilcock, analyste du renseignement sur les menaces chez Talion Cyber Security, a distingué cette activité des démonstrations encadrées de tests d’intrusion par IA. Dans ce cas, les agents étaient délibérément dirigés contre des organisations, chargés de poursuivre leurs recherches de failles et utilisés pour effacer des traces.

L’opération était également peu coûteuse, car ses principaux outils étaient open source. D’après les éléments récupérés, Gambit estime le coût moyen à 25,46 $ pour 101 analyses menées à terme.

Le vol de cartes bancaires a visé les bases de données et les pages de paiement

Les attaques ont cherché à dérober des données de paiement par plusieurs moyens.

Chez deux entreprises victimes, l’acteur malveillant a volé au moins 600 000 numéros de cartes encore valides. Les enquêteurs ont découvert une compétence Hermes conçue pour extraire les données de cartes volées de la base de données Magento d’une victime. Les versions exactes de Magento et la méthode d’accès initiale ne sont pas connues.

La manipulation des bases de données a aussi fait peser un risque de dégâts irréversibles. Lors d’un incident distinct visant un détaillant de vélos, l’agent avait reçu pour consigne d’effacer les tables de préproduction qu’il avait créées. Il a supprimé à la place les tables de sauvegarde du détaillant.

D’autres victimes ont été infectées par des scripts de skimming qui capturaient les informations sur les pages de paiement. Gambit a d’abord confirmé que 19 organisations étaient touchées. En collaboration avec le chercheur en sécurité Varys, les enquêteurs ont ensuite identifié plus de 100 autres sites infectés.

Le plus souvent, l’attaquant insérait le code du skimmer dans un fichier JavaScript existant, mais les méthodes de déploiement variaient considérablement. Le code malveillant était également injecté par les moyens suivants :

• Balises de script ajoutées aux sites web.
• Bloc Google tag d’un site.
• Contenu hébergé dans un compartiment AWS S3.
• Champs de contenu de base de données.
• initContainer Kubernetes.
• Modèle de page mis en cache de la page de paiement.

Cette diversité rend insuffisante une simple analyse des fichiers. Le code JavaScript de la page de paiement peut sembler propre alors que du contenu malveillant est injecté depuis une base de données, un objet hébergé dans le cloud, un conteneur initialisé au démarrage ou une configuration de gestion des balises.

La persistance a survécu au redéploiement de l’application

Une intrusion chez un détaillant de vin américain montre comment l’acteur s’est adapté après que des mesures de récupération courantes ont supprimé le skimmer.

Le redéploiement de l’application du détaillant a rétabli un code de paiement propre et supprimé temporairement la modification malveillante. L’opérateur a réagi en créant une tâche cron dans le répertoire de journaux de JBoss.

La tâche vérifiait la taille du fichier concerné toutes les deux minutes. Si le déploiement rétablissait le fichier légitime, elle réinsérait le skimmer.

Ce mécanisme peut donner l’impression que l’infection réapparaît spontanément après une remédiation. Il montre aussi pourquoi le remplacement des fichiers front-end modifiés ne suffit pas toujours à supprimer le point d’ancrage sous-jacent.

L’utilisation d’un répertoire de journaux pour un mécanisme de persistance planifié peut également compliquer l’enquête si les défenseurs se concentrent uniquement sur les répertoires contenant le code de l’application. Les tâches planifiées, les chemins de services accessibles en écriture et les fichiers inhabituels dans les répertoires JBoss doivent faire l’objet d’un examen distinct.

La préservation des preuves est particulièrement importante. L’acteur a supprimé certains rapports d’attaque, tandis que ses outils ont aussi effacé des données appartenant aux victimes ou détruit par erreur des sauvegardes. Reconstruire les systèmes avant d’avoir collecté les journaux et les données volatiles peut faire disparaître des éléments nécessaires pour reconstituer l’intrusion.

Les détaillants dotés de code sur mesure ont été privilégiés

L’acteur a sélectionné ses cibles à l’aide d’un service de classement du trafic web, en privilégiant les détaillants dont les sites reposaient sur du code personnalisé. L’opérateur a saisi 301 résultats dans la console d’attaque.

Au moins deux cibles ont été choisies manuellement, car l’attaquant possédait déjà leurs mots de passe administrateur. On ignore comment il les a obtenus.

Les applications de vente au détail personnalisées présentent une surface d’attaque vaste et hétérogène. Dans cette campagne, les outils automatisés pouvaient sonder chaque environnement et adapter leur approche au lieu de dépendre d’une vulnérabilité unique commune à toutes les victimes.

Cette souplesse explique en partie pourquoi des organisations autres que des détaillants en ligne traditionnels figurent parmi les victimes. L’opération a touché des entreprises des secteurs de l’hôtellerie, de l’aviation, de la distribution industrielle et de la mode, même si le niveau d’accès précis obtenu dans chaque organisation n’a pas été communiqué.

Les défenseurs doivent examiner toutes les dépendances des pages de paiement

Aucun correctif fournisseur, contournement validé ou procédure de remédiation confirmée n’a été publié pour cette campagne. Les organisations qui exploitent des pages de paiement doivent donc enquêter à la fois sur la compromission initiale et sur les différents emplacements utilisés pour réinstaller les scripts de skimming.

Les mesures à prendre en priorité sont les suivantes :

1. Examiner le JavaScript des pages de paiement et les balises de script à la recherche d’ajouts non autorisés, y compris dans des fichiers par ailleurs légitimes.
2. Auditer les configurations Google tag et repérer les ajouts ou modifications récents.
3. Inspecter les ressources hébergées dans S3 et chargées par les pages de paiement, notamment l’historique des objets et les journaux d’accès lorsqu’ils sont disponibles.
4. Rechercher dans les champs de contenu des bases de données et les modèles de page mis en cache les scripts injectés ou les références inconnues.
5. Examiner les initContainers Kubernetes à la recherche de commandes, d’images, de montages ou de modifications de fichiers non autorisés.
6. Vérifier les tâches planifiées et les répertoires de journaux JBoss, en particulier les tâches qui surveillent la taille des fichiers ou réécrivent régulièrement les ressources de l’application.
7. Enquêter dans les bases de données Magento sur les accès aux données de cartes bancaires, les requêtes suspectes, la mise en attente de données, les suppressions et les sauvegardes modifiées.
8. Préserver les éléments de preuve numériques avant de reconstruire les systèmes touchés, notamment les journaux des agents, les données d’authentification et d’activité des bases de données, les journaux d’audit du cloud et l’historique des déploiements.
9. Changer les identifiants administrateur exposés et déterminer si des mots de passe existants ont servi à sélectionner certaines cibles ou à y accéder.

Les organisations qui découvrent un skimmer doivent y voir le signe d’une compromission plus vaste du serveur, et non d’un simple fichier web altéré. Les mécanismes de persistance observés montrent que le rétablissement d’une page de paiement propre peut supprimer la charge malveillante visible tout en laissant intact le mécanisme permettant à l’attaquant de réinfecter le site.