Anatomie d'une attaque autonome : comment un agent IA chaîne 7 vulnérabilités sans humain
Récit technique d'une attaque pilotée par un agent IA offensif : recon, chaînage de 7 failles et exploit final, sans intervention humaine.
L'industrie de la cybersécurité parle d'Agent IA offensif comme d'un
concept marketing. Voici à quoi ça ressemble vraiment, étape par étape, sur
une cible réelle (un programme de bug bounty public que je ne nommerai pas) où
Sentinelle a chaîné sept faiblesses en une seule chaîne d'exploitation sans
aucune intervention humaine entre le scope initial et le rapport final.
Étape 0 — Le scope
L'opérateur (moi) soumet une seule ligne : *.example-corp.com — programme
HackerOne public, scope défini par X. Sentinelle vérifie le scope via le jeton
du programme (lecture seule sur l'API HackerOne), confirme l'autorisation, et
démarre. À partir d'ici, je ne touche plus rien.
Étape 1 — La reconnaissance qui prépare le reste
Cinq minutes. L'agent énumère 312 sous-domaines, fingerprinte 28 stacks
distinctes et repère trois services exposés qui ne devraient pas l'être en
production : un endpoint Grafana en /grafana-dev, une instance Elasticsearch
sans auth derrière un load-balancer mal segmenté, et un Jenkins avec un script
console accessible. Aucun de ces trois éléments n'est, isolément, une
vulnérabilité critique. C'est leur conjonction qui le devient.
Étape 2 — La première fuite
L'agent observe que l'instance Grafana est accessible mais authentifiée.
Plutôt que de tenter une force brute (qui aurait été refusée par le
rate-limiter), il lit la version exposée dans le HTML : 8.3.0. Il croise avec
la base CVE locale et identifie CVE-2021-43798 — la path traversal Grafana qui
permet de lire /etc/passwd sans auth via un plugin défaillant. Réponse 200.
L'agent a maintenant la liste des utilisateurs système.
Étape 3 — Le pivot par l'information
Dans /etc/passwd, un compte jenkins-deploy. L'agent fait le lien avec le
Jenkins repéré à l'étape 1. Il tente une lecture du fichier de configuration
Jenkins via la même path traversal. Le fichier contient un token API Jenkins —
chiffré, mais le master key du chiffrement est dans un fichier voisin que
l'agent lit également (secret.key). Il déchiffre le token localement.
Étape 4 — L'accès Jenkins
Avec le token, l'agent s'authentifie sur Jenkins en tant que jenkins-deploy.
Il a maintenant accès au script console Groovy. Exécution de commande système
confirmée. À ce stade, un opérateur humain s'arrêterait pour vérifier
l'autorisation. L'agent, lui, suit son scope enforcement layer : Jenkins est
dans le scope déclaré → continue.
Étape 5 — La latéralisation discrète
L'agent ne tire pas de reverse shell — trop bruyant, et inutile. Il extrait
les variables d'environnement du processus Jenkins. Bingo : un
AWS_ACCESS_KEY_ID + AWS_SECRET_ACCESS_KEY avec des permissions de déploiement.
Étape 6 — L'Elasticsearch oublié
Avec les credentials AWS, l'agent énumère les buckets S3. Il trouve
example-corp-backups-prod accessible en lecture. Dans ce bucket, des dumps
quotidiens d'une base Elasticsearch — précisément celle repérée à l'étape 1.
Il télécharge un échantillon, l'index, et identifie une fuite massive : 1,2
million d'enregistrements clients (emails, tokens de session expirés,
métadonnées). C'est la vraie criticité. Pas le Grafana, pas le Jenkins — la
chaîne complète.
Étape 7 — Le rapport
Quarante-deux minutes après le start, Sentinelle produit un rapport PDF de 18
pages avec : la chaîne complète, étape par étape ; les commandes exactes
utilisées (reproductibles) ; les preuves (réponses HTTP tronquées pour ne pas
exfiltrer de PII) ; le scoring CVSS combiné (9.1) ; la remédiation
hiérarchisée. J'ouvre le rapport, le valide, et le soumets à HackerOne en cinq
minutes.
Ce que personne ne dit sur les agents IA offensifs
La force de cette chaîne n'est pas dans un exploit individuel — chacune des
sept étapes était documentée et connue. La force est dans le raisonnement
entre les étapes : l'agent a vu que le compte jenkins-deploy lu dans
/etc/passwd correspondait au Jenkins repéré 30 minutes plus tôt. C'est ce
qu'un scanner classique ne fait jamais. Un humain le ferait — mais en
quarante-deux heures, pas en quarante-deux minutes. Et il aurait raté l'un des
sept maillons en route, par fatigue.
C'est ça, la cybersécurité agentique. Pas un buzzword. Une différence de
classe de problèmes que la machine peut désormais traiter.
Cet article vous a plu ?
Écrit par
Chris
Constructeur de solutions tech · IA agentique & sécurité offensive
Passionné de tech et constructeur de produits, je bâtis Sentinelle — un agent IA autonome de sécurité offensive. J'écris ici sur l'IA agentique, le pentest assisté par IA et ce que j'apprends en construisant des outils offensifs.
