---
title: "La botnet XCPE pone a prueba a los operadores: CGNAT, NetFlow y proxies"
description: "La botnet XCPE convirtió más de 1,3 millones de TV box Android en proxies residenciales. Qué supone para los operadores: CGNAT, reputación de IP y detección con NetFlow."
url: https://revistacloud.com/botnet-xcpe-operadores-cgnat-netflow-proxies-residenciales/
date: 2026-11-05
modified: 2026-11-05
author: "Antonio"
image: https://revistacloud.com/wp-content/uploads/2026/11/ai-photorealistic-wide-shot-inside-a-telecom-operator-network-o-g0YuEk.png
categories: ["Noticias", "Seguridad"]
tags: ["Android", "ciberseguridad", "fraude", "google", "IoT", "isp", "Lumen", "malware", "operadores", "telecomunicaciones"]
type: post
lang: es
---

# La botnet XCPE pone a prueba a los operadores: CGNAT, NetFlow y proxies

**Google y seis socios, entre ellos el operador Lumen, han desmantelado XCPE, una botnet de más de 1,3 millones de decodificadores Android que, según Google Threat Intelligence Group (GTIG), su propio fabricante, Videostrong Technology Co., convirtió en un negocio de fraude publicitario y proxies residenciales.** El informe, publicado el 2 de noviembre de 2026, describe un problema que los operadores conocen bien: equipos domésticos que el cliente no puede limpiar y cuyo tráfico sale a internet con la IP del propio proveedor de acceso.

**Las claves de la botnet XCPE para los operadores en 30 segundos**

- Más de 1,3 millones de TV box Android llevaban de fábrica una puerta trasera atribuida a Videostrong.
- El acceso se vendía a terceros, que instalaban hasta tres SDK de proxy residencial en un mismo equipo.
- Participaron la Agencia Nacional de Policía de Japón, Lumen, HUMAN Security, Plume, Synthient y TrendAI.
- Google calcula que retirar los dominios de los afiliados corta el acceso a otros 10 millones de dispositivos.
- Detrás de un CGNAT, un solo equipo infectado puede comprometer la reputación de una IP compartida.

Según GTIG, la puerta trasera venía precargada en la partición del sistema de los decodificadores, con privilegios de sistema, y se reinstalaba sola tras cada reinicio desde la partición `/oem/`. Google sostiene, con alta confianza, que Videostrong, un OEM (Original Equipment Manufacturer, fabricante de equipo original) y ODM (Original Design Manufacturer) de dispositivos Android, desarrolló y explotó la botnet de forma intencionada. El análisis técnico completo de la persistencia, la arquitectura en tres fases y los indicadores publicados está en [el artículo de OpenSecurity sobre la botnet XCPE](https://www.opensecurity.es/google-desmantela-botnet-xcpe-tv-box-android/).

La respuesta de Google combina vías legales y de plataforma. La compañía ha emprendido acciones para retirar los dominios y servidores con los que Videostrong controlaba la botnet, y también los dominios de C2 (command and control, mando y control) de más de una docena de familias de malware que se cargaban como módulos. Además, ha roto relaciones con el fabricante, le ha prohibido construir dispositivos Android certificados o suministrar software a otros fabricantes certificados y ha anunciado cambios en la verificación de la integridad del firmware de los Android TV certificados. Videostrong había usado ofuscación para aprovechar un hueco en las pruebas de certificación y cargar el código después del primer arranque.

## Un nodo de salida en el salón del cliente

El modelo de negocio explica por qué este caso afecta a la infraestructura más allá del propio dispositivo. Según el informe, Videostrong vendía el acceso a afiliados criminales y cargaba sus módulos en los equipos: fraude publicitario, inscripción silenciosa en redes de proxy residencial e instalación de más malware. Google identificó una decena de SDK de proxy residencial y de compartición de ancho de banda, y casos en los que hasta tres convivían en un mismo aparato. GTIG añade que la inscripción silenciosa, sin consentimiento del usuario, sigue siendo la vía más habitual para convertir dispositivos en nodos de salida.

Para un proveedor cloud, una plataforma de comercio electrónico o un servicio con autenticación, ese tráfico no llega desde rangos de centros de datos fáciles de filtrar, sino desde direcciones de operadores domésticos que comparten con clientes legítimos. El informe de Google habla de fraude publicitario, exfiltración de datos y enrutamiento de tráfico malicioso a través de los equipos. Por eso las empresas que bloquean o puntúan el tráfico procedente de proxies residenciales se enfrentan a un equilibrio delicado: endurecer el filtro sobre una IP residencial puede dejar fuera a usuarios reales que no tienen nada que ver con el abuso. RevistaCloud ya analizó esta presión en su informe sobre [el hogar conectado como munición de botnets y proxies contra la nube](https://revistacloud.com/informe-iot-2026-hogar-conectado-botnets-proxies-nube/).

La cifra de 10 millones merece una lectura precisa. No son equipos de XCPE, sino dispositivos comprometidos por los afiliados a través de otros canales de distribución distintos de esta puerta trasera. Google estima que, al retirar los dominios de C2 de esos afiliados, pierden el acceso a al menos esa cantidad adicional.

## CGNAT, reputación de IP y detección en la red

Alejandro D’Egidio, responsable de proyectos especiales en CABASE (Cámara Argentina de Internet), ha planteado en una publicación en LinkedIn la lectura desde el lado del operador. Según D’Egidio, detrás de un CGNAT (Carrier-Grade NAT, la traducción de direcciones a escala de operador que permite a muchos abonados compartir una misma IP pública) un solo dispositivo infectado puede hacer que esa dirección termine en listas de bloqueo y afecte a cientos de clientes. También recuerda que el usuario no puede limpiar algo que vive en el firmware, así que pedirle que resuelva el problema por su cuenta no funciona.

Su propuesta para los ISP (Internet Service Provider, proveedores de acceso a internet) pasa por revisar los flujos hacia la infraestructura de C2 que se ha hecho pública. Las exportaciones de flujos NetFlow o IPFIX (IP Flow Information Export, el estándar del IETF derivado de NetFlow) permiten cruzar las conexiones de los abonados con los indicadores publicados por Google. Entre ellos figuran el bróker MQTT `mqtt.szbboys[.]com` en los puertos 3885 a 3887, las direcciones 219[.]134[.]163[.]210 y 219[.]134[.]163[.]211 que lo alojaban, y los servidores 23[.]94[.]49[.]57 y 38[.]145[.]197[.]135, usados para alojar ficheros y como C2. Los dominios, como los subdominios de `anyevonline[.]com`, requieren cruzar también registros de DNS, porque un flujo solo muestra direcciones IP.

Esa lista tiene fecha de caducidad. El propio informe advierte de que, cuando se desmantela una pieza, los operadores de estas redes cambian rápido de cargador o de SDK de monetización, y documenta que desde agosto de 2026 la botnet ya estaba sustituyendo su cargador por nuevos instaladores. Los indicadores sirven para localizar equipos afectados ahora, pero no sustituyen a una vigilancia continua del tráfico anómalo hacia el exterior.

## Avisar al cliente y compartir inteligencia entre operadores

La segunda idea de D’Egidio es de procedimiento: notificar al cliente en lugar de limitarse a bloquear, y compartir inteligencia entre operadores. El bloqueo sin aviso deja al abonado con un servicio degradado y sin explicación, mientras que la notificación le permite desconectar el aparato y sustituirlo, que es la única salida real cuando el código está en el firmware. Google, por su parte, anima en su informe a plataformas móviles, ISP y mercados en línea a seguir compartiendo inteligencia y aplicar buenas prácticas para identificar puertas traseras y redes de proxy ilícitas.

La propia operación es un ejemplo de esa cooperación. Junto a Google participaron la Agencia Nacional de Policía de Japón, el operador Lumen, HUMAN Security, Plume, Synthient y TrendAI. Google pide además a distribuidores y minoristas que exijan auditorías de seguridad independientes a los ODM y retiren del catálogo a los fabricantes implicados, y a la industria de proxies que respalde cualquier afirmación de origen ético del tráfico con pruebas de consentimiento transparentes y auditables.

El caso no surge de la nada. El 5 de junio de 2025 el FBI advirtió, a través del IC3 (Internet Crime Complaint Center), sobre BADBOX 2.0, una botnet de dispositivos IoT infectados antes de la compra o durante su configuración y usada para servicios de proxy residencial. El 17 de julio de 2025 Google demandó en Nueva York a sus responsables y cifró la red en más de 10 millones de dispositivos sin certificar basados en AOSP (Android Open Source Project). GTIG no presenta XCPE como parte de BADBOX, aunque señala que dos de los módulos que cargaba, Moyu y Bird, ya se habían visto en esa trama.

## Preguntas frecuentes

### ¿Por qué XCPE afecta a los operadores de telecomunicaciones?

Porque los decodificadores infectados funcionaban como proxies residenciales y su tráfico salía con las direcciones IP de los operadores domésticos. Detrás de un CGNAT, esa IP la comparten muchos clientes.

### ¿Cómo puede un ISP detectar equipos infectados por XCPE?

Cruzando los registros de flujos NetFlow o IPFIX y los de DNS con la infraestructura de mando y control publicada por Google, como el bróker MQTT en los puertos 3885 a 3887 y sus direcciones IP asociadas.

### ¿Quién está detrás de la botnet XCPE?

Google atribuye con alta confianza la puerta trasera y la botnet a Videostrong Technology Co., un fabricante de dispositivos Android, y sostiene que actuó de forma intencionada para obtener beneficio económico.

### ¿Basta con bloquear la IP afectada?

No resuelve el origen, porque el malware vive en el firmware y se reinstala. Alejandro D’Egidio (CABASE) propone avisar al cliente para que retire el aparato en lugar de limitarse a bloquear.

**Fuentes:**

- [Google Threat Intelligence Group: Shutting the door on the XCPE botnet](https://cloud.google.com/blog/topics/threat-intelligence/shutting-the-door-on-the-xcpe-botnet)
- [OpenSecurity: Google desmantela XCPE, la botnet de fábrica en 1,3 millones de TV box Android](https://www.opensecurity.es/google-desmantela-botnet-xcpe-tv-box-android/)
- [Alejandro D’Egidio (CABASE) en LinkedIn](https://www.linkedin.com/in/adegidio/)
- [FBI / IC3: Home Internet Connected Devices Facilitate Criminal Activity (05/06/2025)](https://www.ic3.gov/PSA/2025/PSA250605)
- [Google: We’re taking legal action against the BadBox 2.0 botnet (17/07/2025)](https://blog.google/innovation-and-ai/technology/safety-security/google-taking-legal-action-against-the-badbox-20-botnet/)
- [BleepingComputer: Google disrupts million-device XCPE Android malware botnet](https://www.bleepingcomputer.com/news/security/google-disrupts-million-device-xcpe-android-malware-botnet-bans-tv-box-maker/)