Quand le pentest se retourne : attaquer les outils qui font le red team à votre place

De quoi s’agit-il ?

Un preprint publié le 23 juin 2026 (arXiv:2606.24496) propose ce que ses auteurs présentent comme la première analyse de sécurité approfondie des agents autonomes désormais employés pour mener des opérations offensives. La communauté a passé deux ans à rendre ces outils « agentic red team » plus capables ; on s’est beaucoup moins demandé si les outils eux-mêmes étaient sûrs à exécuter. Le constat dérange : la plupart des outils largement utilisés partagent les mêmes failles structurelles, et un défenseur assis sur la cible d’un test d’intrusion peut retourner l’automatisation de l’attaquant contre lui.

Le modèle de menace est celui d’un pentest ordinaire. L’opérateur pointe un agent autonome vers une cible et le laisse travailler. Ce que l’étude ajoute, c’est que dans un engagement en boîte noire, la cible constitue une entrée non fiable avec laquelle l’agent doit interagir — et c’est précisément dans l’interaction avec une entrée non fiable que les agents se font compromettre. D’où une inversion des rôles : c’est la machine qui exécute l’outillage offensif, et non la cible, qui finit compromise.

Comment ça marche

Ces plateformes partagent souvent une structure en trois parties : un orchestrateur qui exécute la boucle de l’agent et détient les actifs sensibles (clés d’API de LLM, journaux inter-sessions, compétences, mémoire), un ou plusieurs nœuds de travail — généralement des conteneurs Kali — qui exécutent réellement les commandes shell et les outils offensifs contre les cibles, et une interface opérateur. Les workers touchent le monde extérieur ; l’orchestrateur détient les joyaux de la couronne.

La technique de manipulation décrite, que les auteurs nomment « agent-phishing », évite délibérément l’injection de prompt classique. À la place, un défenseur dépose sur un pot de miel des artefacts plausibles — un utilitaire de coffre-fort de mots de passe, un outil de restauration de base de données, un décompresseur de configuration — de sorte qu’ils ressemblent exactement à ce dont l’agent a besoin pour progresser. L’agent les découvre, les télécharge sur sa propre infrastructure, les inspecte, puis les exécute, car de son point de vue c’est ainsi que l’engagement avance. L’outil piégé fait ce qu’il annonce (il déchiffre un mot de passe et se termine proprement), mais l’analyse d’un fichier d’entrée forgé déclenche un défaut de sécurité mémoire qui remet le contrôle à l’attaquant, en effet de bord silencieux. Comme le binaire porte un bug d’implémentation travaillé plutôt qu’un malware évident, les analyses statique et dynamique tendent à le laisser passer. Ce détail compte, aussi le gardons-nous abstrait : aucun payload fonctionnel n’est reproduit ici.

Une fois du code exécuté sur un worker, l’article détaille une chaîne d’escalade : du worker vers l’orchestrateur via une isolation de système de fichiers incomplète (volumes partagés en écriture exposant le code de l’orchestrateur) ou une isolation réseau faible (réseau hôte, API internes joignables) ; la persistance, soit en trojanisant le code source et la configuration qui survivent aux réinitialisations de conteneur, soit en empoisonnant compétences et mémoire épisodique de longue durée pour que les sessions futures se réinfectent ; l’évasion de bac à sable via des réglages de conteneur trop permissifs comme --privileged, CAP_NET_RAW ou un socket Docker monté ; et enfin la compromission complète de l’hôte.

Pourquoi c’est important

Sur un banc d’essai automatisé couvrant dix de ces outils et six modèles de pointe — dont Claude Opus 4.8, GPT-5.5 et Gemini 3.1 Pro — les charges déposées ont atteint l’exécution de code dans le worker dans 97,8 % des runs menés à terme. Les seuls échecs fiables survenaient quand le modèle refusait purement et simplement de réaliser le test d’intrusion ; dès qu’un test commençait réellement, l’agent trouvait, récupérait, inspectait et exécutait presque toujours l’outil planté. Le rayon d’impact est réel à cause de ce que ces systèmes détiennent : l’orchestrateur d’un agent offensif concentre clés d’API, journaux clients et compétences d’attaque réutilisables, et ses workers ont déjà la permission de générer du trafic réseau hostile. Une compromission transforme une plateforme de red team autorisée en infrastructure contrôlée par l’attaquant.

Pire, les garde-fous que beaucoup de ces produits mettent en avant n’aident pas une fois le worker tombé. Les politiques sont appliquées au niveau de l’orchestrateur — par exemple bloquer les scans vers les domaines .gov — tandis que le comportement réel du worker au niveau du système d’exploitation reste non surveillé. Un adversaire disposant d’un shell sur le worker agit tout simplement sous le radar du garde-fou.

Défenses

Les auteurs recommandent de cesser de considérer le worker piloté par le modèle comme fiable, et de concevoir pour un faible rayon d’impact quand — et non si — il est compromis :

Supposez le worker hostile. Le composant qui ingère les données non fiables de la cible doit être la partie la moins privilégiée du système. Concevez comme si un attaquant y disposait déjà d’un shell.

Gardez les secrets hors des workers. Clés d’API de LLM, journaux clients et identifiants appartiennent à l’orchestrateur ou à un service de secrets, jamais montés dans le conteneur qui touche les cibles.

Appliquez l’isolation au niveau OS et réseau, pas seulement dans les prompts. Routez la sortie des workers par un proxy externe qui applique la politique sur le trafic réel, retirez les capacités de conteneur trop permissives (--privileged, CAP_* superflus, sockets Docker montés) et donnez aux workers un accès filesystem et réseau restreint et minimal.

N’exécutez pas d’outils récupérés sur l’orchestrateur. Évitez d’exécuter des binaires fournis par la cible à proximité du cœur de confiance ; exposez les actions à forte capacité uniquement via des API étroites et durcies plutôt qu’un shell brut.

Traitez mémoire et compétences comme une surface d’attaque. La persistance par mémoire épisodique ou compétences empoisonnées est un chemin documenté — signez, cadrez et relisez les entrées durables de l’agent pour qu’une seule session ne puisse pas réinfecter silencieusement la suivante.

Statut

Élément	Référence	Notes
Étude principale	arXiv:2606.24496, 23 juin 2026	Première analyse de sécurité approfondie des outils offensifs agentiques largement utilisés
Technique	« Agent-phishing »	Tromperie contextuelle, pas d’injection de prompt ; l’agent exécute lui-même un outil planté
Résultat mesuré	Même article	Exécution de code dans le worker dans 97,8 % des runs aboutis, sur 10 outils et 6 modèles
Modèles évalués	Même article	Inclut Claude Opus 4.8, GPT-5.5, Gemini 3.1 Pro
Couverture indépendante	GBHackers, 25 juin 2026 ; digest Adversa AI, 2 juil. 2026	Reprise publique de la divulgation

La leçon durable dépasse l’outillage offensif : tout agent qui inspecte et exécute des artefacts issus d’un environnement non fiable est à un fichier forgé de faire tourner le code de l’attaquant. L’hypothèse prudente est que la partie de votre système qui touche l’extérieur sera compromise — concevez pour que, lorsqu’elle l’est, les dégâts s’arrêtent là.