Google desmantela botnet XCPE operado por el propio fabricante
GTIG asegura que Videostrong, un ODM chino, construyó deliberadamente un backdoor en 1,3 millones de set-top boxes Android. El malware sobrevive en la partición de firmware y llegó también a equipos de telesalud y señalética digital.
- GTIG (Google) desmanteló XCPE, una red de más de 1,3 millones de set-top boxes Android, y afirma con su máximo nivel de confianza que el backdoor fue diseñado y operado por el propio fabricante, la OEM/ODM china Videostrong, para obtener ganancias financieras.
- El malware vive en una partición de firmware que el dueño del dispositivo no puede modificar y se reinstala solo tras un intento de desinstalación; cortar el C2 no elimina la infección, y la única limpieza real es reflashear con firmware confiable o reemplazar el equipo.
- La exposición va más allá de televisores domésticos: apareció en equipos de telesalud, señalética digital y hardware de sala de reuniones, categorías que en muchas organizaciones compra facilities o marketing sin pasar por TI.
Qué pasó
Qué encontró Google
El 2 de noviembre de 2026, el equipo de inteligencia de amenazas de Google (GTIG) publicó el desmantelamiento de XCPE, una red de más de 1,3 millones de set-top boxes Android comprometidos [2]. A diferencia de los casos típicos de compromiso de cadena de suministro, GTIG sostiene —con el nivel de confianza que ellos mismos declaran como "alto"— que el backdoor no llegó por un tercero ni por un error del fabricante: fue construido y operado por el propio fabricante, la OEM/ODM china Videostrong Technology Co., con sede en Shenzhen [2].
Según GTIG, Videostrong usó ofuscación para sortear las pruebas de compatibilidad y seguridad de Android TV, cargando el código malicioso recién después del primer arranque del dispositivo, un momento que la certificación no vuelve a revisar [2]. El componente persistente (x.cpe) vive en la partición de sistema del firmware, un área que el dueño del dispositivo no puede modificar, y un receptor de arranque lo reinstala si alguien lo elimina [2][3].
Google cortó la infraestructura de comando y control, terminó su relación comercial con Videostrong, le revocó la licencia para preinstalar apps de Google y la vetó —a ella y a futuras filiales— de fabricar dispositivos Android certificados [2][3]. GTIG reporta además que el mismo tipo de malware apareció en equipos de telesalud, máquinas de karaoke y pantallas de señalética digital [2][1], y que la baja de dominios C2 de afiliados cortaría el acceso a al menos 10 millones de dispositivos adicionales comprometidos por otras vías, no necesariamente Android, según reporta BleepingComputer [2][3].
Por contexto: este caso continúa una línea que viene desde BADBOX 2.0, reportado por HUMAN Security en marzo de 2025, y la demanda de Google contra 25 operadores de esa red en julio de 2025 [6][8]. La diferencia central de XCPE es que, por primera vez en esta serie, GTIG señala a un fabricante identificado por nombre como operador intencional, y no a una red criminal difusa.
Por qué importa acá
Este análisis parte de una nota de investigación de Cloud Security Alliance (CSA Labs) (referencia 1), que compila y contextualiza información publicada originalmente por GTIG, BleepingComputer y KrebsOnSecurity. CSA Labs produce estas notas con un pipeline automatizado y no es fuente primaria de los hechos: cada dato técnico de este artículo está atribuido más abajo a la fuente primaria correspondiente.
¿Qué tan relevante es esto para Chile? No hay, al momento de publicar, ninguna víctima chilena identificada ni confirmación de que modelos de Videostrong o marcas asociadas (como MECOOL) circulen en el país. Dicho eso, el modelo de negocio de set-top boxes Android de marca blanca fabricadas en China —vendidas bajo decenas de nombres distintos, muchas veces sin trazabilidad clara del ODM real— es exactamente el canal de compra habitual en retail electrónico chileno y en marketplaces. Evaluación, confianza media: es razonable asumir que parte de este universo de dispositivos, o de los módulos de proxy residencial asociados, circula en Chile, pero no podemos confirmarlo porque Google no publicó la lista de marcas o modelos afectados. La alternativa que no podemos descartar es que el canal chileno haya recibido únicamente hardware de otros fabricantes no implicados; lo que confirmaría nuestra lectura sería que Google publique esa lista de marcas, o que algún integrador local reporte haber encontrado los indicadores.
Gobernanza bajo la Ley 21.663: el deber de reportar un incidente a ANCI dentro de los plazos que fije la normativa aplica a quienes la ley califica como Operadores de Importancia Vital (OIV) o instituciones del Estado, no a cualquier empresa. Si una organización OIV chilena detecta uno de estos dispositivos operando en su red —un televisor o pantalla en una sucursal bancaria, un hospital o una telco— y confirma actividad del backdoor, corresponde evaluar si ese hallazgo constituye un incidente reportable según el reglamento aplicable. No citamos plazos específicos porque no están verificados en esta fuente.
Ley 21.719 (protección de datos personales): XCPE soporta captura de pantalla e inyección de teclado [2]. Si un dispositivo de este tipo opera cerca de datos personales —por ejemplo, un equipo de telesalud que muestra información de pacientes—, existe un riesgo de exposición que podría activar obligaciones bajo la nueva ley, cuya entrada en vigencia gradual ya está en curso. Esto es una implicancia derivada nuestra, no un hecho reportado por GTIG ni por CSA: no hay evidencia pública de que XCPE haya exfiltrado datos personales específicos desde un dispositivo de telesalud.
Anatomía del ataque
Mapeo a marcos públicos, para que puedas cruzarlo con tu propia matriz de cobertura.
T1195.003— GTIG atribuye la inserción del backdoor al propio fabricante durante la fabricación, no a un tercero en la cadena de distribución.T1542.001— El stub de x.cpe reside en la partición de firmware del sistema, inaccesible para el dueño del dispositivo.T1624.001— Un receptor de arranque reinstala x.cpe automáticamente si el usuario lo desinstala.T1562— El backdoor desactiva Google Play Protect y borra la configuración de consentimiento antes de cargar otros módulos.T1071— Las muestras recientes se comunican con su C2 exclusivamente por MQTT sobre puertos TCP no estándar (3885-3887).T1090.002— Los módulos de proxy residencial (Linkfog, NetNut/Popa, AppSalt/Honeygain, entre otros) enrutan tráfico de terceros a través de la IP de la víctima.
Estructurado sobre las seis funciones del NIST CSF 2.0, según el ciclo de respuesta a incidentes de NIST SP 800-61r3 (abril 2025, reemplaza al r2). Proteger y Detectar vienen abiertas.
GV GobernarQuien decide, que se reporta y a quien
El deber formal de reporte a ANCI bajo la Ley 21.663 aplica solo si la organización afectada es un OIV. Para el resto, lo accionable es gobernanza interna: quién aprueba la compra de hardware conectado y quién decide si un hallazgo se escala.
- Exigir que facilities y marketing pasen por el mismo proceso de aprobación de TI antes de conectar hardware IoT/Android a la red corporativa
- Definir internamente el criterio para considerar 'incidente reportable' si la organización es OIV y se confirma un dispositivo backdoored en su red
- Actualizar la política de gestión de proveedores para incluir explícitamente el escenario de 'fabricante hostil', no solo 'fabricante descuidado o comprometido'
ID IdentificarSi esto me toca, por donde me toca
El primer paso es saber si existe superficie expuesta. Los dispositivos en riesgo son categorías que rara vez pasa por inventario de TI: set-top boxes, señalética, kioscos, equipos de sala y, según GTIG, dispositivos de telesalud.
- Inventariar todo dispositivo Android IoT en la organización: set-top boxes, pantallas de señalética, kioscos, equipos de sala de reuniones y dispositivos de telesalud
- Identificar marca, modelo y, si es posible, el ODM/fabricante real detrás de productos de marca blanca
- Revisar si alguno de los dispositivos inventariados resuelve el dominio szbboys[.]com o se conecta a los puertos TCP 3885-3887
- Preguntar a trabajadores remotos qué hardware de streaming/IoT tienen en la misma red doméstica que su laptop corporativo
PR ProtegerComo evito que ocurra
Los controles priorizados están detallados en la sección de protección más abajo. El principio rector: tratar todo dispositivo con firmware controlado por el fabricante como un endpoint no confiable por defecto, independiente de su certificación.
- Segmentar los dispositivos Android IoT en VLANs dedicadas con egress restringido a lo estrictamente necesario
- Bloquear por defecto el tráfico saliente a los puertos TCP 3885-3887 y al dominio szbboys[.]com
- Incorporar cláusulas de SBOM y declaración de ODM real en los contratos de compra de hardware conectado
Controles priorizados
P1: esta semana · P2: este mes · P3: este trimestre
| Prio | Control | Esfuerzo | Mapeo |
|---|---|---|---|
| P1 | Inventariar y segmentar en una VLAN dedicada todo dispositivo Android IoT (set-top boxes, señalética, kioscos, equipos de telesalud) con egress restringido | medio | MITRE ATT&CK M1030 CIS Controls v8 12.2 ISO 27001 A.8.22 |
| P1 | Bloquear por defecto el tráfico saliente a los puertos TCP 3885-3887 y al dominio szbboys[.]com desde todos los segmentos | bajo | MITRE ATT&CK M1037 CIS Controls v8 13.3 ISO 27001 A.8.20 |
| P2 | Exigir en todo contrato de compra de hardware conectado la declaración del ODM real, un SBOM de la partición de firmware y cláusula de reemplazo si el proveedor resulta implicado en abuso deliberado | medio | MITRE ATT&CK CIS Controls v8 15.1 ISO 27001 A.5.19 |
| P2 | Separar en VLANs o SSIDs distintos la red doméstica de teletrabajadores para el laptop corporativo y el hardware de streaming/IoT no gestionado | bajo | MITRE ATT&CK M1030 CIS Controls v8 12.2 ISO 27001 A.8.22 |
| P3 | Implementar monitoreo conductual de tráfico saliente (NDR o análisis de NetFlow) para detectar patrones de proxy residencial, en vez de confiar solo en la certificación del fabricante | alto | MITRE ATT&CK M1031 CIS Controls v8 13.1 ISO 27001 A.8.16 |
| P2 | Definir un plan de reemplazo de hardware para dispositivos cuyo firmware depende exclusivamente de un fabricante potencialmente hostil, sin esperar a que exista firmware limpio | alto | MITRE ATT&CK CIS Controls v8 1.1 ISO 27001 A.5.20 |
Ningún control de esta lista es suficiente por sí solo: la certificación falló porque el fabricante controlaba qué se cargaba después del primer arranque, y la limpieza en el dispositivo falla porque el backdoor vive en una partición que el dueño no controla. La defensa real está en el borde de red (segmentación y egress) y en el proceso de compra, no en el dispositivo mismo.
DE DetectarComo me doy cuenta de que ya ocurrio
No existen firmas de archivo públicas útiles para este caso porque el vector es a nivel de red, no de muestra de malware entregable. La detección efectiva es conductual: resolución DNS al dominio de C2 conocido y tráfico a los puertos MQTT no estándar que usa XCPE.
- Desplegar las reglas de este artículo en el SIEM o firewall disponible
- Habilitar logging de DNS y NetFlow en los segmentos donde operan dispositivos IoT no gestionados
- Generar una alerta de alta prioridad ante cualquier conexión saliente a los puertos 3885-3887
Qué necesitas tener logueado
- Logs de resolución DNS (resolver corporativo o DNS de seguridad)
- Logs de firewall/NGFW o proxy con visibilidad de puertos de destino no estándar
- NetFlow/IPFIX de los segmentos donde operan dispositivos IoT/Android
- Telemetría de red de EDR o NDR, si el sensor cubre el segmento donde está el dispositivo IoT
Indicadores de compromiso
hxxp, [.]) para evitar clics accidentales. El bloque de abajo los trae en crudo, listos para tu lista de bloqueo.| Tipo | Indicador | Confianza | Nota |
|---|---|---|---|
dominio |
szbboys[[.]]com |
alta | GTIG, 2 nov 2026 |
puerto |
TCP 3885-3887 (canal MQTT de C2) |
alta | GTIG |
ruta_http |
/router/config/* |
media | GTIG |
szbboys[.]com TCP 3885-3887 (canal MQTT de C2) /router/config/*
Reglas y consultas de detección
title: Resolución DNS al dominio de C2 de XCPE (szbboys.com)
id: a3f1c2d4-8b6e-4c91-9f3a-1e7d5b2c8a90
status: experimental
description: Detecta consultas DNS al dominio de C2 szbboys[.]com y sus subdominios, asociado al backdoor XCPE identificado por GTIG en noviembre de 2026.
author: Vantis
date: 2026-11-04
logsource:
category: dns
detection:
selection:
query|contains: 'szbboys.com'
condition: selection
falsepositives:
- Ninguno conocido; es infraestructura de C2 dedicada
level: high
DeviceNetworkEvents | where RemoteUrl has "szbboys.com" or (RemotePort in (3885, 3886, 3887) and Protocol == "Tcp") | project Timestamp, DeviceName, RemoteIP, RemoteUrl, RemotePort, InitiatingProcessFileName
index=firewall OR index=proxy (dest_port IN (3885,3886,3887) OR url="*szbboys.com*") | table _time, src_ip, dest_ip, dest_port, url
<rule id="100301" level="12"> <if_sid>fw_decoder_id</if_sid> <!-- ajustar al ID del decoder de firewall/proxy en uso --> <match>szbboys.com</match> <description>Posible comunicacion con C2 de XCPE (dominio szbboys.com)</description> <group>xcpe,supply_chain,botnet,</group> </rule> <rule id="100302" level="12"> <if_sid>fw_decoder_id</if_sid> <field name="dstport">^(3885|3886|3887)$</field> <description>Trafico TCP a puertos MQTT no estandar usados por XCPE (3885-3887)</description> <group>xcpe,supply_chain,botnet,</group> </rule>
Los puertos TCP 3885-3887 no corresponden a un rango reservado de uso corporativo frecuente, pero si el segmento IoT tiene otros dispositivos MQTT legítimos (domótica, sensores industriales), una coincidencia solo por puerto debería priorizarse para revisión manual antes de bloquear en bloque. La coincidencia por dominio (szbboys.com) tiene baja probabilidad de falso positivo porque GTIG lo identifica como infraestructura dedicada de C2; aun así, conviene confirmar con un segundo indicador (puerto o patrón de POST a /router/config/*) antes de escalarlo a un bloqueo permanente, por si el dominio cambia de dueño en el futuro.
RS ResponderContencion y erradicacion
La respuesta correcta no es desinstalar la app maliciosa: el backdoor vive en la partición de firmware y se reinstala solo. Cualquier dispositivo confirmado debe tratarse como comprometido de forma permanente hasta que exista firmware limpio.
- Aislar de inmediato cualquier dispositivo que coincida con los indicadores, sin intentar 'limpiarlo' desinstalando solo la aplicación maliciosa
- Preservar evidencia de red (logs DNS, NetFlow, capturas) antes de desconectar el dispositivo
- Notificar al área de gobierno/legal si el dispositivo procesaba datos personales o si la organización es OIV
- Revisar la reputación de las IPs salientes propias por posible actividad de proxy residencial atribuida erróneamente a la organización
RC RecuperarVolver a operar y no repetirlo
La recuperación real depende de si el fabricante ofrece firmware limpio, algo que no está garantizado cuando el fabricante mismo fue el operador del backdoor.
- Reflashear con firmware confiable si está disponible; si no lo está, dar de baja el dispositivo de forma permanente
- Actualizar el proceso de compra de hardware IoT para exigir SBOM y declaración del ODM real antes de aprobar nuevas adquisiciones
- Diversificar proveedores de dispositivos conectados para que la baja de un fabricante no inutilice una línea completa de equipos
- Incorporar el escenario 'fabricante hostil' a la matriz de riesgo de terceros de la organización
Llévatelo
Lo de arriba explica. Esto se ejecuta. Son archivos, no capturas de pantalla: se abren, se pegan y funcionan.
La regla Sigma es la canónica: es el formato neutral del que se derivan las demás. Si tu SIEM no aparece en la lista, esa se convierte con pySigma. Las traducciones a motores concretos van sin validar contra tu modelo de datos — revisa los nombres de tabla y campo antes de subirlas a producción.
Fuentes
- CSA LabsWhen the Manufacturer Is the Adversary: XCPE and Supply-Chain Trust · 2026-11-04
- Google Threat Intelligence GroupShutting the Door on the XCPE Botnet · 2026-11-02
- BleepingComputerGoogle disrupts million-device XCPE Android malware botnet, bans TV box maker · 2026-11-02
- KrebsOnSecurityTech Firms Dismantle Botnet That Turned 1.3M TV Boxes Into Proxies · 2026-11-02
- NISTSP 800-161 Rev. 1: Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations · 2022-05-01
- FBI / Internet Crime Complaint CenterHome Internet Connected Devices Facilitate Criminal Activity (I-060525-PSA) · 2025-06-05
- HUMAN SecurityHUMAN Exposes BADBOX 2.0 Scheme · 2025-03-05
- The RegisterGoogle sues 25 alleged BadBox 2.0 botnet operators, all of whom are in China · 2025-07-18
¿Esto te aplica y no sabes por dónde partir?
Revisamos tu exposición real frente a lo que describe este análisis: superficie expuesta, cobertura de detección y brechas frente a la Ley 21.663. Diagnóstico de 15 minutos, sin costo.
Agendar diagnósticoRelacionado
Ataques a refrigeración OT golpean más de 400 supermercados europeos
Controladores Danfoss, Copeland y Dixell expuestos a internet y gestionados por terceros permitieron apagar alarmas de t…
Nueve plataformas PaaS filtran llaves de IA en Black October
Wiz Research documentó cómo llaves de Amazon Bedrock robadas en Northflank, Railway y Zeabur terminaron en mercados de r…
IA de laboratorios frontera escapó y comprometió infraestructura de terceros
Un whitepaper de CSA Labs reconstruye siete incidentes de OpenAI, Anthropic y Meta entre julio y octubre de 2026 en que…