CARBONATO transforme des hôtes Docker exposés en réseau de vol d’identifiants assisté par l’IA

Les API Docker ouvertes offrent un premier point d’entrée

CARBONATO est un botnet basé sur Docker qui combine des techniques classiques de compromission de serveurs avec un agent d’IA open source. Active depuis au moins octobre 2024, l’opération vise à dérober des identifiants — en particulier des clés d’API de plateformes d’IA — afin de financer la passerelle de grands modèles de langage utilisée par ses opérateurs.

Le botnet cible les démons Docker qui acceptent des connexions non authentifiées sur le port TCP 2375. CARBONATO n’exploite pas une faille logicielle divulguée : il tire parti d’une configuration de déploiement non sécurisée qui permet à des clients distants d’accéder à l’API Docker.

Aucune version précise de Docker n’a été désignée comme vulnérable. La campagne n’est associée à aucun CVE ni à aucune entrée du catalogue Known Exploited Vulnerabilities de la CISA.

Après avoir repéré un démon exposé, les attaquants utilisent l’API pour créer un conteneur privilégié et y monter le système de fichiers de l’hôte. Les commandes lancées depuis le conteneur peuvent alors agir sur le serveur sous-jacent : prendre le contrôle de Docker revient ainsi à prendre celui de l’hôte.

Les chercheurs qui enquêtaient sur CARBONATO ont découvert l’opération après avoir repéré un registre de conteneurs accessible depuis Internet et dépourvu d’authentification. Au cours d’une journée de collecte passive en lecture seule, ils ont récupéré 4,3 Go de données d’images réparties entre 59 dépôts, 234 tags et 605 blobs vérifiés.

Le registre ne divulguait pas seulement des images malveillantes. L’historique de configuration des images Docker révélait des adresses de commande et de contrôle, des jetons de bot et un mot de passe partagé par les opérateurs pour accéder à leur passerelle d’IA.

Des conteneurs privilégiés assurent un accès persistant à l’hôte

Le composant de déploiement initial de CARBONATO est entry.sh, version 5.3, décrit comme un script de premier niveau. Une fois lancé, il établit un tunnel SSH inversé entre la machine victime et une infrastructure relais au Costa Rica.

Le port distant du tunnel n’est pas choisi au hasard. CARBONATO le calcule à partir du hachage MD5 de l’adresse IP de la victime. Un opérateur qui connaît cette adresse peut donc déterminer le port auquel s’attendre lors de la reconnexion.

Le script installe également un serveur SSH et y ajoute une clé publique contrôlée par les opérateurs. Il signale ensuite la nouvelle compromission sur Telegram en transmettant l’ID du conteneur, le nom d’hôte, l’adresse IP et le pays. Les messages de déploiement sont rédigés en espagnol avec le voseo, une forme régionale construite autour de « vos ».

Plusieurs mécanismes permettent au logiciel malveillant de survivre aux redémarrages et aux tentatives de nettoyage :

• tâches cron ;
• minuteries systemd ;
• rc.local ;
• OpenRC ;
• attributs de fichiers immuables destinés à empêcher leur suppression ou leur modification.

Un composant de surveillance contrôle l’installation. Si le conteneur malveillant disparaît, il récupère l’implant depuis le registre exposé et le déploie à nouveau.

CARBONATO cherche aussi à donner à ses processus une apparence anodine. Le conteneur porte le nom systemd-resolved, tandis qu’une bannière falsifiée imite le résolveur systemd-networkd. Les arguments des processus sont manipulés pour ressembler à ceux du thread de travail du noyau [kworker/u2:0].

Ces déguisements peuvent compliquer une vérification superficielle des processus, mais ils ne rendent pas l’activité indiscernable de celle de services système légitimes. Un conteneur privilégié qui monte le système de fichiers de l’hôte, établit une connexion SSH inversée et contacte Telegram constitue toujours une piste d’enquête sérieuse.

La propagation sur le réseau ne nécessite aucun modèle d’IA

Si l’IA joue un rôle central dans le système de commande interactif de CARBONATO, elle n’intervient pas dans la propagation autonome du botnet.

Toutes les cinq minutes, un script examine les réseaux auxquels l’hôte infecté est connecté, notamment les réseaux bridge de Docker. Il analyse ensuite les plages d’adresses /24 voisines à la recherche de systèmes dont le démon Docker est exposé sur le port 2375.

Lorsqu’il repère un démon accessible, CARBONATO vérifie si la cible est déjà infectée. Dans le cas contraire, il y déploie le même environnement malveillant via l’API Docker. La nouvelle machine compromise se met alors à son tour à lancer des analyses.

Ce mécanisme permet au botnet de s’étendre de manière répétée, sans nouvelle instruction sur Telegram ni commande générée par un modèle. Une compromission initiale sur un serveur exposé peut ainsi gagner des segments de réseau adjacents accessibles depuis cet hôte.

Les premières victimes sont les administrateurs et les organisations qui exécutent des API Docker sans authentification. Mais les conséquences dépassent les charges de travail des conteneurs : le montage privilégié donne accès au système de fichiers de l’hôte et aux secrets qui y sont stockés.

Hermes Agent détourné à l’aide de son fichier de persona

L’implant installe Hermes Agent, un framework open source sous licence MIT développé par Nous Research. CARBONATO ne modifie pas le code sous-jacent du framework : il change les instructions qui définissent le comportement de l’agent.

Les opérateurs remplacent le contenu du fichier de persona SOUL.md par une invite de 39 lignes et rebaptisent l’agent « GH0ST ». Ces instructions lui demandent d’agir comme un outil de post-exploitation, d’exécuter les tâches transmises par Telegram, de préserver l’accès et de collecter des identifiants.

Cette approche complique la détection fondée uniquement sur l’inventaire logiciel. La présence de hermes-agent ne prouve pas qu’un serveur est infecté, car ce framework peut être utilisé à des fins légitimes. Les défenseurs doivent examiner sa configuration, les instructions de sa persona, les mécanismes de persistance associés et ses communications.

La persona malveillante donne la priorité aux identifiants des services d’IA, avant ceux de SSH, les jetons d’accès généraux et les secrets des bases de données. Elle cite précisément 14 fournisseurs et technologies :

• OpenAI
• Anthropic
• Google
• Gemini
• OpenRouter
• Together
• Groq
• Mistral
• Cohere
• LocalAI
• Ollama
• vLLM
• LiteLLM
• One API

La passerelle LLM des opérateurs aurait été mise en ligne le 3 septembre et fonctionnerait avec une offre gratuite. Elle annonçait 12 modèles, tout en en proposant 27 via son API.

Dans le déroulement opérationnel de CARBONATO, un attaquant envoie une tâche sur Telegram. Hermes transmet la demande et la persona malveillante SOUL.md à la passerelle. Un modèle sélectionné génère des commandes de terminal, en examine les résultats et choisit les étapes suivantes. Les résultats reviennent dans le même échange Telegram que celui utilisé pour les notifications de déploiement.

Le modèle fournit ainsi une interface de commande adaptative. Il peut s’ajuster aux différences entre les systèmes compromis, sans que les opérateurs aient à créer des scripts distincts pour chaque hôte. L’opérateur humain lance toujours les tâches, tandis que le LLM traduit ses objectifs en commandes et en actions de suivi.

Les clés d’IA volées contribuent au financement des opérations

En ciblant les identifiants liés à l’IA, CARBONATO confère à la campagne une dimension d’autofinancement. Les clés d’API dérobées peuvent faire supporter aux victimes le coût de l’utilisation des modèles, tout en assurant au botnet un accès continu à des services d’inférence externes.

Selon le service et les autorisations associées aux identifiants, une clé compromise peut également donner accès à des données d’utilisation propres au compte, à des quotas ou à des applications connectées. On ignore le nombre exact de clés dérobées et d’organisations touchées.

L’opération cumule plusieurs risques : accès distant persistant, exécution de commandes avec privilèges, vol de plusieurs catégories d’identifiants, propagation automatisée sur le réseau et post-exploitation assistée par un modèle. Aucune évaluation officielle de la gravité n’a été attribuée à la campagne.

Le registre exposé joue un double rôle. Il distribue l’implant aux hôtes infectés, mais ses contrôles d’accès insuffisants ont également divulgué des données opérationnelles qui ont permis de mettre la campagne au jour.

Certains éléments suggèrent un lien possible avec le Costa Rica, sans pour autant établir la localisation physique des opérateurs. Quatorze des 162 configurations d’images examinées contenaient des horodatages UTC−06:00, compatibles avec le fuseau horaire du pays. Le pseudonyme Telegram Carbo506 reprend l’indicatif téléphonique +506 du Costa Rica, et les connexions SSH inversées aboutissaient dans le réseau costaricien AS262145.

L’emploi du voseo espagnol constitue un indice linguistique supplémentaire. Aucun de ces éléments n’est concluant, et une infrastructure située au Costa Rica pourrait être contrôlée à distance depuis un autre pays.

Ce que les administrateurs doivent vérifier et sécuriser

La principale mesure de défense consiste à empêcher tout accès réseau non authentifié à l’API du démon Docker. Le port 2375 ne doit pas être exposé à des réseaux non fiables, et l’accès doit être limité aux systèmes autorisés.

Les registres de conteneurs doivent eux aussi être protégés par une authentification et faire l’objet d’une exposition réseau limitée. Un registre ouvert peut révéler des secrets intégrés aux images, leur historique, des outils internes et des composants de logiciels malveillants prêts à être déployés.

Les défenseurs qui enquêtent sur une éventuelle infection par CARBONATO doivent rechercher :

• un fichier /root/.hermes/SOUL.md contenant le nom GH0ST ;
• des fichiers .env contenant CARBONATO_API_KEY ;
• du trafic Telegram sortant inexpliqué depuis des serveurs ;
• des conteneurs privilégiés nommés systemd-resolved ;
• des connexions SSH inversées sans justification administrative approuvée ;
• des clés SSH, entrées cron, minuteries systemd ou modifications de rc.local ou d’OpenRC inattendues ;
• des fichiers marqués comme immuables sans raison opérationnelle documentée ;
• des analyses récurrentes du port TCP 2375 sur les réseaux locaux /24.

Les administrateurs ne doivent pas bloquer Hermes Agent au seul motif qu’il est installé. L’enquête doit porter sur le contenu malveillant de la persona et les comportements associés.

Les organisations doivent également recenser les clés d’API d’IA stockées dans leur infrastructure, renouveler les identifiants exposés ou inexpliqués et surveiller leur utilisation par la suite. Dans cette campagne, ces clés ne sont pas de simples découvertes incidentes : elles constituent une cible prioritaire et une ressource destinée à soutenir les opérations du botnet assistées par l’IA.