ARTEX : comment un outil de pentest IA gratuit est devenu un incontournable des attaquants

En bref

• ARTEX est un framework de test d'intrusion IA multi-agents open source : un backend Go avec une console Next.js et une base PostgreSQL, publié sur GitHub en juillet 2026. Un opérateur fournit une cible et un objectif ; des agents planificateurs et travailleurs exécutent les outils et consignent actifs, constats et preuves dans un graphe partagé.
• En trois mois, il a été utilisé contre des banques sud-coréennes, dans la compromission de la chaîne d'approvisionnement ConnectWise Cloud Backup, dans une campagne VAPOR PANDA contre plus de 200 organisations dans 14 pays, et par un groupe cybercriminel basé au Cambodge que Microsoft suit sous le nom de Storm-3358.
• L'auteur a rendu le projet closed source le 8 octobre 2026. Wiz Research comptait alors plus de 12 000 forks, et des scans indépendants début novembre ont trouvé entre environ 800 et 1 650 consoles exposées, selon ce que chaque scanner comptait.
• Le framework n'a pas besoin d'une vulnérabilité logicielle pour atteindre le cloud. Les intervenants de Unit 42 ont vu des opérateurs transformer des pages de réinitialisation de mot de passe et des API exposées en accès cloud en à peine une journée.
• Sa signature est la vitesse et la répétition, pas la furtivité : des pulvérisations de mots de passe à raison d'environ une tentative par seconde, des rafales de 20 à 60 minutes, une rotation d'IP et de user-agents, et des sessions de 24 à 30 heures.
• Cherchez les artefacts : les user-agents norma/0.4 et artex-enrich/1.0, le téléchargement de source maps suivi d'appels à des routes API internes, les JWT alg:none et le sondage des callbacks OAuth.
• Fermez toute console ARTEX que vous possédez, puis traitez l'identité comme le périmètre : consentement des applications, identifiants des service principals, attributions de rôles et authentification héritée.
• C'est un outil à double usage, pas une CVE. CISA KEV : non applicable (aucune CVE ; évaluation du 13 novembre 2026). La plupart des tentatives ont échoué ; le danger est le coût d'une nouvelle tentative.

Pourquoi ARTEX compte-t-il maintenant ?

ARTEX compte parce qu'il a automatisé la partie coûteuse du test d'intrusion : enchaîner des faiblesses ordinaires à la vitesse de la machine. Trois mois après sa publication sur GitHub en juillet 2026, il était utilisé contre des banques sud-coréennes, dans une compromission de la chaîne d'approvisionnement et dans une campagne d'espionnage visant 200 cibles. Wiz Research rapporte qu'un développeur chinois l'a publié, qu'il a remporté le challenge red team « Agent+ » de Baidu en septembre et qu'il est passé en closed source le 8 octobre, après que des attaquants l'avaient déjà utilisé contre des banques sud-coréennes (Wiz Research, 22 octobre 2026).

C'est une trajectoire courte pour un outil de sécurité. En novembre, Microsoft avait publié deux rapports sur des acteurs qui l'utilisent, CrowdStrike deux autres, la police de Séoul avait décrit une affaire pénale construite autour de lui, et des scanners indépendants comptaient les consoles exposées par milliers. L'outil n'a pas créé une nouvelle classe de vulnérabilité. Il a changé la vitesse à laquelle des faiblesses ordinaires peuvent être essayées, réessayées et enchaînées.

Le changement important est économique. Un pentester humain est limité par ses heures, son attention et ses compétences. Une flotte d'agents est limitée par des tokens, des proxys et des cibles. L'évaluation par Microsoft d'une campagne a relevé plusieurs cas où le délai entre le ciblage initial et l'accès cloud privilégié était inférieur à trois heures (Microsoft, 21 octobre 2026). Unit 42 décrit des opérateurs transformant des pages publiques de réinitialisation de mot de passe et des API exposées en accès cloud « parfois en moins d'une journée », sans exploiter la moindre vulnérabilité logicielle (Unit 42, 11 novembre 2026).

Qu'est-ce qu'ARTEX ?

ARTEX est un système d'orchestration pour agents, outils et preuves, et non un scanner auquel on a greffé un LLM. Un fork public du projet publie un README qui décrit un monolithe Go qui embarque un frontend Next.js, une base PostgreSQL et un runtime d'agents construit sur le SDK norma de l'auteur (README ARTEX, un fork public du projet d'origine). Quatre rôles se partagent le travail : un agent Goals décompose la cible et extrait le périmètre, un Planner produit l'intention suivante, des agents Worker exécutent les outils, et un MainAgent garde un humain dans la boucle.

Deux graphes portent l'état. Le graphe d'actifs est global et partagé entre les tâches : domaines racines, sous-domaines, IP, services, applications et endpoints, regroupés par entreprise. Le graphe d'exploration est propre à chaque tâche : objectifs, intentions, faits, constats et indices, reliés par des arêtes comme spawns, derived_from, yields et proves. Les agents interrogent les deux graphes comme des outils, si bien qu'un fait découvert par un worker devient le contexte du plan suivant.

Le framework embarque ce qu'il faut pour mener une campagne depuis un navigateur : un tableau de bord des tâches, une carte de couverture des actifs, un proxy MITM qui enregistre le trafic avec sa propre AC, un écran d'approbation et d'interception des outils, la prise en charge de serveurs MCP, des « skills » réutilisables, la mémoire des agents et un installateur en un clic qui démarre un conteneur Docker sur le port 8787 (README). L'image par défaut inclut ripgrep, curl, vim, npm et nmap. Microsoft ajoute que les agents utilisent wget, des clients HTTP Python et Chromium headless via Playwright par défaut (Microsoft) ; Wiz a observé Impacket ; Zscaler a observé sqlmap et jadx dans la version personnalisée d'un opérateur (Zscaler ThreatLabz).

C'est précisément l'empaquetage qui compte. Un outil qui exigeait autrefois une équipe, une méthodologie et un modèle de rapport démarre désormais avec docker compose up -d et une clé API. Les mêmes propriétés qui le rendent utile à un testeur autorisé le rendent utile à quelqu'un qui ne l'est pas du tout.

Brève histoire d'un outil qui a dépassé son auteur

ARTEX est resté public moins de trois mois avant que son auteur ne le retire. La séquence compte, car chaque étape a élargi la population capable de l'exécuter.

• Juillet 2026 : le projet est publié sur GitHub comme framework open source sous licence AGPL-3.0 (Wiz ; Security Affairs).
• Septembre 2026 : Wiz rapporte qu'il remporte le challenge red team « Agent+ » de Baidu. Fin septembre, des institutions financières sud-coréennes commencent à signaler des intrusions ; CrowdStrike reliera ensuite une console ARTEX à la campagne.
• 8 octobre 2026 : à 10 h 50 UTC, l'auteur publie un avis indiquant que l'outil a été détourné, qu'il passera en closed source et qu'aucune nouvelle version ne sortira. Le projet passe en privé (BadByte, 4 novembre 2026).
• 11 octobre 2026 : Genians rapporte que le dépôt GitHub et l'image Docker ont été supprimés. Les forks et les miroirs subsistent (Security Affairs).
• Novembre 2026 : environ 34 namespaces Docker Hub publient des images nommées artex, pour environ 60 000 téléchargements cumulés. AntiFox, un fork d'ARTEX 0.1.1, est utilisé dans des intrusions de vol d'identifiants AWS et reste sur GitHub en version 2.0 (BadByte ; BleepingComputer, 11 novembre 2026).

Fermer le code a supprimé le mainteneur, pas la capacité. Wiz comptait plus de 12 000 forks au moment où le projet est passé en privé. L'écosystème Docker a comblé le vide : BadByte a trouvé 34 namespaces publiant des images ARTEX, et le dépôt copycat le plus étoilé n'était pas une continuation propre mais une version troyanisée. Une image piégée, tomicdd/artex, ajoutait un gestionnaire de connexion non authentifié qui exécutait des commandes shell en root et renvoyait la sortie ; Docker l'a retirée le 5 novembre, mais 637 dépôts GitHub pointaient encore vers elle ce jour-là. Nous avons couvert cet incident séparément dans Malicious ARTEX Docker Image Hands Out Root Shells.

L'ironie est utile aux défenseurs. Ceux qui installent un outil offensif depuis une image non vérifiée héritent des mêmes risques qu'ils comptent exploiter : une console non patchée, un conteneur root, des secrets en clair et un port public. L'écosystème ARTEX est désormais à la fois une plateforme d'attaque et une cible de chaîne d'approvisionnement.

À quoi ressemblent les attaques ?

Les campagnes diffèrent par le mobile et les techniques, mais partagent un schéma : trouver une application exposée à Internet, utiliser les flux d'identité plutôt qu'une corruption mémoire, et laisser l'agent itérer jusqu'à ce que quelque chose s'ouvre. Le tableau n'est pas exhaustif ; il reflète ce que les publications publiques établissent.

Corée du Sud : un opérateur, trois modèles nommés et une console restée ouverte

Le rapport du 7 octobre de CrowdStrike décrit une campagne contre des banques sud-coréennes commencée fin septembre. L'acteur a laissé une console ARTEX et des répertoires ouverts contenant des historiques de sessions Claude Code, des fichiers de configuration ARTEX et des fichiers de mémoire Claude. L'instance ARTEX utilisait DeepSeek v4.1 Flash comme modèle principal, complété par GLM-5.3 et Grok 4.6 pour les sessions Claude Code, et joignait DeepSeek via le domaine revendeur xcai[.]pro (CrowdStrike).

Les fichiers de l'opérateur ont fourni l'attribution. Un prompt de CV contenait un nom, un numéro de téléphone, un identifiant Telegram, un âge, une université et une localisation ; CrowdStrike précise que ces détails ne peuvent pas être rattachés définitivement à l'acteur, et qu'une date de naissance du prompt en contredisait une autre. Les sessions montrent aussi l'opérateur demandant à Claude où se vendent les données de fuite coréennes et quels groupes Telegram approcher. BleepingComputer rapporte que les banques incluaient Shinhan, KB Kookmin et Hana, que des données personnelles et des informations de carte ont été exposées, et que certains systèmes ont subi des pannes (BleepingComputer, 10 octobre 2026).

Le suivi de Hunt.io ajoute le détail de l'infrastructure. La console à 38.244.50[.]120 se trouvait sur le réseau de Cogent à Los Angeles avec 15 ports ouverts ; la page de connexion ARTEX apparaissait sur 443 et 8090 aux côtés d'une console d'administration Gemini2API et d'un serveur Tinyproxy. Un serveur de rebond à Hong Kong hébergeait 105 Mo d'outillage, dont des scripts maintenant des tunnels SSH inverses, un script d'interrogation FOFA, une liste de proxys rotatifs et 19 skills personnalisés avec 147 usages enregistrés couvrant l'audit de code, l'injection web, le contournement de WAF, les tests d'authentification, les Telegram Mini Apps, la décompilation d'APK et la logique de paiement (Security Affairs).

Storm-0940 : du scan à la compromission de la chaîne d'approvisionnement

Microsoft évalue que Storm-0940, un acteur aligné sur l'État chinois actif depuis 2021, a utilisé ARTEX dès septembre 2026 contre des centaines d'organisations dans l'aérospatiale, l'automobile, la chimie, l'énergie, les services financiers, le gouvernement, le juridique, l'industrie, les médias, le militaire, les semi-conducteurs, le logiciel, la technologie et les think tanks. Plusieurs intrusions ont atteint un accès cloud privilégié en moins de trois heures (Microsoft).

Le lien avec la chaîne d'approvisionnement est la partie à étudier. Microsoft évalue que Storm-0940 est responsable de la compromission de ConnectWise Cloud Backup, une application multi-tenant. Après avoir acquis les identités de plusieurs applications cloud ConnectWise, les agents se sont authentifiés dans les environnements clients avec les identifiants volés, puis ont opéré dans Microsoft Graph : reconnaissance, modification des identifiants d'application pour la persistance, changements d'identités, de groupes et de rôles privilégiés, et lectures massives de secrets dans les Azure Key Vaults.

La pulvérisation de mots de passe parallèle montre le tempo. Entre le 10 et le 14 octobre, l'infrastructure à 144.172.64[.]99 a ciblé 327 comptes dans huit organisations. Microsoft a enregistré plus de 151 000 échecs de connexion, avec un pic à 2 900 échecs par minute le 11 octobre et plus de 111 000 échecs en une seule journée. Quarante-huit comptes ont reçu plus de 1 000 échecs, et les verrouillages représentaient près de 98 % de l'activité. Aucune authentification réussie, émission de token, appel Graph ou modification d'annuaire n'a été observée dans cette pulvérisation. L'accès à la chaîne d'approvisionnement venait des identifiants d'application volés, pas d'un mot de passe deviné.

Cette distinction compte pour les défenseurs. Une pulvérisation de mots de passe est bruyante et échoue souvent. Une application multi-tenant de confiance qui se connecte avec un identifiant valide est discrète, parce qu'elle est censée être là. L'avantage de l'agent est qu'il peut faire les deux en même temps.

VAPOR PANDA : 200 cibles en 11 jours

Le rapport du 29 octobre de CrowdStrike décrit un autre acteur lié à la Chine, VAPOR PANDA, utilisant ARTEX à partir du 17 octobre contre plus de 200 organisations dans au moins 14 pays sur une fenêtre de 11 jours. Les cibles incluaient des ministères des Affaires étrangères en Amérique latine, en Europe, en Asie et au Moyen-Orient ; des organisations des semi-conducteurs, de la défense et des think tanks aux États-Unis ; et des opérateurs télécoms dans plusieurs régions. CrowdStrike a confirmé une post-exploitation dans neuf organisations et une pulvérisation d'identifiants contre au moins 12 autres (CrowdStrike).

Le détail technique est inhabituellement concret. Chez un laboratoire pharmaceutique américain, l'agent a enchaîné une assertion SAML non signée et une faille XXE pour interroger le service de métadonnées d'instance du cloud, obtenu un rôle capable d'émettre des commandes d'administration vers des milliers d'instances, puis a escaladé vers un compte administrateur d'entreprise. Chez un second, il a déployé des webshells, abusé d'un service d'orchestration non authentifié pour obtenir root dans un conteneur de production, lu des mots de passe LAPS et abusé d'une délégation contrainte basée sur les ressources. Contre une entité gouvernementale grecque, l'opérateur a fourni un export d'annuaire de 2022 ; l'agent a utilisé les clés non renouvelées pour forger un token administrateur, puis des configurations VPN trouvées dans les mails envoyés d'un utilisateur pour atteindre le réseau interne.

VAPOR PANDA a aussi demandé aux agents d'éviter les défenses endpoint. Chez un laboratoire pharmaceutique mondial, l'instruction était de trouver les machines Windows du domaine sans Falcon, en jugeant à partir de tasklist et de listings de dossiers, avec l'argot red team chinois « 猎鹰 » pour le capteur CrowdStrike. Dans une intrusion, les agents de planification ont consommé de l'ordre de 1,4 milliard de tokens d'entrée. C'est un repère d'échelle utile : ce n'est pas une session de chatbot, c'est un budget de calcul.

Cybercriminalité : l'ancien pentester et Storm-3358

Le même outil couvre désormais l'espionnage d'État et la fraude ordinaire. Le 26 octobre, BleepingComputer rapporte que la police de Séoul a identifié sept suspects dans une opération ayant compromis plus de 90 organisations en Corée du Sud. Le chef était un hacker autodidacte de 32 ans ayant travaillé dans une entreprise de cybersécurité entre 2019 et 2022 ; il a commencé à attaquer en septembre 2025 et a adopté l'outillage IA fin août 2026. Dans 38 incidents, le groupe a exigé 360 millions de wons (environ 270 000 dollars) pour ne pas diffuser les données volées. La police l'a décrit comme la première arrestation coréenne dans une affaire de piratage et de vol de données personnelles à grande échelle exploitant l'IA générative (BleepingComputer).

Le rapport du 6 novembre de Microsoft ajoute la couche criminelle professionnelle. Storm-3358 est un groupe d'intrusion basé au Cambodge qui cible principalement des organisations financières en Asie du Sud-Est, plus un petit nombre de grandes organisations financières mondiales. En octobre 2026, il a utilisé ARTEX aux côtés d'automatisations classiques pour scanner des systèmes connectés à Internet, exploiter le téléversement de fichiers anonyme et le SSRF, et installer les trojans d'accès distant WISP, vshell et AdaptixC2, les agents utilisant netcat et curl pour les télécharger (Microsoft).

La longue traîne : WorkOS et AntiFox

Tous les incidents n'exigent pas un État-nation. WorkOS a révélé le 30 octobre qu'un attaquant avait accédé à une application de vente interne et pris des coordonnées professionnelles, des historiques de comptes clients et des résumés de conversations commerciales et de support. Le fondateur de l'entreprise a attribué l'intrusion à ARTEX et indiqué que les enquêteurs avaient vu les user-agents artex-enrich/1.0 et norma/0.4 dans les requêtes web (BleepingComputer, 3 novembre 2026).

AntiFox montre où vont les forks. Arctic Wolf a observé des hôtes Alibaba Cloud faisant tourner des interfaces AntiFox et utilisant des identités AWS valides, dont des utilisateurs IAM et des rôles EC2 assumés, pour effectuer des appels API authentifiés. Dans un cas, l'opérateur a déployé un webshell ASPX sur un serveur IIS exposé à Internet, lu les paramètres applicatifs et les chaînes de connexion à la base, et copié des fichiers de configuration et de logs dans un répertoire accessible par le web. Dans un autre, il a fait tourner les identités et effectué des centaines de requêtes API AWS en environ 30 minutes ; la plupart ont été bloquées, mais certaines ont obtenu des secrets de production, et un incident distinct a utilisé une identité valide pour lire, copier et supprimer des objets S3 (BleepingComputer).

Que font réellement les agents ?

L'analyse de logs de Wiz est la description publique la plus claire de la boucle. Chez plusieurs victimes, le premier geste de l'agent a été de lire l'application : télécharger les source maps JavaScript, config.json, env.js et le document OpenAPI, puis appeler des routes API internes dont les noms n'apparaissent que dans ces fichiers (Wiz). Cette séquence est une empreinte. Un navigateur charge un bundle ; il ne récupère pas main-3a9f.js.map puis ne devine pas GeneratePasswordResetToken deux minutes plus tard.

Le playbook se répète :

1. Cartographier l'application. Les source maps, la configuration d'exécution et les documents Swagger/OpenAPI révèlent des routes, des paramètres et des fonctionnalités cachées.
2. Sonder l'authentification. L'agent initie des flux de connexion, mute les callbacks OAuth et les paramètres state, soumet des JWT non signés et varie les chemins SSO. Wiz a enregistré plus de 60 variantes de routes SSO avec un token alg:none en deux minutes.
3. Abuser la récupération de compte. Il vérifie si un nom d'utilisateur existe, puis appelle les endpoints de réinitialisation de mot de passe, de récupération de nom et d'activation. Un 204 renvoyé par un endpoint de token de réinitialisation est un signal utile même si aucun mail n'arrive.
4. S'inscrire et tester l'isolation des tenants. Là où l'inscription est ouverte, il utilise une boîte jetable, confirme le compte et demande immédiatement les données d'une autre entreprise en manipulant des identifiants prévisibles.
5. Établir une référence. Avant de fuzzer, il demande un chemin inexistant comme /zzz-nonexistent-xyz123 pour apprendre à quoi ressemble un vrai 404.
6. Pulvériser et s'adapter. Les pulvérisations tournent avec un écart médian d'une seconde, par rafales de 20 à 60 minutes, avec un user-agent différent par rafale et une priorité aux comptes d'ingénieurs logiciels. Quand une IP est bloquée, une nouvelle apparaît en quelques minutes ; quand un endpoint est limité, l'agent bascule vers un autre endpoint du même hôte.

Le tableau relie ces comportements à ce qu'un défenseur peut réellement collecter.

Deux autres comportements sont faciles à manquer. L'agent utilise des clients programmatiques ordinaires (python-urllib/3.12, python-requests/2.31.0, curl/7.88.1, norma/0.4, artex-enrich/1.0) et des chaînes Chrome trivialement usurpables. Les user-agents seuls sont bruyants. La séquence est le signal : une récupération de source map, une route interne, un token alg:none, un appel de réinitialisation et une pulvérisation, tout depuis le même ASN en une heure, ce n'est pas un navigateur.

Pourquoi cela fonctionne-t-il ?

Quatre propriétés expliquent l'adoption.

Aucune vulnérabilité n'est nécessaire pour atteindre le cloud. Les intervenants de Unit 42 décrivent les pages de réinitialisation de mot de passe et les API exposées comme le chemin vers l'accès cloud, sans aucune vulnérabilité logicielle exploitée. Les flux d'identité sont conçus pour être joignables depuis Internet ; c'est ce qui les rend utiles et c'est ce qui les rend ciblables.

Le coût marginal est faible. Check Point Research a analysé un opérateur faisant tourner deux consoles ARTEX pendant environ deux semaines contre dix boutiques de signatures de code iOS du marché gris, avec DeepSeek v4.1 Flash et Kimi K3.1 Pro. L'opérateur a consommé 36 milliards de tokens ; aux prix officiels de l'API DeepSeek, Check Point estime le coût de calcul entre 700 et 1 500 dollars (Check Point Research, 5 novembre 2026). Les certificats .p12 volés et leurs mots de passe en clair constituent l'inventaire des boutiques de signature que l'opérateur dévalisait. L'outil est gratuit ; les modèles sont des produits de base ; la liste des cibles est publique.

Les garde-fous font partie du routage. Check Point a trouvé des modèles chinois dominants dans les configurations des opérateurs, DeepSeek Flash étant le plus répandu. Sur les trois instances où des modèles américains étaient configurés, les seuls refus observés venaient d'Opus 5.5 d'Anthropic, et l'opérateur s'est tourné vers des modèles chinois plus permissifs. Le choix du modèle n'est pas une déclaration idéologique ; c'est un paramètre opérationnel, et l'agent contournera un refus comme il contourne une IP bloquée.

L'identité est le plan de contrôle. Chaque campagne décrite dans cet article a dépendu à un moment donné d'identifiants, de tokens ou de rôles : une application OAuth, une assertion SAML, un rôle IMDS, un mot de passe LAPS, une configuration VPN, un secret Key Vault, un utilisateur IAM. L'agent n'a pas besoin de casser la cryptographie. Il a besoin d'une relation de confiance valide et de suffisamment d'essais pour la trouver.

La population de consoles exposées est l'autre moitié de l'histoire. Les scans indépendants de début novembre divergent parce qu'ils comptent des choses différentes : Censys a compté plus de 800 déploiements joignables sans connexion (TechCrunch, 6 novembre 2026) ; Check Point a compté 2 557 systèmes ayant hébergé ou hébergeant un panneau, dont 1 608 en ligne et publics au moment de ses recherches ; BadByte a compté 1 645 hôtes servant la console ARTEX le 4 novembre ; Hunt.io en a compté environ 1 300 en faisant correspondre le titre de la page de la console, selon Security Affairs. Une console exposée n'est pas seulement une victime. Elle détient des listes de cibles, des identifiants, du trafic capturé et une clé d'AC de proxy, et c'est un serveur de rebond tout prêt.

Que craindre dans l'année à venir ?

La trajectoire la plus probable n'est pas une campagne ARTEX unique et catastrophique. C'est la banalisation.

• Plusieurs frameworks, pas un seul. Unit 42 a compté 1 323 hôtes exposés à Internet faisant tourner CyberStrikeAI et 609 faisant tourner ARTEX en octobre 2026, avec 21 hôtes faisant tourner les deux, et a analysé 14 outils de l'écosystème (Unit 42). Check Point cite CyberStrike, Cairn et PentAGI aux côtés d'ARTEX. Fermer un projet ne ferme pas la catégorie.
• Des forks bon marché avec de nouvelles cibles. AntiFox a repris ARTEX 0.1.1 et l'a braqué sur les identités AWS. Le prochain fork visera ce que son auteur connaît : Kubernetes, API d'administration SaaS, CI/CD, OSS télécom. Le framework est une coquille ; les skills et les prompts sont la charge utile.
• L'accès à la chaîne d'approvisionnement comme multiplicateur. ConnectWise est le modèle. Un fournisseur compromis ou un identifiant d'application multi-tenant volé donne à un agent un chemin de confiance vers tous les tenants en aval d'un coup. La plupart des organisations ne voient pas ce chemin parce qu'il ressemble au fournisseur.
• Acteurs étatiques et criminels sur le même outil. Storm-0940, VAPOR PANDA, Storm-3358 et le groupe de l'ancien pentester ont utilisé le même framework avec des objectifs différents. Cette convergence compresse le délai entre l'apparition d'une technique dans l'espionnage et son usage dans la fraude.
• La fenêtre d'alerte du défenseur se réduit. Microsoft note que l'automatisation génère plus de trafic et plus d'alertes, mais que la vitesse laisse peu de temps pour répondre avant que l'acteur n'ait obtenu sa persistance. Un agent qui atteint un accès privilégié en trois heures distancera une file de triage mesurée en jours.
• Les consoles exposées restent une source d'infrastructure d'attaque. Une console sans authentification est un point de rebond, un magasin d'identifiants et une source de données de ciblage d'autrui. La population est assez large pour que le scan de ces consoles soit lui-même une activité.

Le contrepoids est que les agents actuels sont bruyants et échouent souvent. Microsoft indique que la majorité du ciblage de Storm-0940 n'a pas abouti. Unit 42 a vu Cairn générer des centaines de milliers de requêtes à haute fréquence depuis une seule IP d'origine. La vitesse crée des occasions de détection en même temps que de la pression.

Comment les défenseurs doivent-ils se préparer ?

L'ordre compte. Commencez par les consoles, puis l'identité, puis la matière première que consomment les agents.

1. Trouvez et fermez les consoles ARTEX et similaires. Cherchez dans votre inventaire d'actifs et vos logs de sortie le titre de la console, le port par défaut 8787 et les build IDs. Si une console est exposée, traitez-la comme compromise : elle détient des listes de cibles, des identifiants, du trafic capturé et une clé privée d'AC de proxy. Retirez l'accès public, placez l'administration derrière un VPN ou une liste d'autorisation, faites tourner le mot de passe PostgreSQL, les clés LLM, les clés d'API de recherche, les webhooks de notification et les identifiants de proxy, et remplacez jwt.key, qui peut forger des tokens admin.

2. Traitez l'identité comme le périmètre. Imposez le MFA résistant au phishing, bloquez l'authentification héritée et revoyez vos politiques d'accès conditionnel. Auditez les enregistrements d'applications et les applications d'entreprise : qui a consenti, quelles permissions ont été accordées, quels identifiants ont été ajoutés et quels service principals se sont attribué un rôle. Les consignes de Microsoft sur ConnectWise sont précises : préservez la configuration et les preuves avant de supprimer une application, inventoriez les ID d'application concernés et examinez les connexions des service principals depuis au moins le 15 octobre, en remontant au 1er octobre lorsque les enregistrements le permettent.

3. Chassez la séquence agentique, pas le user-agent. Construisez des détections pour un téléchargement de source map ou de config.json suivi d'appels à des routes internes ; les JWT alg:none et les state OAuth malformés ; l'énumération de noms d'utilisateur suivie d'appels de réinitialisation ; les inscriptions par e-mail jetable suivies de sondage d'ID d'objets ; une sonde 404 de référence avant une rafale de fuzzing ; et des échecs de connexion à environ un par seconde sur de nombreux comptes. Gardez ensemble les taux par IP et par compte, l'ASN, le timing et le chemin.

4. Retirez la matière première. Ne servez pas de source maps, env.js, config.json ou documents Swagger depuis la production sans intention. Retirez les secrets des bundles clients et des dépôts ; faites tourner tout ce qui a été commité. Exigez IMDSv2, gardez les clés d'accès de longue durée hors de la configuration applicative et limitez les rôles d'instance au minimum. Ce sont les mêmes correctifs qui battaient la version manuelle de ces attaques ; ils fonctionnent toujours.

5. Détectez la post-exploitation. Surveillez les ajouts d'identifiants d'application, les nouveaux service principals ou propriétaires, les attributions de rôles, l'auto-attribution du rôle Global Administrator et les appels SecretGet massifs sur plusieurs Key Vaults en peu de temps. Surveillez les webshells, les téléchargements netcat/curl vers des racines web, les nouvelles tâches cron, le trafic LDAP/JNDI, les callbacks DNS et les accès inhabituels aux mails ou fichiers. Les marqueurs de chasse de CrowdStrike pour une campagne incluaient des lignes de commande contenant artx, des rôles cloud préfixés artx-, des commentaires de commande d'administration contenant art18- et le répertoire C:\ProgramData\artx5v\.

6. Ralentissez l'agent. Les tests de Microsoft ont montré que les honeypots, leurres, tarpits et fausses victoires réduisaient le trafic d'attaque atteignant les actifs réels et produisaient un signal d'attribution à haute confiance. Un tarpit consomme le temps et le budget de l'agent ; une fausse victoire peut le faire s'arrêter sur un faux succès. Ce n'est pas un substitut au patch, mais cela change l'économie d'une campagne non supervisée.

7. Répétez la réponse. Décidez à l'avance qui peut désactiver une application fournisseur, révoquer des sessions et faire tourner des clés, et dans quel ordre. Préservez les logs avant le confinement. Supposez que les données accessibles à l'identité compromise ont été lues, et notifiez sur cette base plutôt que d'attendre la preuve d'une exfiltration.

Qu'est-ce que cela ne signifie pas ?

• Toutes les consoles exposées ne sont pas malveillantes. Beaucoup appartiennent à des testeurs autorisés qui ont laissé un labo sur Internet. Silas Cutler, de Censys, le dit explicitement. Le problème est l'exposition, pas l'intention de chaque opérateur.
• La plupart des tentatives échouent. Microsoft n'a observé aucune authentification réussie dans la pulvérisation de 151 000 événements, et indique que la majorité du ciblage de Storm-0940 n'a pas abouti. Les agents sont persistants, pas omnipotents.
• Un outil n'est pas une campagne. ARTEX a été utilisé par un acteur étatique, un groupe d'espionnage distinct, un groupe criminel et un ancien pentester individuel. L'attribution appartient à l'opérateur, pas au framework.
• Les techniques ne sont pas nouvelles. Wiz note qu'aucune des techniques individuelles observées n'était nouvelle. Ce qui est nouveau, c'est l'enchaînement, le rythme et l'endurance.
• Les comptages ne sont pas comparables. Censys, Check Point, BadByte et Hunt.io ont mesuré des populations différentes à des dates différentes. Ne les moyennez pas et ne traitez pas l'un comme le total vrai.

Qu'est-ce qui n'a pas pu être vérifié ?

• Les nombres exacts d'étoiles et de forks d'origine. Wiz rapporte plus de 12 000 forks à la fermeture ; la page GitHub du dépôt a disparu et un instantané archivé n'a pas pu être récupéré pendant cette recherche.
• La victoire au challenge « Agent+ » de Baidu est rapportée par Wiz Research ; nous n'avons pas trouvé d'annonce primaire de Baidu ou d'ARTEX.
• Le nombre d'enregistrements volés dans l'affaire de la police de Séoul. Le corps de l'article de BleepingComputer dit 8,2 millions ; son titre dit 82 millions. Nous n'utilisons aucun des deux chiffres dans cet article.
• Si Storm-3358 et Storm-0940 se recoupent, ou si l'acteur des banques coréennes est lié à l'un ou l'autre. Microsoft et CrowdStrike décrivent des groupes distincts.
• La population exacte des consoles exposées. Les comptages publiés vont de plus de 800 à 1 645, et chacun utilise une définition différente.
• La lignée d'AntiFox au-delà du fork d'ARTEX 0.1.1 rapporté, et qui opère l'infrastructure Alibaba Cloud.
• Si la fermeture du code a réduit le mésusage. Les forks, miroirs et images Docker étaient déjà publics.

Chronologie

• Juillet 2026 : ARTEX est publié sur GitHub comme framework open source.
• Septembre 2026 : Wiz rapporte sa victoire au challenge red team « Agent+ » de Baidu ; des institutions financières sud-coréennes commencent à signaler des intrusions.
• 7 octobre 2026 : CrowdStrike publie son analyse de la campagne coréenne.
• 8 octobre 2026 : l'auteur annonce le passage en closed source ; le projet passe en privé.
• 16 octobre 2026 : ConnectWise publie son avis initial sur Cloud Backup.
• 17-28 octobre 2026 : VAPOR PANDA utilise ARTEX contre plus de 200 organisations dans 14 pays.
• 26 octobre 2026 : la police de Séoul annonce sept suspects et 90+ organisations compromises.
• 4 novembre 2026 : BadByte publie l'analyse de l'image Docker piégée ; 1 645 consoles ARTEX sont comptées en ligne.
• 6 novembre 2026 : Microsoft rapporte que Storm-3358, un groupe à motivation financière, utilise ARTEX contre des organisations financières.
• 11 novembre 2026 : Arctic Wolf et BleepingComputer décrivent AntiFox, un fork, utilisé dans le vol d'identifiants AWS.

FAQ

ARTEX est-il une vulnérabilité ou une CVE ?

Ni l'un ni l'autre. C'est un framework de test d'intrusion à double usage. Une recherche par mot-clé dans le NVD pour artex ne renvoie aucun enregistrement au 13 novembre 2026 (NVD), et les intrusions décrites ici exploitent des classes de faiblesses connues : API exposées, MFA faible ou absente, flux de réinitialisation de mot de passe, SSRF, assertions SAML non signées, JWT alg:none, IDOR et identifiants fuités.

ARTEX attaque-t-il les applications mobiles ?

Les publications publiques décrivent des applications web, des fournisseurs d'identité, des API cloud et des hôtes Windows et Linux locaux. Hunt.io a récupéré du code source de sonde iOS, des utilitaires de noyau et de firmware Android et un outil pour une plateforme d'échange de cryptomonnaies dans le répertoire d'un opérateur, mais leur lien avec les intrusions confirmées n'est pas établi. Les parcs mobiles sont plus susceptibles d'être atteints via les API backend et les flux d'identité que les mêmes agents ciblent.

Peut-on le détecter en bloquant les user-agents ?

Pas de manière fiable. Les opérateurs font tourner les user-agents, et Wiz a relevé 15 chaînes différentes chez les victimes, dont des chaînes Chrome ordinaires et python-urllib. Utilisez les user-agents comme un signal faible et corrélez-les avec la séquence de requêtes, le rythme et le chemin.

Faire tourner ARTEX pour des tests autorisés est-il sûr ?

Seulement si vous le traitez comme un service à haut risque. La console n'a pas d'authentification au-delà de son formulaire de connexion (BadByte), le conteneur tourne en root, le fichier compose publie le port 8787 sur toutes les interfaces et les secrets sont stockés en clair. Placez-la derrière un VPN, restreignez la sortie, utilisez un hôte dédié, faites tourner ses clés et ne l'installez jamais depuis une image non vérifiée.

Quel est le contrôle le plus utile ?

Fermer les surfaces d'administration et d'identité exposées à Internet. Le point de Unit 42 est que ces agents ne peuvent pas cibler ce qu'ils ne trouvent pas. Chaque console retirée, chaque source map dont la diffusion cesse et chaque flux de réinitialisation limité en débit réduit l'ensemble des chemins qu'un agent peut essayer à la vitesse de la machine. Si vous ne devez faire qu'une chose, commencez par la liste de chasse aux consoles de « Comment les défenseurs doivent-ils se préparer ? » ; l'image troyanisée est traitée dans l'article séparé sur la backdoor ARTEX.

Références

• Microsoft Threat Intelligence, « AI-driven, large-scale nation-state campaign using ARTEX enables supply chain compromise », 21 octobre 2026 : https://www.microsoft.com/en-us/security/blog/2026/10/21/storm-0940-uses-artex-agentic-ai-connectwise-supply-chain-compromise/ (vérifié le 2026-11-13)
• Microsoft Threat Intelligence, « ARTEX abuse expands as cybercriminals target financial sector », 6 novembre 2026 : https://www.microsoft.com/en-us/security/blog/2026/11/06/artex-abuse-expands-as-cybercriminals-target-financial-sector/ (vérifié le 2026-11-13)
• Wiz Research, « ARTEX in the Wild: Storm-0940 Expands Targeting of IT and Software Vendors », 22 octobre 2026 : https://www.wiz.io/blog/artex-in-the-wild-storm-0940-expands-targeting-of-it-and-software-vendors (vérifié le 2026-11-13)
• CrowdStrike, « Unknown Threat Actor Uses AI-Driven ARTEX to Target South Korean Finance », 7 octobre 2026 : https://www.crowdstrike.com/en-us/blog/unknown-threat-actor-uses-artex-to-target-south-korean-finance/ (vérifié le 2026-11-13)
• CrowdStrike, « VAPOR PANDA Uses AI-Driven ARTEX to Grow Global Espionage Campaign », 29 octobre 2026 : https://www.crowdstrike.com/en-us/blog/vapor-panda-uses-artex-to-scale-global-campaign/ (vérifié le 2026-11-13)
• Check Point Research, « Hacking on Autopilot: Inside ARTEX Cybercrime Campaigns », 5 novembre 2026 : https://research.checkpoint.com/2026/hacking-on-autopilot-inside-artex-cybercrime-campaigns/ (vérifié le 2026-11-13)
• Unit 42, « ARTEX and AI-Powered Red Teaming Tools: What Defenders Need to Know », 11 novembre 2026 : https://unit42.paloaltonetworks.com/artex-and-ai-powered-red-teaming-tools/ (vérifié le 2026-11-13)
• Zscaler ThreatLabz, « Inside the Global AI-Assisted Hacking Campaign » : https://www.zscaler.com/blogs/security-research/inside-global-ai-assisted-hacking-campaign (vérifié le 2026-11-13)
• Security Affairs, « Inside ARTEX: AI Hacking Tools, Exposed Servers and South Korean Bank Breaches », 7 novembre 2026 : https://securityaffairs.com/184100/cyber-crime/inside-artex-ai-hacking-tools-exposed-servers-and-south-korean-bank-breaches.html (vérifié le 2026-11-13)
• BleepingComputer, « Hacker used ARTEX AI and Claude agents to target South Korean banks », 10 octobre 2026 : https://www.bleepingcomputer.com/news/security/hacker-used-artex-ai-and-claude-agents-to-target-south-korean-banks/ (vérifié le 2026-11-13)
• BleepingComputer, « Former pentester used ARTEX AI to steal 8.2 million data records », 26 octobre 2026 : https://www.bleepingcomputer.com/news/security/former-pentester-used-artex-ai-to-steal-82-million-data-records/ (vérifié le 2026-11-13)
• BleepingComputer, « WorkOS says attacker used ARTEX AI to breach internal sales app », 3 novembre 2026 : https://www.bleepingcomputer.com/news/security/workos-says-attacker-used-artex-ai-to-breach-internal-sales-app/ (vérifié le 2026-11-13)
• BleepingComputer, « Hackers use AntiFox AI agents in AWS credential-theft attacks », 11 novembre 2026 : https://www.bleepingcomputer.com/news/security/hackers-use-antifox-ai-agents-in-aws-credential-theft-attacks/ (vérifié le 2026-11-13)
• BadByte, « ARTEX Backdoor: 7,946 Pulls of a Trojanized Docker Image Handing Out Root Shells », 4 novembre 2026, mis à jour le 5 novembre 2026 : https://badbyte.io/artex-backdoor-docker-image/ (vérifié le 2026-11-13)
• TechCrunch, « Hundreds of Artex AI hacking tools found publicly exposed to the web », 6 novembre 2026 : https://techcrunch.com/2026/11/06/hundreds-of-artex-ai-hacking-tools-found-publicly-exposed-to-the-web/ (vérifié le 2026-11-13)
• README ARTEX, fork public du projet d'origine : https://github.com/horizonl/ARTEX (vérifié le 2026-11-13)
• Recherche par mot-clé dans le NVD pour artex, zéro enregistrement le 2026-11-13 : https://nvd.nist.gov/vuln/search/results?query=artex&search_type=all (vérifié le 2026-11-13)