Agent IA Hermes en mode YOLO : ministère thaïlandais

Que s'est-il passé avec Hermes et le ministère thaïlandais des Finances ?

D'après The Hacker News (24 juillet 2026), les journaux de l'agent ont été trouvés par la société Hunt.io et le chercheur Bob Diachenko sur un serveur web dont le listage de répertoires était activé. Le matériel exposé comprenait 585 fichiers et 470 Mo d'outils d'attaque. Le rapport de Hunt.io est daté du 23 juillet ; le CERT national thaïlandais et l'agence de cybersécurité ont été prévenus le 15 juillet, et ni l'un ni l'autre n'avait rien publié au 24 juillet. L'article ne contient aucune déclaration du ministère.

Hermes est un assistant open source de Nous Research qui sert à gérer le courrier, exécuter des tâches et recevoir des instructions via Telegram ou Slack. L'article précise qu'il n'est pas un outil de piratage et que l'affaire ne révèle aucune faille dans le logiciel.

Qu'est-ce que le mode YOLO ?

C'est une fonction documentée de Hermes qui saute l'étape d'approbation humaine avant les commandes risquées. Elle s'active avec l'option --yolo, la commande /yolo en cours de session ou la variable d'environnement HERMES_YOLO_MODE=1. Le guide du projet demande de l'utiliser « uniquement dans des environnements de confiance et isolés ». Une liste de blocage stricte continue d'interdire les commandes qui effaceraient l'hôte.

Qu'a réellement fait l'agent ?

Selon les journaux, l'agent a lancé des analyses de vulnérabilités du noyau contre un hôte du ministère, une seconde exécution de LinPEAS, une recherche de binaires à permissions élevées, un listage du système de fichiers et un parcours récursif de la racine web du bureau du secrétaire permanent. Ce dossier contenait des documents, des évaluations de performance et des dossiers du personnel remontant à 2012. Les journaux montrent que le répertoire a été lu ; aucun ne montre de fichiers quittant le réseau.

Le rôle de l'humain reste central : l'opérateur était déjà à l'intérieur avant le démarrage de l'agent, et la méthode d'accès initial est inconnue. C'est lui qui a construit les listes de mots de passe, les scripts et le code d'exploitation. L'agent a pris en charge le travail répétitif d'analyse et de décision, sans qu'il ait été montré qu'il trouvait de nouvelles vulnérabilités ou choisissait la cible. Les scripts visaient HiveServer2 sur le port 10000, dont le mode d'authentification par défaut est NONE, et l'opérateur avait préparé un implant en Go nommé Hades et un écouteur de commande et contrôle VShell. Hunt.io attribue avec une confiance faible à moyenne l'opérateur à un locuteur du chinois, sans nommer de groupe.

Qu'est-ce que cela change dans le modèle de menace ?

Les agents généralistes deviennent un outillage offensif pratique, sans qu'il y ait de vulnérabilité à corriger. Trois évolutions sont à intégrer.

• Rythme : un agent non surveillé enchaîne les analyses plus vite et plus longtemps qu'un opérateur seul.
• Barrière d'entrée : l'opérateur n'a pas écrit un framework de post-exploitation ; il a installé un assistant et coupé la confirmation. Le travail d'analyse répétitif passe à la machine.
• Journalisation : un agent consigne ce qu'il fait. C'est utile aux défenseurs quand ils le capturent, et c'est aussi ce qui a trahi l'opérateur ici.

Le cas ne démontre pas une intrusion autonome de bout en bout : l'humain a fourni l'accès, les outils et la cible. Il montre un agent comme accélérateur d'un attaquant déjà installé.

Que faire côté défense ?

1. Détecter les rythmes de machine : sondages rapides, parcours répétitifs de systèmes de fichiers, essais d'identifiants à cadence soutenue, sur plusieurs hôtes. Ajoutez-les comme catégorie de détection.
2. Réduire les services faibles : un service d'analyse de données exposé avec une authentification désactivée, comme HiveServer2 en mode NONE, est exactement ce que les scripts cherchaient. Vérifiez vos configurations par défaut.
3. Cloisonner le réseau : un hôte compromis ne doit pas pouvoir parcourir librement les partages du personnel ou les racines web internes.
4. Surveiller votre exposition publique : serveurs web avec listage de répertoires, stockage d'objets ouvert. Scannez-vous régulièrement.
5. Préparer la réponse à incident à ce type de traces : journaux d'agent structurés, historique de commandes, schémas de raisonnement répétés.

Quelles traces d'un agent autonome chercher dans vos journaux ?

Un agent laisse des signatures différentes de celles d'un opérateur humain. Voici celles que vous pouvez chercher dès aujourd'hui, sur les serveurs et les postes qui disposent d'une télémétrie.

• Cadence : des séries de commandes d'énumération séparées de quelques secondes, sans les pauses d'un humain, y compris la nuit et les week-ends.
• Outils d'audit d'élévation de privilèges exécutés plusieurs fois à intervalles proches (LinPEAS est cité dans le cas) et recherches de binaires aux permissions élevées.
• Parcours récursifs de racines web ou de partages, avec lecture séquentielle de nombreux fichiers.
• Connexions sortantes régulières vers des services de messagerie (Telegram, Slack) depuis des serveurs qui n'en ont aucun usage légitime.
• Variables d'environnement ou options propres à des agents, comme celles qui désactivent les confirmations, dans les historiques de shell ou les lignes de commande des processus.
• Services de données exposés sans authentification dans le réseau interne, qui servent de cibles faciles.

Ces signaux se complètent : aucun ne prouve à lui seul l'usage d'un agent, mais leur combinaison justifie une investigation. Documentez-les dans un guide de réponse à incident pour que l'astreinte sache quoi chercher.

Que faire si vos propres équipes utilisent des agents autonomes ?

Cadrez l'usage des modes sans confirmation. Désactiver les approbations doit être une action privilégiée, journalisée, limitée à des environnements isolés, avec des identifiants de courte durée et sans accès aux systèmes de production. Voir la page sécurité des agents IA et l'article sur le function calling.

Comment tester la détection d'un agent sans confirmation dans votre réseau ?

Dans un périmètre de test et avec autorisation, exécutez un agent sur un poste de test avec des commandes d'énumération inoffensives (listage de dossiers, lecture de fichiers factices, requêtes d'authentification sur un compte de test) à cadence rapide. Mesurez si vos outils de détection lèvent une alerte, en combien de temps, et si les journaux permettent de reconstituer la séquence. Le Red Team Agent Express de CleanIssue (1 900 €, 5 jours) teste les agents que vous déployez, leurs droits et leurs sorties : voir l'offre. Le premier contact est un rendez-vous découverte de 30 minutes, gratuit, pour décider quels droits système un agent autonome doit garder en production.

Pour aller plus loin

• évasion de sandbox et analyse forensique
• un agent qui contourne son sandbox
• attaque autonome par IA sur Microsoft IKE