BADBOX 2.0

01Sumário executivo

BADBOX 2.0 é uma operação de fraude construída sobre um backdoor pré-instalado em aparelhos Android de baixo custo, divulgada pela equipe Satori, da HUMAN Security, em 5 de março de 2025, em conjunto com Google, Trend Micro e Shadowserver [1]. Os aparelhos afetados são dispositivos do AOSP (Android Open Source Project) sem certificação Play Protect, ou seja, caixas de TV conectada, tabletes, projetores digitais e centrais multimídia automotivas de reposição [1]. A operação é a maior botnet de dispositivos de TV conectada já documentada [1], e sucede a campanha BADBOX, divulgada pela mesma equipe em 2023.

Este relatório não descreve uma detonação em laboratório. Ele é um perfil de ameaça construído sobre fonte aberta verificada, e existe por um motivo específico: o Brasil concentra mais de um terço dos dispositivos infectados observados pela plataforma da HUMAN [1]. Uma ameaça cuja maior massa de vítimas está no país precisa ser lida como risco de rede local.

O número de um milhão de dispositivos é a estimativa da HUMAN para janeiro de 2025 [1]. Em julho de 2025, ao processar os operadores, o Google declarou mais de dez milhões de aparelhos comprometidos [8]. A célula de remoção por restauração de fábrica, no painel acima, registra um zero deliberado: nenhuma das fontes consultadas descreve o reset como medida eficaz, e a autoridade irlandesa afirma o contrário de forma explícita [4].

As recomendações deste relatório estão ordenadas pelo que a instituição de fato controla. A seção 08 vai da fonte de telemetria mais barata e abrangente para a mais cara. A seção 09 segue o ciclo de incidente, e termina em prevenção estrutural, porque é nela, e não na resposta, que esta ameaça específica se resolve.

02Identificação do objeto analisado

As fontes descrevem quatro grupos distintos e cooperativos, e não um ator único [1]. O Google nomeia réus na China na ação civil de julho de 2025 [8], e a Trend Micro associa um dos grupos, o Lemon Group, a operações anteriores de firmware pré-infectado [7]. Nenhuma das fontes atribui a operação a um Estado, e este relatório também não o faz. Trate BADBOX 2.0 como crime financeiro organizado, porque é assim que ele se comporta e é assim que a resposta deve ser dimensionada.

03Contexto técnico: o aparelho não certificado

Entender BADBOX 2.0 exige distinguir duas coisas que o mercado vende sob o mesmo nome comercial de Android. O AOSP é a base livre do sistema, que qualquer fabricante pode compilar e embarcar sem passar por auditoria. Android TV OS e os aparelhos certificados Play Protect são produtos licenciados, submetidos a testes de segurança e compatibilidade pelo Google [1].

Essa distinção é o que separa o aparelho afetado do aparelho seguro, e ela se manifesta em três pontos práticos:

• quem monta a imagem do sistema no dispositivo AOSP não certificado é o fabricante ou um fornecedor terceiro de firmware, frequentemente com segurança de cadeia de suprimento precária [4];
• o Play Protect, que bloqueia aplicativos com comportamento associado ao BADBOX no momento da instalação, depende dos Google Play Services, ausentes em boa parte desses aparelhos [1];
• o malware embarcado na imagem de sistema ou assinado com certificado privilegiado sobrevive à restauração de fábrica e, em alguns casos, à regravação do firmware [4].

O resultado é um dispositivo que funciona exatamente como anunciado. Os aplicativos com backdoor se comportam como esperado, ou seja, um aplicativo de espelhamento de tela realmente espelha a tela, o que torna a percepção do problema pelo usuário comum bastante improvável [1].

04Os quatro grupos e a economia da fraude

BADBOX 2.0 não é obra de um grupo. Os pesquisadores da Satori identificaram quatro conjuntos de atores, ligados entre si por infraestrutura de comando e controle compartilhada e por vínculos comerciais [1]. Essa estrutura importa para a defesa: cada grupo monetiza o mesmo aparelho de um jeito, então um único dispositivo comprometido pode gerar simultaneamente tráfego de proxy, requisições de anúncio e cliques fraudulentos.

O serviço de proxy residencial do MoYu era anunciado a 13,64 dólares por 5 GB de tráfego roteado [1]. O preço é o dado mais revelador da seção, porque define o modelo de negócio: o aparelho da vítima é um insumo barato e renovável, e quem compra o acesso não é necessariamente quem infectou o aparelho.

Dentro da botnet do MoYu, os operadores usavam um identificador chamado channel para agrupar permutações de backdoor e configuração de comando e controle. Os pesquisadores identificaram 20 canais distintos, controlando mais de 83 mil dispositivos [1]. Esse número descreve apenas a botnet específica do MoYu, e não o total de infectados pela operação.

05Cadeia de infecção e o backdoor BB2DOOR

5.1Os três caminhos de entrega

O backdoor que sustenta a operação chega ao aparelho por três vias distintas [1]:

Pré-instalado no dispositivo

Da mesma forma que na campanha BADBOX original, embarcado na imagem de sistema antes de o produto sair da fábrica.

Baixado de um servidor de comando e controle

Contatado pelo próprio aparelho no primeiro acionamento, o que permite ao operador decidir, depois da venda, qual variante instalar.

Instalado pelo usuário

A partir de mercados de aplicativos não oficiais, em versões reempacotadas de aplicativos populares às quais o backdoor foi acrescentado.

A terceira via é a que mais interessa a quem defende uma rede institucional, porque ela não depende de compra de hardware suspeito. Um aparelho legítimo pode ser comprometido por um aplicativo baixado fora da loja oficial, e a orientação do FBI sobre mercados de aplicativos suspeitos nasce exatamente daí [3].

5.2Execução do backdoor

A cadeia de execução descrita pela Satori tem etapas bem delimitadas [1]:

• uma classe chamada com.hs.app, sepultada no código-fonte do aplicativo portador, carrega a biblioteca nativa libanl.so;
• a sigla ANL vem de Android Native Library, e a biblioteca é uma versão modificada pelos operadores, com ferramentas próprias de persistência e comunicação implantadas nela;
• ao ser ativada, libanl.so baixa e instala arquivos JAR responsáveis por manter o canal com o comando e controle e por garantir a permanência no aparelho;
• cadeias de texto cifradas dentro da biblioteca são decifradas para lançar dois arquivos, p.jar e q.jar, com os artefatos .oat correspondentes;
• o q.jar responde por impedir a remoção do backdoor, e a função com.hs.cld.Main, dentro de p.jar, baixa novos módulos de fraude e novos backdoors dos servidores de comando e controle.

Na campanha BADBOX original, o ponto de implante era o arquivo libandroid_runtime.so, do próprio Android, modificado pelos operadores. A migração para libanl.so é a mudança técnica que a Satori aponta como aprimoramento da segunda campanha [1]. No trabalho de engenharia reversa, a equipe identificou o algoritmo XXTEA na ofuscação do backdoor, reconhecível pela constante DELTA exibida como -0x61c88647 na desmontagem [2].

A Satori considera o BB2DOOR associado ao Vo1d, descrito pela Dr.Web em 2024, com base no uso comum de libanl.so. A diferença que a própria fonte registra é de alcance: o Vo1d se limitava a caixas de TV conectada, enquanto o BB2DOOR atingiu também tabletes, projetores e centrais automotivas [1]. O Vo1d infectou cerca de 1,3 milhão de aparelhos em 197 países, e o Brasil foi o país mais afetado também nessa campanha [6].

5.3Nomenclatura das variantes

Em um servidor de comando e controle exposto, os pesquisadores encontraram a lista de APKs do backdoor. A nomenclatura dos arquivos é sistemática e informa duas coisas [1]:

• o prefixo indica o tipo de aplicativo portador, entre AppStore, HiCast, Launcher, MirrCast, PadLauncher e Update. Os dois que contêm cast correspondem a aplicativos de espelhamento de tela;
• o sufixo identifica o modelo de aparelho alvo. A fonte exemplifica com 713M, associado a um projetor digital específico, e TP3002O, associado a um dispositivo de TV conectada.

06Esquemas de fraude e ataques de terceiros

Os pesquisadores observaram quatro modelos distintos de fraude viabilizados pelo acesso privilegiado persistente do BB2DOOR [1]. A ressalva que a própria fonte faz é importante para dimensionar o risco: os operadores não estão limitados a esses quatro, porque têm capacidade técnica de enviar ao aparelho qualquer funcionalidade, carregando um APK de sua escolha ou mandando o dispositivo executar código [1].

6.1Os quatro esquemas observados

No esquema de anúncios ocultos, os pesquisadores identificaram 24 aplicativos gêmeos maliciosos, com contrapartes na Play Store que compartilham o mesmo nome de pacote, técnica que a Satori havia descrito na divulgação Konfety, de 2024 [1]. A versão publicada na loja oficial não contém os módulos fraudulentos, o que é relevante para não condenar o aplicativo legítimo pelo nome.

6.2O que o proxy residencial habilita

O risco maior não está no roteamento em si, e sim no que terceiros fazem com ele depois de comprar o acesso. As fontes listam os seguintes ataques a jusante [1] [4]:

• tomada de conta, ou seja, uso de credenciais válidas a partir de um IP residencial legítimo;
• criação de contas falsas em massa;
• negação de serviço distribuída;
• distribuição de malware;
• furto de senhas de uso único, incluindo interceptação de segredos de autenticação em dois fatores [4].

A autoridade irlandesa descreve ainda um módulo de coleta de dados, que reúne aplicativos instalados, endereços IP e MAC, geolocalização, identificador do dispositivo, IMEI e versão do Android [4]. A Trend Micro havia documentado, no implante Guerrilla do Lemon Group, um plugin de SMS que intercepta senhas de uso único de aplicativos de mensagens, redes sociais e comércio eletrônico [7].

07Alcance da campanha e a exposição brasileira

Em janeiro de 2025, a Satori estimava mais de um milhão de dispositivos infectados no mundo, com tráfego associado à operação vindo de 222 países e territórios [1]. Em julho de 2025, ao entrar com ação civil contra os operadores em corte federal de Nova York, o Google declarou mais de dez milhões de aparelhos comprometidos, e pediu medida judicial para desmontar a infraestrutura da operação [8].

A concentração geográfica é o dado que justifica este relatório. Mais de um terço dos dispositivos infectados observados pela plataforma da HUMAN está no Brasil, onde aparelhos AOSP de baixo custo são particularmente populares [1]. Estados Unidos, México, Argentina e Colômbia aparecem em seguida com números expressivos [1]. A campanha Vo1d, tecnicamente aparentada, também teve o Brasil como país mais afetado [6].

Os dados de sinkhole confirmam a escala por outro caminho. A Bitsight, ao assumir domínios da campanha, registrou mais de 160 mil endereços IP únicos em 24 horas e observou modelos até então não associados à operação, incluindo televisores de marcas conhecidas [5]. A Shadowserver coordena o sinkhole de BADBOX 2.0 e distribui a telemetria resultante a equipes nacionais de resposta [4].

O efeito prático dessa distribuição é o que a autoridade irlandesa documenta. Recebendo dados do sinkhole da Shadowserver, o CSIRT-IE contabilizou 10.053 endereços IP irlandeses conversando com a infraestrutura de BADBOX 2.0, contra 260, 203, 200 e 138 endereços para as outras quatro famílias monitoradas no mesmo levantamento [4]. Em um país com população bem menor que a brasileira, BADBOX 2.0 sozinho supera em mais de uma ordem de grandeza qualquer outra família da lista.

08Detecção

A ordem desta seção vai do mais barato e abrangente para o mais caro e específico. Ela começa em telemetria de rede porque, como estabelecido na seção 03, os aparelhos afetados não comportam agente de endpoint, então a caça automatizada por varredura não está disponível. A inspeção do próprio aparelho aparece por último, na seção 8.6, porque exige acesso físico ou administrativo e não escala.

8.1Registros de DNS

É a fonte com melhor relação entre custo e cobertura, porque o backdoor resolve nomes antes de qualquer outra coisa. Consulte os domínios da seção 10 contra o histórico de resoluções.

index=dns query IN ("catmore88.com","ipmoyu.com","coslogdydy.in",
                    "app-goal.com","ads-goal.com","1ztop.work",
                    "yydsmr.com","logcer.com","cbpheback.com")
| stats count, dc(query) AS dominios, values(query) AS quais BY src_ip
| sort - count

DnsEvents
| where Name has_any ("catmore88.com","ipmoyu.com","coslogdydy.in",
                      "app-goal.com","1ztop.work","yydsmr.com")
| summarize Total=count(), Primeira=min(TimeGenerated),
            Ultima=max(TimeGenerated) by ClientIP, Name
| order by Total desc

8.2Regra Sigma para o resolvedor

A consulta acima é específica de plataforma. A regra Sigma abaixo expressa a mesma lógica de forma portável, para conversão ao backend de SIEM que a instituição usar. Ela consome registro de consulta do resolvedor recursivo, e não telemetria de endpoint, porque o aparelho afetado não tem agente.

title: Resolucao de dominio de comando e controle BADBOX 2.0
id: 8f3c1d94-1b7a-4c6e-9a21-7d5e2f0c4b83
status: experimental
description: >
  Detecta consulta DNS, a partir da rede interna, a dominios de comando e
  controle e de apoio a fraude atribuidos a operacao BADBOX 2.0. Voltado ao
  log do resolvedor recursivo, porque os dispositivos afetados sao AOSP nao
  gerenciados e nao comportam agente de endpoint.
references:
  - https://www.humansecurity.com/learn/blog/satori-threat-intelligence-disruption-badbox-2-0/
  - https://www.bitsight.com/blog/badbox-botnet-back
author: CiberLab, Ciencia Embarcada
date: 2026/09/11
tags:
  - attack.command-and-control
  - attack.t1437.001
  - attack.t1604
logsource:
  category: dns
detection:
  c2_principal:
    query:
      - 'catmore88.com'
      - 'ipmoyu.com'
      - 'admoyu.com'
      - 'moyu88.xyz'
      - 'bltproxy.com'
      - 'bullet-proxy.com'
  apoio_fraude:
    query:
      - 'app-goal.com'
      - 'ads-goal.com'
      - '1ztop.work'
      - 'tvsnapp.com'
      - 'pixelscast.com'
  sinkhole_e_legado:
    query:
      - 'coslogdydy.in'
      - 'yydsmr.com'
      - 'logcer.com'
      - 'cbpheback.com'
  condition: c2_principal or apoio_fraude or sinkhole_e_legado
falsepositives:
  - Resolvedor compartilhado que atende rede de terceiros, onde a origem
    registrada nao identifica o dispositivo real
  - Ferramenta de pesquisa de ameacas ou sandbox interna resolvendo os
    dominios de proposito
level: high

8.3IDS e IPS

Regras de exemplo para Suricata. A primeira cobre a consulta de DNS, a segunda os caminhos de URI em claro observados pela Bitsight na infraestrutura da família, e a terceira o certificado TLS autoassinado compartilhado por dezenas de domínios [5].

# 1. Consulta DNS a dominio de comando e controle BADBOX 2.0 [1]
alert dns $HOME_NET any -> any any (
  msg:"CIBERLAB BADBOX2 consulta a C2 conhecido";
  dns.query; content:"catmore88.com"; nocase; endswith;
  classtype:trojan-activity; priority:1;
  sid:9000201; rev:2;
)

# 2. Caminho de URI de registro de terminal, observado em C2 [5]
alert http $HOME_NET any -> $EXTERNAL_NET any (
  msg:"CIBERLAB BADBOX2 registro de terminal em C2";
  flow:established,to_server;
  http.method; content:"POST";
  http.uri; content:"/terminal/client/register"; startswith; nocase;
  classtype:trojan-activity; priority:1;
  sid:9000202; rev:1;
)

# 3. Certificado TLS autoassinado compartilhado pela familia [5]
alert tls $HOME_NET any -> $EXTERNAL_NET any (
  msg:"CIBERLAB BADBOX2 certificado TLS da familia";
  tls.cert_fingerprint;
  content:"5b:3a:a6:59:cb:8d:ec:e5:c9:a1:4d:60:5c:68:a4:32:b7:73:96:9c";
  classtype:trojan-activity; priority:1;
  sid:9000203; rev:1;
)

/terminal/client/apiInfo
/terminal/client/register
/ota/api/conf/v1
/ota/api/tasks/v2

8.4Proxy e NetFlow

Onde não houver visibilidade de DNS, procure no NetFlow o padrão que o proxy residencial produz: sessões de longa duração, saindo de um endereço interno para destinos muito variados, com volume de dados descolado de qualquer uso humano do aparelho. Uma caixa de TV que conversa com centenas de destinos distintos por hora não está transmitindo vídeo.

A Bitsight registrou um certificado TLS autoassinado compartilhado por dezenas de domínios da família, com impressão digital 5b3aa659cb8dece5c9a14d605c68a432b773969c [5]. Onde houver registro de metadados de TLS, essa impressão é um indicador de alta confiança e baixo falso positivo, e é a base da terceira regra da seção 8.3.

8.5Regra YARA para artefatos de dispositivo

Aplicável apenas a quem consiga extrair o APK portador ou a biblioteca nativa do aparelho, o que exige o acesso administrativo descrito na seção 8.6. A regra combina os identificadores de classe e de arquivo que a fonte primária documenta com a constante DELTA do XXTEA apontada no relato de engenharia reversa [2].

rule BADBOX2_BB2DOOR_Loader
{
    meta:
        description = "Artefatos do carregador BB2DOOR da operacao BADBOX 2.0"
        author      = "CiberLab, Ciencia Embarcada"
        date        = "2026-09-11"
        reference   = "https://www.humansecurity.com/learn/blog/satori-reverse-engineering-badbox-2/"
        confidence  = "derivada de OSINT, sem validacao contra amostra"
        tlp         = "TLP:CLEAR"

    strings:
        // Classe portadora e funcao de descarga de modulos [1]
        $class_loader = "com.hs.app"        ascii
        $class_main   = "com.hs.cld.Main"   ascii

        // Biblioteca nativa modificada que da nome ao backdoor [1]
        $lib          = "libanl.so"         ascii

        // Artefatos lancados a partir das cadeias cifradas [1]
        $jar_p        = "p.jar"             ascii
        $jar_q        = "q.jar"             ascii

        // Pacotes de fraude recuperados do C2 [1]
        $pkg_webview  = "com.mz.sdk"        ascii
        $pkg_proxy    = "com.debby.devour"  ascii

        // Constante DELTA do XXTEA, exibida como -0x61c88647 [2]
        $xxtea_delta  = { 47 86 C8 61 }

    condition:
        // Duas familias de indicador independentes, para nao alertar por um
        // unico nome de pacote que possa aparecer em codigo legitimo
        ($lib and 1 of ($class_*))
        or (2 of ($class_*, $jar_*, $pkg_*) and $xxtea_delta)
}

8.6Telemetria de sinkhole

É a fonte mais precisa disponível para uma instituição, e não custa nada:

• a Shadowserver coordena o sinkhole de BADBOX 2.0 e envia relatórios diários gratuitos aos responsáveis pelos blocos de endereços e às equipes nacionais de resposta [4];
• o relatório chega com o endereço IP de origem e o horário da conexão, ou seja, aponta o dispositivo infectado dentro da sua rede sem que você precise instrumentar nada;
• foi exatamente esse mecanismo que permitiu ao CSIRT-IE contabilizar os 10.053 endereços irlandeses citados na seção 07 [4].

8.7Inventário e aquisição

A verificação mais cara é também a mais definitiva, e depende de acesso físico ou administrativo ao aparelho. Confirme se o dispositivo é certificado Play Protect, e trate a exigência de desativar o Play Protect como sinal de alerta direto, conforme o indicador do FBI [3]. A lista de modelos da seção 10 serve para essa conferência, e também para orientar compras futuras.

09Mitigação e resposta

9.1Contenção imediata

• Bloqueie os domínios de comando e controle da seção 10 no resolvedor DNS recursivo da instituição. Esta é a primeira ação porque interrompe a monetização sem depender de localizar o aparelho, e porque um bloqueio no resolvedor cobre toda a rede de uma vez.
• Isole os endereços internos que resolveram esses nomes em segmento sem acesso a sistemas administrativos, e não apenas sem acesso à internet. O risco principal do aparelho é servir de ponto de partida lateral e de saída de proxy.
• Assine o relatório da Shadowserver para os blocos da instituição, se ainda não houver assinatura ativa. É a via mais rápida de transformar suspeita em lista de endereços concretos [4].

9.2Erradicação

A erradicação efetiva é a substituição do aparelho por um modelo certificado Play Protect. Onde a substituição não for viável no curto prazo, mantenha o dispositivo em segmento isolado, com bloqueio de saída por padrão, e trate a permanência como risco aceito e documentado, com prazo definido.

9.3Avaliação de alcance

Confirmada a presença de um aparelho infectado, o escopo da investigação precisa se estender além do dispositivo, por causa das capacidades descritas na seção 06:

• verifique autenticações bem-sucedidas partindo do endereço interno do aparelho e de seu endereço público de saída, por causa do risco de tomada de conta;
• considere comprometidos os segredos de autenticação em dois fatores que tenham trafegado por SMS na mesma rede, dada a interceptação documentada [4] [7];
• levante o inventário de dados que o módulo de coleta alcança, ou seja, identificadores de dispositivo, IMEI, geolocalização e endereços MAC do segmento [4].

9.4Prevenção estrutural

9.5Mapeamento MITRE ATT&CK

As técnicas abaixo pertencem à matriz Mobile do ATT&CK, conferidas nome a nome em attack.mitre.org [9]:

10Indicadores de comprometimento

Todos os indicadores abaixo vêm de fonte aberta, e não de análise própria desta equipe. As URLs estão desarmadas de propósito, ou seja, precisam ser reconstituídas antes do uso.

A lista completa publicada pela fonte primária traz mais de cinquenta modelos e cerca de cento e dez domínios [1]. A seleção abaixo privilegia os indicadores que as fontes descrevem com função explicada, porque indicador sem papel conhecido gera alerta que ninguém sabe triar.

Artefatos de dispositivo, úteis para quem tiver acesso administrativo ao aparelho:

Amostra de modelos de aparelho apontados pela fonte primária, para conferência de inventário e de compras [1]:

11Limitações da análise

• Não houve detonação nem aquisição de amostra. Esta equipe não submeteu aparelho ou APK a sandbox, não extraiu firmware e não confirmou nenhum indicador por observação própria. Todo o conteúdo técnico vem das referências, e cada afirmação foi conferida contra o texto da fonte que a sustenta.
• Não há hashes de amostra neste relatório. As fontes consultadas descrevem nomes de arquivo, classes e pacotes, mas não publicaram hashes que pudessem ser verificados de forma independente.
• As regras das seções 8.2, 8.3 e 8.5 são derivadas, não validadas. Elas foram escritas a partir dos comportamentos e indicadores descritos nas fontes, sem execução de amostra nem teste contra tráfego real. A regra YARA, em particular, nunca foi aplicada a um artefato do BB2DOOR, e a condição de duas famílias de indicador existe justamente para reduzir o risco de alerta por um nome de pacote isolado.
• Os números de dispositivos infectados são estimativas de terceiros, produzidas por metodologias que as fontes não detalham por inteiro, em datas diferentes. A ressalva da seção 07 se aplica a qualquer uso desses valores.
• A proporção brasileira de mais de um terço descreve a telemetria da plataforma da HUMAN [1], e não uma medição independente da base instalada no Brasil. Ela indica ordem de grandeza, não um percentual auditável.
• A lista de indicadores da seção 10 reflete a infraestrutura observada até a divulgação das fontes. As próprias fontes registram que os operadores trocam domínios para evadir detecção [1], então ausência de correspondência não é prova de ausência de infecção.
• A associação entre BB2DOOR e Vo1d é declarada pela fonte primária como crença dos pesquisadores, com base no uso comum de libanl.so [1]. Este relatório reproduz a associação com essa ressalva, e não a trata como identidade entre as duas famílias.
• As alegações da ação judicial do Google são peça processual, não achado técnico revisado [8]. Elas são citadas aqui pelo escopo declarado, e não como confirmação independente de número de dispositivos.
• Este relatório não atribui a operação a Estado nem a grupo patrocinado, porque nenhuma fonte consultada o faz.