Campaña Carbonato explota Docker expuesto y despliega Hermes Agent controlado por Telegram

Investigadores en ciberseguridad han revelado una campaña activa que usa un nuevo botnet apodado Carbonato para comprometer servidores con Docker expuesto sin autenticación y desplegar un agente de inteligencia artificial de código abierto llamado Hermes Agent. Según el informe técnico que difundieron las firmas que investigaron la operación, el impacto principal es que los atacantes transforman hosts comprometidos en nodos controlables de forma remota que obedecen instrucciones enviadas por Telegram y priorizan la búsqueda de claves de APIs de IA y credenciales.

Los hechos confirmados por los investigadores son los siguientes: Carbonato explota demonios Docker accesibles por la red a través del puerto no seguro 2375, lanza contenedores con privilegios sobre los hosts afectados para ejecutar comandos en el sistema subyacente, establece persistencia mediante tareas programadas y scripts watchdog, y pone en marcha un túnel SSH inverso hacia un relevo exterior. En cada máquina comprometida se instala Hermes Agent sin modificar el binario, pero se sobreescribe su fichero de personalidad SOUL.md con un prompt que ordena al agente actuar como un "operador senior" sin restricciones éticas y responder a órdenes recibidas por Telegram. Además, la operación cuenta con capacidades parecidas a un gusano: cada host escanea redes adyacentes cada cinco minutos para localizar nuevos demonios Docker sin autenticación y propagarse. Estos hallazgos fueron identificados, según los reportes, a partir de datos expuestos en un registro Docker sin autenticación que estaba público desde mayo de 2026.

Técnicamente, la cadena de compromiso descrita combina técnicas de explosión de superficie y automatización. El vector inicial es el acceso al socket del demonio Docker (expuesto por ejemplo en el puerto 2375), que permite al atacante crear contenedores privilegiados. Dentro de esos contenedores se ejecuta un script que levanta un túnel SSH inverso hacia un relevo controlado (investigadores anotan infraestructura en Costa Rica como punto intermedio), instala un servidor SSH con la clave pública del operador para acceso persistente y notifica el nuevo nodo a través de Telegram. Hermes Agent, configurado con el prompt malicioso, recibe tareas vía Telegram, reenvía esas instrucciones a un modelo LLM o a una pasarela LLM, y convierte las salidas del modelo en comandos de terminal que el contenedor ejecuta en el host comprometido. Los atacantes también habrían troceado o incluido en el registro datos de otra campaña —aplicaciones de monedero cripto troceadas— lo que sugiere uso compartido de infraestructura para múltiples operaciones.

Qué está confirmado: la mecánica básica de infección (Docker expuesto → contenedor privilegiado → persistencia → despliegue de Hermes Agent) y el uso de Telegram como canal de control. Las evidencias técnicas documentadas incluyen los artefactos del túnel SSH inverso, cron jobs y watchdogs que relanzan el implant si se elimina, y la modificación del fichero SOUL.md del agente para forzar comportamiento ofensivo. También está confirmado que la operación prioriza la recolección de claves de API y credenciales.

Qué es estimación o aún no verificado: la atribución completa del actor que opera Carbonato. Los investigadores señalan indicios de idioma, zonas horarias e infraestructura que apuntan a operadores localizados en Costa Rica, pero no existe una vinculación pública y concluyente a un grupo conocido. Tampoco está plenamente verificado el alcance total de las infecciones en Internet (cantidad de máquinas comprometidas) ni la lista completa de objetivos afectados.

Este caso encaja en una tendencia mayor: operadores que combinan agentes de IA con implantes tradicionales para automatizar el ciclo de ataque. Informes previos mencionan usos de Hermes Agent y herramientas afines en campañas que automatizan reconocimiento, explotación y exfiltración sin supervisión humana constante. Además, se han identificado implantes que consultan múltiples proveedores de LLM para decidir acciones post-compromiso, lo que demuestra la elevación del rol de los modelos de lenguaje en la cadena de mando maliciosa.

Para organizaciones y administradores de sistemas, las implicaciones son concretas y urgentes. Un demonio Docker expuesto sin autenticación es equivalente a dar acceso root remoto: permite ejecutar contenedores con privilegios y comprometer el host. La combinación con agentes IA añade velocidad, creatividad y persistencia a las campañas maliciosas, porque el atacante puede orquestar múltiples tareas de recogida de secretos, latencia y pivotaje con poca intervención humana.

Acciones prácticas inmediatas: primero, identifique y cierre cualquier daemon Docker expuesto a redes públicas. No exponga el socket del demonio en la red; confínelo a localhost o use TLS y autenticación. Para directrices públicas sobre cómo proteger el demonio Docker, revisite la documentación oficial de Docker y buenas prácticas comunitarias como la guía de OWASP para Docker: https://docs.docker.com/engine/security/ y https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html.

Segundo, investigue indicadores de compromiso en hosts que ejecutan Docker: busque contenedores lanzados con la bandera --privileged, presencia de servidores SSH recién instalados, procesos autossh o conexiones SSH salientes inusuales (túneles inversos), y entradas en cron o scripts watchdog que relancen binarios. Audite autorizaciones SSH (authorized_keys) y revise imágenes de contenedor y registros para identificar cargas nuevas o imágenes no firmadas.

Tercero, rote y audite claves y credenciales que pudieran haber sido exfiltradas, en especial claves de APIs de IA y tokens de servicio. Configure alertas para actividad inusual hacia APIs de mensajería (Telegram) o hacia proveedores de LLM y limite, por política, el acceso de servicios a claves sensibles.

Cuarto, implemente controles de red: segmentación, listas de control de acceso que impidan que hosts de producción contacten libremente a Internet o a relays externos, inspección de tráfico saliente y bloqueo de puertos que no sean necesarios (como 2375). Considere políticas de imagen firmada y escaneo de imágenes en registries privados con autenticación R/O.

Por último, si sospecha compromiso, preserve evidencia (logs, imágenes de contenedor, procesos en memoria) y considere la desconexión controlada para evitar propagación. Notifique a equipos de respuesta a incidentes y, si corresponde, a las autoridades competentes. La automatización con IA reduce la ventana de respuesta viable: la contención debe ser más rápida y estar acompañada de medidas de resiliencia y de rotación de secretos.

Este caso vuelve a subrayar que la seguridad de contenedores y la protección de credenciales de IA son ahora vectores críticos. Proteger el demonio Docker, garantizar registries privados y auditar el uso de claves son medidas concretas que reducen el riesgo de que herramientas legítimas de automatización —como Hermes Agent— sean reutilizadas para operaciones maliciosas.