Mis à jour : Gambit indique avoir prévenu de nombreuses organisations touchées et contribué, avec la fondation Shadowserver, à mettre hors service l’infrastructure de l’attaquant ; Gambit ne relie pas la campagne à un groupe ou à un pays précis, selon The Next Web, 28 septembre 2026.
Un attaquant a confié l’essentiel d’une campagne de vol de cartes bancaires à trois agents d’IA open source : repérage, exploitation, puis pose de skimmers sur des pages de paiement. Cette analyse s’adresse aux auditeurs, RSSI et responsables sécurité : mode opératoire, correspondance avec MITRE ATT&CK, questions d’audit ISO 27001 et pistes de sensibilisation. Les détails viennent d’une seule source primaire, la société Gambit, relayée par BleepingComputer ; nous n’avons pas pu consulter directement le rapport de Gambit, et les victimes ne sont pas nommées.
Pour une lecture orientée dirigeant, voir notre décryptage « Vol de cartes bancaires : quand des agents d’IA attaquent les sites marchands pour 25 dollars ».
Contexte
- Victimes : au moins 119 sites marchands compromis avec un skimmer ; plus de 600 000 cartes valides volées chez deux sociétés ; skimmers posés chez cinq autres organisations (chiffres Gambit). Victimes citées de façon anonyme : un groupe hôtelier du Fortune 500, une grande compagnie aérienne américaine, un distributeur industriel américain, un site de mode en ligne.
- Secteur : commerce en ligne (pages de paiement).
- Période : campagne active depuis au moins juillet 2026, toujours en cours au 22 septembre 2026.
- Type : vol de données de paiement par injection de code (« skimming », de type Magecart), industrialisé par des agents d’IA.
- Coût pour l’attaquant : environ 25 dollars par cible, selon Gambit.
- Attaquant : acteur motivé par l’argent. Selon Gambit, l’opérateur humain « semble être chinois », une attribution non étayée publiquement. Voir aussi la mise à jour en tête d’article.
- Source : BleepingComputer, 23 septembre 2026, qui relaie le rapport de Gambit.
Mode opératoire : ce qui est documenté et ce qui ne l’est pas
| Étape | Ce qui est rapporté | Correspondance MITRE ATT&CK (notre lecture) |
|---|---|---|
| Préparation des outils | Trois frameworks d’IA : Strix (scan, découverte de failles), Cairn (exploitation autonome), Hermes (orchestration, post-exploitation, décisions). Hermes contenait un persona « SOUL – Red Team Operator » et 121 « skills », dont 78 offensifs. Un message publié sur X, cité par BleepingComputer, indique que Hermes s’appuyait sur un modèle d’Anthropic (claude-opus-4.6) : information de seconde main. | T1588.007 Obtain Capabilities: Artificial Intelligence |
| Repérage | Strix lancé 146 fois contre 138 hôtes entre le 23 et le 31 août (633 heures de scan). Priorisation avec un service de classement du trafic web, en préférant les sites en code sur mesure. | T1595 Active Scanning, T1593 Search Open Websites/Domains |
| Accès initial | Exploitation par Cairn de vulnérabilités d’applications web exposées (objectif : shell ou accès administrateur). Accès souvent obtenu « en quelques heures ». Les failles précises ne sont pas détaillées publiquement. | T1190 Exploit Public-Facing Application |
| Injection du skimmer | Selon le niveau d’accès : ajout de code dans des fichiers JavaScript légitimes, balises script sur les pages de paiement ou dans des blocs Google Tag, empoisonnement de contenus S3 ou CDN et de caches serveur, modification de champs en base, altération de déploiements Kubernetes. | T1059.007 JavaScript, T1565.001 Stored Data Manipulation |
| Persistance | Tâches cron qui réinstallent le skimmer après sa suppression. | T1053.003 Scheduled Task/Job: Cron |
| Collecte et exfiltration | Captation des cartes par le skimmer ; extraction directe de données de cartes depuis des bases Magento. Le canal d’exfiltration n’est pas détaillé. | T1005 Data from Local System (bases) |
| Impact | Consigne d’effacer « par lots » les champs de cartes après extraction, d’où des pertes de données et des perturbations chez plusieurs marchands. | T1485 Data Destruction |
La colonne MITRE est une lecture de notre part, à partir des techniques décrites. Ce n’est pas une classification publiée par Gambit.
Ce qu’on ne sait pas
Les failles exploitées, le canal d’exfiltration, l’identité des victimes et l’attribution de l’attaquant. Nous ne spéculons pas sur ces points.
Détection : ce qui est public et ce qui ne l’est pas
- Ce qui est public : la campagne a été mise au jour par les chercheurs de Gambit, qui ont eu accès à un serveur de préparation (« staging ») de l’attaquant. C’est là qu’ils ont trouvé les preuves directes : fichiers de skills, suivi des coûts, compte OpenRouter.
- Ce qui ne l’est pas : on ne sait pas si les victimes ont détecté l’attaque par elles-mêmes, ni en combien de temps. Nous ne pouvons donc pas dire pourquoi la détection a été tardive chez elles.
- Notre lecture (déduite des techniques décrites, pas d’une source) : l’injection dans des fichiers légitimes, des caches ou des CDN, et la réinstallation par cron sont conçues pour échapper à un contrôle ponctuel. Seule une surveillance continue de l’intégrité des scripts servis au navigateur permet de les voir.
Questions d’audit ISO 27001:2022
- A.8.8, A.8.25 et A.8.28 (gestion des vulnérabilités techniques, développement sécurisé) : « Pour vos applications web développées sur mesure, quel est le délai réel entre la découverte d’une faille et sa correction en production ? Montrez-moi les trois dernières. » Avec un coût d’attaque d’environ 25 dollars, les applications « maison » exposées deviennent aussi rentables à attaquer que les grands CMS.
- A.8.9 et A.8.16 (gestion des configurations, activités de surveillance) : « Disposez-vous d’un inventaire des scripts chargés sur vos pages de paiement, et d’un mécanisme qui alerte en cas de modification (fichier, balise, CDN, cache) ? » Pour les entités soumises à PCI DSS v4.0, cela rejoint les exigences 6.4.3 et 11.6.1 : demander les preuves de leur mise en œuvre.
- A.5.21, A.5.22 et A.8.32 (chaîne d’approvisionnement TIC, suivi des fournisseurs, gestion des changements) : « Qui peut modifier le contenu servi par vos buckets S3, CDN et gestionnaires de balises ? Ces changements passent-ils par votre processus de gestion des changements, et sont-ils tracés ? »
- A.8.13, A.5.29 et A.5.30 (sauvegarde, continuité) : « Vos sauvegardes de bases transactionnelles permettent-elles de restaurer des données effacées volontairement par un attaquant ? Quand avez-vous testé une restauration pour la dernière fois ? » L’effacement des champs de cartes après le vol montre qu’une fuite peut aussi devenir une perte de données.
Pistes de sensibilisation
- Atelier pour les développeurs et les équipes e-commerce : montrer une page de paiement avec un script injecté, en environnement de test, et faire chercher « ce qui a changé ». Message clé : le navigateur du client exécute tout ce qu’on lui sert, y compris ce qu’un tiers a ajouté.
- Module pour la direction et les métiers : utiliser le chiffre de 25 dollars par cible pour casser l’idée « nous sommes trop petits pour intéresser un attaquant ». Relier ce point aux décisions de budget (correctifs, supervision) plutôt qu’à la peur.
À lire aussi : notre décryptage pour les dirigeants, « Vol de cartes bancaires : quand des agents d’IA attaquent les sites marchands pour 25 dollars », et le bulletin de veille du 24 septembre 2026.
Analyse préparée avec l’aide d’une intelligence artificielle à partir de sources publiques, sous la responsabilité de KyNeo. Malgré nos contrôles, des erreurs peuvent subsister : en cas de doute, référez-vous aux sources citées. Les informations non confirmées sont signalées comme telles.