Fernando.VH en 18:12 12 ago 2026

2026-08-12T18:12:24Z

← Revisión anterior		Revisión del 18:12 12 ago 2026
Línea 261:		Línea 261:

	* [[Mitigaciones Botnets\|Relación de acciones para mitigar el riesgo de esta actividad maliciosa.]]		* [[Mitigaciones Botnets\|Relación de acciones para mitigar el riesgo de esta actividad maliciosa.]]

			[[Category:Familias de malware\|Familias de malware]]

Fernando.VH: Relación de acciones para mitigar el riesgo de esta actividad maliciosa.

2026-08-12T18:11:59Z

Relación de acciones para mitigar el riesgo de esta actividad maliciosa.

← Revisión anterior		Revisión del 18:11 12 ago 2026
Línea 259:		Línea 259:
	== Origen y motivación de Kimwolf v7 (un solo párrafo) ==		== 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 .		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 .

			* [[Mitigaciones Botnets\|Relación de acciones para mitigar el riesgo de esta actividad maliciosa.]]

Fernando.VH: Descripción de Kimwolf v7

2026-08-12T18:11:31Z

Descripción de Kimwolf v7

Página nueva

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 <code>netd_service</code> para pasar desapercibido entre los procesos del sistema Android, y crea un socket Unix <code>@n[redacted]boxv7</code> 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 <code>User-Agent</code>, <code>Accept-Language</code> y <code>Accept-Encoding</code> 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 <code>0xrpc.io/eth</code> y <code>eth.llamarpc.com</code>), un servicio oculto Tor .onion (<code>edctgwib2n5l34t525zkxqzk5bqb6e5il2yiq5r6zu7gtlxa4uosn3qd.onion</code>) codificado como respaldo, y un proxy local en <code>127.0.0.1:23075</code> 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 <code>SystemService</code>, 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 <code>n[redacted]boxv7</code> identifica esta muestra como la versión 7 de la botnet .

Al ejecutarse:

* Crea un socket Unix <code>@n[redacted]boxv7</code> para garantizar que solo una instancia del malware se ejecute simultáneamente
* Cambia su nombre de proceso a <code>netd_service</code> para mezclarse con los procesos legítimos del sistema Android
* Lee 32 bytes de <code>/dev/urandom</code> para sembrar el generador de números pseudoaleatorios Xorshift256 (con fallback SplitMix64 si <code>/dev/urandom</code> no 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:

* <code>hxxps://0xrpc.io/eth</code>
* <code>hxxps://eth.llamarpc.com</code>
* <code>hxxps://ethereum-rpc.publicnode.com</code>
* <code>hxxps://eth-protect.rpc.blxrbdn.com</code>
* <code>hxxps://eth.merkle.io</code>

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, <code>eth.rpcuniverse.com</code>, fue identificado con confianza moderada como operado por los propios atacantes:

* Resuelve a una única IP (<code>23.94.221.104</code>) 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:

<code>edctgwib2n5l34t525zkxqzk5bqb6e5il2yiq5r6zu7gtlxa4uosn3qd.onion</code>

La función <code>tor_proxy_state_machine</code> gestiona los estados del protocolo:

# Envía el saludo SOCKS5 (<code>0x05 0x01 0x00</code>)
# Construye una solicitud CONNECT con el tipo de dominio <code>0x03</code> y 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 <code>127.0.0.1:23075</code>. 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):
{| class="wikitable"
!Caso
!Función
!Descripción
|-
|0
|<code>attack_case0_tcp_socket_flood</code>
|Inundación TCP basada en sockets
|-
|1
|<code>attack_case1_udp_flood_v1</code>
|Inundación UDP variante 1
|-
|2
|<code>attack_case2_game_server_udp</code>
|Inundación UDP para servidores de juegos (puerto 27015)
|-
|3
|<code>attack_case3_dns_flood</code>
|Inundación de consultas DNS
|-
|4
|<code>attack_case4_udp_flood_v2</code>
|Inundación UDP variante 2
|-
|5
|<code>attack_case5_tcp_syn_flood</code>
|Inundación TCP SYN
|-
|6
|<code>attack_case6_tcp_ack_flood</code>
|Inundación TCP ACK
|-
|7
|<code>attack_case7_tcp_synack_flood</code>
|Inundación TCP SYN-ACK
|-
|9
|<code>attack_case9_udp_async_flood</code>
|Inundación UDP asíncrona
|-
|10
|<code>attack_case10_tcp_rst_flood</code>
|Inundación TCP RST
|-
|12
|<code>udp_flood_attack</code>
|Inundación UDP de alto rendimiento (NEON SIMD)
|-
|14
|<code>attack_case14_icmp_flood</code>
|Inundación ICMP
|-
|15
|<code>attack_case15_tcp_connection_flood</code>
|Inundación de conexiones TCP (basada en epoll)
|-
|16
|<code>attack_case16_tls_https_flood</code>
|Inundación TLS/HTTPS (BoringSSL)
|-
|17
|<code>attack_case17_http2_flood</code>
|Inundación HTTP/2 con huellas de Chrome
|}

==== HTTP/2 Flood con huellas de navegador ====
La función <code>attack_case17_http2_flood</code> 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 <code>User-Agent</code>, <code>Accept-Language</code>, <code>Accept-Encoding</code> y 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 <code>/dev/urandom</code> para sembrar el PRNG Xorshift256
* Procesa cuatro halfwords de 16 bits simultáneamente usando instrucciones <code>VLD1.16</code>, <code>VADDW.U16</code> y <code>VADD.I32</code>
* 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 <code>SystemService</code>:

* Clase componente: <code>systemservice0644.N[redacted]Kernel</code>
* Certificados de firma: Tres certificados diferentes:
*# Certificado original de Kimwolf (C=CN, CN=a)
*# Certificado de depuración de Android
*# Certificado autofirmado con sujeto <code>C=XK, ST=lol, L=lol, O=lol, OU=lol, CN=lol</code>

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:
#* <code>libn[redacted]kernel.so</code> (ARM) - El más común
#* <code>libdevice.so</code> (ARM) - Renombra su proceso a <code>TVHelper</code>
#* <code>libn[redacted]kernel.so</code> (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):
** <code>212.193.31.158:443</code> (HTTPS, offline después del 31 de enero de 2026)
** <code>212.193.31.119:13</code> y <code>212.193.31.122:13</code> (tráfico C2)
** <code>212.193.31.92:443</code> (HTTPS)
** <code>212.193.31.102</code> (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: <code>eth.rpcuniverse.com</code> (registrado el 9 de diciembre de 2023, resuelve a <code>23.94.221.104</code> en 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 <code>127.0.0.1:23075</code> que 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 <code>127.0.0.1:23075</code> son 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:
{| class="wikitable"
!IoC
!Descripción
|-
|<code>netd_service</code>
|Proceso malicioso en dispositivos Android
|-
|<code>@n[redacted]boxv7</code>
|Socket Unix de instancia única
|-
|Conexiones a <code>0xrpc.io/eth</code>, <code>eth.llamarpc.com</code>
|Tráfico Ethereum RPC desde dispositivos IoT
|-
|<code>127.0.0.1:23075</code>
|Proxy local C2
|-
|Conexiones Tor
|Tráfico hacia el servicio oculto <code>.onion</code>
|-
|<code>23.94.221.104</code>
|IP del operador (<code>eth.rpcuniverse.com</code>)
|-
|<code>212.193.31.*</code>
|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 <code>23075</code> en localhost
# Auditoría de procesos: Identificar procesos <code>netd_service</code> en 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 .

Kimwolf v7 - Historial de revisiones

Fernando.VH en 18:12 12 ago 2026

Fernando.VH: Relación de acciones para mitigar el riesgo de esta actividad maliciosa.

Fernando.VH: Descripción de Kimwolf v7