L’IA offensive quitte le stade de la démonstration pour entrer dans les opérations réelles. Depuis septembre 2026, plusieurs groupes utilisent ARTEX et d’autres frameworks agentiques pour automatiser des étapes allant de la reconnaissance à la préparation de l’exfiltration, selon Google Threat Intelligence Group et Mandiant. Microsoft a observé des campagnes où l’accès initial jusqu’aux privilèges élevés dans le cloud prenait parfois moins de trois heures.
Cette évolution ne repose pas sur un modèle autonome capable de tout faire seul. Elle s’appuie sur une combinaison plus opérationnelle : des LLM, des outils de sécurité existants, un système de planification et des agents spécialisés. Le résultat est une industrialisation du travail offensif, avec une conséquence directe pour les entreprises : les erreurs de configuration, les identités sur-privilégiées et les connexions entre fournisseurs deviennent exploitables à une vitesse difficile à suivre manuellement.
ARTEX transforme un objectif en chaîne d’attaque
ARTEX est un framework open source de pentest agentique, c’est-à-dire un logiciel qui utilise plusieurs agents pilotés par un LLM pour planifier et exécuter des tests de sécurité. Le projet, écrit en Go et doté d’une interface web Next.js, ne fournit pas son propre modèle d’IA : il se connecte à des modèles externes, notamment ceux compatibles avec les interfaces d’Anthropic ou d’OpenAI.
L’opérateur définit un objectif et un périmètre. Un agent de planification convertit ensuite cette demande en tâches, tandis que des agents d’exécution utilisent des outils réels, consignent les résultats et poursuivent l’exploration. Le CERT-EU décrit un fonctionnement couvrant la reconnaissance et les tests de manière autonome, dans le cadre défini par l’utilisateur.
Les capacités observées dépassent le simple balayage automatisé. Google Threat Intelligence Group et Mandiant ont documenté des actions comprenant la reconnaissance Active Directory, l’escalade de privilèges, l’analyse d’infrastructures cloud, la récupération de clés Azure et la préparation de webshells. ARTEX peut également conserver les découvertes et les réutiliser au fil de la progression dans l’environnement ciblé.
À retenir : ARTEX n’est pas un modèle d’IA isolé, mais une couche d’orchestration qui relie un LLM à des outils offensifs. Sa force vient de cette continuité entre planification, exécution et adaptation.
Le projet a été publié en juillet 2026, puis son dépôt d’origine a été retiré par son créateur en octobre après des signalements d’abus. Cette suppression n’a pas fait disparaître le logiciel : des forks et des sauvegardes continuent de circuler, et des variantes comme ScopeWeaver ainsi qu’une version commerciale baptisée ARTEX PRO ont été signalées.
La vitesse devient l’avantage décisif des attaquants
L’apport principal de l’IA offensive n’est pas nécessairement la découverte d’une vulnérabilité inconnue. Il réside dans la capacité à tester rapidement une grande quantité de chemins d’attaque et à enchaîner des actions qui demanderaient du temps à une équipe humaine.
Le CERT-EU souligne qu’ARTEX peut traiter de nombreuses erreurs de configuration peu complexes, y compris celles qu’un analyste identifierait facilement mais qu’il ne pourrait pas vérifier partout faute de temps. Cette différence est déterminante dans les environnements hybrides, où les applications, les comptes, les API et les services cloud se multiplient.
Microsoft a rapporté que l’acteur Storm-0940, aligné sur la Chine, a utilisé ARTEX dès septembre 2026 contre des centaines d’organisations dans plusieurs secteurs. Certaines intrusions ont permis d’obtenir un accès privilégié à des infrastructures cloud en moins de trois heures après le ciblage initial.
La machine accélère également les étapes intermédiaires. Elle peut inventorier les ressources d’un tenant, analyser les droits d’une application, rechercher des identifiants exploitables et proposer la suite logique. L’opérateur conserve un rôle de contrôle, mais il n’a plus besoin de guider chaque commande.
Une campagne observée par CrowdStrike aurait consommé environ 1,4 milliard de tokens en entrée au cours d’une seule intrusion. Ce volume illustre l’écart entre une utilisation ponctuelle d’un chatbot et un système agentique exécutant des boucles longues, avec analyse continue des résultats.
| Fonction offensive | Travail manuel traditionnel | Automatisation agentique observée |
|---|---|---|
| Reconnaissance | Collecte et tri réalisés par des analystes | Inventaire automatisé des domaines, ports, endpoints et ressources cloud |
| Planification | Choix progressif des hypothèses de test | Décomposition d’un objectif en tâches et intentions |
| Exploitation | Validation outil par outil | Exécution coordonnée de plusieurs outils avec conservation du contexte |
| Mouvement latéral | Vérifications successives | Recherche automatisée de chemins entre comptes, postes et services |
| Persistance cloud | Analyse manuelle des identités et applications | Vérification rapide des permissions, secrets et jetons accessibles |
La vitesse modifie donc le coût d’une attaque. Un groupe disposant d’un framework public et d’un accès à un modèle peut multiplier les tentatives sans augmenter proportionnellement ses effectifs. Les défenseurs doivent alors réduire la fenêtre entre la première anomalie et la révocation des accès, plutôt que compter uniquement sur la détection d’une charge malveillante.
Les banques sud-coréennes illustrent le passage à l’échelle
Des opérations liées à ARTEX ont touché des banques et des institutions financières sud-coréennes à la fin de septembre et au début d’octobre 2026, selon plusieurs analyses de sécurité. Les actions décrites comprennent le sondage automatisé d’applications web, le credential stuffing, le mouvement latéral et la préparation de l’exfiltration.
Le secteur financier concentre plusieurs caractéristiques favorables à ce type d’attaque : une forte interconnexion, des applications exposées, de nombreux prestataires et une exigence de disponibilité permanente. Un agent n’a pas besoin de compromettre chaque système de manière originale. Il peut identifier les chemins les plus accessibles, réutiliser des identifiants volés et changer de cible rapidement.
L’intérêt d’ARTEX tient aussi à sa capacité à conserver une représentation structurée de l’environnement. Les découvertes effectuées sur un domaine, une application ou une identité peuvent alimenter les étapes suivantes. Cette mémoire opérationnelle évite de recommencer l’analyse à chaque action.
Les attaques visant les établissements financiers ne doivent pas être réduites à l’image d’un piratage entièrement autonome. Les observations disponibles montrent plutôt une collaboration entre opérateurs humains et agents logiciels. L’humain choisit la cible, fournit le périmètre et peut orienter les objectifs ; le framework accélère ensuite la collecte, l’évaluation et l’exécution.
Cette distinction compte pour la défense. Bloquer un seul modèle ou une seule interface ne suffit pas lorsque le framework accepte plusieurs fournisseurs de LLM. ARTEX peut fonctionner avec différents modèles et des services compatibles avec des interfaces courantes, ce qui rend son écosystème plus difficile à neutraliser par une mesure unique.
Les attaques par la chaîne d’approvisionnement multiplient l’impact
La deuxième rupture vient de la concentration des accès. Une compromission ne s’arrête plus nécessairement à l’organisation directement ciblée : elle peut se propager par une application autorisée, un fournisseur de services ou un plugin connecté à plusieurs environnements.
Microsoft a décrit une campagne où l’utilisation d’ARTEX a accéléré l’abus d’applications déjà autorisées à accéder à des environnements Microsoft 365. Les agents ont notamment procédé à l’énumération de ressources, à la manipulation de certificats et de secrets d’applications et à l’attribution de rôles élevés à des identités de service.
Ce mode opératoire exploite des fonctions légitimes. Une requête adressée à une API officielle, exécutée par une application bénéficiant déjà d’un consentement, peut ressembler à une activité d’administration. La difficulté consiste alors à distinguer l’usage normal d’un privilège de son détournement.
Les risques s’étendent aux fournisseurs d’IA eux-mêmes. Le fait établi publié par Brief IA fait état du piratage d’un fournisseur d’IA ayant exposé 5 000 entreprises par l’intermédiaire d’un plugin malveillant. Cette situation montre qu’un composant périphérique peut devenir le point de passage vers un grand nombre de clients.
Le problème ne se limite pas à l’IA générative. Un plugin, une extension, une application d’intégration ou un connecteur peut disposer de droits disproportionnés par rapport à sa fonction. Si cet élément est compromis, l’attaquant bénéficie d’un effet de levier supérieur à celui d’une intrusion isolée.
Les identités deviennent le nouveau périmètre
Les environnements modernes reposent sur des identités de service, des jetons, des secrets d’application et des consentements inter-tenant. Ces éléments permettent aux logiciels de fonctionner sans intervention humaine, mais ils deviennent aussi des cibles prioritaires pour les agents offensifs.
Les chercheurs ont observé ARTEX rechercher des jetons SAS, des comptes de service, des identifiants Kudu, des clés de comptes de stockage et d’autres secrets Azure. Le framework a également été associé à des tentatives de modification des identités applicatives et d’attribution de privilèges élevés.
La défense doit donc suivre les droits effectifs, et pas seulement les connexions réseau. Une application légitime qui obtient soudainement un nouveau secret, appelle une API sensible ou ajoute une permission administrative doit déclencher une vérification indépendante.
Pourquoi les défenses traditionnelles perdent du terrain
Les outils de détection classiques restent utiles, mais ils sont moins efficaces lorsqu’ils recherchent uniquement des signatures, des fichiers suspects ou des comportements manifestement anormaux. L’IA offensive permet d’utiliser les fonctions natives de l’environnement, ce qui réduit la visibilité des opérations malveillantes.
ARTEX peut, par exemple, s’appuyer sur des fonctionnalités de gestion, des API cloud et des identités déjà présentes. L’attaque ne nécessite donc pas toujours le déploiement d’un malware identifiable. Elle peut progresser au moyen de commandes et d’appels légitimes, effectués dans une séquence inhabituelle.
La fatigue humaine constitue un autre désavantage. Les équipes de sécurité doivent examiner des alertes, des journaux et des configurations provenant de dizaines de services. En face, un framework agentique peut répéter les mêmes contrôles sur de nombreux actifs et adapter ses tests dès qu’il découvre un nouveau privilège.
Google Threat Intelligence Group et Mandiant ont signalé depuis la fin août 2026 l’utilisation de plusieurs frameworks agentiques de pentest, dont ARTEX, PentAGI et CAIRN, dans des interventions liées à des incidents. Les activités documentées couvrent notamment le mouvement latéral, l’exploitation de bases de données et la préparation de l’exfiltration.
La tension opérationnelle s’est maintenue depuis octobre, selon le fait établi publié par Brief IA. Cette continuité est plus significative qu’une campagne isolée : elle indique que les outils restent disponibles, que les forks peuvent survivre au retrait d’un dépôt et que plusieurs groupes savent les intégrer à leurs propres infrastructures.
La réponse doit combiner contrôle, vitesse et simulation
La priorité n’est pas d’interdire indistinctement les outils d’IA. Les mêmes mécanismes peuvent servir aux équipes autorisées pour évaluer les actifs, détecter les chemins d’attaque et mesurer l’exposition réelle. La priorité consiste à encadrer strictement les actions qu’un agent peut déclencher et les droits dont il dispose.
Réduire les chemins d’attaque les plus rentables
Les organisations devraient concentrer leurs efforts sur les éléments qu’ARTEX et les frameworks similaires exploitent déjà :
- Inventorier les applications connectées aux environnements cloud et supprimer les consentements inutilisés.
- Réduire les privilèges des identités de service et imposer une durée de vie limitée aux secrets.
- Surveiller les ajouts de certificats, de mots de passe et de rôles sur les applications existantes.
- Révoquer rapidement les jetons compromis et les sessions associées.
- Segmenter les environnements afin qu’un compte de service ne puisse pas explorer toute l’infrastructure.
- Journaliser les appels API sensibles, y compris lorsqu’ils sont effectués par une application légitime.
La surveillance doit être corrélée. Une modification de privilège prise isolément peut être normale ; la même modification suivie d’une exploration massive du tenant et d’un accès à des ressources inhabituelles doit être traitée comme un incident potentiel.
Tester les défenses contre des agents
Les exercices de sécurité doivent intégrer des scénarios où l’adversaire ne suit pas un playbook fixe. Un agent peut changer d’objectif intermédiaire, abandonner une piste peu rentable et exploiter immédiatement une nouvelle permission découverte.
Les équipes peuvent simuler ce comportement dans un périmètre autorisé, avec des limites explicites sur les données, les systèmes et les actions. L’objectif n’est pas de reproduire une attaque sans contrôle, mais de mesurer le temps nécessaire pour détecter une chaîne composée de signaux faibles.
Cette approche permet de vérifier plusieurs indicateurs concrets : délai de détection, délai de révocation, capacité à identifier une application détournée et précision de la reconstruction de la chaîne. Elle rapproche les tests de la réalité opérationnelle décrite dans les campagnes récentes.
Protéger les fournisseurs et les plugins
Le cas du plugin malveillant ayant exposé 5 000 entreprises rappelle qu’un programme de sécurité doit couvrir les dépendances, pas seulement les systèmes internes. Chaque intégration devrait être évaluée selon ses droits, sa capacité d’écriture, son accès aux données et la possibilité de la désactiver rapidement.
Les fournisseurs d’IA doivent également séparer les environnements, limiter les secrets accessibles aux extensions et contrôler les changements de code et de configuration. Une intégration qui touche plusieurs clients ne peut pas être traitée comme un simple module applicatif.
À retenir : la défense contre l’IA offensive se joue moins dans la détection d’un chatbot que dans le contrôle des permissions, des intégrations et des séquences d’actions.
Notre avis : l’IA offensive impose une défense plus automatisée
ARTEX marque un changement concret parce qu’il relie un objectif en langage naturel à des outils capables d’agir dans un environnement réel. Les opérations observées en 2026, notamment contre des organisations financières sud-coréennes et des environnements cloud, montrent que le risque ne dépend plus uniquement de groupes disposant d’importantes équipes techniques.
Le retrait du dépôt d’origine n’a pas suffi à interrompre la diffusion du framework. Les forks, les modèles multiples et les outils complémentaires réduisent l’efficacité des réponses fondées sur le blocage d’un nom ou d’une adresse. Les entreprises doivent traiter l’IA offensive comme un accélérateur de chaînes existantes, avec un impact particulier sur les identités et les fournisseurs.
Dans les six prochains mois, l’avantage ira aux équipes capables d’automatiser elles aussi la surveillance des permissions, la corrélation des appels API et la révocation des accès. Une défense qui dépend uniquement d’analystes examinant manuellement chaque alerte laissera mécaniquement une fenêtre aux agents offensifs.
La question n’est donc plus de savoir si l’IA peut être utilisée pour attaquer, mais si les systèmes de défense sauront détecter et interrompre une chaîne automatisée avant qu’elle n’atteigne les privilèges critiques.