AntiFox, un pentest à agents IA, est détourné pour voler des secrets AWS

11 novembre 2026. Arctic Wolf publie son analyse d’AntiFox, une plateforme de pentest pilotée par des agents IA, utilisée de façon offensive contre des services web et des environnements AWS. 2.0. C’est la version du projet, désormais capable de documenter et de rapporter ses propres découvertes. Une trentaine de minutes. C’est le temps qu’un attaquant a mis pour enchaîner des centaines d’appels API avec des identités volées. Pourquoi c’est important : les agents IA autonomes ne sont plus une démonstration de laboratoire — ils exploitent des failles, déploient des webshells et récoltent des secrets de production.

AntiFox, l’héritier direct d’ARTEX

AntiFox est né comme un fork d’ARTEX 0.1.1, l’autre framework de pentest agentique développé en Chine, dont l’histoire a déjà été documentée ici — la campagne d’espionnage de Vapor Panda l’avait poussé à passer en source fermée après des attaques contre des banques sud-coréennes. AntiFox reprend le principe, avec une interface en chinois et une promesse simple : laisser l’utilisateur déployer des agents IA qui automatisent les tâches de pentest — cartographier les services exposés, sonder les points d’entrée, chercher des vulnérabilités. CrowdStrike a par ailleurs relié ARTEX à une campagne d’espionnage où le groupe chinois Vapor Panda a visé plus de 200 organisations dans 14 pays — ce qui a précipité le passage du projet en source fermée.

Ce qui change avec la version 2.0, toujours disponible sur GitHub, c’est la boucle de retour : l’outil documente et rapporte ses propres découvertes, ce qui en fait un assistant de bout en bout plutôt qu’un simple scanner. Le problème n’est pas l’outil — un pentesteur légitime s’en sert comme d’un collègue. Le problème est ce qui se passe quand la même autonomie tombe entre d’autres mains.

Ce que les agents font une fois lâchés

Le rapport d’Arctic Wolf décrit des instances d’AntiFox auto-hébergées sur Alibaba Cloud, associées à des actions malveillantes confirmées contre des services web exposés et les environnements AWS qui leur sont liés. Le répertoire des activités observées ressemble au plan de travail d’un pentest réel, sauf qu’il est exécuté sans mandat :

• exploitation de vulnérabilités sur des services web accessibles depuis Internet ;
• déploiement de webshells — dont un webshell ASPX posé sur un serveur IIS exposé ;
• validation d’identifiants et découverte de configuration ;
• récolte de secrets AWS.

Le cas d’école détaillé par les chercheurs montre la profondeur d’une intrusion réussie. Après avoir déposé un webshell ASPX sur un serveur IIS, l’attaquant a exécuté des commandes système, lu les réglages d’application et les chaînes de connexion aux bases de données, puis copié les fichiers de configuration et de logs vers un répertoire accessible par le web. À partir de là, il détenait ce que ces fichiers contenaient — dont, souvent, des identifiants.

Le choix d’Alibaba Cloud pour l’hébergement n’est pas anodin. Les instances y sont louées à la demande, payées de façon anonyme, et les demandes de retrait y traversent des frontières juridiques que les équipes de réponse à incident occidentales ne franchissent pas vite. C’est la même logique que celle observée avec ARTEX, dont l’infrastructure opérait depuis des hébergeurs difficiles à atteindre — l’attaquant choisit l’endroit où l’on viendra le chercher le moins.

Le point AWS : des identités valides, pas une faille du cloud

L’élément le plus instructif du rapport concerne AWS. Les attaquants n’ont pas exploité une vulnérabilité du cloud. Ils ont utilisé des identités AWS valides — des utilisateurs IAM et, dans certains cas, des rôles EC2 assumés — pour émettre des appels authentifiés vers les API Amazon Web Services. Autrement dit, ils ont fait exactement ce qu’une application compromise est autorisée à faire.

Un cas illustre la méthode : l’attaquant a fait tourner plusieurs identités et émis des centaines d’appels API en une trentaine de minutes, obtenant des secrets de production malgré des refus ponctuels. Dans un autre incident, une identité valide a servi à lire, copier et supprimer des objets S3. La recommandation d’Arctic Wolf est limpide : révoquer les sessions et les clés AWS concernées, faire tourner les identifiants exposés dans les fichiers d’application, et corréler l’activité de webshell avec des accès AWS inhabituels — en particulier les appels réussis au milieu de rafales de refus.

Amazon a répondu le 12 novembre par la voix d’un porte-parole : « AWS services were not compromised and operated as designed », précisant que les chercheurs décrivent des acteurs utilisant des identifiants pris dans des applications clientes compromises. Le géant du cloud renvoie vers ses recommandations de toujours — moindre privilège, IMDSv2 sur les instances EC2, pas de clés de longue durée dans les configurations d’application, et GuardDuty activé.

La vraie leçon : les agents baissent la barrière

Le fond du sujet n’est ni AntiFox ni ARTEX en particulier. C’est que l’IA agentique a franchi un seuil : un opérateur n’a plus besoin d’enchaîner manuellement la reconnaissance, l’exploitation et l’exfiltration — l’agent orchestre la séquence. Les éditeurs d’AntiFox interdisent explicitement l’usage contre des systèmes réels, dans des tests réels ou à des fins illégales, mais ils ne décrivent aucun contrôle technique qui applique ces restrictions. La distinction entre l’outil légitime et l’arme offensive ne tient qu’à la bonne foi de l’utilisateur.

C’est la même trajectoire que celle déjà observée avec les agents autonomes de type llmjacking : le coût marginal d’une attaque automatisée s’effondre, et avec lui la barrière d’entrée. Pour les défenseurs, la conséquence est concrète — les signaux d’une attaque agentique sont anormalement rapides et bruyants : des rafales d’appels API, des identités qui alternent, des webshells qui écrivent dans des répertoires publics.

Le contraste avec le pentest manuel est net. Un humain enchaîne la reconnaissance, l’exploitation et l’exfiltration en heures ou en jours, avec des pauses et des erreurs ; l’agent les enchaîne en minutes, sans fatigue et sans peur de se faire repérer. C’est ce qui explique les centaines d’appels API en trente minutes décrits par Arctic Wolf — un rythme qu’un opérateur humain ne tiendrait pas. Pour le défenseur, c’est paradoxalement une chance : ce rythme anormal est lui-même un signal détectable, à condition d’avoir branché la télémétrie qui le voit.

Verdict

Si vous exposez des services web et que des identités AWS peuvent être lues depuis vos fichiers d’application, le risque décrit ici vous concerne directement, même sans faille dans votre code — car la charge n’est plus portée par un humain, mais par un agent qui automatise la chaîne complète. Les contre-mesures à appliquer maintenant sont celles que recommande Amazon : moindre privilège sur les rôles, IMDSv2 obligatoire, aucune clé de longue durée dans les configurations, et GuardDuty actif pour détecter les rafales d’appels et les identités qui alternent. Si vous êtes plutôt côté recherche, ce rapport est un jalon : l’IA agentique n’est plus un sujet de prospectives, c’est un outil déjà présent dans les incidents réels — et il fonctionne avec des identifiants légitimes volés, pas avec des exploits zero-day.

Références

• BleepingComputer — « Hackers use AntiFox AI agents in AWS credential-theft attacks » (Bill Toulas, 11 novembre 2026)
• The Hacker News — « AntiFox AI Pentesting Platform Linked to Attacks That Accessed AWS Production Secrets » (11 novembre 2026)
• ETTAYEB — ARTEX et la campagne Vapor Panda
• ETTAYEB — llmjacking et les agents autonomes