Selon CrowdStrike, des cyberattaques menées avec ARTEX AI ont ciblé des organismes financiers sud-coréens en septembre et octobre 2026. Les données exposées montrent qu’un attaquant a utilisé ARTEX, des sessions Claude Code, des proxys et plusieurs grands modèles de langage pour faciliter l’exfiltration de données. Les éléments disponibles documentent des flux d’intrusion assistés par l’IA, mais ne montrent pas que le Claude de Anthropic a été compromis et n’identifient pas d’attaquant nommément.
Que s’est-il passé lors des cyberattaques menées avec ARTEX AI ?
Les cyberattaques menées avec ARTEX AI constituaient une campagne d’exfiltration de données menée en 2026 contre des organismes financiers sud-coréens. CrowdStrike a établi un lien entre des données de configuration ARTEX exposées, des enregistrements Claude Code et cette activité le 7 octobre 2026. Les informations publiques faisaient état d’au moins sept entreprises ciblées et de données associées à environ 68 000 personnes, même si le nombre d’organisations touchées reste à confirmer.
ARTEX est un open source, cadre de tests d’intrusion multi-agents qui répartit les objectifs entre des agents, invoque des outils de sécurité et accumule des informations sur les actifs et les vulnérabilités. Ces capacités ont des usages légitimes dans le cadre d’évaluations autorisées. Entre les mains d’un attaquant, le même flux de travail peut accélérer la reconnaissance, les tests et l’organisation des informations volées.
CrowdStrike a identifié une infrastructure connexe en septembre et octobre 2026. Dans son rapport du 7 octobre, l’entreprise décrivait une architecture à deux serveurs comprenant un système principal basé à Hong Kong et un hôte ARTEX à l’adresse 38.244.50[.]120, ainsi que neuf adresses IP de proxy associées à cette activité.
Les médias coréens ont décrit une énumération automatisée présumée d’un service de consultation du statut de prêts et d’un système d’assistance mobile destiné aux employés en octobre 2026. CrowdStrike n’a pas établi de manière indépendante la méthode d’accès initiale ; ces informations ne doivent donc pas être considérées comme la preuve de la manière dont les intrusions ont commencé.
Claude a-t-il été piraté ou était-il responsable des attaques contre les banques coréennes ?
Il n’a pas été démontré que Claude avait été piraté ou qu’il était directement responsable des attaques contre le secteur financier coréen. Les éléments recueillis par CrowdStrike en octobre 2026 montrent des sessions Claude Code exécutées dans le cadre d’un flux de travail plus large contrôlé par l’attaquant, qui utilisait également ARTEX, des proxys, une infrastructure offensive conventionnelle et des backends de modèles externes. La compromission du service de Anthropic n’a été ni démontrée ni alléguée par les chercheurs.
Le 7 octobre 2026, des répertoires contrôlés par l’attaquant et exposés sur Internet ont révélé des historiques de sessions Claude Code, des fichiers mémoire et un fichier d’instructions CLAUDE.md. Ces éléments offrent un aperçu rare de la manière dont l’opérateur interagissait avec des agents de codage. Ils n’établissent pas que Claude a sélectionné les cibles, obtenu l’accès initial ou agi sans directives humaines.
Une session a montré l’opérateur demander où les données coréennes volées lors d’une fuite sont généralement vendues et demander de l’aide pour localiser des groupes coréens de Télégramme vente de données, selon le rapport 2026 de CrowdStrike. Une autre contenait de possibles informations sur l’opérateur, mais CrowdStrike a explicitement averti que ces informations ne pouvaient pas être attribuées de manière définitive à l’attaquant.
La distinction est importante. Qualifier l’incident de « piratage de Claude » reviendrait à confondre l’utilisation abusive d’un outil accessible avec la compromission de son fournisseur. Des questions similaires se posent dans le cadre des incidents récents de fuite de données impliquant des agents d’IA, où les autorisations, les limites d’exécution et le comportement de l’opérateur comptent davantage que le nom de marque du modèle.
Quels modèles et outils d’IA l’attaquant a-t-il utilisés ?
Selon CrowdStrike, l’installation ARTEX observée utilisait DeepSeek v4.1-flash comme backend principal en octobre 2026. D’autres sessions Claude Code faisaient référence à GLM-5.3 et Grok 4.6. La campagne reposait donc sur une chaîne d’outils multimodèle plutôt que sur un unique modèle autonome menant l’intégralité de l’attaque.
| Composant | Rôle ou élément observé | Source et date |
|---|---|---|
| ARTEX | Framework de tests d’intrusion multi-agents utilisé pour répartir les objectifs et invoquer des outils de sécurité | CrowdStrike, 7 octobre 2026 |
| DeepSeek v4.1-flash | Backend principal configuré pour l’instance ARTEX observée | CrowdStrike, 7 octobre 2026 |
| Claude Code | Sessions, fichiers mémoire et instructions exposés documentant l’activité de l’opérateur | CrowdStrike, 7 octobre 2026 |
| GLM-5.3 et Grok 4.6 | Apparus dans des enregistrements supplémentaires de sessions Claude Code | CrowdStrike, 7 octobre 2026 |
| Infrastructure de proxy | Neuf adresses IP de proxy associées ont été répertoriées | CrowdStrike, 7 octobre 2026 |
| Hôtes ARTEX exposés sur Internet | Environ 600 adresses IP supplémentaires découvertes ; toutes n’étaient pas considérées comme malveillantes | AhnLab, 6 octobre 2026 |
Les recherches d’AhnLab menées en octobre 2026 ont révélé que certaines infrastructures liées à ARTEX exécutaient des passerelles d’API d’IA, des services de gestion de la surface d’attaque, des frameworks de tests d’intrusion, des outils de commande et de contrôle ou CyberStrikeAI. Cette diversité montre pourquoi les défenseurs doivent disposer d’une télémétrie couvrant toute la chaîne d’exécution. Surveiller uniquement les invites ne permet pas de détecter les scanners, les shells, les passerelles et les connexions sortantes qui transforment la sortie d’un modèle en action.
Les risques liés à la sécurité agentique ne sont pas propres à ARTEX. Ils apparaissent également lorsque le codage assisté par l’IA introduit des dépendances dangereuses ou lorsque les attaquants déploient des agents d’IA sur des hôtes Docker compromis. À mon avis, les équipes de sécurité qui se concentrent uniquement sur la sûreté des modèles surveillent le point de contrôle le moins fiable.
Qui était derrière les cyberattaques menées avec ARTEX AI ?
Aucun acteur malveillant identifié n’a été attribué aux cyberattaques menées avec ARTEX AI. Le 7 octobre 2026, CrowdStrike a estimé avec un degré de confiance modéré que l’opérateur était probablement sinophone et motivé par des considérations financières. L’Institut national hongrois de cybersécurité a conservé la description « attaquant inconnu » dans son résumé des conclusions du 9 octobre 2026.
La langue et l’infrastructure sont des indices, pas des pièces d’identité. Un opérateur peut utiliser des outils de traduction, des serveurs loués et des artefacts délibérément trompeurs. Les informations personnelles potentiellement trouvées dans une session Claude constituent un indice d’attribution particulièrement faible, car CrowdStrike n’a pas pu les associer de manière certaine à la personne ayant mené les attaques.
AhnLab a signalé environ 600 adresses IP supplémentaires hébergeant des instances ARTEX le 6 octobre 2026. Le lendemain, CrowdStrike a répertorié neuf adresses IP de proxy pour l’activité étudiée. Diviser 600 par neuf donne environ 66,7, mais ce calcul n’a aucune valeur d’attribution, car les chiffres décrivent des ensembles différents : une exposition générale sur Internet contre des proxys liés à une seule campagne.
C’est un piège que de nombreux résumés de menaces ne détectent pas. En 2026, AhnLab a averti que des systèmes de recherche légitimes pouvaient figurer parmi les quelque 600 hôtes. Bloquer chaque adresse ARTEX observée sans validation pourrait perturber des tests autorisés tout en étant peu efficace contre un opérateur qui change d’infrastructure.
Comment les banques doivent-elles se défendre contre les cyberattaques agentiques ?
Les banques devraient se défendre contre les cyberattaques orchestrées par des agents en enregistrant chaque invocation d’agent et d’outil, en détectant les automation taux anormaux, en restreignant les destinations sortantes, en séparant les identifiants selon les tâches et en préservant immédiatement les preuves après tout accès anormal aux données. Les éléments probants relatifs à ARTEX en 2026 montrent que les contrôles de l’exécution, de l’identité et des communications réseau sortantes restent efficaces même lorsque les attaquants alternent entre plusieurs modèles d’IA.
L’objectif pratique est de rendre toute action automatisée attribuable. Une requête adressée à un modèle, une commande shell, un appel de scanner, une utilisation d’identifiants et un transfert sortant doivent partager suffisamment d’identifiants et d’horodatages pour permettre aux enquêteurs de reconstituer la séquence. Cette approche transforme l’automatisation à grande vitesse en une chaîne visible plutôt qu’en un pic inexpliqué.
Les organismes financiers doivent donner la priorité aux contrôles suivants :
- Consigner les invites des agents, les appels d’outils, la création de processus, l’utilisation des API et les connexions aux backends de modèles avec des horodatages 2026 synchronisés.
- Déclencher une alerte lorsque des requêtes répétées ou des demandes arrivent plus rapidement que dans les flux de travail humains habituels, tout en tenant compte de l’automatisation approuvée.
- Limiter le trafic sortant en fonction de la destination et faire transiter le trafic des agents par des proxys d’entreprise surveillés.
- Attribuer des identifiants propres à chaque tâche, à durée de validité courte, au lieu de partager de larges comptes de service entre les agents et les outils.
- Conserver les journaux, les fichiers mémoire, les instructions et les éléments de preuve réseau immédiatement après tout accès ou toute exfiltration suspecte.
Les contrôles officiels de Claude Code de Anthropic documentés d’octobre 2025 à octobre 2026 comprennent le bac à sable pour le système de fichiers et le réseau, les restrictions de domaine, le routage via proxy d’entreprise et les autorisations gérées de manière centralisée. Ces fonctionnalités peuvent contribuer au confinement et à la visibilité, mais uniquement lorsque les organisations les configurent au lieu de se fier à la confiance par défaut.
L’application au moment de l’exécution constitue la stratégie la plus robuste. Une politique écrite relative à l’utilisation de l’IA ne peut pas empêcher un agent d’accéder à un hôte non approuvé ; une règle de sortie réseau le peut. Ce même principe sous-tend le passage des documents de politique vers les contrôles d’exécution pour la gouvernance de l’IA et les approches de isolation des agents d’IA.
FAQ sur ARTEX et les attaques financières coréennes
ARTEX est-il un logiciel malveillant ?
ARTEX est un framework open source de tests d’intrusion multi-agents, et non un logiciel malveillant en soi. Les cyberattaques menées par l’IA d’ARTEX montrent comment un framework de sécurité légitime peut être détourné à des fins d’intrusion non autorisée et de vol de données.
Combien d’entreprises financières sud-coréennes ont été touchées ?
Des informations publiées en octobre 2026 faisaient état d’au moins sept entreprises financières sud-coréennes, mais CrowdStrike a indiqué que le nombre d’organisations touchées restait à confirmer. Ces informations faisaient également état d’incidents liés à des données concernant environ 68 000 personnes.
600 serveurs ARTEX ont-ils été impliqués dans l’attaque ?
Aucun élément ne permet d’établir que l’ensemble des quelque 600 adresses IP hébergeant ARTEX signalées par AhnLab le 6 octobre 2026 ont participé à la campagne. AhnLab a expressément averti que des systèmes de recherche légitimes pourraient être inclus.
Les banques peuvent-elles bloquer ARTEX pour empêcher les attaques assistées par l’IA?
Bloquer l’infrastructure ARTEX connue peut réduire l’exposition, mais cela ne peut pas empêcher les attaquants de modifier les serveurs, les proxys, les frameworks ou les backends de modèles. Les banques ont besoin d’une détection fondée sur les comportements, d’un trafic sortant restreint, d’identifiants segmentés et de journaux complets de l’exécution des outils.