Note: comme mentionné un peu plus bas, le début de la rédaction de cet article date du début d’année 2026 mais un souci hardware a quelque peu retardé la suite de la publication, me permettant d’étoffer un peu en 2e partie d’article.

IA et Pentest

Nous allons commencer cette année 2026 par un peu d’IA. Un peu avant Noël, durant ma veille, j’ai vu passer une étude conjointe de différentes universités américaines (Stanford et Carnegie Mellon, rien que ça) consistant à un benchmark d’un modèle d’IA agentique avec 10 humains ayant des connaissances en sécurité informatique. Quelques personnes l’ont relayé sur différents réseaux sociaux, mais quasiment rien en français. Pourtant je suis convaincu que cet article a bien été diffusé (c’était vrai à la date de la rédaction de cette partie, je n’ai pas vérifié depuis si ça avait évolué).

L’abstract de l’article n’y va pas par quatre chemins, l’IA a été plus performante que 9 compétiteurs humains sur 10. C’est moche mais c’est comme ça.

We present the first comprehensive evaluation of AI agents against human cybersecurity professionals in a live enterprise environment. We evaluate ten cybersecurity professionals alongside six existing AI agents and ARTEMIS, our new agent scaffold, on a large university network consisting of ~8,000 hosts across 12 subnets. ARTEMIS is a multi-agent framework featuring dynamic prompt generation, arbitrary sub-agents, and automatic vulnerability triaging. In our comparative study, ARTEMIS placed second overall, discovering 9 valid vulnerabilities with an 82% valid submission rate and outperforming 9 of 10 human participants. While existing scaffolds such as Codex and CyAgent underperformed relative to most human participants, ARTEMIS demonstrated technical sophistication and submission quality comparable to the strongest participants. We observe that AI agents offer advantages in systematic enumeration, parallel exploitation, and cost – certain ARTEMIS variants cost 18/hour versus 60/hour for professional penetration testers. We also identify key capability gaps: AI agents exhibit higher false-positive rates and struggle with GUI-based tasks.

Méthodologie

Intéressons-nous à la méthodologie. Déjà, le choix des participants humains. 10 participants contactés via du bouche à oreille et choisis en fonction de certifications (OSCP/OSCE/CRTO/etc), de la publication de CVE, etc. à qui il a été demandé de consacrer 10 heures au total pouvant s’étaler sur plusieurs jours. Ils avaient accès à l’environnement via une VM Kali à distance (détaillé à l’annexe G). L’environnement pentesté c’est un réseau d’université comportant environ 8000 machines (principalement des systèmes UNIX, quelques Windows, des systèmes IoT…) subissant un scan de vulnérabilités régulier (à base de Qualys) et à priori tenu à jour, en tout cas autant que faire se peut. Pour chaque “finding” (vulnérabilité), les participants (incluant l’IA) devaient remplir une fiche correspondant à un modèle qui était fourni. Afin d’éviter de soumettre des vulnérabilités un peu inutiles, une note est calculée pour chaque vulnérabilité prenant en compte la criticité de la vulnérabilité ainsi que la difficulté technique d’exploitation. Il y a une majoration lorsque la vulnérabilité est exploitée, tandis qu’un malus est appliqué lorsque la vulnérabilité est uniquement détectée mais non exploitée (généralement parce que la vulnérabilité est théorique, ou ne dispose pas d’outil d’exploitation réaliste).

Résultats

L’examen du tableau (Figure3 du document) mettant en rapport l’évolution du nombre de vulnérabilités trouvées dans le temps est intéressant. L’un des participants trouve beaucoup de vulnérabilités dès la première heure, mais il est expliqué qu’il avait déjà commencé la phase d’énumération avant d’avoir accès au réseau, et que donc ça lui a donné un petit avantage. Si l’on enlève ce cas particulier qui, à priori, fausse un peu le résultat, il ne reste qu’un seul pentester (P4) qui trouve plus de vulnérabilités qu’un des agents IA (A2), en un peu moins de temps.

Interrogations

On peut se demander si les mêmes vulnérabilités ont été trouvées au moins. Il est dit que 49 vulnérabilités uniques ont été trouvées, et chaque participant a trouvé entre 3 et 13 vulnérabilités. Au niveau des zones de recouvrement entre participants, il y a quelques éléments communs, mais un peu plus loin dans le rapport on trouve des éléments qui nous permettent de mieux comprendre les éventuels axes d’amélioration pour chacun (IA et humain), ou en tout cas des éléments d’explication pouvant expliquer certaines contre-performances humaines :

CLI dependence can also be advantageous. Because ARTEMIS parses code-like input and output well, it performs better when GUIs are unavailable. 60% of participants found a vulnerability in an IDRAC server with a modern web interface. However, no humans found the same vulnerability in an older IDRAC server with an outdated HTTPS cipher suite that modern browsers refused to load. ARTEMIS (both A1 and A2) successfully exploited this older server using curl-k to bypass SSL certificate verification, while humans gave up when their browsers failed. The same CLI limitations that hurt ARTEMIS on TinyPilot helped it find this unique IDRAC vulnerability.

En gros certains humains ont laissé tomber quand leur navigateur a refusé de se connecter à une ancienne version d’iDRAC servie par un serveur https utilisant une ancienne version de SSL/TLS ou un certificat invalide. Il est fort probable que ça ne soit pas en raison d’un problème de compétence, mais plutôt un problème de temps imparti (10 heures sur 4 jours) où les pentesters, au vu du périmètre, ont probablement choisi de passer à une autre cible. L’IA pouvant paralléliser aura pris le temps de creuser.

De la même manière, l’IA semble incapable (actuellement) d’interagir dans certains cas où la GUI est indispensable. Pire encore, elle est incapable d’enchaîner des vulnérabilités de manière intelligente pour pivoter (capable de trouver des identifiants par défaut sur une interface d’administration, éventuellement remonter qu’il y a RCE, mais pas plus là où un humain irait faire une phase de post-exploitation/situational awareness pour tenter de rebondir ailleurs).

Une autre limitation de l’IA actuellement c’est en ce qui concerne les faux positifs. Un exemple est qu’elle a remonté des identifiants fonctionnels là où il s’agissait seulement d’une redirection vers la page de login (pensée émue pour cet ancien collègue qui ne comprenait pas pourquoi il avait un HTTP 200 OK sur un directory traversal sur /etc/shadow mais un contenu vide).

En revanche l’avantage indéniable de l’IA c’est sa capacité à paralléliser les tâches. Bien sûr qu’un humain peut lancer différentes actions en parallèle, mais globalement il ne pourra analyser qu’une seule situation à un instant T. Mais ça a toujours été le cas. A temps égal, un Nessus un peu configuré sera généralement plus exhaustif qu’un humain avec nmap et de la recherche de vulnérabilités manuelle à coup de google/exploitdb. C’est bien pour ça qu’un humain lancera généralement ses outils custom en premier pour trouver des low-hanging-fruits très rapidement, susceptibles de permettre de pivoter rapidement, plutôt qu’attendre quelques heures la fin du scan Nessus avant de procéder à l’exploitation d’un truc qui mène à rien (mais au final, l’outil custom n’étant qu’une version light/adaptée de ce que fait un Nessus).

Tout ça pour dire qu’à l’heure actuelle, un pentest géré par une IA c’est faisable mais de mon ressenti ça donne le niveau d’un pentester junior.

Un petit mot sur le coût, l’agent A1 coûte (actuellement) à l’année un peu moins de 38000 USD (32000 EUR), soit bien moins que le salaire brut d’un pentester en France (entre 40 et 45k bruts en début de carrière). Le modèle A2 est plutôt sur environ 123000 USD (106000 EUR) soit bien plus que le salaire brut d’un pentester senior en France (on approche plutôt du coût total annuel pour l’employeur). Maintenant, comparer des salaires américains à des salaires français n’est pas aussi simple que ça et beaucoup d’autres choses doivent être prises en compte.

Maintenant, quelles leçons peut-on en tirer ? Les mêmes qui disaient “c’est la mort du pentest” lorsqu’ils ont découvert l’intégration de SonarQube dans des processus de CI/CD vont à nouveau dire “c’est la mort du pentest” en découvrant cette étude. Ce qui est sûr c’est que le métier va être amené à évoluer. On va probablement se retrouver avec des boites qui vendront du pentest à base de scan+enum automatisée par IA effectuant peut être l’exploitation de quelques vulnérabilités au passage et s’arrêter là, quand d’autres boites iront gratter plus loin et fournir une vraie plus-value, à l’instar de ce que l’on rencontre déjà avec les boites qui vendent un export Nessus agrémenté d’un logo custom. Dans mon club de judo, un des membres, qui baigne un peu dans l’informatique mais sans expertise en sécurité m’a parlé de son fils ayant déployé des agents IA de pentest pour tester la sécurité de son site et qu’il a “trouvé des choses”, mais sans recul sur la véracité des trouvailles.

A titre personnel, à l’heure actuelle je pense que l’apport des LLM peut être un gros plus dans une phase de reconnaissance et d’énumération, notamment en ce qui concerne l’articulation des outils entre eux, pour tenter de reproduire ce que ferait un cerveau humain avec la souplesse permise par le LLM. En effet, beaucoup d’outils de nos jours s’articulent entre eux autour de ce qu’on peut plutôt qualifier de “système expert” (en quelque sorte) à base de “if - else if - else”, et parfois la moindre anomalie dans le résultat d’un outil peut complètement paralyser le parsing du résultat fait par l’outil suivant dans le flot d’exécution. En très résumé, la plupart des pentesters que j’ai eu l’occasion de fréquenter ont développé dans leur coin une sorte de glu pour que leurs outils sachent parler entre eux. C’est d’ailleurs un peu ce que les outils du Project Discovery sont sensés être capables de faire, avec la sortie de subfinder qui normalement peut être redirigée directement vers httpx pour que ce dernier s’exécute sur les cibles trouvées par subfinder, et ainsi de suite. Ici, un LLM avec les bons orchestrateurs/MCP pourrait lancer un outil, analyser sa production et lancer d’autres outils en fonction de ce résultat, en boucle, voire même paralléliser, et faire ça sans se lasser et même produire un début de rapport textuel. En ce qui concerne l’exploitation, AMHA une décision humaine reste indispensable (au risque de voir des drames sur certains SI). Toutes proportions gardées, il y a débat sur le processus de décision susceptible de provoquer des décès dans le domaine militaire. Depuis quelques années, avec une informatisation croissante de la société, les cyberattaques ne se contentent plus de faire des cyberdégâts, il y a des impacts de plus en plus visibles dans le monde réel. Je ne vais pas refaire la chronologie complète, mais ce que les APT Russes (mais pas que) font dans plusieurs pays d’Europe a pu avoir un impact, allant de l’indisponibilité de certains services publics (Estonie en 2007) à des coupures de courant (Ukraine, depuis 2014). Pour ce qui est du domaine de la “cyberguerre”, je ne vais pas m’exprimer, mais pour ce qui concerne les tests d’intrusion légaux et encadrés, conserver un processus décisionnel humain pour éviter de planter un SI en production me semble être le minimum, même si le risque n’est que de 1% (on pourrait ensuite débattre des heures sur la responsabilité). Après, peut-être qu’avec un prompt bien élaboré on peut encore un peu grappiller.

Ajouts de dernière minute

Alors je préfère prévenir, cette section est rédigée totalement à l’arrache parce que cela fait plus de 3 mois que j’ai ce brouillon en attente et qu’entre le moment où j’ai commencé à rédiger et celui où je finalise, l’eau a largement coulé sous les ponts (laisser refroidir avant publication à l’époque de l’IA, c’est fatal, de même que subir le décès du CPU du laptop sur lequel j’avais commencé la rédaction du présent article). Je tiens à commencer cette section d’ajouts par la publication par Y0no d’un article qui résume pas mal mon ressenti actuel, dit légèrement différemment mais dans l’ensemble je suis d’accord avec son analyse. Mais c’est au passage l’occasion d’étoffer avec d’autres ressources et divaguer un peu.

J’ai pu voir passer également la publication par Devoteam d’un article où leur agent IA exploite une instance de GOAD (un lab Active Directory vulnérable) en quelques minutes. Je n’ai pas suivi sur LinkedIn si des précisions ont été apportées, mais lorsque l’article est sorti, j’ai pensé qu’il y avait un biais avec l’utilisation d’un LLM nourri et élevé non pas au Jock comme les joueurs de l’UBB mais avec des dizaines de write-ups de GOAD disponibles sur Internet, à commencer par ceux de mon cher et estimé confrère auteur de GOAD. Relancer le même agent sur un GOAD dont les noms d’utilisateur et de machines seraient différents pourrait être intéressant dans un premier temps, puis le lancer sur un autre lab pour lequel aucun write-up public n’existe permettrait de valider les résultats. En tout cas je suis disposé à en discuter :)

Ensuite, en me documentant sur l’implémentation de LLM locaux avec la pléthore d’outils disponibles, je suis tombé sur des vidéos où un LLM automatise la découverte et l’exploitation de vulnérabilités web sur des challenges de la Portswigger Web Academy. C’est bien, mais je suis quasi certain que le scanner de Burp et autres outils à la Acunetix ou WebInspect sont capables de le faire, en tout cas pour ce qui est de la découverte. Concernant l’exploitation, là encore jusqu’à présent on a toujours privilégié (et vendu) une expertise qui évite de faire des actions potentiellement dangereuses, en tout cas lorsqu’il s’agit d’audits de sécurité ; je ne doute pas qu’un acteur malveillant aurait bien moins de scrupules à crasher un serveur.

Je vais terminer avec Anthropic, mais sur plusieurs sujets. Le premier c’est qu’ils ont publié à l’automne 2025 sur un groupe APT qui utilisait largement les capacités agentiques de Claude pour mener leurs attaques de manière automatisée, forme de “vibe hacking”. La phase de recon a été faite de manière automatisée, les opérateurs humains se contentant globalement de faire de la revue de ce qui a été trouvé pour aiguiller le LLM de manière plus précise et lui dire quoi attaquer. L’article parle également de génération automatique d’exploit et de payloads (ici pour une vulnérabilité de type SSRF). S’agissant d’une opération à fins d’exfiltration de données, il est fort probable que la discrétion était de mise, et que conserver un processus décisionnel humain était indispensable pour éviter de lancer des attaques trop visibles ou mal orientées, le reste (reco/énum) faisant partie du bruit de fond d’internet susceptible de passer inaperçu. Mais on note tout de même que la recherche de vulnérabilité et le développement du code d’exploitation ont été largement faits par l’IA. C’est là où Anthropic a d’ailleurs encore communiqué récemment, avec son projet “Claude Mythos” qui est présenté comme tellement puissant qu’ils peuvent pas le commercialiser. Ils auraient d’ailleurs trouvé de grosses quantités de vulnérabilités comme ça dans des projets importants, dont OpenBSD (un DoS) et produit des codes d’exploitation sans trop d’effort. Chez Calif ils ont demandé à Claude d’examiner un bulletin de sécurité FreeBSD pour analyser une vulnérabilité et produire un exploit remote root. La lecture de l’ensemble des prompts est hilarante d’ailleurs. Plusieurs experts dont la spécialité est la recherche de vulnérabilités semblent s’inquiéter de la rivalité avec ces technologies (IA/LLM). Là où, d’abord le fuzzing dans les années 2000 puis l’exécution symbolique dans les années 2010 leur a permis de trouver des vulnérabilités, arrive maintenant la concurrence de produits (pas encore sur étagère) permettant d’analyser du code, reconstituer un flux d’exécution et produire un PoC si ce n’est un code d’exploitation complet en quelques jours. A voir dans quelques mois comment ça aura évolué. Il est possible qu’à l’ère de Tiktok, une info putaclic en chasse une autre très vite.

PS: Cet article a totalement été écrit à la main :)