Nombres prestados

El capítulo anterior dejó a Superior instalado en una tele y la víctima sin poder quitárselo. Este empieza por las etiquetas que lleva colgadas, que casi nunca son suyas:

se llama a sí mismo     superior-v21
su paquete Android      com.android.logcatd        # el de Kimwolf
uno de sus ataques      kimwolf
lo que escribe          t[.]me/mozibotnet          # Mozi, una botnet famosa
en la consola
el contacto             «Rise», con la cara de un hacker buscado por el FBI
los antivirus           trojan.mirai

Cinco nombres de otros y uno propio. Lo que sigue es por qué me quedo con el propio, qué hay dentro del bicho, y lo que se ve del que lo maneja.

01Lo que lleva dentro

Desempaquetado, el nativo de la tele son 540 KB de C, estático y sin símbolos. Su configuración va en una tabla de 46 entradas cifradas con un XOR de ocho bytes, al estilo de Mirai, idéntica en las tres arquitecturas. Descifrada, dice quién es:

versión          superior-v21
servidor         coolcams.duckdns.org
nombre falso     kworker/0:1
consola          clave superior-swarm-••••     # la oculto: daría el control de la red
proxy SOCKS      socksuser / sockspass123      # nadie lee estas dos entradas
señuelo          «S Y S T E M   U P D A T E … Build 2026.10.31-1543 · Channel stable»
ataque           User-Agents de navegador, cabeceras sec-ch-ua, banners SSH,
                 rutas y cookies del reto de Cloudflare

El señuelo es lo que imprime al arrancar, en la consola, en la salida estándar y en el registro del núcleo: una actualización del sistema que no hace nada. La fecha de «build» puede ser la de compilación, 31 de octubre; o puede ser texto, sin más.

Lo que sabe hacer, en resumen:

DDoS             37 entradas en su catálogo de ataques, de capa 3 a capa 7, una llamada «kimwolf»
propagación      Telnet, con 45 pares de usuario y contraseña
                 y un buscador de servicios que manda los banners a casa
robo             un catálogo de ficheros que le interesan, y una vía para subirlos
competencia      killer de rivales, vigilante de carpetas, desinstalador de apps
persistencia     en Android, la del capítulo anterior; en Linux, intentada
control          C2 central; una malla P2P y una consola, apagadas en esta versión
ocultación       nombres de hilos del núcleo y de demonios del sistema, al azar
                 borra wtmp, btmp y lastlog al arrancar en Linux

De esas 37 entradas, la que se llama kimwolf es una inundación UDP de alto caudal. Su ayuda ofrece una opción para falsificar la dirección de origen, pero sin socket en bruto no puede hacerlo: la opción es decorativa. Es un ataque corriente con un nombre famoso, no código de Kimwolf.

UDP    pps udp udpbypass kimwolf udpxor tcprst tcpsynack dnsq gameudp rtc query icmp damp ssdp
TCP    ack stomp ssh hold bypass tcp fivem tcpkill minecraft ovhkill
HTTP   http2 http1 httpbypass cdn http3 httpdown h2cont captcha cfbypass tlsfull ws httpemu odom

02Cómo habla con casa

Para encontrar su servidor no se fía del resolvedor del sistema: lleva el suyo, que pregunta directamente a resolvedores públicos. Luego lo intenta por dos vías. Primero TLS al 443, con un cliente TLS propio cuyo saludo cambia de tamaño en cada intento y lleva valores de relleno variables, como hacen los navegadores. Eso, probablemente, para que no lo reconozcan las huellas fijas de TLS. Si falla, TCP en claro al 29444 (al arrancar prueba también el 14444).

Por el 29444 se presenta con un anuncio cifrado. Y el cifrado tiene un fallo de manual: usa siempre la misma clave, el mismo número de un solo uso y el contador a cero, en cada conexión y en cada bot. La clave va dentro del binario. Así que el anuncio no es secreto: cualquiera con el binario lo lee, y un detector de red puede leerlo al vuelo. Dice esto:

tipo                0x0d
arquitectura        aarch64
versión             superior-v21
CPU y memoria       2 · 1967 MB
etiqueta de build   acer
¿root?              sí
línea de órdenes    /usr/sbin/cupsd           # ya disfrazada
clave efímera       32 bytes, nueva en cada conexión
huella del equipo   8 bytes
etiqueta            piharnessapk              # la del instalador

La sesión que viene después sí incorpora autenticación: lleva metida en el binario la clave pública del operador, y el intercambio exige su clave privada para establecer la sesión prevista. Por eso nunca le di órdenes. Eso no quiere decir que todo esté protegido: su TLS y la autenticación de alguna de sus órdenes tienen defectos propios y cabos sin revisar.

La etiqueta acer es la de la compilación; la del instalador viaja aparte, en el último campo. Qué es acer para el operador, una campaña, un cliente o nada, no lo sé. En la tele, una vez instalado en el sistema y relanzado por su supervisor sin argumentos, el anuncio ya solo llevaba acer: la etiqueta de la vía de entrada se pierde por el camino.

Además del canal cifrado, habla mucho en claro. En la máquina virtual ARM64, al puerto 80 de su servidor: [ARCH] a=aarch64 al arrancar, un [SERIAL] con el identificador de la máquina cada minuto, miles de [CATALOG] con los ejecutables del sistema y un POST /r con la cabecera Host: cnc que lleva su inventario de ficheros. En la tele, ya lo vimos, casi todo eso iba al 5821. Y si su instalador se lo pide, nada más arrancar manda una baliza al 8099, GET /b/y/<PID> con Host: beacon: la prueba de que el binario de verdad corre.

También le pregunta a ip-api.com por su propia IP: país, región y proveedor y, sobre todo, si es la de un proxy o la de un centro de datos. Parece que le interesa saber si ha caído en una casa.

03Lo que lleva apagado

Las cadenas del binario prometen más de lo que hace. Una parte grande viene compilada y no funciona:

malla P2P «swarm»   saludo SWR1 en el 443, pares en .swarm_peers, órdenes SCARE y KILL
                    entre bots. Todo depende de un indicador que nadie pone a 1:
                    la única escritura que tiene lo pone a 0
consola             también en el 443, con su clave; sale si ese indicador vale 0
proxy SOCKS         usuario y contraseña en la tabla; nadie las lee, no hay código
anti-emulador       cadenas de qemu, goldfish, ranchu… sin una sola referencia
ocultación eBPF     un programa «hide» que no hace nada: return 0
lifeline 42428      un canal de rescate; en Linux nunca llega a escuchar

Lo busqué de todas las formas que se me ocurrieron: escrituras directas, por desplazamiento, por pares, por copias de memoria, por punteros guardados. El indicador de la malla solo se escribe una vez, con un cero. En veinte minutos de ejecución, ni una escucha en el 443 ni un saludo SWR1. El bot «híbrido» que prometen sus cadenas es, en esta versión, un bot de servidor central.

Captura: el interruptor de la malla, en GhidraGhidra

El lifeline tiene su gracia. En Linux nunca escucha: el proceso que lo atiende, al hacerse demonio, cierra los descriptores 0, 1 y 2 por costumbre, y todo indica que uno de ellos es su propio socket. En la tele, en cambio, escuchaba en el 42428. Cómo se entra por él no lo cuento: es una puerta trasera en las víctimas.

Lo que sí arranca es una pieza aparte, a la que el código llama HYDRA. Abre el UDP 8346 y está escrita para saludar cada treinta segundos a una lista de hasta dieciséis hermanos que le pasa el servidor, con mensajes autenticados; si alguien le manda uno que no cuadra, lo denuncia a casa como [MESH]|probe=1|ip=…, y así delata a quien sondea el puerto. Pero tiene un fallo: la lista de hermanos la recibe el proceso principal, y el vigía corre en un proceso aparte, con su propia tabla. Según el estático y un ensayo en jaula, esa lista no le llega, así que, tal como está, no sabe a quién saludar. Lo que sí hace, y se vio en la tele, es vigilar un fichero de latido que el bot toca solo mientras está conectado a su servidor: si el latido caduca, intenta avisar a los pares de su tabla y activa diez minutos de «modo oscuro», en los que el bot mata sus propios ataques. Los intentos de volver a casa siguen, y la propagación también.

04Los fallos que lo delatan

Para un bot con criptografía propia y TLS propio, tiene partes bastante mejorables, y algunas en sitios clave. Unas no le importan a nadie más que a él. Otras sirven para cazarlo, y no dependen de una IP ni de un dominio que pueda cambiar:

el barrido «local»       quiere recorrer su propia red y recorre Internet (abajo)
el banner al servidor    su salida estándar acaba siendo el socket del C2, y el banner
                         «S Y S T E M   U P D A T E» viaja dentro de la conexión
el anuncio               misma clave y mismo nonce siempre: se lee al vuelo
los informes en claro    una conexión TCP por mensaje: más de mil por minuto en la tele
la persistencia Linux    intenta copiarse desde «/memfd:kworker/9 (deleted)», una ruta
                         que no existe, y no se copia
el desempaquetador       sin barreras de caché: causa probable de los SIGILL y SIGSEGV en ARM real
la actualización         según un análisis estático que no he comprobado, sin hash
                         un fichero de 0 a 3 bytes pasa por un ejecutable válido
el killer                informa de muertes que no se producen

El primero es el mejor. Cada media hora, si su dirección es privada, el bot quiere sondear su red local: las 254 direcciones de su /24. Pero guarda la IP con los bytes al revés y cambia el primer octeto en vez del último. Una tele en 192.168.1.50 no recorre 192.168.1.1 a 192.168.1.254: recorre 1.168.1.50, 2.168.1.50… hasta 254.168.1.50. 253 direcciones, ninguna de su red y casi todas de Internet, cada media hora, desde cada casa infectada.

Captura: el barrido, en GhidraGhidra

Lo que busca en ellos es interesante: trece servicios, entre ellos Telnet, ADB, IRC de botnets antiguas, paneles en el 4444 y el 31337, y dos que llama superior-c2 (29444) y superior-ui (29596). Parece buscar paneles, de rivales y suyos. Los banners se los manda a casa como [CNC]|ip=…|port=…|kind=…|banner=….

05Su guerra

Buena parte de su código está dedicada a la competencia. El killer tiene cuatro trabajadores. Caza a 32 familias de botnets por nombre y a los mineros de criptomonedas (no mina: mata mineros), puntúa los procesos sospechosos, ocupa los puertos que usan otros bots para que no los abran, y vigila con inotify /tmp, /var/tmp, /dev/shm y /var/run para borrar cualquier fichero nuevo que no sea él, salvo unos pocos críticos para el sistema. Y lleva una despedida, que escribe en la salida de otro proceso; por el tono, de un rival:

sorry brother I own this box

Captura: la despedida, en GhidraGhidra

Y en Android, la lista de apps que desinstala es un quién es quién de las botnets de cajas de TV de este año:

com.n2.systemservice06, …061, …062, …063, …0644    # Kimwolf
com.oreo.mcflurry, com.android.log_handler_v2,
com.android.boothandler                            # alias de Lorikazz
com.android.docks                                  # Snow
com.google.android.gms.update                      # el disfraz de Jackskid
com.iranbot.loadd                                  # ¿IranBot?
com.abcproxy.*, com.proxypeer.peerapp, io.earnify  # proxyware
com.meowrisee.service                              # sin identificar

Ese com.iranbot.loadd es casi el com.iranbot.load que ya salió en los capítulos 7 y 21, con una d de más. Si es el mismo con una errata o otro distinto, no lo sé. Desinstalar a los rivales no es nuevo en este terreno: Jackskid y Lorikazz también lo hacen. Lo que este añade es hacerlo vestido de uno de ellos.

El último de la lista, com.meowrisee.service, lleva «meow», como su propio meowbox, y «rise», como el contacto de Telegram que veremos. Puede ser casualidad, una versión suya anterior o un rival. No hay nada público sobre ese paquete.

Para propagarse, prueba sus 45 credenciales por Telnet en el 23 y el 2323 y, si entra, baja un guion con lo que haya en la máquina (wget, curl, busybox, toybox o, si no hay nada, una petición HTTP a mano con nc). Antes descarta a las víctimas que parezcan una trampa: si la respuesta menciona cowrie, kippo, dionaea, glastopf, conpot, «honeypot», tarpit, canarytoken, dshield, shadowserver, «internet census», «capture the flag» o «malware analysis», se va.

Y para robar, cataloga ficheros por extensión y por cabecera en dieciocho raíces del sistema (.key, .pem, .crt, .env, .db, .sqlite, .sql, configuraciones, guiones, APK…) y, si su servidor se lo pide, los sube por el TCP 5822 o con un POST /pull. El killer puede hacer lo mismo con los binarios de los rivales antes de matarlos, aunque esa opción, según el código, viene apagada.

06No es Kimwolf

Kimwolf es una de las botnets de cajas de TV más documentadas de este año: XLab la describió en diciembre de 2025 y Unit 42 publicó su versión 7 en agosto. Superior lleva su nombre de paquete, un ataque con su nombre, un esquema de nombres parecido (meowbox frente a niggabox), el sufijo v7 en su cerrojo de instancia y la misma costumbre de pasar una etiqueta como primer argumento. Así que lo comparé con lo publicado y, después, con muestras reales: un APK y un ELF v7 de Unit 42 que están en MalwareBazaar con la firma de Kimwolf.

                 Kimwolf                             Superior
TLS              wolfSSL; BoringSSL estático (v7)    propio
autenticación    firma ECDSA                         X25519 + BLAKE2s + ChaCha20, propios
C2               ENS, DNS sobre TLS, Tor             DuckDNS, TLS al 443, TCP al 29444
uso principal    proxy residencial (96,5 % órdenes)  sin proxy: DDoS, robo, control
propagación      ADB vía proxies; v7 sin escáner     Telnet con 45 credenciales
tamaño (ARM)     1,7 MB                              unos 550 KB (217 KB empaquetado)
cerrojo          @niggaboxv<n>                       @superior:instance:v7

De 8.739 y 2.389 cadenas, comparten 155, y todas son genéricas: la biblioteca de C que enlazan los dos, las cabeceras para imitar a Chrome, las etiquetas de TLS 1.3. Ninguno de los 37 nombres de su catálogo de ataques aparece en Kimwolf. Ni su configuración, ni sus credenciales, ni sus plantillas, ni nada de lo suyo. En la capa Java, lo mismo: de 4 componentes contra 14, comparten los dos genéricos, y el APK de esa muestra es un lanzador de Tor. El código es otro. Confianza alta.

Con un matiz de nombres. com.android.logcatd lo documentó Unit 42 primero, en abril, como alias de Lorikazz, y después, en agosto, como la variante Android de Kimwolf v7. Y la muestra con Tor que usé encaja con la variante que describe su informe de Lorikazz. Son nombres de una misma constelación, que según Nokia se fragmentó en más de veinte botnets a partir de marzo. Para lo que importa aquí da igual: Superior no comparte código con ninguna de esas muestras.

Pero lleva puesto su paquete. Y eso tiene una consecuencia práctica: las reglas públicas que buscan Kimwolf por el nombre del paquete pueden llamar Kimwolf a Superior. Los antivirus, por su parte, lo meten en Mirai: el APK lo detectan 24 o 25 de 75 motores, y la etiqueta de consenso es «trojan.mirai», el cajón donde cae cualquier bot que escanea aparatos e inunda. ThreatFox llega a etiquetar su dominio como EchoBot, otra variante de Mirai, que resulta estar en su lista de rivales. No es una familia: es una estantería.

Los paquetes que usa él son dos: com.android.logcatd y com.superior.node. Por qué ponerse el paquete de otro, no lo sé. Puede ser para mezclarse donde Kimwolf ya estuvo, o para ocupar el sitio: Android no deja instalar un paquete con el mismo nombre y otra firma, así que donde ya esté el Kimwolf auténtico, Superior no entra, y donde entre Superior, Kimwolf ya no podrá. Eso último no lo he comprobado.

07Ni Mozi, ni «Rise»

Con el nombre de Mozi pasa lo mismo. Bajo ciertas condiciones, si su malla no tiene pares, Superior escribe en la consola del aparato:

t[.]me/mozibotnet

Captura: la firma, en GhidraGhidra

En la máquina virtual lo vi en su consola; en los registros de la tele no apareció. Mozi fue una botnet P2P de aparatos IoT muy extendida entre 2019 y 2021, cuyos operadores fueron detenidos en China y que se apagó en 2023. Busqué sus marcas en el binario: la malla por la red de BitTorrent, su configuración entre etiquetas, su clave fija, su nombre. No hay ninguna. La malla de Superior es otro diseño, y además está apagada. Lo único «mozi» que lleva es la firma de la consola y una palabra en su lista de 32 rivales a los que mata. Usa el nombre y caza a la familia. Igual que con Kimwolf.

Esa dirección de Telegram la visité una vez, por Tor, sin JavaScript y sin escribir a nadie. No es un canal: es una cuenta personal, con el nombre visible «Rise», sin biografía. El bot escribe en cada aparato infectado el contacto de una persona, lo que encaja más con un anuncio de venta o de contacto que con un canal de noticias. No hay nada público sobre «Rise» en este terreno.

La foto de perfil no la enseño, pero la explico. La busqué por coincidencia exacta de imagen, sin reconocimiento facial, y aparece 227 veces en 81 sitios, casi todos medios de prensa y agencias, desde 2018: es la foto que difundió el FBI en el cartel de un programador norcoreano acusado por el hackeo de Sony Pictures y por WannaCry. Es un avatar prestado, como los nombres. Esa persona no tiene nada que ver con este caso, y no voy a insinuar lo contrario. Lo que sí dice es algo del personaje que se monta el operador: un ataque con el nombre de Kimwolf, una firma con el de Mozi y la cara de un hacker de leyenda.

08Un Frankenstein con hilo propio

Puesto todo junto, se ve de dónde viene cada pieza:

credenciales Telnet    de Mirai y derivadas           datos públicos, no código
matar rivales          la idea es de Mirai            código propio
malla P2P              la idea es de Mozi y Hajime    diseño distinto, y apagada
disfraz Android        de Kimwolf                     sin código común
terreno y entrada      cajas de TV por ADB, como el ecosistema de Kimwolf
ataques de navegador   la escena de DDoS de alquiler  propio
catálogo de métodos    nombres de panel de alquiler   propio
nombres de fachada     Kimwolf, Mozi, Lazarus         remiten a otros

lo suyo                criptografía propia, TLS propio, el vigía HYDRA, el robo de
                       ficheros, la pantalla de miedo, el borrado de apps legítimas

Toma prestados nombres, datos e ideas; el código parece suyo. Que eligiera esos nombres para hacerse pasar por otros es mi lectura, no algo que el binario diga. Y está cosido con prisa: piezas a medio montar, partes mejorables y, a la vez, una compilación al día. Su lista de rivales es un quién es quién de las botnets de IoT, así que conoce bien la escena. No parece una variante de ninguna: parece un recién llegado que imita a las grandes y compite con ellas por las mismas cajas de TV.

09Ocho meses del mismo dominio

Un subdominio de DuckDNS pertenece a una cuenta. Así que la historia de coolcams.duckdns.org es, probablemente, la del mismo operador, salvo que la cediera. Y viene de lejos:

febrero          primeros registros de DNS del dominio y el primer binario Mirai que habla con él
marzo · abril    sirve un Mirai clásico en /bins/<arch>, desde 176.65.139.42
mayo             otro bot, distinto, con cat.sh, desde la misma IP; el 12 un blog analiza un bot
                 de este dominio, muy probablemente ese
junio            pasa a 31.56.209.231: ese bot, recompilado, y entre otras cosas iran.<arch>,
                 el kit público de IranBot
julio · octubre  tras dos saltos más, entra en el bloque 77.239.124.0/24 y pasa por varias IP
noviembre        Superior, y un segundo bot en Rust, desde 77.239.124.167

Lo mismo lo sirvieron otros dos nombres de DuckDNS, r34fa352.duckdns.org y toomanyways.duckdns.org: los ficheros que repartían son idénticos byte a byte a los de coolcams. Tres nombres para los mismos ficheros. Que se sirvan de respaldo unos a otros es la explicación habitual; aquí es una interpretación.

Pero el linaje hacia atrás no lo puedo cerrar. La IP de primavera era un servidor compartido: por ella pasaron otras marcas de bots, mineros y hasta dominios con pinta de phishing en 2025. Y en marzo, en las mismas fechas que coolcams, esa IP servía también, según Hunt.io, a otra botnet de cajas de TV que entra por ADB, xlabs_v1. Comparado con lo que se ha publicado de ella, no he encontrado nada en común. Compartieron servidor, y a la vez, pero era un servidor con muchos inquilinos, así que eso no prueba parentesco. Tampoco puedo descartarlo. Hay un cabo suelto que podría inclinarlo: un cool.sh que esa IP sirvió el 10 de marzo, que se asocia a xlabs pero cuyo nombre recuerda a coolcams, y del que no queda copia. Y el kit de IranBot lo servían más de cuarenta máquinas en otoño. Que el operador de coolcams pasara de un Mirai de catálogo a un bot de base pública y de ahí a uno propio es una lectura razonable. No es una prueba.

Donde sí hay continuidad es en el alojamiento, permisivo. El bloque 77.239.124.0/24 es el mismo desde el que repartía DIICOT en el capítulo 34, y en él conviven al menos media docena de operadores. Detrás hay tres capas: una sociedad británica de creación reciente que da la cara, una empresa rumana que anuncia las direcciones y un proveedor estonio por el que se enruta todo, sobre direcciones IPv4 de alquiler que cambian de manos en semanas. No es un alojamiento «a prueba de balas» con marca y publicidad: es uno que se monta por capas desechables.

ROCKET & MARINICA LTD    sociedad británica (Companies House 17340426), constituida el
(«RocketCloud»)          15-jul-2026, hosting, un único director, correo de Proton,
                         domicilio en una oficina virtual de Londres; dominio rocket-cloud.org
                         su organización en el registro europeo, un día antes (14-jul)
                         AS219141 «ROCKET-MARINICA», 24-jul; también 31.77.227.0/24
BANATSYNC                SRL rumana, AS198364; anuncia 77.239.124.0/24 desde el 18-jul
TakeHost                 OÜ estonia, AS214639: el tránsito principal de BANATSYNC
antes                    el bloque lo anunciaron Aeza (2025), Alfahost y Ace Data Centers II,
                         el mayorista estadounidense que alquila las direcciones

10Un equipo de producto

Lo que más dice del operador no es su infraestructura, sino cómo trabaja. Su escáner de ADB (casi seguro suyo: la misma secuencia, desde su propio bloque y desde el mismo proveedor que uno de sus instaladores), el de las cinco preguntas del capítulo anterior, ya llamaba a la puerta de este cebo el 19 de octubre, desde servidores de alquiler en Japón, Alemania y Singapur y desde su propio bloque, entre otros. En un honeypot público, su saludo aparece desde principios de octubre. Primero filtra; días después, otra máquina instala.

Y el instalador lleva telemetría. El guion /s, el que baja el bot en las máquinas que entran por Telnet, se presenta en su cabecera como «superior — telnet dropper». Lo bajé una vez, por Tor, y lo leí como texto. Va comentado en un inglés que explica el porqué de cada decisión. Esto es lo que hace, y lo que cambió entre el 7 y el 10 de noviembre:

balizas de embudo    nuevas el 10:
                     /b/s  el instalador se ha ejecutado
                     /b/x  el binario está descargado (con su tamaño)
                     /b/b  el binario está lanzado
                     /b/y  el bot está vivo (la manda el propio bot, con su PID)
reinfecciones        cambia el 10: el del 7 mataba las copias viejas; el del 10 ya no:
                     «A duplicate is cheaper than a hole»
routers              ya el 7: lee la cabecera ELF de la shell para saber la arquitectura,
                     porque «uname -m lies on a lot of routers», y antes eso acababa en SIGILL;
                     el 10 añade más lectores, y si falta od comprueba por tamaño
                     que lo bajado no sea una página de error
descarga             diecisiete formas de bajar el binario, más TFTP y HTTP a mano
panel                en los dos: la etiqueta de cada vía sirve para que las cajas se distingan
                     «on the CNC panel without a rebuild»

Mide la conversión de su embudo de infección: cuántos instaladores se ejecutan, cuántos descargan, cuántos lanzan y cuántos bots arrancan de verdad. Es lo que hace un equipo de producto. Y el comentario del SIGILL es la otra cara del capítulo anterior: él también sabe lo que es instalar el binario y verlo morir.

Ni siquiera la frase del duplicado es suya del todo: aparece tal cual en tres repositorios de este año que no tienen nada que ver, uno de ellos un proyecto para un asistente de programación con IA. Puede que esos comentarios los escribiera una IA. No lo sé.

El ritmo encaja: tres versiones del APK en dos días, el /s reescrito en tres (y el del día 10 pasa limpio: 0 de 75 en VirusTotal), un instalador nuevo el mismo día de la infección. Y no solo entra por ADB y por Telnet: según ThreatFox, su /s también se servía explotando una vulnerabilidad de PHPUnit en servidores web, CVE-2017-9841.

11Un segundo bot

El 8 de noviembre, entre el /s de Superior del día 7 y el del día 10, la misma dirección sirvió otra cosa. Cada uno de los tres lo tengo de una fuente distinta:

7-nov    Superior                         # de MalwareBazaar
8-nov    otro bot: RUSTBOX                # de la copia que guardó urlscan
10-nov   Superior                         # el que bajé yo; ya circulaba el 9

El del día 8 lo sirve un servidor que se presenta como Server: rustbox, lleva el mismo inglés explicativo y baja otro bot, escrito en Rust, que también pone ADB en el 12108 y usa un supervisor con el mismo nombre, .srvc. El mismo operador, eso lo afirmo con confianza alta, alternando sus dos bots en la misma dirección: parece una prueba A/B.

Lo que no afirmo es que el segundo descienda del primero. El código es otro, y la criptografía, aunque usa piezas de la misma familia, está montada de otra manera. Puede ser una reescritura con el mismo diseño o un bot nuevo que el mismo operador también maneja; el código no lo dice. Es el capítulo siguiente.

12Indicadores

Los de la infección y la caja de TV están en el capítulo anterior. Estos son los del binario, su red y su infraestructura.

Para cazarlo sin depender de su dirección: una caja en una red privada que, cada media hora, intenta conectar con 253 direcciones, casi todas de Internet, que comparten con ella los tres últimos números de la IP. Es un patrón distintivo, que permite buscarlo sin depender del dominio.