Le botnet Carbonato compromet des API Docker Engine non authentifiées exposées sur le port TCP 2375, lance des conteneurs privilégiés et déploie un agent d’IA pour le vol d’identifiants et le contrôle à distance. Divulguée par ThreatDown le 22 septembre 2026, la campagne relève principalement d’une défaillance de l’infrastructure Docker, et non d’une nouvelle vulnérabilité de l’IA. Les opérateurs doivent fermer l’accès exposé au démon, enquêter sur les hôtes affectés et faire tourner tous les secrets accessibles.
Qu’est-ce que le botnet Carbonato ?
Le botnet Carbonato est une opération malveillante de type ver qui compromet des API Docker Engine accessibles sans authentification sur le port TCP 2375. Selon la divulgation de ThreatDown de septembre 2026, Carbonato démarre un conteneur privilégié, obtient un large accès à l’hôte sous-jacent, établit une persistance et recherche sur les réseaux connectés d’autres démons Docker exposés.
La faiblesse initiale est simple : un administrateur a rendu accessible la puissante interface de gestion de Docker sans authentification adéquate ni restrictions réseau. La documentation de sécurité 2026 de Docker avertit que le contrôle du démon peut permettre des modifications illimitées du système de fichiers de l’hôte. Un attaquant n’a pas besoin d’une évasion de conteneur lorsque le démon fournit déjà le contrôle nécessaire.
ThreatDown a découvert un registre d’attaquant non authentifié en août 2026 et a collecté passivement 59 référentiels, 234 balises d’image, 605 blobs vérifiés et 4.3 GB de données en une journée. Les horodatages du registre indiquaient une activité d’octobre 2024 à août 2026. Ces constatations offrent une visibilité inhabituelle sur l’opération, mais elles restent issues d’une seule enquête principale.
Aucun nombre de victimes vérifié de manière indépendante ni attribution définitive des opérateurs n’avait été publié au 1 octobre 2026. BleepingComputer et Dark Reading ont rapporté indépendamment le vecteur d’infection via l’API Docker exposée, tout en s’appuyant largement sur les éléments récupérés par ThreatDown. Les affirmations concernant l’ampleur de la campagne doivent donc être traitées avec prudence.
Comment Carbonato compromet-il les hôtes Docker ?
Le botnet Carbonato atteint un démon Docker exposé sans authentification, utilise l’API pour créer un conteneur privilégié et accède aux fichiers, processus et réseaux de l’hôte. ThreatDown a rapporté en septembre 2026 que le malware installe ensuite une persistance et un accès à distance avant d’analyser les réseaux connectés et les ponts Docker à la recherche de cibles supplémentaires sur le port 2375.
L’exécution privilégiée est l’étape décisive. Un conteneur configuré avec des montages bind root de l’hôte, un accès aux processus de l’hôte ou le réseau de l’hôte peut offrir à un attaquant une portée bien plus large qu’une charge de travail isolée ordinaire. À partir de là, Carbonato peut inspecter les secrets, modifier les mécanismes de démarrage et se déplacer latéralement.
ThreatDown a rapporté en septembre 2026 que le malware analyse toutes les cinq minutes. Ce rythme produit jusqu’à 288 cycles d’analyse par jour pour chaque implant actif : 60 minutes divisées par cinq, multipliées par 24 heures. Même un court retard dans le confinement peut donc exposer de nombreux hôtes de développement accessibles, exécuteurs de build et ponts Docker internes.
| Stade | Mécanisme observé | Signal défensif |
|---|---|---|
| Accès initial | API Docker non authentifiée sur le port TCP 2375 | Connexions Internet ou latérales vers le port 2375 |
| Exécution | Conteneur privilégié créé via Docker Engine | Heure de création, image ou point d’entrée inattendu |
| Accès à l’hôte | Fichiers, processus et réseau de l’hôte exposés | Montages bind root et mode PID ou réseau de l’hôte |
| Déploiement de l’agent | Agent Hermes avec une ligne 39 remplacée SOUL.md |
Fichiers d’agent inattendus et Télégramme trafic |
| Propagation | Analyses du port 2375 signalées toutes les cinq minutes | Tentatives de connexion répétées sur plusieurs sous-réseaux |
Le tableau distingue la compromission de l’infrastructure du composant IA apparu plus tard. Cette distinction est importante, car bloquer uniquement le logiciel de l’agent laisse l’exposition d’origine intacte. À mon avis, toute réponse qui commence par l’analyse du prompt au lieu du confinement du daemon a des priorités inversées.
Pourquoi le botnet Carbonato déploie-t-il un agent IA ?
Le botnet Carbonato déploie le framework Hermes Agent sous licence MIT pour exécuter des tâches fournies par les opérateurs via Telegram et des outils de terminal. ThreatDown a constaté en septembre 2026 que les attaquants avaient laissé le code du framework sous-jacent inchangé, mais avaient remplacé sa SOUL.md persona par un prompt malveillant de 39 lignes axé sur la recherche et le vol d’identifiants.
Hermes Agent lui-même est un open source projet de Nous Research, et ses fonctionnalités légitimes incluent des passerelles Telegram ainsi que des outils d’exécution de commandes dans le terminal. Carbonato montre comment des attaquants peuvent réutiliser un framework d’agent général sans exploiter ni modifier secrètement ce framework. Le comportement malveillant découle du déploiement, des autorisations et des instructions.
La persona écrasée donne la priorité aux clés API des fournisseurs d’IA avant les identifiants SSH, les jetons d’accès, les mots de passe de base de données et d’autres secrets. ThreatDown a indiqué en septembre 2026 que le prompt cite 14 fournisseurs d’IA. Les clés IA peuvent avoir une valeur financière directe, car un accès volé peut consommer une capacité d’inférence payante, exposer des données stockées ou permettre l’accès à des applications connectées.
Ce schéma s’inscrit dans le problème plus large des agents IA non gérés au sein des entreprises. Cela complique également la découverte de l’IA fantôme: les défenseurs doivent identifier les environnements d’exécution d’agents ainsi que les shells, mineurs et outils d’accès à distance plus familiers. Ici, le malware agentique constitue la couche d’exécution, et non le point d’entrée.
Comment détecter Carbonato sur un hôte Docker ?
La détection de Carbonato doit commencer par l’exposition de l’API Docker, l’historique des conteneurs et la persistance sur l’hôte plutôt que par une signature de fichier unique. Le 1 octobre 2026, il a été conseillé aux défenseurs d’inventorier chaque hôte Docker, de tester l’accessibilité du port 2375 depuis plusieurs zones de confiance et d’inspecter les conteneurs en cours d’exécution et arrêtés afin de repérer des privilèges, montages et points d’entrée inattendus.
Effectuez des tests depuis Internet, les réseaux de conteneurs, les sous-réseaux non fiables et les sécurité du cloud groupes pertinents. Un daemon masqué à un scanner public peut néanmoins être accessible ultérieurement de manière latérale depuis une application compromise ou un exécuteur d’intégration continue. Cette exposition interne est le piège que de nombreuses vérifications rapides ne détectent pas.
Utilisation docker inspect pour récupérer une configuration de bas niveau pour les objets Docker, comme décrit dans la référence des commandes 2026 de Docker. Examinez les heures de création des conteneurs, les images sources, les paramètres de privilèges, les montages bind de l’hôte, les modes PID et réseau, les variables d’environnement et les points d’entrée. Ne limitez pas l’examen aux seuls conteneurs en cours d’exécution ; un artefact arrêté peut conserver des preuves précieuses.
La chasse au niveau de l’hôte doit couvrir les installations inattendues de Hermes, les SOUL.md fichiers, le trafic de passerelle Telegram, les tunnels SSH inversés et les mécanismes de persistance inhabituels dans cron, systemd, rc.local ou OpenRC. Les équipes de sécurité qui examinent la manière dont les logiciels autonomes sélectionnent des capacités en ligne de commande peuvent également trouver les mécanismes de AI agents choosing tools utiles pour construire des détections comportementales.
Comment contenir et prévenir les infections par Carbonato ?
Le confinement du botnet Carbonato exige d’isoler les hôtes suspects, de bloquer le port TCP 2375 en entrée et latéralement, de préserver les preuves et de faire tourner chaque identifiant auquel l’hôte a pu accéder. Les recommandations d’octobre 2026 de Docker préconisent de restreindre l’accès au daemon aux réseaux de confiance ou à un VPN et d’utiliser SSH ou TLS avec authentification mutuelle sur le port 2376 lorsqu’un accès distant est nécessaire.
Utilisez l’ordre de réponse suivant pour fermer le point d’entrée sans perdre de vue les identifiants volés :
- Dressez l’inventaire des hôtes Docker et confirmez qu’aucune Engine API non authentifiée n’est accessible depuis internet, les conteneurs, des sous-réseaux non fiables ou des groupes de sécurité cloud trop permissifs.
- Bloquez par défaut le port TCP 2375 en entrée et latéralement. Lorsqu’une administration à distance est nécessaire, utilisez SSH ou TLS avec authentification mutuelle sur le port TCP 2376 et limitez les réseaux sources autorisés.
- Isolez les systèmes suspects et préservez les métadonnées Docker, les journaux, les systèmes de fichiers des conteneurs, les informations sur les processus et les preuves réseau avant de reconstruire.
- Recensez les conteneurs en cours d’exécution et arrêtés, puis inspectez les images, les heures de création, les indicateurs de privilège, les montages bind, l’utilisation des espaces de noms de l’hôte et les points d’entrée.
- Recherchez les fichiers Hermes Agent, les
SOUL.mdcontenus, les communications Telegram, les tunnels SSH inversés et les entrées de démarrage inhabituelles. - Révoquez et faites tourner les clés d’API d’IA, les identifiants SSH, les jetons cloud, les secrets de base de données et les jetons de bot Telegram, puis enquêtez sur leur utilisation à partir de la date la plus ancienne de compromission suspectée.
Faire tourner uniquement les identifiants de connexion de l’hôte Docker est insuffisant. L’invite de septembre 2026 de Carbonato cherche explicitement des secrets appartenant à des services externes, donc chaque clé exposée nécessite son propre examen d’utilisation. Vérifiez les journaux d’audit du fournisseur, les anomalies de facturation, les adresses sources et les ressources nouvellement créées lorsque ces enregistrements existent.
Reconstruire un hôte est souvent plus propre qu’essayer de certifier comme fiable un système profondément privilégié. En toute franchise, préserver un serveur suspect n’a de sens que pour les preuves ou pour une enquête soigneusement contrôlée ; le service de production doit reprendre sur une image saine connue, avec une politique réseau corrigée et de nouveaux secrets émis.
FAQ du botnet Carbonato
Carbonato exploite-t-il une vulnérabilité logicielle de Docker ?
Le botnet Carbonato a été signalé en 2026 comme abusant des API Docker Engine exposées sans authentification, et non comme exploitant une vulnérabilité de code Docker nouvellement identifiée. La défaillance principale réside dans une exposition non sécurisée du daemon et un accès excessif.
Hermes Agent est-il un malware ?
Hermes Agent est un framework légitime d'agent IA open source sous licence MIT maintenu par Nous Research. Les opérateurs de Carbonato auraient installé le framework non modifié en 2026 et fourni un fichier malveillant de 39 lignes SOUL.md persona.
Le port 2375 de Docker doit-il jamais être exposé à Internet ?
Le port TCP 2375 de Docker ne doit pas être exposé sans authentification. La documentation 2026 de Docker recommande des réseaux de confiance ou un VPN, avec SSH ou une authentification TLS mutuelle sur le port TCP 2376 lorsque l’accès distant au démon est nécessaire.
Quels identifiants doivent être renouvelés après une infection par Carbonato ?
Une infection présumée par Carbonato nécessite la révocation et la rotation des clés API des fournisseurs d’IA, des identifiants SSH, des jetons cloud, des secrets de base de données, des jetons d’accès et des jetons de bot Telegram accessibles depuis l’hôte. L’utilisation doit être examinée en remontant jusqu’à la date de compromission la plus ancienne possible.
Quelle est l’ampleur de la campagne Carbonato ?
Aucun nombre de victimes de Carbonato vérifié de manière indépendante n’avait été publié au 1er octobre 2026. ThreatDown a récupéré 4.3 GB à partir d’un registre d’attaquants exposé en août 2026, mais la taille de l’archive ne permet pas d’établir le nombre d’organisations compromises.