Mientras ves la tele, tu decodificador ataca Internet: Kimwolf convirtió Android TV en un ejército DDoS

Un receptor Android común puede permanecer junto al televisor durante años y casi no atraer la atención del propietario. Los operadores de Kimwolf usan esos dispositivos como nodos de un gran botnet, y en la versión v7 han complicado de forma notable tanto los ataques DDoS como la comunicación con la infraestructura de mando. El programa malicioso aprendió a generar tráfico HTTP/2 con señales propias de un auténtico Chrome, obtener la dirección del servidor de comandos a través de Ethereum y pasar a Tor si el canal principal deja de funcionar.

Kimwolf v7 fue detectado el 3 de febrero de 2026 durante la búsqueda de nuevos componentes del botnet tras publicaciones sobre versiones anteriores. Kimwolf infecta principalmente receptores de televisión y otros dispositivos con Android. El botnet emparentado para Linux, AISURU, opera al menos desde mediados de 2024, y la actividad del propio Kimwolf se puede rastrear desde agosto de 2025.

Uno de los cambios principales de la v7 está relacionado con HTTP/2. Los desarrolladores integraron la biblioteca nghttp2 y añadieron un método de ataque que crea una huella completa de navegador. Al enviar solicitudes, el bot selecciona encabezados y parámetros del protocolo siguiendo el patrón de Chrome, de modo que el servidor recibe tráfico que a nivel de HTTP/2 es mucho más difícil de distinguir de una sesión normal de navegador.

Las medidas de defensa contra DDoS evalúan de inmediato múltiples señales del cliente. Se tienen en cuenta la estructura de la solicitud, el conjunto y el orden de los encabezados HTTP, las configuraciones de HTTP/2 y las particularidades del establecimiento de la conexión. Un bot primitivo a menudo se delata por combinaciones no estándar de parámetros, mientras que Kimwolf v7 intenta reproducir el comportamiento de Chrome con mucha mayor precisión. La filtración de ataques a nivel de aplicación exige por ello un análisis más profundo, y un bloqueo sencillo por una huella conocida del cliente funciona peor.

Los desarrolladores reorganizaron la infraestructura de mando de forma igualmente notable. En el binario de Kimwolf v7 están registradas las direcciones de cinco servicios RPC públicos y legítimos de Ethereum. RPC, o Remote Procedure Call, permite a un programa dirigir llamadas a un nodo remoto de Ethereum mediante una interfaz de programación. Kimwolf usa esas solicitudes para trabajar con Ethereum Name Service, abreviado ENS, y obtiene a través de ENS la dirección actual del servidor C2.

Ethereum Name Service asocia nombres legibles con datos dentro del ecosistema Ethereum. Para Kimwolf el mecanismo es útil porque no es necesario codificar rígidamente la dirección IP del servidor de mando en el código del malware. El operador puede cambiar el registro asociado al nombre ENS, tras lo cual los dispositivos infectados obtendrán la nueva dirección a través de la cadena de bloques. Antes de cada consulta, Kimwolf mezcla la lista de cinco puntos RPC, por lo que el bloqueo de una puerta de enlace casi no altera la situación.

Los servicios RPC públicos no son maliciosos por sí mismos y atienden a muchas aplicaciones legítimas. Por eso el bloqueo masivo de tales nodos puede afectar al tráfico normal de Ethereum. Para buscar infecciones es más útil tener en cuenta el contexto: un receptor de televisión normalmente no necesita consultar de forma periódica la infraestructura de la cadena de bloques, especialmente si aparecen al mismo tiempo otras señales de Kimwolf.

Durante el análisis los especialistas encontraron además otra dirección, eth.rpcuniverse.com. Unit 42 la relaciona con moderada seguridad con los operadores del botnet. El dominio funcionaba en una infraestructura separada, apareció en un período cronológico coherente y solo se encontró en muestras de Kimwolf. Dos variantes analizadas del malware contenían esa dirección directamente en el código y contactaban con el servidor asociado, algo que no se observó en los cinco proveedores RPC legítimos. La suma de señales apunta a un servicio RPC intermedio preparado ad hoc, aunque los investigadores no lograron identificar al propietario del dominio.

Si no es posible obtener la dirección C2 mediante ENS, Kimwolf v7 cambia a un canal de reserva en Tor. En el programa está registrada una dirección v3 permanente en la zona de dominio .onion. Para la conexión se emplea una máquina de estados separada tor_proxy_state_machine: el malware realiza la negociación SOCKS5, envía una solicitud CONNECT a la dirección .onion necesaria, espera la respuesta del proxy y luego inicia el apretón de manos TLS dentro del túnel creado.

Entre el módulo principal de Kimwolf y la red externa los desarrolladores añadieron una capa adicional. El tráfico de mando se dirige primero a la dirección local 127.0.0.1 y al puerto 23075. Un proxy local decide entonces adónde enviar la conexión, directamente a Internet o a través de Tor. Esa arquitectura permite cambiar el enrutamiento sin modificar el módulo principal de DDoS y evita redistribuir todo el binario tras cada bloqueo o traslado del C2.

El esquema de tres niveles con ENS, Tor y proxy local surgió tras dos operaciones contra la infraestructura de mando de Kimwolf en diciembre de 2025. Los desarrolladores tuvieron claramente en cuenta el riesgo de una nueva desconexión de servidores y dividieron los componentes de modo que la pérdida de una ruta no interrumpa la conexión con toda la red infectada.

Kimwolf llega a los receptores Android por otra debilidad. Muchos dispositivos económicos se entregan con Android Debug Bridge accesible en el puerto TCP 5555. Android Debug Bridge, o ADB, es una herramienta de línea de comandos para comunicarse con un dispositivo Android. Mediante ADB, un desarrollador puede instalar aplicaciones, ejecutar comandos y depurar. El acceso de red abierto sin autenticación adecuada convierte esa interfaz de servicio en un punto de entrada cómodo.

Los operadores de Kimwolf acceden a las cajas mediante servicios de proxy residencial. Un proxy residencial enruta la conexión a través de un dispositivo en una red doméstica habitual, de modo que el atacante obtiene acceso a recursos que desde Internet pueden no estar disponibles directamente. Tras entrar en la red local, el atacante busca cajas con el puerto 5555 abierto y, mediante ADB, instala el software malicioso sin contraseña.

Tras la ejecución, Kimwolf trata de no llamar la atención con el nombre del proceso. Una de las variantes utiliza el nombre netd_service, similar a las designaciones de componentes de red sistémicos de Android. Los investigadores también hallaron ocho paquetes APK que se distribuyeron entre octubre y diciembre de 2025. Se disfrazaban como el componente del sistema SystemService, comprobaban la posibilidad de obtener acceso root y ejecutaban la carga útil integrada.

Las compilaciones APK cambiaron de forma notable entre versiones. La variante de octubre contenía tres componentes de bajo nivel; después los desarrolladores dejaron un solo binario y cambiaron el nombre del paquete. En noviembre la biblioteca integrada se renombró a libdevice.so, y en las compilaciones de diciembre recuperaron el nombre anterior. Para firmar los APK se usaron tres certificados distintos, incluyendo un certificado de depuración de Android y un certificado autofirmado con campos ficticios.

El componente ELF más antiguo encontrado data del 2 de septiembre de 2025 y está pensado para x86, no para ARM. En su interior había un archivo libcow.so, cuyo nombre los investigadores asocian con la vulnerabilidad Dirty COW CVE-2016-5195. El proceso se renombraba a inetd, imitando un servicio Unix conocido. Una versión posterior, libdevice.so, ya usaba el nombre de proceso TVHelper, orientado a entornos de receptores de televisión. El conjunto de muestras muestra cómo los desarrolladores fueron desplazando progresivamente la atención hacia Android TV y dispositivos ARM.

Las versiones para Android se compilan con el NDK, o Native Development Kit. El Android NDK permite incluir en las aplicaciones código nativo en C y C++. Para Kimwolf ese enfoque ofrece acceso directo a capacidades de red y del sistema de bajo nivel, necesarias para realizar ataques DDoS de alto rendimiento y para trabajar con el dispositivo fuera de la parte Java habitual de la aplicación.

Las primeras generaciones de Kimwolf combinaban varias funciones en un solo binario. El malware podía realizar ataques DDoS, funcionar como proxy de tráfico, abrir una shell inversa de comandos y trabajar con archivos del dispositivo infectado. Los datos sensibles se protegían con un esquema simple Stack XOR, las consultas DNS se enviaban a través de DNS over TLS y las órdenes del C2 se verificaban mediante firmas digitales en curvas elípticas. En versiones posteriores los desarrolladores empezaron a utilizar EtherHiding y trasladaron parte de los datos de infraestructura a la cadena de bloques.

En v7 la arquitectura se separó con mucha más rigidez. Del binario principal eliminaron el escaneo, la explotación de vulnerabilidades y la fuerza bruta de contraseñas. El acceso inicial lo proporcionan ahora cargadores externos, y Kimwolf, tras instalarse, se encarga de los ataques y opera como un nodo de red intermedio. Gracias a esa separación, el módulo principal detectado ya no contiene el conjunto completo de herramientas que permitiría reconstruir toda la cadena de infección de un vistazo.

También reorganizaron el conjunto de comandos DDoS. Las versiones anteriores soportaban 43 métodos con nombres en texto, mientras que v7 usa 15 variantes numeradas para ataques en las capas tres a siete del modelo OSI. La lista incluye flood TCP vía sockets, dos variantes de flood UDP, ataque a servidores de juegos por el puerto UDP 27015, flood DNS, floods TCP SYN, ACK, SYN-ACK y RST, flood UDP asincrónico, flood ICMP, apertura masiva de conexiones TCP usando epoll, flood TLS/HTTPS sobre BoringSSL y el nuevo flood HTTP/2 mediante nghttp2. Los números 8, 11 y 13 en la tabla de conmutación están ausentes. Los desarrolladores pudieron reservar posiciones o eliminar los métodos correspondientes al reducir el conjunto antiguo de comandos.

Para los ataques UDP los autores optimizaron por separado la generación de paquetes. El generador Xorshift256 obtiene el estado inicial desde /dev/urandom: el programa lee 32 bytes, es decir, cuatro valores de 64 bits. Si la fuente de datos aleatorios no está disponible, se emplea un inicializador de reserva SplitMix64. Las sumas de control IP y UDP se calculan con instrucciones vectoriales ARM NEON SIMD.

NEON permite al procesador ejecutar una operación sobre varios valores a la vez. En Kimwolf el bucle de cálculo de la suma de comprobación procesa en paralelo cuatro valores de 16 bits, reduciendo el coste de preparar cada paquete. La optimización se ajusta bien a los procesadores ARM, que se instalan masivamente en los receptores Android TV, y ayuda a un dispositivo doméstico limitado a enviar más tráfico UDP en el mismo intervalo de tiempo.

El análisis de la infraestructura de mando vinculó la v7 con 22 direcciones IP en un único sistema autónomo cuya geolocalización apunta a San Petersburgo. Desde el 18 de diciembre de 2025 hasta el 3 de febrero de 2026 los 22 nodos presentaron la misma clave SSH host. El primer servidor con esa clave apareció el 18 de diciembre; después la misma configuración se extendió a otros 21 direcciones durante seis semanas. El último nodo se añadió el 31 de enero. Fuera del rango encontrado, los investigadores no localizaron la misma clave SSH.

Una clave SSH host coincidente ayuda a relacionar servidores entre sí incluso después del cambio de direcciones IP. La propia dirección puede sustituirse rápidamente, trasladarse a otro hosting o desconectarse. La presencia de la misma clave criptográfica en un conjunto de nodos ofrece una señal técnica más sólida de infraestructura común.

La magnitud de Kimwolf ya pudo estimarse al estudiar versiones anteriores. Según XLab, el botnet infectó a más de 1,8 millones de dispositivos. Tras tomar el control de un dominio C2, los investigadores registraron alrededor de 2,7 millones de direcciones IP consultantes en tres días. El número de IP no puede compararse directamente con el número de dispositivos infectados debido a la asignación dinámica de direcciones y al cambio de redes, por lo que la estimación del número real de víctimas es menor.

Entre el 19 y el 22 de noviembre de 2025 la infraestructura de Kimwolf transmitió a los dispositivos infectados más de 1,7 millardos de comandos DDoS. El enorme volumen muestra cuán activamente los operadores usaron la red para ataques en ese período. Al mismo tiempo, el botnet siguió desempeñando funciones de proxy, que permiten encaminar tráfico ajeno a través de dispositivos domésticos infectados.

La infraestructura vinculada de Aisuru y Kimwolf participó en algunos de los ataques más potentes de finales de 2025. Cloudflare registró un DDoS con un pico de tráfico de 31,4 Tbit/s. En diciembre, televisores Android y receptores infectados lanzaron ataques HTTP contra clientes de Cloudflare y contra la propia infraestructura de la compañía a velocidades superiores a 200 millones de solicitudes por segundo. Los sistemas de protección detectaron y bloquearon los ataques de forma automática.

El 19 de marzo de 2026 el Departamento de Justicia de Estados Unidos informó sobre una operación internacional contra la infraestructura C2 de varios botnets de IoT. Las fuerzas del orden interrumpieron los servidores de mando de Aisuru, KimWolf, JackSkid y Mossad. En la operación participaron autoridades de Canadá y Alemania junto con empresas tecnológicas. Las autoridades estadounidenses obtuvieron autorizaciones judiciales para actuar contra los servidores por los que los dispositivos infectados recibían órdenes.

Para proteger los receptores Android TV, los especialistas recomiendan ante todo cerrar el acceso de red a ADB. Si la depuración es necesaria, conviene limitarla a la conexión USB. En redes corporativas, los dispositivos Android de consumo es preferible ubicarlos en un segmento separado sin acceso directo a sistemas de trabajo.

Al buscar Kimwolf hay que comprobar actividad de red inusual. Un receptor de televisión no debería, sin motivo aparente, establecer conexiones HTTPS con nodos RPC públicos de Ethereum, crear conexiones Tor, enrutar tráfico mediante SOCKS5 o conectarse al puerto local 23075. Otro indicador adicional es el proceso netd_service en un dispositivo Android de consumo. La combinación de varias señales justifica aislar la caja y revisar su actividad de red.