Ilustración abstracta de pintura fluida en tonos violeta, magenta y negro para la noticia: Google tumba XCPE, un backdoor de fábrica en 1,3 millones de TV boxes

Malware

Google tumba XCPE, un backdoor de fábrica en 1,3 millones de TV boxes

Videostrong preinstaló el backdoor XCPE en TV boxes Android que Google y sus socios han dejado sin mando. TrendAI cuenta 25.240 equipos en España.

«A device manufacturer intentionally infecting their users with malware is an unacceptable breach of trust» (que un fabricante infecte a propósito a sus usuarios con malware es una ruptura inaceptable de la confianza). Con esa frase justifica el Google Threat Intelligence Group la operación que anunció el día 2 de noviembre de 2026 contra XCPE, un backdoor que Videostrong Technology, fabricante chino de TV boxes Android, preinstaló en más de 1,3 millones de equipos para alquilar su acceso a redes de proxies residenciales y de fraude publicitario, y del que TrendAI contó 25.240 dispositivos en España entre junio y octubre.

  • El día 2 de noviembre de 2026, Google anunció el desmantelamiento de XCPE, un backdoor que atribuye con confianza alta al fabricante Videostrong Technology, preinstalado en más de 1,3 millones de TV boxes Android.
  • El backdoor x.cpe corre con privilegios de system, se reinstala desde la partición /oem/ y recibe órdenes por MQTT en claro desde mqtt.szbboys.com, con módulos de proxy residencial, fraude publicitario y backdoors de BadBox.
  • TrendAI contó 1.472.554 equipos de 206 modelos entre junio y octubre de 2026, con 25.240 en España, y Synthient publica 182 cadenas de modelo, entre ellas la familia MECOOL KM.
  • La caída de los dominios deja los equipos sin mando, pero el implante sigue en el firmware. Desinstalar o restablecer de fábrica no sirve y la salida es un firmware limpio del fabricante o sustituir el equipo.

Lo que Google atribuye a Videostrong y lo que la operación ha desconectado

El informe de GTIG sitúa el desmantelamiento en la semana anterior al anuncio y atribuye el backdoor, con confianza alta, a Videostrong Technology Co., una empresa de Shenzhen que trabaja como OEM y ODM (fabrica equipos con su marca y para marcas de terceros). Según Google, la empresa no se limitó a colar el código en el firmware. Vendía el acceso a afiliados y cargaba en los equipos infectados los módulos de esos afiliados, que convertían cada TV box en nodo de salida de proxies residenciales, en generador de impresiones publicitarias falsas o en plataforma para instalar más malware.

La respuesta ha sido legal y comercial. Google ha emprendido acciones para tumbar los dominios y servidores con los que Videostrong gobernaba la botnet y, en la misma operación, los dominios de mando y control de más de una docena de familias de malware que se distribuían como módulos. Como esos afiliados reparten sus módulos por otros canales, GTIG calcula que la caída de sus C2 corta el acceso a al menos 10 millones de dispositivos más. Videostrong y cualquier filial futura quedan vetadas para fabricar dispositivos Android certificados o suministrar software a otros fabricantes certificados, y Google ha cambiado la forma en que comprueba la integridad del firmware de los Android TV certificados. El fabricante había superado las pruebas de certificación con técnicas de ofuscación que retrasaban la carga del código malicioso hasta después del primer arranque.

La cuenta de Google Cloud Security resumió el caso en X el mismo 2 de noviembre con la idea que distingue a XCPE de otras botnets, que aquí no entró ningún atacante porque fue el propio fabricante quien escondió la puerta en sus equipos. En la nota conjunta publicada el mismo día figuran los socios de la operación, Plume, TrendAI, Lumen, HUMAN Security, Synthient y la Agencia Nacional de Policía de Japón, y una frase de Charley Snyder, Head of Disruption Operations de GTIG, sobre el objetivo de estas acciones, que demuestran que «the infrastructure they rely on isn't out of reach» (la infraestructura de la que dependen no está fuera de alcance). El mismo esquema de acción legal contra dominios es el que usó Microsoft en octubre contra la red de phishing YAM Store.

La atribución tiene pruebas fuera de Google. Synthient, que llegó a Videostrong tras comprar a finales de 2025 un MECOOL KM9PRO Max con el backdoor de serie, publica en su repositorio de GitHub las huellas de los certificados con los que se firmaban las actualizaciones OTA y las apps del sistema, y en dos de ellos la identidad es una dirección de correo corporativa de Videostrong. Según recoge BleepingComputer del informe de Synthient, el servidor de ficheros del backdoor tenía un directorio abierto con un PDF firmado por el director de I+D de la empresa, y el dominio corporativo de Videostrong resolvía a la misma dirección IP que uno de los servidores de mando. La mayoría de los equipos infectados son TV boxes, pero GTIG también ha visto el backdoor en dispositivos de telemedicina, máquinas de karaoke y cartelería digital.

De x.cpe a com.abc.nexus, cómo un TV box pasa a ser proxy residencial

Diagrama de Google con el ecosistema de XCPE: backdoor x.cpe, loader com.abc.nexus, broker MQTT y módulos de monetización
Fuente: Google Threat Intelligence Group, «Shutting the Door on the XCPE Botnet»

El diagrama de GTIG resume una arquitectura en tres piezas que Videostrong fue separando desde finales de 2024, según Google como posible respuesta a sus acciones anteriores contra BadBox. La primera es el backdoor x.cpe (com.oemservice en algunas compilaciones), un paquete preinstalado en la partición del sistema que corre con el identificador android.uid.system. Si el usuario lo desinstala, el receptor de arranque lo vuelve a copiar desde la partición /oem/ al reiniciar. La segunda es el loader com.abc.nexus, que recibe las órdenes de x.cpe por comunicación entre procesos, extrae librerías nativas y pone en marcha los módulos. La tercera son los módulos de monetización, que desarrollan los afiliados y no Videostrong.

El mando y control tiene dos fases. Al arrancar, x.cpe envía un POST HTTP cifrado con AES a un servidor de registro en anyevonline.com (mcstb.anyevonline.com si la propiedad ro.mecool.device vale true, y un subdominio formado con la versión de Android en el resto) y recibe tres configuraciones, entre ellas las credenciales del broker MQTT. A partir de ahí mantiene una conexión persistente con mqtt.szbboys.com y se suscribe a temas con la forma /device/{modelo}/{chipId}/{acción}. El libro blanco de Plume, que arrancó su investigación al ver un dominio sospechoso en una petición MQTT, añade un dato que da la medida del descuido, que la configuración llega con el flag useSsl a false, así que las órdenes viajan en claro por TCP. El 8 de septiembre de 2026 Plume contó 424.108 sesiones en el clúster de ese broker a través de su endpoint de Prometheus, y encontró la consola de administración de EMQX expuesta en el puerto 18083.

Por ese canal los operadores podían instalar APK sin que apareciera nada en pantalla, ejecutar comandos y scripts de shell con privilegios de system, capturar la pantalla de forma continua con la API oculta SurfaceControl.screenshot, inyectar pulsaciones de teclado y reconocer la red local con un binario de traceroute. Para que las instalaciones silenciosas funcionen, el backdoor borra el consentimiento del usuario y apaga Google Play Protect poniendo a -1 el ajuste global package_verifier_user_consent. Son las mismas recomendaciones de seguridad para IoT que llevamos años repitiendo, pero vistas desde el lado del atacante, que las desactiva una a una.

Tabla de TrendAI con comandos shell enviados por MQTT a los TV boxes infectados por XCPE, como ps, getprop y setprop
Fuente: TrendAI Research, «TrendAI™ Research Helps Disrupt Botnet of More Than 1.3 Million Pre-Infected Set-Top Boxes»

La tabla de TrendAI muestra el tipo de órdenes que llegaban por MQTT a los equipos. Los operadores comprobaban si había Magisk o SuperSU instalados, buscaban procesos de módulos rivales como RewardService o appsalt, leían propiedades del sistema y en un caso activaban ADB por TCP en el puerto 5555. TrendAI, que midió la botnet entre el 3 de junio y el 1 de octubre de 2026, contabilizó más de 187.000 instalaciones silenciosas por recuento de descargas y vio un script que apagaba Play Protect en un gran número de equipos.

Esquema de TrendAI con la evolución del loader com.abc.nexus de XCPE entre 2025 y junio de 2026
Fuente: TrendAI Research, «TrendAI™ Research Helps Disrupt Botnet of More Than 1.3 Million Pre-Infected Set-Top Boxes»

El loader no ha dejado de cambiar. TrendAI documenta una línea de 2025 (versiones 1.4.x a 1.7.4) con proxy, fraude publicitario y el dropper com.mm.a.moyu, una versión 1.7.81 en mayo de 2026 que incorpora el módulo de Linkfog, y una 1.7.89 en junio de 2026 que añade Honeygain y Traffmonetizer, la librería antianálisis libseccomp_guard.so y un limpiador que desinstalaba unos 90 paquetes de botnets rivales. GTIG describe el último giro, que desde agosto de 2026 el canal MQTT instala droppers disfrazados de aplicaciones del sistema, con nombres como com.android.system.ntp y com.android.sso.auth.handler, que extraen una librería libexploit.so para reiniciar adbd como root, remontar /system en escritura y copiarse en /system/priv-app/ con un fichero de permisos que les concede INSTALL_PACKAGES y REBOOT. Uno de los parámetros, persist.networkstack.install_time, falsea la fecha de instalación para que el paquete parezca tan antiguo como el resto del sistema.

Los módulos que cargaban esos droppers son el negocio. GTIG enumera SDK de proxies residenciales y de reparto de ancho de banda de Linkfog, Jaguar, AppSalt (el SDK de Honeygain, propiedad de Oxylabs), BWM/IPWeb, GaGaNode (de IPCola, que a su vez inicializa NetNut/Popanet y EarnFM) y Traffmonetizer, módulos de fraude publicitario como HiddenView, que carga páginas en WebViews ocultos y simula clics, y backdoors de segundo nivel como Moyu, Spirit y Bird, los dos últimos ya vistos en BadBox. TrendAI calcula que el producto de proxies ofrecía unas 180.000 direcciones IP domésticas cada día y que en cuatro meses pasaron por la red más de 3,8 millones de IP residenciales y móviles distintas, el tipo de acceso que se vende en el mercado del cibercrimen para que un atacante parezca un cliente local ante un banco o una tienda online.

25.240 TV boxes en España y un MECOOL que se vende en tiendas online

Gráfico de barras de TrendAI con los países con más de 25.000 TV boxes infectados por XCPE, España con 25.240
Fuente: TrendAI Research, «TrendAI™ Research Helps Disrupt Botnet of More Than 1.3 Million Pre-Infected Set-Top Boxes»

El gráfico de TrendAI es el dato español de esta historia. Su telemetría cuenta 1.472.554 dispositivos infectados de 206 modelos en más de 170 países entre el 3 de junio y el 1 de octubre de 2026, y España aparece con 25.240 equipos, el último de los dieciocho países que superan los 25.000. Malasia (300.390), Brasil (150.080), Irak (124.298), México (94.588) y Taiwán (88.350) encabezan la lista, y en Europa están por delante Alemania (39.065) y Reino Unido (29.489). El mapa del informe de GTIG también pinta España entre los países con presencia de x.cpe. Al cierre de esta noticia no consta aviso de INCIBE-CERT ni del CCN-CERT sobre XCPE.

Las cifras no coinciden entre socios y conviene saber de dónde sale cada una.

Cifra

Quién la da y cuándo

Más de 1,3 millones de TV boxes con XCPE

Google Threat Intelligence Group, informe del 2 de noviembre de 2026

Al menos 10 millones de dispositivos más sin C2 de afiliados

GTIG, estimación tras la caída de los dominios de los módulos

1.472.554 dispositivos de 206 modelos en más de 170 países

TrendAI, telemetría del 3 de junio al 1 de octubre de 2026

Unos 1,33 millones con módulos de proxy o fraude activados

TrendAI, mismo periodo

25.240 dispositivos en España

TrendAI, mismo periodo

424.108 sesiones en el broker mqtt.szbboys.com

Plume, endpoint de Prometheus del broker, 8 de septiembre de 2026

26.477 conexiones en el broker usamqtt.szbboys.com (YOKATV)

Plume, misma fecha

182 cadenas de modelo observadas en la campaña

Synthient, repositorio público en GitHub

Plume explica la diferencia por el momento de cada instantánea y por lo que ve cada uno. Su desglose por fabricante, sacado del tráfico MQTT, reparte los equipos entre Droidlogic (189.352, con marcas como SviCloud), ext-MECOOL (182.585, la compilación de la clase KM2), el código de inquilino AB (92.482, con el modelo PRO-M2 popular en Irak), equipos con marca Google (59.031, entre ellos el INTV-110 de Steren en México) y Aquario (40.087, el STV-3000 Plus brasileño). Plume insiste en que la flota mezcla dispositivos AOSP sin certificar con dispositivos certificados por Google, suministrados por Videostrong o por sus socios. La certificación no fue una garantía en este caso.

Montaje de Synthient con la web de MECOOL, su página de Facebook y anuncios del KM9PRO Max en tiendas online
Fuente: Synthient, «The Internals of a Badbox Operation»

El montaje de Synthient recoge la marca con la que más se ha asociado el caso. MECOOL pertenece, según Krebs on Security, a Skyworth Technology, una empresa china cotizada, y el fabricante del KM9PRO Max que analizó Synthient figura en el firmware como SkyworthDigital, con Google TV sobre Android 12, compilación C1.0.8 del 25 de marzo de 2025 y parche de seguridad de febrero de 2025. Su repositorio de GitHub lista 182 cadenas de modelo observadas en la campaña, de KM1 a KM9PRO_MAX pasando por KM2, KM6, KM7 y KM8, con una advertencia literal, «A model name alone is not sufficient to confirm compromise» (el nombre del modelo por sí solo no basta para confirmar el compromiso). El KM9PRO Max figura en el catálogo de tiendas online españolas como equipo certificado para Netflix. Ben Brundage, fundador de Synthient, dijo a Krebs on Security que la cifra de 1,3 millones es conservadora y que «This is probably the largest operation against backdoored TV boxes that we’ve seen» (probablemente es la mayor operación contra TV boxes con backdoor que hemos visto).

XCPE es la cuarta gran botnet de TV boxes Android en dos años, y la primera que se atribuye al propio fabricante. BadBox 2.0 se interrumpió en marzo de 2025 y Google demandó a sus operadores en julio de ese año. Kimwolf infectó millones de equipos en enero de 2026 aprovechando fallos de los propios SDK de proxy, según la investigación de Synthient que cita Krebs, y en julio de 2026 el FBI incautó cientos de dominios de NetNut por la botnet Popa. En cada caso la respuesta fue la misma, tumbar los dominios, y en cada caso el implante siguió en los equipos. TrendAI lo dice sin matices para XCPE, «cleanup needs vendor action, platform protection or replacement of the device» (la limpieza requiere la acción del fabricante, protección de la plataforma o sustituir el dispositivo), y recuerda que operadores de este tipo ya han reconstruido su infraestructura otras veces. Desde este blog lo leemos como el caso de cadena de suministro más puro que hemos cubierto este año, más aún que el de las actualizaciones de AOMEI Backupper, porque aquí nadie comprometió un servidor de actualizaciones, fue el fabricante quien diseñó el backdoor como producto. Y lo que cabe esperar es que los afiliados cambien de loader, como advierte el propio Google, y que los equipos sigan conectados a las redes de quien los compró.

Indicadores de compromiso que publican Google, TrendAI y Synthient

GTIG publica en su informe la lista completa de dominios de cada módulo y de las once cuentas de GitHub que alojaban los paquetes como releases, TrendAI mantiene un fichero de indicadores con los hashes de las muestras y Synthient añade certificados, hosts y URL en GitHub. Esta tabla reúne los más útiles para buscar en DNS, proxies y en el propio equipo, con los valores tal como los escriben las fuentes.

Tipo

Valor

Contexto

dominio

*[.]anyevonline[.]com

Subdominios de registro y configuración inicial de x.cpe (GTIG)

dominio

szbboys[.]com

Dominio principal del C2 de XCPE (GTIG)

dominio

mqtt[.]szbboys[.]com

Broker MQTT que reparte las órdenes a los equipos (GTIG)

dominio

ott[.]szbboys[.]com

Subida y descarga de ficheros y actualizaciones OTA (GTIG)

dominio

intermedia-arts[.]tv

C2 de reserva de los paquetes de sistema (GTIG)

dominio

yokatvonline[.]com

C2 de reserva ligado al reproductor YokaTV (GTIG)

IP

219[.]134[.]163[.]210

Aloja el broker MQTT del C2 (GTIG)

IP

219[.]134[.]163[.]211

Aloja el broker MQTT del C2 (GTIG)

IP

38[.]145[.]197[.]135

Aloja anyevonline[.]com y el servidor de ficheros (GTIG)

IP

23[.]94[.]49[.]57

Servidor de ficheros y de mando y control (GTIG)

URL

github[.]com/Aviciiii/

Cuenta de GitHub del operador que aloja módulos como releases (GTIG)

URL

github[.]com/yf-videostrong/

Cuenta de GitHub del operador con el nombre de la empresa (GTIG)

nombre de paquete

x.cpe

Backdoor principal preinstalado en el firmware (GTIG)

nombre de paquete

com.oemservice

Nombre alternativo del backdoor en algunas compilaciones (GTIG)

nombre de paquete

com.abc.nexus

Loader y motor de ejecución de los módulos (GTIG)

nombre de paquete

com.android.system.ntp

Dropper disfrazado de app del sistema desde agosto de 2026 (GTIG)

nombre de paquete

com.android.sso.auth.handler

Dropper disfrazado de app del sistema desde agosto de 2026 (GTIG)

nombre de paquete

com.ota.service

Módulo de fraude publicitario HiddenView cargado desde GitHub (GTIG)

ruta de archivo

/oem/

Partición desde la que x.cpe se reinstala tras cada reinicio (GTIG)

ruta de archivo

/system/priv-app/

Destino de los droppers que se instalan con libexploit.so (GTIG)

hash SHA-256

d5a72e40f8821334ecfda30541435f8a9ad2fae1eb9aae133dd298bf1be374c7

com.abc.nexus v1.4.6, compilación firmada (TrendAI)

hash SHA-256

cd8ef4ba20823b926b45a04946f24e45a7bcd4bf2bfc439cac8061a43f146903

com.abc.nexus v1.7.89, compilación firmada (TrendAI)

hash SHA-256

07b511a6f7715ccd2f77b5f51e4cf46542ccaada99564252711f4a142ac26179

Muestra del backdoor x.cpe (TrendAI)

certificado

9f6e3ba0389ee113e3cd861c57a4f39771c77ddb040a209bd919e5adc55b506b

Certificado OTA con identidad hong.luo@videostrong.com (Synthient)

certificado

f90a646f51f4b9a96694ccad099b20e97a1556c81c4fa3375dd6c42e8198231f

Firma de las apps Yoka, CPE y herramientas de depuración (Synthient)

Las direcciones del broker reciben las conexiones de los equipos por los puertos 3885 a 3887, y GTIG observó que los operadores gestionaban el broker por la API REST (8082), WebSocket (8083) y la consola web de EMQX (18083) desde direcciones que no eran de bots. Para una organización, cualquier conexión saliente de un dispositivo de red doméstica o de oficina hacia esos dominios o puertos merece una revisión.

Cómo saber si tu TV box está en la botnet y qué hacer con él

La comprobación más fiable se hace con ADB desde un ordenador conectado al TV box, porque los paquetes del backdoor no aparecen en el listado de aplicaciones de la interfaz. Estos comandos buscan los paquetes que nombran GTIG y TrendAI, las copias en /oem/ y /system/priv-app/, el ajuste que apaga Play Protect y las propiedades que usan los droppers nuevos.

adb shell pm list packages | grep -E 'x\.cpe|com\.oemservice|com\.abc\.nexus|com\.android\.system\.ntp|com\.android\.sso\.auth\.handler|com\.ota\.service'
adb shell ls -la /oem/ /system/priv-app/
adb shell settings get global package_verifier_user_consent
adb shell getprop | grep -E 'persist\.networkstack|ro\.mecool\.device'

Un valor -1 en package_verifier_user_consent, cualquier paquete de la lista o una propiedad persist.networkstack.* son motivo para dar el equipo por comprometido. Quien tenga varios equipos puede seguir la guía de auditoría de dispositivos IoT que publicamos para automatizar la revisión. A partir de ahí, por orden de urgencia.

  1. Desconecta de internet cualquier TV box cuyo modelo esté en la lista de Synthient o cuyo fabricante sea Videostrong, MECOOL, SkyworthDigital, Steren, SviCloud o Aquario hasta terminar la comprobación con ADB.
  2. Busca en los registros DNS del router o del firewall, y en los proxies de salida, consultas a anyevonline.com, szbboys.com, yokatvonline.com e intermedia-arts.tv desde el 3 de junio de 2026, y conexiones TCP salientes a 219.134.163.210, 219.134.163.211, 38.145.197.135 y 23.94.49.57 por los puertos 3885 a 3887.
  3. No confíes en desinstalar el paquete ni en un restablecimiento de fábrica. x.cpe se reinstala desde /oem/ al reiniciar y los droppers de agosto de 2026 viven en /system/priv-app/. Sin un firmware limpio del fabricante, la salida es sustituir el equipo o dejarlo sin red.
  4. Si decides conservarlo mientras llega un firmware, aíslalo en una VLAN o red de invitados sin acceso al resto de la casa o la oficina y bloquea en el firewall los dominios e IP de la tabla.
  5. En una empresa, trata los TV boxes de salas de reuniones, cartelería y recepción como cualquier otro dispositivo IoT, inventaría quién los suministró y exige al proveedor la versión de firmware y el fabricante real del equipo.
  6. Si gestionas un servicio online, revisa con el equipo antifraude los accesos desde IP residenciales que fallan varias veces al iniciar sesión. TrendAI recomienda registrar huellas de red como JA4T y combinarlas con señales de comportamiento antes de bloquear.
  7. Notifica el caso a INCIBE-CERT (empresas y particulares, también por el 017) y al CCN-CERT cuando el equipo esté en una administración pública.

Para quien administre el DNS de la casa o de la oficina con dnsmasq o Pi-hole, estas cuatro líneas devuelven una dirección nula para los dominios de registro, mando y reserva del backdoor, de modo que un equipo infectado se queda sin broker aunque alguien levante de nuevo la infraestructura con las mismas direcciones.

address=/anyevonline.com/0.0.0.0
address=/szbboys.com/0.0.0.0
address=/yokatvonline.com/0.0.0.0
address=/intermedia-arts.tv/0.0.0.0

El bloqueo no limpia el equipo ni impide que los droppers ya instalados sigan ejecutando sus módulos, así que sirve como contención mientras se sustituye el TV box, no como solución.

Dudas habituales sobre los Android TV box tras la caída de XCPE

¿Cómo resetear un Android TV box?

El restablecimiento de fábrica se hace desde Ajustes, Sistema, Restablecer, o con el botón de recuperación del equipo. Con XCPE no sirve de nada, porque el backdoor vive en las particiones /oem/ y /system/, que el restablecimiento no toca, y no en los datos del usuario. Tras el reinicio x.cpe se vuelve a instalar y se conecta al broker. Solo un firmware completo firmado por el fabricante, o el cambio de equipo, elimina el implante.

¿Cómo actualizar un Android TV box?

En un Google TV certificado las actualizaciones del sistema llegan por Ajustes, Sistema, Información, Actualización del sistema, y Google ha endurecido desde el 2 de noviembre las comprobaciones de integridad del firmware de esos equipos. En un equipo AOSP sin certificar la actualización depende solo de la marca, y en el caso de Videostrong el canal OTA estaba firmado con certificados de la propia empresa, así que una actualización legítima y un módulo malicioso llegaban por la misma vía.

¿Qué Android TV box comprar?

Comprueba en Google Play, en Ajustes, Acerca de, que el equipo aparece como certificado por Play Protect y que la marca publica actualizaciones con fecha. No es una garantía absoluta, porque Plume encontró dispositivos certificados dentro de la flota de XCPE, pero descarta la mayoría de las cajas de marca blanca que anuncian cientos de canales de pago por un pago único. Conviene completar la protección con alguno de los antivirus para Android que hemos analizado, aunque ninguno puede limpiar la partición del sistema de un equipo como estos. Ese mismo 2 de noviembre Google retiró a Videostrong la licencia para fabricar cualquier dispositivo con sus aplicaciones preinstaladas.

Temas

No hay comentarios todavía