Kimwolf v7
Kimwolf v7 (también rastreado como AISURU) es una botnet para Android y dispositivos IoT que ha estado activa desde al menos agosto de 2024 y que en febrero de 2026 fue descubierta en su séptima versión por la Unidad 42 de Palo Alto Networks . Esta nueva variante representa una evolución significativa de la botnet, con mejoras sustanciales en sus capacidades de ataque DDoS y en la resiliencia de su infraestructura de Comando y Control (C2). La botnet se propaga principalmente abusando de servicios de proxy residenciales para alcanzar televisores Android y decodificadores que tienen habilitado el puerto 5555 de Android Debug Bridge (ADB) en redes locales, instalando el malware sin autenticación una vez que los atacantes tunelizan a través del proxy hacia la red local .
El payload analizado es un binario ELF ARM de 32 bits enlazado estáticamente, compilado con el NDK de Android usando Clang y Bionic libc, que enlaza estáticamente BoringSSL para operaciones TLS y nghttp2 para funcionalidad HTTP/2 . Al ejecutarse, el malware se oculta como el proceso legítimo netd_service para pasar desapercibido entre los procesos del sistema Android, y crea un socket Unix @n[redacted]boxv7 para asegurar que solo una instancia se ejecute a la vez . La versión v7 ha consolidado los comandos de ataque DDoS en 15 métodos numerados (en lugar de los 43 métodos con nombre de texto de versiones anteriores), eliminando por completo los módulos de escaneo, explotación y fuerza bruta, lo que indica que los operadores han separado la cadena de propagación del binario principal, delegando la tarea de acceso inicial a un cargador externo .
La innovación más destacada de Kimwolf v7 es la incorporación de un ataque DDoS basado en HTTP/2 que construye huellas digitales completas del navegador (incluyendo encabezados como User-Agent, Accept-Language y Accept-Encoding que imitan a Chrome y Safari), haciendo que el tráfico de ataque sea prácticamente indistinguible de la navegación legítima . Además, implementa una arquitectura C2 de tres niveles diseñada específicamente para sobrevivir a intentos de desmantelamiento: un mecanismo principal que utiliza el Servicio de Nombres de Ethereum (ENS) para resolver direcciones C2 a través de cinco endpoints RPC públicos hardcodeados (como 0xrpc.io/eth y eth.llamarpc.com), un servicio oculto Tor .onion (edctgwib2n5l34t525zkxqzk5bqb6e5il2yiq5r6zu7gtlxa4uosn3qd.onion) codificado como respaldo, y un proxy local en 127.0.0.1:23075 que enruta todo el tráfico C2 tanto hacia la red abierta como hacia Tor, permitiendo que el componente proxy sea actualizado independientemente del binario principal . Los operadores también han optimizado el rendimiento de los ataques utilizando instrucciones NEON SIMD para el cálculo de checksums UDP, diseñadas específicamente para los procesadores ARM que se encuentran en los dispositivos Android TV, maximizando el rendimiento de paquetes por segundo . La botnet también se distribuye a través de paquetes APK que se hacen pasar por un servicio del sistema llamado SystemService, los cuales buscan obtener acceso de superusuario y ejecutan un payload ELF del kernel empaquetado en su interior, con al menos ocho APK identificados entre octubre y diciembre de 2025 .
Funcionamiento de Kimwolf v7
1. Estructura del binario y ejecución inicial
El binario principal de Kimwolf v7 es un ELF ARM de 32 bits enlazado estáticamente, compilado con el NDK de Android utilizando Clang y Bionic libc . Enlaza estáticamente BoringSSL para operaciones TLS y nghttp2 para la funcionalidad HTTP/2 . Aunque el binario está "stripped" (sin símbolos de depuración), conserva suficiente información de símbolos para que los investigadores puedan identificar la versión . La cadena de versión interna n[redacted]boxv7 identifica esta muestra como la versión 7 de la botnet .
Al ejecutarse:
- Crea un socket Unix
@n[redacted]boxv7para garantizar que solo una instancia del malware se ejecute simultáneamente - Cambia su nombre de proceso a
netd_servicepara mezclarse con los procesos legítimos del sistema Android - Lee 32 bytes de
/dev/urandompara sembrar el generador de números pseudoaleatorios Xorshift256 (con fallback SplitMix64 si/dev/urandomno está disponible)
2. Arquitectura C2 de tres niveles
El sistema de Comando y Control ha sido rediseñado para sobrevivir a desmantelamientos, incorporando tres capas de resolución:
Nivel 1: Resolución mediante Ethereum Name Service (ENS)
El binario contiene cinco endpoints RPC públicos de Ethereum hardcodeados en texto plano:
hxxps://0xrpc.io/ethhxxps://eth.llamarpc.comhxxps://ethereum-rpc.publicnode.comhxxps://eth-protect.rpc.blxrbdn.comhxxps://eth.merkle.io
El malware utiliza estos endpoints legítimos para consultar registros ENS y obtener direcciones C2. Para aumentar la resiliencia, los endpoints se barajan aleatoriamente usando el PRNG antes de cada intento de resolución, y el malware implementa una redundancia de cinco vías que hace que el bloqueo sea extremadamente difícil .
Un sexto endpoint, eth.rpcuniverse.com, fue identificado con confianza moderada como operado por los propios atacantes:
- Resuelve a una única IP (
23.94.221.104) en un VPS de bajo costo - El dominio fue registrado el 9 de diciembre de 2023
- Está presente en dos muestras de Kimwolf junto a los cinco endpoints legítimos
- Su certificado TLS fue emitido por Let's Encrypt y apareció días después del registro del dominio
Nivel 2: Servicio oculto Tor como respaldo
Cuando la resolución ENS falla, el malware recurre a un servicio oculto Tor v3 hardcodeado:
edctgwib2n5l34t525zkxqzk5bqb6e5il2yiq5r6zu7gtlxa4uosn3qd.onion
La función tor_proxy_state_machine gestiona los estados del protocolo:
- Envía el saludo SOCKS5 (
0x05 0x01 0x00) - Construye una solicitud CONNECT con el tipo de dominio
0x03y la dirección .onion de 62 bytes - Espera la respuesta y realiza un handshake TLS a través del túnel
Nivel 3: Proxy local para enrutamiento flexible
Todo el tráfico C2, tanto hacia la red abierta como hacia Tor, se enruta a través de un proxy local en 127.0.0.1:23075. Esta arquitectura modular permite que el componente proxy sea actualizado independientemente del binario principal de la botnet .
3. Capacidades de ataque DDoS
Kimwolf v7 soporta 15 métodos de ataque DDoS numerados del 0 al 17 (con los casos 8, 11 y 13 ausentes, presumiblemente reservados para uso futuro):
| Caso | Función | Descripción |
|---|---|---|
| 0 | attack_case0_tcp_socket_flood
|
Inundación TCP basada en sockets |
| 1 | attack_case1_udp_flood_v1
|
Inundación UDP variante 1 |
| 2 | attack_case2_game_server_udp
|
Inundación UDP para servidores de juegos (puerto 27015) |
| 3 | attack_case3_dns_flood
|
Inundación de consultas DNS |
| 4 | attack_case4_udp_flood_v2
|
Inundación UDP variante 2 |
| 5 | attack_case5_tcp_syn_flood
|
Inundación TCP SYN |
| 6 | attack_case6_tcp_ack_flood
|
Inundación TCP ACK |
| 7 | attack_case7_tcp_synack_flood
|
Inundación TCP SYN-ACK |
| 9 | attack_case9_udp_async_flood
|
Inundación UDP asíncrona |
| 10 | attack_case10_tcp_rst_flood
|
Inundación TCP RST |
| 12 | udp_flood_attack
|
Inundación UDP de alto rendimiento (NEON SIMD) |
| 14 | attack_case14_icmp_flood
|
Inundación ICMP |
| 15 | attack_case15_tcp_connection_flood
|
Inundación de conexiones TCP (basada en epoll) |
| 16 | attack_case16_tls_https_flood
|
Inundación TLS/HTTPS (BoringSSL) |
| 17 | attack_case17_http2_flood
|
Inundación HTTP/2 con huellas de Chrome |
La función attack_case17_http2_flood es la innovación más significativa:
- Utiliza la biblioteca nghttp2 para generar tráfico HTTP/2 legítimo
- Construye encabezados completos de navegador que imitan a Chrome y Safari
- Incluye campos como
User-Agent,Accept-Language,Accept-Encodingy otros - Hace que el tráfico de ataque sea casi indistinguible de la navegación legítima
UDP Flood optimizado con NEON SIMD
La función de inundación UDP de alto rendimiento utiliza instrucciones NEON SIMD:
- Lee 32 bytes de
/dev/urandompara sembrar el PRNG Xorshift256 - Procesa cuatro halfwords de 16 bits simultáneamente usando instrucciones
VLD1.16,VADDW.U16yVADD.I32 - Esta optimización está diseñada específicamente para los procesadores ARM que se encuentran en los dispositivos Android TV
- Reduce significativamente la sobrecarga de checksum por paquete para maximizar el rendimiento
4. Distribución a través de APK Android
Los operadores distribuyen paquetes APK que se hacen pasar por un servicio del sistema llamado SystemService:
- Clase componente:
systemservice0644.N[redacted]Kernel - Certificados de firma: Tres certificados diferentes:
- Certificado original de Kimwolf (C=CN, CN=a)
- Certificado de depuración de Android
- Certificado autofirmado con sujeto
C=XK, ST=lol, L=lol, O=lol, OU=lol, CN=lol
Funcionamiento:
- El APK se ejecuta y busca acceso de superusuario (root)
- Ejecuta el payload ELF del kernel empaquetado con comandos como:
bash
chmod 755 /data/data/com.android.logcatd/libn[redacted]kernel.so /data/data/com.android.logcatd/libn[redacted]kernel.so
- El payload ELF puede ser uno de tres binarios:
libn[redacted]kernel.so(ARM) - El más comúnlibdevice.so(ARM) - Renombra su proceso aTVHelperlibn[redacted]kernel.so(x86) - La muestra más antigua, que atacaba la vulnerabilidad Dirty COW
Los kernels ELF extraídos no incrustan los endpoints RPC de Ethereum; la capa de resolución C2 reside en el APK wrapper o en el binario ELF independiente, mientras que el kernel maneja las operaciones de bajo nivel de la botnet .
5. Infraestructura C2 y agrupación
El análisis de infraestructura reveló:
- Direcciones IP C2 (todas en AS202799, San Petersburgo, Rusia):
212.193.31.158:443(HTTPS, offline después del 31 de enero de 2026)212.193.31.119:13y212.193.31.122:13(tráfico C2)212.193.31.92:443(HTTPS)212.193.31.102(primer host observado el 18 de diciembre de 2025)
- Clave SSH compartida: Todos los hosts presentaban la misma clave SSH, lo que permitió pivotar e identificar 22 IPs totales en el mismo rango que compartían la clave entre el 18 de diciembre de 2025 y el 3 de febrero de 2026
- Dominio operador:
eth.rpcuniverse.com(registrado el 9 de diciembre de 2023, resuelve a23.94.221.104en AS36352 RackNerd, Dallas)
Impacto y consecuencias de Kimwolf v7 (técnico y extenso)
1. Escala de la botnet y alcance del impacto
Kimwolf v7 representa una evolución de una botnet que ya era de gran escala, afectando a dispositivos Android TV y decodificadores en redes locales a nivel global . La transición de la botnet desde la explotación tradicional de Linux (usando Dirty COW en arquitectura x86) hacia el modelo actual de propagación basado en ADB para Android indica una expansión significativa de su superficie de ataque, aprovechando la proliferación de dispositivos Android TV económicos que a menudo vienen con ADB habilitado por defecto en el puerto 5555 . La capacidad de la botnet para escalar rápidamente se ve facilitada por:
- El abuso de servicios de proxy residenciales que permiten a los atacantes tunelizar hacia redes locales
- La instalación sin autenticación en dispositivos con ADB expuesto
- La masificación de dispositivos IoT con prácticas de seguridad deficientes
2. Consecuencias para las organizaciones
Para las organizaciones, las consecuencias de una infección por Kimwolf v7 son múltiples y severas:
Impacto en la red corporativa:
- Dispositivos Android TV no gestionados (como los utilizados en salas de reuniones o espacios comunes) pueden convertirse en nodos de la botnet
- El tráfico DDoS generado desde estos dispositivos puede saturar el ancho de banda de la red, afectando operaciones legítimas
- La participación en ataques DDoS puede llevar a que la dirección IP de la organización sea incluida en listas negras de reputación
Riesgos de seguridad:
- El malware establece un proxy local en
127.0.0.1:23075que puede ser utilizado para enrutar tráfico malicioso a través de la red corporativa - La botnet elimina todo el código de escaneo y explotación, delegando la propagación a cargadores externos, lo que significa que los operadores pueden reemplazar fácilmente el módulo de propagación sin cambiar el binario principal
Desafíos de detección:
- El tráfico HTTP/2 con huellas de navegador legítimo dificulta la distinción entre ataques y navegación normal
- Las conexiones a endpoints RPC públicos de Ethereum desde dispositivos IoT son altamente anómalas y pueden ser utilizadas como indicador de compromiso
- El tráfico Tor y las conexiones al proxy local
127.0.0.1:23075son señales detectables
3. Resistencia a desmantelamientos
La arquitectura C2 de tres niveles representa un avance significativo en la resiliencia operativa:
- Redundancia ENS: Los cinco endpoints RPC públicos hacen que el bloqueo de un solo endpoint sea inefectivo
- Respaldo Tor: Incluso si la resolución ENS es bloqueada, el malware puede recurrir al servicio oculto Tor
- Proxy local modular: Permite actualizar el componente de enrutamiento sin necesidad de recompilar todo el binario
La respuesta directa de los operadores a los intentos de desmantelamiento de diciembre de 2025 demuestra que:
- Están monitoreando activamente la visibilidad de su infraestructura
- Realizan ajustes operativos en respuesta a la exposición pública
- Invierten en redundancia y resiliencia para mantener la botnet operativa
4. Consecuencias para defensores y recomendaciones técnicas
Indicadores de Compromiso (IoCs) detectables:
| IoC | Descripción |
|---|---|
netd_service
|
Proceso malicioso en dispositivos Android |
@n[redacted]boxv7
|
Socket Unix de instancia única |
Conexiones a 0xrpc.io/eth, eth.llamarpc.com
|
Tráfico Ethereum RPC desde dispositivos IoT |
127.0.0.1:23075
|
Proxy local C2 |
| Conexiones Tor | Tráfico hacia el servicio oculto .onion
|
23.94.221.104
|
IP del operador (eth.rpcuniverse.com)
|
212.193.31.*
|
Rango IP C2 (AS202799, Rusia) |
Recomendaciones técnicas:
- Segmentación de red: Aislar los dispositivos Android TV y IoT de las redes corporativas
- Deshabilitar ADB: Desactivar Android Debug Bridge en todos los dispositivos Android TV, o restringir su acceso a conexiones USB únicamente
- Monitoreo de red: Buscar tráfico hacia endpoints Ethereum RPC, conexiones Tor y conexiones al puerto
23075en localhost - Auditoría de procesos: Identificar procesos
netd_serviceen dispositivos Android TV (que no deberían tener este proceso legítimamente) - Actualizaciones de seguridad: Mantener todos los dispositivos Android TV actualizados, especialmente aquellos que podrían ser vulnerables a versiones antiguas de ADB
5. Perspectivas a largo plazo
La evolución de Kimwolf desde una botnet Linux tradicional (con explotación de Dirty COW) hacia un modelo centrado en Android con ADB refleja una tendencia más amplia en el ecosistema de botnets: el movimiento hacia la masificación de dispositivos IoT con vectores de propagación simples pero efectivos . La separación del pipeline de propagación del binario DDoS principal sugiere que los operadores están construyendo una infraestructura modular donde los componentes pueden ser actualizados independientemente, similar a las arquitecturas de malware modernas como las de los cargadores (loaders) . Es probable que futuras versiones de Kimwolf continúen:
- Añadiendo más métodos de ataque DDoS basados en protocolos modernos (HTTP/3, QUIC)
- Incorporando técnicas de evasión adicionales (ofuscación de tráfico, rotación de User-Agent)
- Expandiendo el soporte a más arquitecturas y plataformas (x86_64, MIPS, RISC-V)
La eliminación de los módulos de escaneo y explotación en v7 sugiere que los operadores están profesionalizando su operación, separando roles y responsabilidades (un equipo para propagación, otro para ataques DDoS), lo que hace que la botnet sea más difícil de desmantelar por completo .
Origen y motivación de Kimwolf v7 (un solo párrafo)
Kimwolf v7 es una botnet para Android y dispositivos IoT que ha estado activa desde al menos agosto de 2024, evolucionando desde una botnet Linux tradicional llamada AISURU que atacaba dispositivos IoT con Linux . Su origen se rastrea hasta mediados de 2024, cuando inicialmente apuntaba a sistemas Linux x86 explotando la vulnerabilidad Dirty COW (CVE-2016-5195) para obtener acceso, antes de pivotar hacia la propagación basada en Android Debug Bridge (ADB) en agosto de 2025, explotando televisores Android y decodificadores que vienen con ADB habilitado en el puerto 5555 . La motivación principal de Kimwolf es financiera y operativa, generando ingresos mediante la venta de servicios de ataques de denegación de servicio distribuido (DDoS) como parte de un modelo de DDoS-for-hire (DDoS como servicio), donde los operadores alquilan el poder de cómputo de la botnet para lanzar ataques contra objetivos de los clientes. La evolución constante del malware, la inversión en infraestructura C2 resiliente (con ENS, Tor y proxy local) y la optimización de ataques para procesadores ARM mediante NEON SIMD indican que los operadores están altamente motivados para mantener una botnet escalable, difícil de desmantelar y rentable, características típicas de cibercriminales profesionales con fines de lucro .