Google ha desmantelado XCPE, una botnet que reclutó más de 1,3 millones de TV box y decodificadores Android mediante una puerta trasera que, según su equipo de inteligencia de amenazas, instaló de forma deliberada el propio fabricante, Videostrong Technology Co., para sacar dinero de los equipos. Google Threat Intelligence Group (GTIG) publicó el análisis el 2 de noviembre de 2026 y sitúa la operación la semana anterior, con la colaboración de la Agencia Nacional de Policía de Japón, Lumen, HUMAN Security, Plume, Synthient y TrendAI.
Las claves de la botnet XCPE en 20 segundos
- XCPE controlaba más de 1,3 millones de TV box Android y otros equipos IoT.
- Google la atribuye, con alta confianza, a Videostrong, un fabricante de dispositivos Android.
- El acceso se vendía a afiliados para fraude publicitario y proxies residenciales.
- Retirar los dominios de esos afiliados corta, según Google, el acceso a otros 10 millones de dispositivos.
El caso tiene un componente que lo separa de la mayoría de botnets de dispositivos domésticos. Aquí no hubo contraseñas por defecto ni vulnerabilidades sin parchear: el código malicioso venía de serie en el firmware. GTIG describe a Videostrong como OEM (Original Equipment Manufacturer, fabricante de equipo original) y ODM (Original Design Manufacturer, fabricante que diseña y produce equipos que luego venden otras marcas), y sostiene que la campaña no fue obra de un empleado desleal ni un descuido de desarrollo. En palabras del propio informe (traducción propia), «un fabricante de dispositivos que infecta intencionadamente a sus usuarios con malware es una ruptura inaceptable de la confianza».
Aunque la inmensa mayoría de los equipos infectados eran decodificadores Android TV, Google también encontró el malware en otros dispositivos IoT basados en Android, como equipos de telemedicina, máquinas de karaoke y pantallas de señalización digital. El informe no cita marcas ni modelos concretos y se limita a decir que el código estaba integrado en muchos modelos y marcas diferentes durante varios años. Synthient, uno de los socios, ha explicado por su parte que localizó el malware preinstalado en un MECOOL KM9PRO Max comprado a finales de 2025, según recoge BleepingComputer.
Una puerta trasera en la partición del sistema que vuelve tras cada reinicio
La pieza central es un paquete llamado x.cpe (en algunas versiones, com.oemservice), precargado en la partición del sistema y ejecutado con el nivel de privilegio android.uid.system. Google exige a los fabricantes certificados una batería de pruebas de compatibilidad y seguridad, pero Videostrong recurrió a técnicas de ofuscación para aprovechar un hueco en esas pruebas y cargar el código malicioso después del primer arranque, según GTIG.
La persistencia está pensada para que el usuario no pueda deshacerse de ella. Al tratarse de una aplicación del sistema, x.cpe no se puede eliminar desde el propio dispositivo, y si se desinstala de /data/app/, su servicio BootReceiver la reinstala en el siguiente reinicio a partir de la partición /oem/. Además, el malware desactiva la verificación de aplicaciones de Google Play Protect fijando el ajuste global package_verifier_user_consent en -1.
Desde finales de 2024, Videostrong evolucionó hacia una arquitectura de tres fases. x.cpe se ocupa de la comunicación con el servidor de mando y control (C2, command and control), un cargador llamado com.abc.nexus ejecuta los módulos y estos, desarrollados por los afiliados, llegan como demonios ELF nativos, SDK integrados o APK secundarios. Google apunta que ese cambio pudo ser una respuesta a sus acciones anteriores contra BadBox, aunque lo plantea como posibilidad. Desde agosto de 2026 aparecieron además nuevos instaladores disfrazados de componentes del sistema, como com.android.system.ntp y com.android.sso.auth.handler, que escalan privilegios con libexploit.so, montan /system en modo escritura, se instalan en /system/priv-app/ y manipulan la fecha de instalación para confundirse con el resto de paquetes del sistema.
El canal de control combinaba dos piezas. Primero, una petición HTTP POST a subdominios de anyevonline[.]com con telemetría del hardware cifrada con AES. Después, una conexión MQTT persistente con mqtt.szbboys[.]com, desde la que los operadores podían instalar APK en silencio, ejecutar comandos de shell, capturar la pantalla, inyectar pulsaciones de teclado y reconocer la red local. GTIG precisa que la mayoría de las órdenes servían para instalar, desinstalar y configurar módulos, pero también detectó shells inversas.
Indicadores de compromiso publicados
El informe incluye tablas extensas de IOC (indicators of compromise, indicadores de compromiso). Estos son algunos de los principales, en formato desactivado:
| Indicador | Función según Google |
|---|---|
| mqtt[.]szbboys[.]com (puertos 3885-3887) | Bróker MQTT de mando y control |
| 219[.]134[.]163[.]210 y 219[.]134[.]163[.]211 | Alojan el bróker MQTT |
| 23[.]94[.]49[.]57 y 38[.]145[.]197[.]135 | Alojamiento de ficheros y C2 |
| *[.]anyevonline[.]com | Subdominios de registro de los equipos |
| szbboys[.]com y ott[.]szbboys[.]com | C2 principal, subida de ficheros y OTA |
| intermedia-arts[.]tv y yokatvonline[.]com | C2 de respaldo para paquetes del sistema |
| 3768f470934a111f1c3e3d098eb1392a3cb6f3e298ef5fd2a6309e6a98ee1e18 | SHA-256 de x.cpe |
| 1f2ab93c35f0c37d9b88f82268183a2f77491aa6b142a48381524b18e217b960 | SHA-256 de com.abc.nexus |
Google publica además los hashes de los módulos de afiliados, una lista de once cuentas de GitHub que alojaban paquetes como versiones publicadas y cerca de un centenar de dominios vinculados a uno de los SDK de proxy.
Un negocio de alquiler: fraude publicitario y proxies residenciales
Según GTIG, Videostrong rentabilizaba la puerta trasera vendiendo acceso a afiliados criminales y cargando sus módulos en los equipos infectados. Esos módulos se dedicaban al fraude publicitario, a convertir el dispositivo en un nodo de proxy residencial sin avisar al usuario y a instalar más malware. Google identificó varias puertas traseras de segunda fase (Spirit, Moyu, Bird y Fission) y un módulo de fraude publicitario llamado HiddenView, además de una decena de SDK de proxy residencial y de compartición de ancho de banda que enumera en el informe. Moyu y Bird ya se habían visto antes, según la compañía, dentro de la trama BadBox.
La explotación era intensiva: en un mismo aparato llegaron a convivir hasta tres SDK de proxy residencial. Ese tráfico sale con la IP de una conexión doméstica, así que resulta mucho más difícil de bloquear que el de un centro de datos. El informe insiste en que la inscripción silenciosa, sin consentimiento del usuario, sigue siendo la forma más habitual de convertir dispositivos en nodos de salida. Google ya actuó contra este mercado a comienzos de año, cuando interrumpió la red de proxies IPIDEA.
El precedente más cercano es BADBOX 2.0. El FBI publicó el 5 de junio de 2025 un aviso a través del IC3 (Internet Crime Complaint Center) en el que explicaba que esos equipos llegaban infectados antes de la compra o se contaminaban al descargar aplicaciones durante la configuración. El 17 de julio de 2025 Google demandó en un tribunal federal de Nueva York a sus responsables y cifró la botnet en más de 10 millones de dispositivos sin certificar con AOSP (Android Open Source Project, la versión de código abierto de Android), sin las protecciones de Google. GTIG no presenta XCPE como una continuación de BADBOX, pero sí señala módulos compartidos. El informe tampoco menciona Vo1d, otra botnet de TV box Android documentada en 2024, así que no hay base para vincularlas.
Entre las medidas que enumera Google figuran acciones legales para retirar los dominios y servidores de Videostrong, la retirada de los dominios de C2 de más de una docena de familias de malware cargadas como módulos, la ruptura de relaciones con el fabricante, la prohibición de que Videostrong o futuras filiales fabriquen dispositivos Android certificados o suministren software a otros fabricantes certificados, y cambios en la verificación de la integridad del firmware de los Android TV certificados. El informe no detalla si hubo sumidero (sinkhole) de dominios ni qué tribunales intervinieron.
Qué pueden hacer usuarios y operadores
Como el código forma parte del firmware de origen, desinstalar aplicaciones o restablecer el aparato no basta. La primera comprobación es si el dispositivo está certificado. Según la ayuda oficial de Google Play, hay que abrir la aplicación Google Play Store, tocar el icono de perfil arriba a la derecha, entrar en Ajustes y pulsar Información, donde aparece la certificación de Play Protect. Solo los equipos certificados pueden incluir Play Store, de modo que una TV box que no la trae, o que muestra «Dispositivo no certificado», merece desconfianza. El aviso del FBI sobre BADBOX 2.0 añadía otras señales: aparatos de marcas desconocidas, anunciados como desbloqueados o capaces de dar acceso a contenido gratis, y aplicaciones que piden desactivar Play Protect.
Ante un equipo sospechoso, lo prudente es desconectarlo de la red y sustituirlo por un modelo de un fabricante reconocido. Google remite a su lista de socios certificados de Android TV y pide desconfiar de las aplicaciones que ofrecen dinero a cambio de compartir el ancho de banda que no se usa. A los distribuidores les reclama auditorías de seguridad independientes de los ODM y retirar del catálogo a los fabricantes implicados.
Los proveedores de acceso a internet (ISP, Internet Service Provider) tienen una posición especial. Según Alejandro D’Egidio, responsable de proyectos especiales en CABASE (Cámara Argentina de Internet), en una publicación en LinkedIn, detrás de un CGNAT (Carrier-Grade NAT, la traducción de direcciones que permite a muchos clientes compartir una misma IP pública) basta un dispositivo infectado para que esa IP acabe en listas de bloqueo y perjudique a cientos de abonados. D’Egidio recuerda que el usuario no puede limpiar algo que vive en el firmware y propone que los operadores revisen los flujos hacia la infraestructura de C2 publicada, avisen al cliente en lugar de limitarse a bloquear y compartan inteligencia entre ellos. Google pide algo parecido en su informe a plataformas móviles, ISP y mercados en línea, un terreno en el que los centros de operaciones de seguridad de los ISP ya trabajan.
Preguntas frecuentes
¿Qué es la botnet XCPE?
Es una red de más de 1,3 millones de dispositivos, sobre todo TV box Android, controlados mediante una puerta trasera preinstalada en el firmware. Google la atribuye con alta confianza al fabricante Videostrong Technology Co.
¿Se puede eliminar XCPE de una TV box infectada?
No desde el propio dispositivo. El paquete x.cpe es una aplicación del sistema y se reinstala desde la partición /oem/ tras cada reinicio, así que lo recomendable es desconectar el equipo y sustituirlo.
¿Cómo sé si mi TV box está certificada por Google?
En Google Play Store, toca el icono de perfil, entra en Ajustes y después en Información para ver la certificación de Play Protect. Si el aparato no trae Play Store o aparece como no certificado, conviene desconfiar.
¿Qué relación tiene XCPE con BADBOX 2.0?
Google no las presenta como la misma operación, pero indica que dos módulos cargados por XCPE, Moyu y Bird, ya se habían visto en la trama BadBox. También sugiere que Videostrong reorganizó su malware tras las acciones de Google contra BadBox.
Fuentes:
- Google Threat Intelligence Group: Shutting the door on the XCPE botnet
- Google: We’re taking legal action against the BadBox 2.0 botnet (17/07/2025)
- FBI / IC3: Home Internet Connected Devices Facilitate Criminal Activity (05/06/2025)
- Ayuda de Google Play: Comprobar y corregir el estado de certificación de Play Protect
- Android: socios certificados
- BleepingComputer: Google disrupts million-device XCPE Android malware botnet
- Alejandro D’Egidio (CABASE) en LinkedIn
