godhive: un nuevo framework de robo de criptomonedas y minería escrito en Rust

TLP:CLEAR. Autorizado para difusión pública. Capturado por la red de sensores honeypot de Kinryū Labs. Los indicadores que siguen están desactivados (defanged).

Resumen ejecutivo

• 6,946solicitudes a la API de Docker en una sola ráfaga automatizada
• 946módulos fuente de Rust en el binario
• 8+blockchains a las que apunta su drenador de billeteras
• 9tipos de canal de mando

godhive es un framework de gusano, robo de criptomonedas y minería compilado en Rust que llegó a nuestra red de honeypots a través de una API remota de Docker expuesta. Un único operador ejecutó una campaña automatizada de alto volumen contra una API de Docker expuesta, repitiendo la cadena de ataque completa 21 veces. Kinryū Labs evalúa con alta confianza que godhive es crimeware desarrollado a medida y no un minero de uso común: lleva su propia marca, su nombre está ausente de la inteligencia de amenazas pública y el binario recuperado contiene 946 módulos fuente de Rust distintos y meses de desarrollo.

El operador nunca descargó el framework desde una URL. Introdujo el ELF en un contenedor en línea, trozo a trozo, con printf en base64. El binario se reconstruyó por completo a partir de los propios fragmentos en línea del operador: 215 fragmentos reensamblados en un ELF x86-64 de 6.2 MB (SHA-256 4194f2337c2b261ed6e1fd0b6d18f0ba75388bdc91a2658eb827a154ed784f36), que no está presente en VirusTotal.

El hallazgo distintivo es que godhive no es principalmente un minero. La minería es su plan alternativo. Su negocio principal es el robo: retiros automatizados en seis exchanges importantes y barrido de fondos en más de ocho blockchains, con minería de Monero solo cuando no encuentra billeteras.

Entrega: una API de Docker expuesta

El punto de entrada es el más antiguo del mundo de los contenedores: una API remota de Docker sin autenticación en TCP/2375. A partir de ahí la cadena es una toma de control del host de manual, extraída de las solicitudes a la API de Docker del operador.

El operador crea un contenedor a partir de alpine:latest con privileged: true, usa network_mode: host y monta por bind todo el sistema de archivos del host en lectura y escritura (/:/host:rw). Esa única configuración de contenedor es el escape: montar la raíz del host dentro de un contenedor privilegiado equivale a control root de la máquina. Luego elimina mineros rivales (pkill -9 xmrig; pkill -9 lolMiner; pkill -9 minerd; pkill -9 godhive_c2), escribe su directorio de persistencia en el host en /etc/godhive y lee secretos del host directamente a través del montaje, volcando /etc/shadow y /root/.ssh/authorized_keys.

Solo entonces aparece el cryptojacking reconocible. godhive descarga una compilación de XMRig desde un servicio anónimo de alojamiento de archivos, la despliega, abre un túnel de ngrok para acceso fuera de banda y publica los resultados en un bot de Telegram. Termina consultando el servicio de metadatos de la nube (169.254.169.254) en busca de credenciales y sondeando Kubernetes, Elasticsearch y Kibana para ampliar su alcance. El operador repitió la cadena 21 veces durante la ráfaga.

La minería es lo de menos

El binario recuperado es mucho mayor que la cadena que vimos ejecutarse. Sus 946 módulos de Rust y las cadenas de compilación asociadas describen un kit ofensivo amplio. Parte de ello está respaldado por código compilado (literales duplicados por la monomorfización de Rust, rutas de gestión de errores y directorios de compilación de crates); otras partes son solo nombres de módulos y esbozos de configuración, así que la lista siguiente debe leerse tanto como intención como función probada.

El núcleo es la cadena de monetización. Un harvester recorre el sistema de archivos en busca de wallet.dat, .env, claves SSH y wp-config.php; un scorer cotiza BTC, XMR, ETH y Ravencoin contra CoinGecko y clasifica a las víctimas por valor; una etapa de credenciales realiza credential stuffing con integración de 2CAPTCHA para superar los desafíos de inicio de sesión; y un drenador extrae fondos mediante la librería de exchanges CCXT y barridos DeFi on-chain, derivando claves a partir de frases semilla robadas y eligiendo la cadena más barata para cada retiro. Un comentario del desarrollador dejado en el binario optimiza los retiros de stablecoins para evitar las comisiones de gas de Ethereum, que es el nivel de cuidado que separa un drenador funcional de una prueba de concepto.

Alrededor de ese núcleo está el resto del kit: un gusano que escanea con Masscan y Nuclei y explota Docker, Redis, Kubernetes, Elasticsearch, WordPress y un conjunto de vulnerabilidades de Windows y Java, entre ellas Log4Shell; un matador de EDR que apunta a nueve fabricantes de endpoint por nombre de proceso; cinco capas de persistencia que llegan hasta un bootkit UEFI con manipulación del TPM; un sistema de plugins WASM para enviar nuevas capacidades a la flota sin tocar el C2; ransomware condicionado a dispararse solo por encima de un umbral de valor de 1,000 dólares estadounidenses; un secuestrador del portapapeles; un módulo de DDoS; y anti-forense que borra wtmp, btmp y los registros del journal y siembra ruido falso en syslog para hacer perder tiempo al analista. Enmascara cada módulo bajo un nombre de proceso falso, sysd, y disfraza su propio tráfico como streaming de YouTube tomando prestados nombres SNI reales de googlevideo.com.

Dos detalles matizan el cuadro. El framework incluye detección de quince plataformas de honeypot y de una batería de sandboxes e hipervisores. Y varias de sus configuraciones están sin terminar: el pool de minería predeterminado cerró en 2022, un nombre ENS del portapapeles nunca se registró y una clave de cifrado sigue siendo el marcador de posición CHANGE_ME. La capacidad está compilada y es real; partes de ella todavía no están conectadas.

ngrok, y por qué se clasifica como hacktool

La muestra que señaló por primera vez esta campaña es el binario legítimo y firmado de ngrok, descargado desde la propia CDN de ngrok. No es malware. Es una herramienta comercial de túnel inverso, y los motores antivirus la etiquetan como hacktool precisamente porque resulta muy útil tras un compromiso. Una vez que godhive logra ejecución de código dentro de un contenedor privilegiado, ngrok marca hacia la nube de ngrok y expone un servicio local elegido a través de una URL pública, sin abrir ningún puerto entrante y sin nada que un firewall perimetral o un NAT de solo salida puedan detener. El operador confirmó el túnel consultando la API local del agente de ngrok (127.0.0.1:4040/api/tunnels) y envió la URL pública resultante a su bot de Telegram, convirtiendo cada host recién comprometido en un acceso de un solo clic.

Un canal de mando construido para sobrevivir a un desmantelamiento

godhive no depende de un único C2. Apila canales en orden según lo difícil que sea eliminar cada uno. En la base hay una malla peer-to-peer Kademlia con desafíos de prueba de trabajo para unirse y travesía de NAT, que no tiene ningún punto central que incautar. Por encima está EtherHiding, donde la dirección actual del backend se almacena en un contrato inteligente en blockchain que no se puede revocar, resuelta en tiempo de ejecución a través de un relay activo en Cloudflare Workers (c2-proxy.operator.workers[.]dev) que oculta el backend a los defensores. Por encima de eso hay dominios de respaldo generados algorítmicamente y obtenidos por DNS-over-HTTPS con SNI falsificado, un servicio oculto en Tor, buzones muertos en gists de GitHub, ocho canales de software como servicio y Telegram como canal principal del operador. La detección de canal quemado vigila una racha de consultas de comandos vacías y migra automáticamente al operador a infraestructura nueva con una copia de seguridad cifrada de la configuración, y una función de federación permite la coordinación entre varios bots.

Tomamos huella del relay de Cloudflare Workers desde el exterior y confirmamos que está activo y procesando solicitudes: los endpoints de registro, de asignación de tareas y del panel enrutan hacia un backend, mientras que la entrada no autenticada se rechaza, lo que es coherente con los tokens cifrados con AEAD que el binario usa para autenticarse ante el C2. El operador también mantiene detrás un panel de administración endurecido, con hashing de contraseñas Argon2, autenticación multifactor, control de acceso basado en roles e incluso opciones poscuánticas en su configuración TLS. Se trata de alguien que trata una botnet como infraestructura de producción, hasta el punto de exportar métricas de Prometheus para ella.

La otra mitad: operaciones de aficionado

Con toda esa ingeniería, el despliegue es descuidado en aspectos que importan. La campaña provino de una única conexión móvil de consumo de Verizon Wireless en Estados Unidos (174.230.35[.]232, DNS inverso 232.sub-174-230-35.myvzw.com, Gainesville, Florida), no de un hosting a prueba de balas ni de un VPS, en una ráfaga automatizada y compacta sin reutilización de infraestructura. El token del bot de Telegram está codificado en texto plano, un único punto de desmantelamiento. La carga útil de XMRig se sirvió desde un servicio público y anónimo de alojamiento de archivos. Y, pese a todo su código de detección de honeypots, se desplegó en una sola ráfaga ruidosa desde una dirección rastreable.

El binario se compiló en macOS, bajo un usuario llamado dev, en un directorio llamado research/godhive. Leído junto con la anonimización deliberada de la identidad del operador en Telegram, las configuraciones sin terminar y el despliegue autoatribuido, la lectura más económica es la de un desarrollador solitario con habilidad que prueba y opera su propio framework, y no la de un cliente de una plataforma de malware como servicio. La marca está pulida, con un logotipo dorado de colmena a medida y el lema “one mind, one purpose, one hive”; las operaciones no lo están.

Atribución

La campaña se vincula a un único operador a través de su infraestructura de Telegram. godhive envía credenciales robadas, URLs de túneles y confirmaciones de infección a un bot codificado en el binario, @godhive_bot (id de bot 8836117161). Su chat_id capturado resuelve a una cuenta personal, @godhive77 (id de usuario 7659611777), con guiones bajos como nombre visible y sin foto de perfil, un intento de anonimato que el propio alias godhive77 deshace. El mismo operador mantiene un canal de reserva coincidente, @godhive (un suscriptor, sin publicaciones públicas, reenvío deshabilitado), y el id secuencial de usuario de Telegram sitúa la creación de la cuenta a finales de 2024. El alias godhive77 es el pivote más sólido para profundizar en la atribución.

Indicadores de compromiso

La infraestructura del atacante está desactivada (defanged). Los servicios legítimos de terceros de los que abusa el malware se dejan intactos para facilitar la detección.

Red y host

Indicador	Contexto
c2-proxy.operator.workers[.]dev	Relay de C2 activo en Cloudflare Workers (reportar a Cloudflare)
hxxps://files.catbox.moe/p46h39.gz	Carga útil de XMRig en un servicio anónimo de alojamiento de archivos (SHA-256 cb49ae0793b2…)
bin.equinox.io/c/.../ngrok-v3-stable-linux-amd64.tgz	Descarga de ngrok (CDN legítima); la señal es el tráfico saliente hacia bin.equinox.io desde un servidor
127.0.0.1:4040/api/tunnels	Consulta al agente local de ngrok (lee la URL pública asignada al túnel)
169.254.169.254/latest/meta-data/	SSRF contra los metadatos de la nube para robo de credenciales
api.telegram.org	C2 y exfiltración vía bot de Telegram; el tráfico saliente desde cargas de trabajo de servidor es la señal de caza
gitlab.com/nzyme/	Alojamiento de herramientas estáticas (sshpass, redis-cli, wget, tor, proxychains)
2captcha.com, hashes.org, nitrxgen.net	Servicios de resolución de CAPTCHA y de cracking de hashes de los que abusa la cadena de credenciales
r[1-20]---sn-*.googlevideo.com, manifest.googlevideo.com	Nombres reales de la CDN de YouTube usados para falsificar el SNI en TLS; alertar cuando resuelvan a IPs que no sean de Google

Actor, identidad de C2 y pagos

Indicador	Contexto
174.230.35[.]232	Origen de la campaña (móvil de Verizon Wireless, 232.sub-174-230-35.myvzw.com, Gainesville FL); dirección dinámica de operadora con escaso valor de bloqueo
@godhive_bot (id de bot de Telegram 8836117161)	Bot de C2 y exfiltración del malware; token codificado en el binario (secreto redactado aquí; reportado a Telegram para su retirada)
@godhive77 (id de usuario de Telegram 7659611777)	Cuenta de exfiltración del operador y pivote de atribución más sólido
@godhive (id de canal de Telegram -1002105830453)	Canal de reserva del operador
49aXwwgXBKRKTUVgYuLy3fZkTeLP3PWgMhwiyK55Ur7WhgYXJ33N8JZG87vzUV1UyVdZzPGLvx1w9YQHk7faWPn1UzJte2R	Billetera de pagos en Monero confirmada (emparejada con la configuración activa de XMRig)
pool.minexmr.com:4444	Pool de la configuración de XMRig; nótese que minexmr cerró en 2022, por lo que este valor predeterminado fallaría

Archivos y artefactos

• Binario de godhive (reconstruido): SHA-256 4194f2337c2b261ed6e1fd0b6d18f0ba75388bdc91a2658eb827a154ed784f36 (ELF x86-64 de 6.2 MB, ausente de VirusTotal). Sus cabeceras ELF están corrompidas deliberadamente para declarar ~106 MB y apuntar el código más allá del final del archivo, derrotando a las herramientas estándar.
• Persistencia en el host: /etc/godhive, /host/usr/local/bin/sysd (binario que simula ser systemd), /host/tmp/godhive_deployed.txt, proceso godhive_c2, imagen propia creada en el contenedor godhive:latest.
• Firma del escape de contenedor: un contenedor creado con Privileged:true, network_mode:host y un bind /:/host:rw.
• Artefacto de compilación: rutas de cargo bajo /Users/dev/.cargo/registry/src/ y un directorio de compilación research/godhive (desarrollador en macOS).
• Indicio de endurecimiento del host: contraseña de Redis fijada en CHANGED_BY_GODHIVE; una webshell b374k.php junto con actividad de fuerza bruta contra WordPress.

Comportamiento

• pkill -9 xmrig|lolMiner|minerd|godhive_c2 seguido de mkdir /host/etc/godhive.
• Lecturas de /host/etc/shadow y /host/root/.ssh/authorized_keys desde un montaje de contenedor.
• Un proceso sysd que no es el systemd real; escrituras de efibootmgr que crean una entrada de arranque EFI etiquetada “System Core”.
• Directorio de trabajo de Nuclei /tmp/.nuclei_assault-t*.

Detección

• Alertar sobre tráfico saliente hacia bin.equinox.io y cualquier host *.ngrok* desde servidores, y sobre la consulta a la API del agente de ngrok 127.0.0.1:4040/api/tunnels.
• Alertar sobre cualquier contenedor creado con Privileged:true y un bind /:/host; esa combinación es casi con certeza un intento de escape.
• Alertar sobre tráfico saliente hacia api.telegram.org, c2-proxy.operator.workers[.]dev, gitlab.com/nzyme/, 2captcha.com y servicios de cracking de hashes desde cargas de trabajo de servidor.
• Alertar sobre un proceso sysd, sobre agentes EDR detenidos o eliminados (falcon-sensor, SentinelOne, cbdefense, sophos-edr, cylancesvc) y sobre CONFIG SET requirepass CHANGED_BY_GODHIVE.
• Tratar el TLS con SNI googlevideo.com que resuelve a IPs que no son de Google, y manifest.googlevideo.com desde procesos que no son navegadores, como enmascaramiento de tráfico.

Mitigación

• Nunca exponer la API de Docker en el 2375 sin autenticación. Vincularla a localhost con autenticación TLS de cliente. Esta es la causa raíz.
• Imponer no-new-privileges, eliminar --privileged y restringir los bind mounts del host, o usar Docker rootless o gVisor.
• Bloquear el acceso de los contenedores al servicio de metadatos de la nube (169.254.169.254) y exigir IMDSv2.
• Filtrar la salida: las cargas de trabajo de servidor no deberían alcanzar servicios anónimos de alojamiento de archivos, ngrok, Telegram, resolutores de CAPTCHA ni las rutas de alojamiento de herramientas estáticas indicadas arriba.
• Habilitar Secure Boot para limitar la persistencia UEFI, y activar la protección contra manipulación en los agentes de endpoint, que godhive intenta eliminar.
• Si algún host pudo verse comprometido, rotar de inmediato las claves de API de los exchanges; godhive automatiza los retiros.

Mapeo MITRE ATT&CK

Táctica	Técnica
Acceso inicial	T1190 Explotación de aplicación expuesta al público (API de Docker; Redis, Kubernetes, WordPress y Log4Shell en el arsenal)
Ejecución	T1610 Despliegue de contenedor; T1059.004 Shell de Unix
Escalada de privilegios	T1611 Escape al host (contenedor privilegiado, montaje del host)
Persistencia	T1543 Creación o modificación de proceso del sistema (sysd); T1542.003 Bootkit (UEFI); T1014 Rootkit
Evasión de defensas	T1562.001 Degradación de defensas (matador de EDR); T1070 Eliminación de indicadores (borrado de registros); T1497 Evasión de virtualización/sandbox (detección de honeypot y de máquina virtual); T1036 Enmascaramiento (sysd, SNI de YouTube); T1027 Archivos ofuscados (ELF corrompido)
Acceso a credenciales	T1003.008 /etc/passwd y /etc/shadow; T1552.004 Claves privadas; T1552.005 API de metadatos de instancia en la nube
Descubrimiento	T1046 Escaneo de servicios de red (Masscan, Nuclei)
Mando y control	T1572 Túnel de protocolo (ngrok); T1090 Proxy; T1071.001 Protocolos web (Telegram, Cloudflare Workers); T1102 Servicio web (gists de GitHub, canales SaaS)
Impacto	T1496 Secuestro de recursos (XMRig); T1486 Datos cifrados con fines de impacto (ransomware); T1657 Robo financiero (drenaje de exchanges y DeFi); T1498 Denegación de servicio de red

Metodología y notas

• El análisis es un análisis estático del binario ELF, que se reconstruyó por completo a partir de los propios fragmentos en base64 en línea del operador capturados por el honeypot, junto con la revisión del tráfico capturado de la API de Docker y reconocimiento externo autorizado del relay activo del operador en Cloudflare Workers. No se ejecutó ningún malware ni se intentó autenticarse contra el C2.
• Los indicadores están desactivados (defanged), y los servicios legítimos de terceros de los que abusa el malware se dejan intactos para facilitar la detección.
• Las muestras están disponibles para otros investigadores y defensores previa solicitud. Escriba a contact@kinryu.sh con una nota breve sobre quién es usted y para qué las necesita.