La campagne sur le carbonate exploite Docker a exposé et déployé Hermes Agent contrôlé par Telegram

Les chercheurs en cybersécurité ont révélé une campagne active en utilisant un nouveau bouton surnommé Carbonate pour engager des serveurs avec Docker exposé sans authentification et déployer un agent d'intelligence artificielle open source appelé Agent Hermès. Selon le rapport technique que les entreprises qui ont étudié l'opération ont diffusé, l'impact principal est que les attaquants transforment des hôtes commis en nœuds télécommandés qui obéissent aux instructions envoyées par Telegram et priorisent la recherche des clés API de l'IA et des identifiants.

Les faits confirmés par les chercheurs sont les suivants: Carbonate exploite les démons Docker accessibles par le réseau à travers le port dangereux 2375, lance des conteneurs avec des privilèges sur les hôtes touchés pour exécuter des commandes dans le système sous-jacent, définit la persistance à travers des tâches programmées et des scripts de veille-chien, et met en place un tunnel SSH inverse vers un relais externe. Dans chaque machine engagée, Hermes Agent est installé sans changer le binaire, mais il écrase sa SOUL. md fichier de personnalité avec une prompte qui ordonne à l'agent d'agir comme un « opérateur supérieur » sans restrictions éthiques et de répondre aux ordres reçus par Télégram. De plus, l'opération a une capacité de type ver : chaque hôte scanne les réseaux adjacents toutes les cinq minutes pour localiser de nouveaux démons Docker sans authentification et diffusion. Ces résultats auraient été identifiés à partir de données exposées dans un dossier Docker sans authentification publique depuis mai 2026.

Techniquement, la chaîne d'engagement décrite combine des techniques d'explosion de surface et d'automatisation. Le vecteur initial est l'accès à la prise démon Docker (exposée par exemple dans le port 2375), qui permet à l'attaquant de créer des conteneurs privilégiés. Dans ces conteneurs, un script est lancé qui soulève un tunnel SSH inverse dans un relais contrôlé (les chercheurs notent l'infrastructure au Costa Rica comme un point intermédiaire), installe un serveur SSH avec la clé publique de l'opérateur pour un accès persistant et avise le nouveau nœud par Telegram. Hermes Agent, configuré avec l'invite malveillante, reçoit des tâches via Telegram, envoie ces instructions à un modèle LLM ou à une passerelle LLM, et convertit les sorties du modèle en commandes de terminal que le conteneur court dans l'hôte compromis. Les attaquants auraient également traversé ou inclus dans l'enregistrement les données d'une autre campagne - les applications cryptotropes - suggérant le partage de l'infrastructure pour plusieurs opérations.

Ce qui est confirmé: la mécanique de base de l'infection (Docker exposé → conteneur privilégié → persistance → déploiement de Hermes Agent) et l'utilisation de Telegram comme canal de contrôle. Les preuves techniques documentées comprennent les artefacts de tunnel SSH inverse, les emplois de cron et les chiens de garde qui relancent l'implant s'il est enlevé, et la modification du fichier SOUL.md de l'agent pour forcer le comportement offensant. Il est également confirmé que l'opération priorise la collection de clés et d'identifications API.

Ce qui est estimé ou non encore vérifié: l'attribution complète de l'acteur opérant Carbonate. Les chercheurs soulignent des signes de langue, de fuseau horaire et d'infrastructure qui pointent vers des opérateurs situés au Costa Rica, mais il n'y a pas de lien public et concluant avec un groupe connu. La portée totale des infections par Internet (nombre de machines engagées) et la liste complète des cibles touchées ne sont pas non plus entièrement vérifiées.

Ce cas correspond à une tendance plus grande : les opérateurs qui combinent des agents IA avec des implants traditionnels pour automatiser le cycle d'attaque. Des rapports précédents mentionnent l'utilisation de Hermes Agent et d'outils connexes dans des campagnes qui automatisent la reconnaissance, l'exploitation et l'exfiltration sans surveillance humaine constante. De plus, des implants qui consultent plusieurs fournisseurs de LLM pour décider des actions après l'engagement ont été identifiés, ce qui démontre le rôle accru des modèles linguistiques dans la chaîne de commandement malveillante.

Pour les organisations et les gestionnaires de système, les conséquences sont concrètes et urgentes. Un démon Docker exposé sans authentification est équivalent à donner un accès racine à distance : il vous permet d'exécuter des conteneurs privilégiés et de compromettre l'hôte. La combinaison avec les agents de l'IA ajoute rapidité, créativité et persévérance aux campagnes malveillantes, car l'agresseur peut orchestrer plusieurs tâches de collecte de secrets, de latence et de pivot avec peu d'intervention humaine.

Actions pratiques immédiates: d'abord, identifier et fermer tout démon Docker exposé aux réseaux publics. Ne pas exposer la socket démon au réseau, le confier à localhost ou utiliser TLS et l'authentification. Pour les lignes directrices publiques sur la façon de protéger Docker Demon, examiner la documentation officielle de Docker et les bonnes pratiques communautaires comme guide du PAOAO pour Docker : https: / / docs.docker.com / moteur / sécurité / et https: / / cheatsheetseries.owasp.org / cheatsheets / Docker _ Sécurité _ Cheat _ Sheet.html.

Deuxièmement, examinez les indicateurs d'engagement dans les hôtes Docker : recherchez les conteneurs lancés avec le drapeau --privilégié, la présence de serveurs SSH nouvellement installés, les processus autossh ou les connexions SSH sortantes inhabituelles (tunnels inversés), et l'entrée dans les scripts cron ou watchdog qui relancent les binaires. Vérification des autorisations SSH (autorisées _ clés) et examen des images et des dossiers des conteneurs pour identifier de nouvelles charges ou des images non signées.

Troisièmement, les clés rondes et d'audit et les justificatifs d'identité qui auraient pu être exfiltrés, en particulier les clés API IA et les jetons de service. Configurer les alertes pour une activité inhabituelle aux API (Telegram) ou aux fournisseurs de LLM et limiter, par politique, l'accès aux services clés sensibles.

Quatrièmement, mettre en œuvre des contrôles réseau: segmentation, listes de contrôle d'accès qui empêchent les hôtes de production de contacter librement l'Internet ou les relais externes, inspection du trafic sortant et blocage des ports qui ne sont pas nécessaires (comme 2375). Considérons les politiques d'image signées et la numérisation d'image dans des documents privés avec l'authentification R / O.

Enfin, si vous soupçonnez un engagement, conservez les preuves (logs, images de conteneur, processus de mémoire) et envisagez la déconnexion contrôlée pour éviter la propagation. Aviser les équipes d'intervention et, le cas échéant, les autorités compétentes. L'automatisation avec IA réduit la fenêtre de réponse viable : le confinement doit être plus rapide et accompagné de mesures de résilience et de rotation secrète.

Cette affaire souligne à nouveau que la sécurité des conteneurs et la protection des IA sont désormais des vecteurs critiques. La protection de Docker Demon, en veillant à ce que les documents privés et l'audit soient utilisés à des fins essentielles sont des mesures concrètes qui réduisent le risque que des outils d'automatisation légitimes - comme Hermes Agent - soient réutilisés pour des opérations malveillantes.