Straiker décrit une opération utilisant l’IA contre plus de 400 cibles financières en Amérique latine

Ce que l’enquête affirme au sujet de CARLIY0S

Le 21 octobre 2026, Straiker a publié une enquête sur CARLIY0S, un système qui aurait été utilisé, selon l’entreprise, par des opérateurs associés à CyberCartel pour coordonner des activités visant plus de 400 cibles financières en Amérique latine. Les types d’organisations recherchées comprendraient des banques et des prestataires de services de paiement. Ce chiffre correspond au nombre de cibles attribuées à l’opération ; il ne prouve pas que plus de 400 établissements aient été compromis avec succès.

D’après Straiker, l’enquête repose sur l’accès à une copie de systèmes et de documents de travail attribués au groupe, notamment des fichiers de configuration, des scripts, des éléments d’infrastructure et une base de données appelée FinancialSoft. Ces éléments témoignent de ce qui se trouvait dans cet environnement, mais le rapport ne fournit pas de vérification indépendante de chaque attaque et ne nomme pas les organisations visées. Les attributions et l’ampleur de l’opération doivent donc être comprises comme des conclusions de l’entreprise, et non comme une confirmation publique de la responsabilité du groupe ou des dommages subis par chaque établissement.

Les informations disponibles sur l’affaire soulignent également cette limite : les noms des banques n’ont pas été divulgués et il n’est pas possible d’établir publiquement quels établissements de la région auraient été infiltrés. Les sources fournies ne contiennent pas non plus de liste vérifiable reliant chacune des plus de 400 cibles à un accès réussi, à une extraction de données ou à des pertes financières.

Une chaîne d’outils, pas un agent autonome unique

Straiker présente CARLIY0S comme un dispositif distribué combinant des opérateurs humains, des scripts, des outils de sécurité et des modèles commerciaux. Le système aurait reposé sur PentAGI, un cadre de tests de sécurité automatisés, ainsi que sur des composants permettant de partager des informations et de déléguer des tâches. Il est donc plus juste de le décrire comme une opération assistée et coordonnée à l’aide de l’IA que comme un agent ayant agi seul.

Le rapport attribue des fonctions différentes à plusieurs modèles. Claude apparaît dans une configuration d’agents chargés d’analyser des informations, de générer du code ou d’évaluer des options ; un modèle aurait servi de coordinateur depuis Cursor. Grok est associé à des tâches de collecte et de classement d’informations, tandis que Kimi figure dans des configurations de secours. La présence de ces paramètres dans des fichiers ne prouve pas, à elle seule, que chaque modèle ait été exécuté avec succès à toutes les étapes ou contre toutes les cibles.

Des outils classiques sont également décrits pour automatiser les interactions avec des sites Web, analyser le trafic et synchroniser des données entre plusieurs machines. Les modèles pouvaient fournir des analyses ou des suggestions, mais l’accès aux systèmes et l’exécution dépendaient d’outils, d’identifiants, de scripts et d’infrastructures. La capacité réelle de chaque étape ne peut donc pas être déduite de la seule présence d’une configuration d’IA.

Ce que montrent les données et ce qu’elles ne permettent pas de conclure

Dans la copie que Straiker affirme avoir examinée, FinancialSoft contenait 4 493 enregistrements. La description inclut des données de comptes financiers, des adresses électroniques, des mots de passe, des clés API et d’autres informations sensibles. Parmi les chiffres publiés figurent 2 911 adresses électroniques et 903 numéros de compte. Ces quantités sont attribuées à l’inventaire observé ; elles ne mesurent pas le nombre de personnes touchées et ne confirment pas que toutes les données étaient valides ou ont été utilisées.

Le rapport mentionne également des identifiants associés à des infrastructures de paiement, notamment des informations susceptibles d’être liées au SPEI, le système mexicain de paiements interbancaires. L’exposition d’identifiants peut accroître les risques d’accès non autorisé ou de fraude, mais elle ne suffit pas à démontrer que des virements ont été effectués, que des comptes clients ont été consultés ou que les identifiants étaient encore actifs.

L’entreprise affirme avoir anonymisé les organisations et assaini les informations sensibles publiées. Le lecteur ne peut donc pas vérifier l’identité des établissements concernés ni contrôler publiquement l’état de chaque compte ou clé mentionné. Le volume et la nature des données justifient une attention défensive, mais ne doivent pas être présentés comme la preuve de pertes concrètes.

Réponse des fournisseurs et portée des mesures

Straiker affirme avoir communiqué des indicateurs pertinents aux fournisseurs de modèles. Selon l’entreprise, Anthropic a révoqué un identifiant compromis qui permettait d’accéder à Claude. Elle a également indiqué que xAI avait été informée et examinait l’activité associée à cinq « Grok miners ». Ces mesures concernent l’accès à des services précis ; elles ne prouvent pas que toute l’infrastructure attribuée au groupe ait été désactivée.

Les documents fournis ne décrivent pas de mesures précises prises par des banques latino-américaines pour bloquer des agents d’IA et ne nomment aucun établissement qui aurait déployé des contrôles particuliers. Il n’est donc pas possible d’affirmer que les banques de la région aient instauré un blocage général des agents tiers à la suite de cette affaire. Il faut distinguer cette question des restrictions préventives décrites sur d’autres marchés, qui ne démontrent pas la réponse des établissements latino-américains.

Du point de vue de la défense, l’affaire met en évidence plusieurs domaines à examiner : identifiants exposés, autorisations d’API, accès aux portails d’administration, activités inhabituelles et connexions à des services externes. Ce sont des axes de défense pertinents face aux risques d’accès et d’automatisation ; ils ne garantissent pas la détection et ne constituent pas une liste de mesures dont la mise en œuvre aurait été confirmée dans les banques concernées.

Ce qui change — et ne change pas — pour la sécurité de l’IA

L’intérêt de cette affaire ne dépend pas de l’autonomie générale d’un modèle. L’enquête décrit une combinaison de modèles commerciaux, d’outils automatisés, de scripts, d’infrastructures partagées et d’opérateurs. Cet assemblage peut faciliter l’organisation de tâches et élargir la portée d’une opération, mais le rapport ne permet pas de conclure que l’IA ait remplacé les attaquants ou qu’elle ait choisi et exécuté seule chaque action.

Les éléments présentés par Straiker constituent une étude de cas fondée sur des documents que l’entreprise attribue à l’environnement de travail des opérateurs. Ils ne mesurent pas, à eux seuls, la fréquence des attaques menées avec des agents et ne prouvent pas que la même architecture produirait des résultats comparables pour d’autres groupes ou secteurs. La présence d’une configuration de modèle ne prouve pas non plus que celui-ci ait généré une intrusion réussie.

La conclusion pratique est plus limitée : les établissements financiers doivent tenir compte du fait que des outils d’IA peuvent être intégrés à des processus offensifs qui reposent déjà sur des logiciels et des infrastructures traditionnels. La réponse ne consiste pas seulement à bloquer un modèle : elle suppose aussi de protéger les identifiants, de limiter les autorisations, de surveiller le comportement des comptes et des API et de vérifier les incidents à partir des journaux techniques. Les sources fournies ne permettent pas d’attribuer à cette affaire une nouvelle mesure réglementaire ni de décrire une politique commune aux banques latino-américaines.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.