La botnet Carbonato compromete las API de Docker Engine sin autenticación expuestas en el puerto TCP 2375, lanza contenedores con privilegios y despliega un agente de IA para el robo de credenciales y el control remoto. Divulgada por ThreatDown el 22 de septiembre de 2026, la campaña es principalmente un fallo de infraestructura de Docker, no una nueva vulnerabilidad de IA. Los operadores deben cerrar el acceso expuesto al daemon, investigar los hosts afectados y rotar todos los secretos accesibles.
¿Qué es la botnet Carbonato?
La botnet Carbonato es una operación de malware de tipo gusano que compromete las API de Docker Engine accesibles sin autenticación en el puerto TCP 2375. Según la divulgación de ThreatDown de septiembre de 2026, Carbonato inicia un contenedor con privilegios, obtiene amplio acceso al host subyacente, establece persistencia y busca en las redes conectadas más daemons de Docker expuestos.
La debilidad inicial es sencilla: un administrador ha hecho accesible la potente interfaz de gestión de Docker sin la autenticación adecuada ni restricciones de red. La documentación de seguridad de Docker de 2026 advierte de que el control del daemon puede permitir cambios sin restricciones en el sistema de archivos del host. Un atacante no necesita escapar de un contenedor cuando el daemon ya proporciona el control necesario.
ThreatDown descubrió un registro de atacante sin autenticación en agosto de 2026 y recopiló pasivamente 59 repositorios, 234 etiquetas de imagen, 605 blobs verificados y 4.3 GB de datos durante un día. Las marcas temporales del registro indicaban actividad desde octubre de 2024 hasta agosto de 2026. Estos hallazgos ofrecen una visibilidad poco habitual sobre la operación, pero siguen siendo hallazgos de una única investigación principal.
No se había publicado ningún recuento de víctimas verificado de forma independiente ni una atribución definitiva de los operadores a fecha de 1 de octubre de 2026. BleepingComputer y Dark Reading informaron de forma independiente sobre la vía de infección a través de la API de Docker expuesta, aunque basándose en gran medida en el material recuperado por ThreatDown. Por tanto, las afirmaciones sobre la magnitud de la campaña deben tratarse con cautela.
¿Cómo compromete Carbonato los hosts de Docker?
La botnet Carbonato alcanza un daemon de Docker expuesto sin autenticación, utiliza la API para crear un contenedor con privilegios y accede a archivos, procesos y redes del host. ThreatDown informó en septiembre de 2026 de que el malware instala después persistencia y acceso remoto antes de escanear las redes conectadas y los puentes de Docker en busca de más objetivos en el puerto 2375.
La ejecución con privilegios es el paso decisivo. Un contenedor configurado con montajes bind de host-root, acceso a procesos del host o redes del host puede proporcionar a un atacante mucho más alcance que una carga de trabajo aislada ordinaria. A partir de ahí, Carbonato puede inspeccionar secretos, alterar mecanismos de arranque y moverse lateralmente.
ThreatDown informó de que el malware escanea cada cinco minutos en septiembre de 2026. Ese calendario produce hasta 288 rondas de escaneo al día por cada implante activo: 60 minutos divididos entre cinco, multiplicados por 24 horas. Por tanto, incluso un breve retraso en la contención puede exponer muchos hosts de desarrollo accesibles, ejecutores de compilación y puentes internos de Docker.
| Escenario | Mecanismo observado | Señal defensiva |
|---|---|---|
| Acceso inicial | API de Docker sin autenticación en el puerto TCP 2375 | Conexiones de Internet o laterales al puerto 2375 |
| Ejecución | Contenedor con privilegios creado a través de Docker Engine | Hora de creación, imagen o entrypoint inesperados |
| Acceso al host | Archivos, procesos y redes del host expuestos | Montajes bind root y modo PID o de red del host |
| Despliegue del agente | Hermes Agent con una línea 39 sustituida SOUL.md |
Archivos de agente inesperados y Telegrama tráfico |
| Propagación | Escaneos del puerto 2375 notificados cada cinco minutos | Intentos de conexión repetidos entre subredes |
La tabla separa el compromiso de la infraestructura del componente de IA posterior. Esa distinción importa porque bloquear solo el software del agente deja intacta la exposición original. En mi opinión, cualquier respuesta que empiece con el análisis del prompt en lugar de con la contención del daemon tiene las prioridades equivocadas.
¿Por qué la botnet Carbonato despliega un agente de IA?
La botnet Carbonato despliega el framework Hermes Agent, con licencia MIT, para ejecutar tareas proporcionadas por el operador a través de Telegram y herramientas de terminal. ThreatDown descubrió en septiembre de 2026 que los atacantes dejaron sin cambios el código del framework subyacente, pero sustituyeron su SOUL.md persona por un prompt malicioso de 39 líneas centrado en encontrar y robar credenciales.
El propio Hermes Agent es un de código abierto proyecto de Nous Research, y sus capacidades legítimas incluyen pasarelas de Telegram y herramientas para ejecutar comandos en el terminal. Carbonato demuestra cómo los atacantes pueden reutilizar un marco de agente general sin explotar ni modificar en secreto dicho marco. El comportamiento malicioso proviene del despliegue, los permisos y las instrucciones.
La persona sobrescrita prioriza las claves API de proveedores de IA por delante de las credenciales SSH, los tokens de acceso, las contraseñas de bases de datos y otros secretos. ThreatDown informó en septiembre de 2026 de que el prompt menciona 14 proveedores de IA. Las claves de IA pueden tener un valor financiero directo porque el acceso robado puede consumir capacidad de inferencia de pago, exponer datos almacenados o proporcionar entrada a aplicaciones conectadas.
Este patrón debe situarse junto al problema más amplio de los agentes de IA no gestionados dentro de las empresas. También complica el descubrimiento de IA en la sombra: los defensores deben identificar los entornos de ejecución de agentes, así como las shells, los mineros y las herramientas de acceso remoto habituales. Aquí el malware agentico es la capa de ejecución, no el punto de entrada.
¿Cómo se puede detectar Carbonato en un host Docker?
La detección de Carbonato debe comenzar por la exposición de la API de Docker, el historial de contenedores y la persistencia del host, más que por una única firma de archivo. El 1 de octubre de 2026, se aconsejó a los defensores inventariar cada host Docker, comprobar la accesibilidad del puerto 2375 desde múltiples zonas de confianza e inspeccionar los contenedores en ejecución y detenidos en busca de privilegios, montajes y puntos de entrada inesperados.
Pruebe desde Internet, redes de contenedores, subredes que no sean de confianza y grupos seguridad en la nube . Un demonio oculto para un escáner público puede seguir siendo accesible lateralmente desde una aplicación comprometida o un ejecutor de integración continua. Esa exposición interna es el escollo que muchas comprobaciones rápidas pasan por alto.
Utilice docker inspect para recuperar la configuración de bajo nivel de los objetos de Docker, tal como se describe en la referencia de comandos de Docker de 2026. Revise las horas de creación de los contenedores, las imágenes de origen, la configuración de privilegios, los montajes bind del host, los modos PID y de red, las variables de entorno y los puntos de entrada. No limite la revisión a los contenedores en ejecución; un artefacto detenido puede conservar pruebas valiosas.
La búsqueda a nivel de host debería abarcar instalaciones inesperadas de Hermes, SOUL.md archivos, tráfico de pasarela de Telegram, túneles SSH inversos y persistencia desconocida en cron, systemd, rc.local u OpenRC. Los equipos de seguridad que examinan cómo el software autónomo selecciona capacidades de línea de comandos también pueden encontrar la mecánica de AI agents choosing tools útil para crear detecciones de comportamiento.
¿Cómo se contienen y previenen las infecciones de Carbonato?
Contener la botnet Carbonato requiere aislar los hosts sospechosos, bloquear el puerto TCP 2375 de entrada y lateralmente, preservar las pruebas y rotar todas las credenciales a las que el host pudiera acceder. La guía de Docker de octubre de 2026 recomienda restringir el acceso al daemon a redes de confianza o a una VPN y usar SSH o TLS con autenticación mutua en el puerto 2376 cuando se requiera acceso remoto.
Utilice el siguiente orden de respuesta para cerrar el punto de entrada sin perder de vista las credenciales robadas:
- Haga inventario de los hosts de Docker y confirme que ninguna Engine API sin autenticación sea accesible desde internet, los contenedores, subredes no confiables o grupos de seguridad en la nube permisivos.
- Bloquee por defecto el puerto TCP 2375 de entrada y lateralmente. Cuando se requiera administración remota, utilice SSH o TLS con autenticación mutua en el puerto TCP 2376 y restrinja las redes de origen permitidas.
- Aísle los sistemas sospechosos y conserve los metadatos de Docker, los registros, los sistemas de archivos de los contenedores, la información de los procesos y las pruebas de red antes de reconstruir.
- Enumere los contenedores en ejecución y detenidos; después, inspeccione las imágenes, las horas de creación, los indicadores de privilegios, los montajes bind, el uso del espacio de nombres del host y los puntos de entrada.
- Busque archivos de Hermes Agent,
SOUL.mdcontenido alterado, comunicaciones de Telegram, túneles SSH inversos y entradas de inicio desconocidas. - Revoque y rote las claves de API de IA, las credenciales SSH, los tokens de la nube, los secretos de bases de datos y los tokens de bot de Telegram; después, investigue su uso desde la fecha más temprana de compromiso sospechado.
Rotar únicamente las credenciales de inicio de sesión del host de Docker es insuficiente. El prompt de Carbonato de septiembre de 2026 busca explícitamente secretos pertenecientes a servicios externos, por lo que cada clave expuesta necesita su propia revisión de uso. Compruebe los registros de auditoría del proveedor, las anomalías de facturación, las direcciones de origen y los recursos recién creados cuando existan esos registros.
Reconstruir un host suele ser más limpio que intentar certificar como fiable un sistema con privilegios profundos. Sinceramente, conservar un servidor sospechoso solo tiene sentido como prueba o para una investigación cuidadosamente controlada; el servicio de producción debería volver sobre una imagen de confianza con la política de red corregida y secretos recién emitidos.
Preguntas frecuentes sobre la botnet Carbonato
¿Carbonato explota una vulnerabilidad del software Docker?
La botnet Carbonato fue reportada en 2026 por abusar de las API de Docker Engine expuestas sin autenticación, no por explotar una vulnerabilidad de código de Docker recientemente identificada. El principal fallo es la exposición insegura del daemon y el acceso excesivo.
¿Es Hermes Agent malware?
Hermes Agent es un marco legítimo de agentes de IA de código abierto con licencia MIT mantenido por Nous Research. Según se informa, los operadores de Carbonato instalaron el marco sin modificar en 2026 y proporcionaron un código malicioso de 39 líneas SOUL.md persona.
¿Debería exponerse alguna vez el puerto 2375 de Docker a internet?
El puerto TCP 2375 de Docker no debe exponerse sin autenticación. La documentación de 2026 de Docker recomienda redes de confianza o una VPN, con SSH o TLS con autenticación mutua en el puerto TCP 2376 para el acceso remoto necesario al daemon.
¿Qué credenciales se deben rotar después de una infección por Carbonato?
Una sospecha de infección por Carbonato requiere la revocación y rotación de las claves de API del proveedor de IA, las credenciales SSH, los tokens de la nube, los secretos de la base de datos, los tokens de acceso y los tokens de bot de Telegram accesibles desde el host. Debe investigarse el uso hasta la fecha más temprana posible de la posible vulneración.
¿Qué tamaño tiene la campaña de Carbonato?
No se había publicado ningún recuento de víctimas de Carbonato verificado de forma independiente hasta el 1 de octubre de 2026. ThreatDown recuperó 4.3 GB de un registro de atacantes expuesto en agosto de 2026, pero el tamaño del archivo no determina el número de organizaciones comprometidas.