alta research global

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.

·12 min de lectura ·Equipo Vantis
En 30 segundos
  • 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.

Qué hacer, fase por fase

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

PrioControlEsfuerzoMapeo
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

OjoLos indicadores están defanged (hxxp, [.]) para evitar clics accidentales. El bloque de abajo los trae en crudo, listos para tu lista de bloqueo.
TipoIndicadorConfianzaNota
dominio szbboys[[.]]com alta GTIG, 2 nov 2026
puerto TCP 3885-3887 (canal MQTT de C2) alta GTIG
ruta_http /router/config/* media GTIG
blocklistIndicadores en crudo
szbboys[.]com
TCP 3885-3887 (canal MQTT de C2)
/router/config/*

Reglas y consultas de detección

sigmaResolución DNS al dominio de C2 de XCPE (szbboys.com)
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
Requiere: Logs de consultas DNS centralizados (resolver corporativo, DNS de seguridad o sensor de red tipo Zeek)
sentinel-kqlTráfico hacia infraestructura de XCPE (dominio o puertos MQTT no estándar)
DeviceNetworkEvents
| where RemoteUrl has "szbboys.com"
   or (RemotePort in (3885, 3886, 3887) and Protocol == "Tcp")
| project Timestamp, DeviceName, RemoteIP, RemoteUrl, RemotePort, InitiatingProcessFileName
Requiere: Tabla DeviceNetworkEvents de Microsoft Defender for Endpoint/Sentinel; en dispositivos IoT sin agente, aplicar la lógica equivalente sobre los logs del NGFW que les da salida a internet
splunkTráfico hacia infraestructura de XCPE en firewall/proxy
index=firewall OR index=proxy (dest_port IN (3885,3886,3887) OR url="*szbboys.com*")
| table _time, src_ip, dest_ip, dest_port, url
Requiere: index=firewall o index=proxy con logs de NGFW/proxy que registren IP, puerto destino y URL/SNI
wazuhAlerta sobre tráfico a C2 de XCPE desde logs de firewall
<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>
Requiere: Decoder de Wazuh configurado para el firewall/proxy que entrega los logs (ajustar if_sid al decoder real usado en el entorno)
Falsos positivos esperables

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

¿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óstico

Relacionado