La botnet llamada kimlobo ha infectado más de 2 millones de dispositivos Android mediante túneles a través de redes proxy privadas, según los hallazgos de Synthient.
“Se observa que los actores clave involucrados en la botnet Kimwolf monetizan la botnet mediante la instalación de aplicaciones, venden ancho de banda proxy a usuarios residenciales y venden su funcionalidad DDoS”, dijo la compañía en un análisis publicado la semana pasada.
Kimwolf fue documentado públicamente por primera vez por QiAnXin XLab el mes pasado, documentando sus vínculos con otra botnet llamada AISURU. Kimwolf ha estado activo desde al menos agosto de 2025 y se considera una variante de Android de AISURU. Cada vez hay más pruebas de que la botnet estuvo detrás de una serie de ataques DDoS sin precedentes a finales del año pasado.
El malware convierte los sistemas infectados en conductos para enrutar el tráfico malicioso y orquestar ataques distribuidos de denegación de servicio (DDoS) a gran escala. La gran mayoría de las infecciones se concentran en Vietnam, Brasil, India y Arabia Saudita, y Synthient monitorea alrededor de 12 millones de direcciones IP únicas por semana.
Se descubrió que los ataques que propagan la botnet se dirigen principalmente a dispositivos Android que ejecutan un servicio expuesto de Android Debug Bridge (ADB) que utiliza una infraestructura de escaneo que utiliza servidores proxy privados para instalar el malware. Hasta el 67% de los dispositivos conectados a la botnet no están autenticados y ADB está habilitado de forma predeterminada.
Se sospecha que estos dispositivos ya están infectados con kits de desarrollo de software (SDK) de proveedores de proxy para poder integrarlos en secreto en la botnet. Los dispositivos más vulnerables incluyen televisores inteligentes y decodificadores no oficiales basados en Android.
En diciembre de 2025, las infecciones de Kimwolf utilizaron direcciones IP proxy ofrecidas en alquiler por IPIDEA, con sede en China, que implementó un parche de seguridad el 27 de diciembre para bloquear el acceso a dispositivos de red local y varios puertos sensibles. IPIDEA se describe a sí misma como el “proveedor de proxy IP líder en el mundo” con más de 6,1 millones de direcciones IP actualizadas diariamente y 69.000 nuevas direcciones IP diarias.
En otras palabras, el enfoque consiste en aprovechar la red proxy de IPIDEA y otros proveedores de proxy y luego hacer un túnel a través de las redes locales de los sistemas que ejecutan el software proxy para bloquear el malware. La carga útil principal escucha en el puerto 40860 y se conecta al 85.234.91(.)247:1337 para recibir más comandos.
“La escala de esta vulnerabilidad no tenía precedentes y expuso a millones de dispositivos a ataques”, dijo Synthient.
Además, los ataques infectan dispositivos con un servicio de monetización de ancho de banda llamado Plainproxies Byteconnect SDK, lo que sugiere intentos de monetización más amplios. El SDK utiliza 119 servidores de retransmisión que reciben tareas de proxy desde un servidor de comando y control, que luego son ejecutadas por el dispositivo comprometido.
Synthient dijo que descubrió la infraestructura utilizada para ataques de relleno de credenciales en servidores IMAP y sitios web populares en línea.
“La estrategia de monetización de Kimwolf fue evidente desde el principio a través de agresivas ventas de bienes raíces residenciales”, dijo la compañía. “Ofrecer servidores proxy para ancho de banda ilimitado a partir de 0,20 centavos por GB o 1,4 mil dólares al mes lograría una adopción temprana por parte de múltiples proveedores de servidores proxy”.
“El descubrimiento de cajas de TV preinfectadas y la monetización de estos bots a través de SDK secundarios como Byteconnect indica una relación cada vez más profunda entre los actores de amenazas y los proveedores de proxy comerciales”.
Para abordar el riesgo, se recomienda a los proveedores de proxy bloquear las solicitudes a direcciones RFC 1918, que son rangos de direcciones IP privadas definidos para su uso en redes privadas. Se recomienda a las organizaciones que bloqueen los dispositivos que ejecutan shells ADB no autenticados para evitar el acceso no autorizado.
About The Author
