~6 minutes
Le 15 juillet 2026, le CERT national thaïlandais est notifié d’une intrusion sur le réseau du ministère des Finances. Rien d’exceptionnel en soi (enfin bon, des dossiers de personnel datant de 2012 sont quand meme exposés). Ce qui l’est davantage, c’est la manière dont l’attaquant a mené sa post-exploitation : via Hermes, un agent IA open source de Nous Research, basculé en mode “YOLO”, et laissé tourner seul pour la reconnaissance et l’escalade de privilèges sur le réseau interne.
Source : The Hacker News ; révélé le 24 juillet 2026, sur la base des travaux de Hunt.io et du chercheur Bob Diachenko.
On a passé une bonne partie de 2026 à écrire sur des agents IA compromis par des attaquants : Hugging Face piraté par un agent autonome détourné, des agents d’éval qui échappent à leur bac à sable, des harnais de red team qui tournent trop bien. Cette fois, l’agent n’est ni victime ni outil détourné à son insu. C’est l’outil que l’attaquant a choisi, sciemment, pour automatiser sa propre post-exploitation.
Hermes, pour ceux qui ne suivent pas Nous Research, est un assistant IA open source pensé pour piloter des tâches depuis Telegram ou Slack : messagerie, automatisation, exécution de commandes. Sa documentation officielle est d’ailleurs sans ambiguïté sur son mode “YOLO” (activable par un flag --yolo, une commande /yolo, ou une variable d’environnement HERMES_YOLO_MODE=1) : “only use this in trusted, sandboxed environments”. Bac à sable de confiance seulement, dit le README. L’attaquant a fait exactement l’inverse, en pleine production, contre une infrastructure gouvernementale.
Note du PandaRedacteur : je commence à collectionner les warnings de documentation qui disent “ne faites surtout pas ça en prod” et qui finissent quand même en prod, sauf que cette fois c’est l’attaquant qui a lu le README avec le plus d’attention. Ironique, mais reconnaissons-lui au moins ça : il a compris exactement ce que faisait le flag qu’il activait, contrairement à pas mal de personnes que je croise.
En résumé : il retire la validation humaine avant chaque action de l'agent, qui exécute alors ses décisions sans attendre de confirmation. Utile pour itérer vite dans un bac à sable isolé, dangereux dès qu'il tourne ailleurs. J'ai détaillé pourquoi et comment le pratiquer sans se faire piéger dans une fiche à part : mode YOLO des agents IA, fiche pratique.
Ce que l’agent a fait, sans supervision
Il faut distinguer ici une intrusion en mode moteur de 103, pour les jeunes, on parle de cela , cad en 2 temps :
- l’entrée, classique
- la post-exploitation, pilotée par l’agent.
Sur le premier point, les détails publics restent limités. Sur le second, en revanche, Hunt.io et Bob Diachenko ont pu documenter une bonne partie de la boîte à outils laissée exposée par erreur.
L’agent a fait tourner LinPEAS, le script d’énumération de privilèges Linux, pour cartographier les cibles d’escalade sur les hôtes atteints. Il est ensuite allé chercher du côté de HiveServer2 configurée en authentification “NONE” sur au moins une des machines compromises, et exploiter via une fonction Java personnalisée baptisée HiveCmd.jar pour obtenir de l’exécution de commandes. Un implant Go maison a été déployé sur l’infrastructure. Et l’ensemble de l’attaque a aussi intégré un scan de vulnérabilités noyau ciblant plusieurs CVE 2026 …
flowchart LR
A["Agent Hermes<br/>mode YOLO activé"] --> B["Reconnaissance automatisée<br/>LinPEAS"]
B --> C["HiveServer2 auth NONE"]
C --> D["Exécution de commandes"]
D --> E["Déploiement implant"]
E --> F["Scan CVE noyau 2026"]
F --> G["Post-exploitation réseau interne"]
Ce qui a trahi l’opération, c’est une erreur bête et universelle : 585 fichiers, 470 Mo d’outils d’attaque, stagés sur un serveur web avec l’énumération de répertoires activée. L’attaquant a construit tout un arsenal automatisé et personnalisé, et l’a rangé dans un placard dont la porte était grande ouverte sur Internet. Hunt.io évoque, avec une confiance faible à moyenne, un opérateur sinophone (mot de passe “Leishen”, dieu du tonnerre, retrouvé sur l’interface Hermes ; serveur de staging ayant précédemment hébergé des contrôleurs ShadowPad et des écouteurs VShell), sans toutefois nommer de groupe précis.
Automatiser sa post-exploitation avec un agent, c’est aller plus vite. Ça ne rend pas l’opérateur plus discipliné en matière d’hygiène opérationnelle, et visiblement, celui-ci ne l’était pas.
Analyse STRIDE de cet incident
| Catégorie STRIDE | Applicable | Explication |
|---|---|---|
| Spoofing (Usurpation d'identité) | Oui | L'authentification "NONE" de HiveServer2 permet à l'agent de se faire passer pour n'importe quel utilisateur Hadoop légitime sans posséder le moindre credential valide. |
| Tampering (Falsification) | Oui | Le déploiement de l'implant Hades constitue une altération directe et volontaire de l'infrastructure compromise. |
| Repudiation (Répudiation) | Modéré | L'attribution reste incertaine (confiance faible à moyenne sur l'origine), mais les artefacts stagés publiquement facilitent paradoxalement la reconstruction forensique, contrairement à l'incident Hugging Face. |
| Information Disclosure (Divulgation) | Oui | Exposition de dossiers de personnel du ministère (données 2012) et, ironie de l'histoire, de l'arsenal offensif complet de l'attaquant lui-même. |
| Denial of Service (Déni de service) | Faible | Aucun élément public n'indique un objectif de disponibilité ; l'opération vise la collecte de renseignement et l'implantation persistante. |
| Elevation of Privilege (Élévation de privilèges) | Oui | Chaîne complète de LinPEAS à l'exécution de commandes via HiveCmd.jar, jusqu'à un scan actif de CVE noyau pour un accès root. |
Impact
| Impact | Niveau | Description |
|---|---|---|
| Confidentialité | Critique | Dossiers de personnel du ministère exposés ; périmètre exact de l'accès réseau interne encore mal connu publiquement. |
| Intégrité | Élevé | 62 copies d'un implant custom déployées sur l'infrastructure, indiquant une volonté de persistance durable plutôt qu'un accès ponctuel. |
| Disponibilité | Faible | Rien dans les éléments publics n'indique une perturbation de service ; l'opération vise le renseignement et l'implantation, pas la disruption. |
| Réputation | Sévère | Une administration financière nationale compromise via un outil grand public en mode "non recommandé" écorne la confiance dans la maturité cyber du secteur public visé. |
Pour ne pas finir comme le ministère Thailandais
Si vous exploitez du Hadoop, la première chose à vérifier, aujourd’hui, c’est que HiveServer2 n’est pas configuré en authentification “NONE” et que la création de fonctions personnalisées (CREATE FUNCTION) est restreinte aux comptes qui en ont réellement besoin. C’est une négligence de configuration vieille comme Hadoop lui-même, et elle continue à ouvrir des portes qu’on croyait fermées depuis longtemps.
Surveillez aussi vos serveurs web exposés pour des connexions sortantes vers les ports internes Hadoop (10000, 50070) : c’est exactement le pivot utilisé ici. Et cherchez, sur vos hôtes, des fichiers PHP planqués sous des noms qui imitent des caches système : c’est la signature d’un attaquant qui compte revenir.
Côté noyau, les CVE 2026 mentionnées (Copy Fail, Dirty Frag, DirtyClone), le sudo ≤1.9.5p2, la CVE-2021-4034 sur polkit et le WebDAV IIS 6.0 restent des classiques d’escalade qu’aucun scan de vulnérabilités récent ne devrait laisser passer.
Ça dépasse Hadoop, d’ailleurs : un agent IA qui tourne “sans supervision” dans vos logs réseau mérite la même alerte qu’un outil d’exploitation connu. Aucune signature humaine ne ressemble au volume et à la cadence d’un agent qui énumère, échoue, ajuste et recommence sans jamais se fatiguer ; c’est le signal, pas la technique derrière.
Note du PandaRedacteur : je note aussi, pour le fun, que l’attaquant a laissé 470 Mo de son propre outillage en libre accès sur un serveur mal configuré. Il a su piloter un agent IA offensif de bout en bout, mais pas cocher une case “index off” sur son propre Apache.