O Google, cinco empresas de segurança e a Agência Nacional de Polícia do Japão desmantelaram nesta semana a botnet XCPE, escondida no firmware de caixas de TV Android vendidas ao consumidor final. O relatório técnico do Google Threat Intelligence Group, publicado em 2 de novembro de 2026, estima que a operação alistou mais de 1.3 milhão de dispositivos em mais de 200 países — todos infectados antes de sair da fábrica, sem qualquer clique ou instalação por parte do usuário. Para equipes defensivas, a ação prioritária é localizar esses aparelhos na rede corporativa e residencial, segregar o tráfego MQTT de saída e substituir o hardware comprometido: desinstalar o pacote malicioso não resolve, porque ele se reinstala sozinho após reiniciar.
O ataque que nasceu na fábrica
A diferença central deste caso está na origem da infecção. A maioria das campanhas contra dispositivos móveis depende de engenharia social, como o trojan Hirudo, que substitui aplicativos de banco por versões adulteradas instaladas pela vítima. No XCPE, o código malicioso veio embutido na partição de firmware do aparelho, colocado pelo próprio fabricante antes da venda. O Google atribui com alta confiança o backdoor à Videostrong Technology Co., fabricante e projetista de equipamentos Android, cortou relações com a empresa e a proibiu de produzir aparelhos certificados com aplicativos Google pré-carregados, incluindo subsidiárias e afiliadas.
Segundo o relatório, a Videostrong desenvolveu, distribuiu e operou o backdoor de propósito, para lucro financeiro. A fabricante empregou técnicas de ofuscação para explorar uma lacuna nos testes de compatibilidade e segurança do ecossistema Android e carregar código malicioso depois do primeiro boot do aparelho. O caso mostra que a cadeia de suprimentos de hardware começa no fabricante, não na loja: auditoria de firmware e telemetria de rede são controles obrigatórios para qualquer dispositivo conectado que entra em casa ou na empresa.
Três estágios e C2 por MQTT
O malware evoluiu desde pelo menos o fim de 2024, saindo de droppers simples para uma arquitetura modular em três estágios. O estágio primário, chamado x.cpe (com.oemservice em algumas compilações), roda com privilégio de sistema (android.uid.system) e vem pré-carregado na partição de firmware; se o usuário o desinstala, ele se reinstala automaticamente a partir da partição /oem/ no próximo boot, mantendo acesso persistente. Um carregador externo, com.abc.nexus, executa os módulos e usa utilitários nativos de anti-análise para frustrar sandboxes — e, nas versões mais recentes, foi substituído por droppers mais especializados que carregam um módulo por vez.
A comunicação acontece em dois estágios. Primeiro, o backdoor faz requisições HTTP POST criptografadas para buscar configuração dinâmica, dados de geolocalização e parâmetros de servidor STUN. Depois, estabelece uma conexão MQTT persistente — protocolo leve de publicação e assinatura desenhado para redes de baixa banda — com o corretor mqtt.szbboys[.]com. Pelos tópicos MQTT, o operador podia instalar aplicativos em silêncio, executar comandos shell com UID de sistema, capturar a tela, fazer reconhecimento de rede e desativar o Google Play Protect remotamente, alterando a configuração package_verifier_user_consent. Boa parte dos módulos adicionais era hospedada como releases de GitHub em páginas controladas pelos operadores — o uso de infraestrutura legítima como esconderijo segue o padrão de malware que aposta na evasão e na persistência silenciosa.
Como a botnet gerava dinheiro
O modelo de negócio era multi-inquilino. A Videostrong vendia acesso dos aparelhos a afiliados criminosos e carregava os módulos desses afiliados nos dispositivos infectados. Os módulos transformavam as caixas de TV em nós de saída de proxies residenciais (Linkfog, AppSalt e NetNut), motores de fraude publicitária (CBOXTV, HiddenView) e portas de entrada para backdoors adicionais (Moyu, Spirit). O tráfego de terceiros passava pelos endereços IP residenciais das vítimas, sem consentimento — o que significa que ataques subsequentes, como roubo de credenciais e stuffing, podem ter saído da banda larga de casas comuns.
A telemetria dos parceiros reforça a dimensão da operação: o levantamento da TrendAI identificou mais de 1.3 milhão de aparelhos afetados, e o comunicado conjunto do desmantelamento registra receita com revenda de banda larga, entrega de conteúdo em vídeo, fraude publicitária, carregamento de backdoors adicionais e, em versões anteriores, instalação paga de aplicativos. A caixa de TV virava ativo econômico de terceiros desde o primeiro boot.
Além da ação legal contra os domínios e servidores usados pela Videostrong, o Google derrubou os domínios de comando de mais de uma dúzia de famílias de malware carregadas como módulos. Como esses afiliados distribuem seus módulos por outros canais além do XCPE, o Google estima que a derrubada corta o acesso a pelo menos 10 milhões de dispositivos adicionais comprometidos — ou seja, a rede afetada era muito maior que o estoque de caixas de TV com firmware adulterado.
Sinais de comprometimento
Para provedores de internet e equipes que gerenciam redes com dispositivos conectados, o relatório oferece indicadores concretos. A verificação mais direta combina inventário de pacotes com análise de tráfego de saída:
| Verificação | O que procurar | Interpretação |
|---|---|---|
| Pacotes no aparelho | x.cpe ou com.oemservice pré-instalados; carregador com.abc.nexus | Presença indica firmware adulterado |
| Tráfego de saída | Conexões persistentes a mqtt.szbboys[.]com; HTTP POST na porta 8000 para subdomínios anyevonline.com | Canal de comando ativo |
| Volume assimétrico | Upload residencial constante sem uso aparente; picos noturnos | Possível proxy residencial |
| Apps desconhecidos | Instalações silenciosas; Play Protect desativado sem ação do usuário | Módulo de afiliado em execução |
Em redes domésticas gerenciadas por provedores, a Plume — um dos parceiros da operação — destaca que um aparelho de streaming funcionando normalmente ainda pode gerar tráfego inexplicado. Para o time de segurança, isso significa que inventário de dispositivos e baseline de tráfego por aparelho são pré-requisitos: sem eles, o proxy residencial passa despercebido por meses.
Ações de defesa priorizadas
O caso muda a prioridade de defesa para IoT: o risco não está só no usuário descuidado, mas no fornecedor. Um roteiro prático:
- P1 — inventariar e isolar: mapeie todas as caixas de TV, dongles e aparelhos Android não gerenciados na rede; coloque-os em VLAN segregada, sem acesso a recursos corporativos.
- P1 — bloquear o canal de comando: filtre MQTT (porta 1883 e variantes) e os hosts do IOC na borda; monitore HTTP POST suspeito na porta 8000.
- P2 — trocar, não limpar: aparelhos com firmware adulterado não têm correção confiável; substitua por hardware de fornecedor auditável.
- P2 — revisar contratos de aquisição: exija atestados de integridade de firmware, atualizações assinadas e canal de revogação antes de comprar dispositivos conectados.
- P2 — monitorar proxies residenciais: em serviços de verificação de IP, trate tráfego de proxy residencial como de risco elevado, porque pode sair de equipamentos infectados como estes.
Para o consumidor, os sinais visíveis são limitados: lentidão na banda larga, aplicativos que aparecem sem instalação e o Play Protect desativado sem explicação. O caminho mais seguro permanece comprar aparelhos certificados, de fabricantes com histórico verificável, e trocar boxes de procedência duvidosa.