Malware reuniu cerca de 1,8 milhão de dispositivos Android, combinando DDoS, proxy, shell reverso e adaptação de infraestrutura por ENS.
| Componente | Botnet Kimwolf em TVs Android, set-top boxes e tablets, com amostras compiladas com NDK. |
| Vetor | Propagação para TV boxes em redes residenciais; o método exato de infecção não foi determinado no contexto analisado. |
| Impacto | Aproximadamente 1,83 milhão de IPs ativos em pico diário, emissão de comandos DDoS, uso de proxy, shell reverso e gerenciamento de arquivos. |
| Prioridade | Inventariar dispositivos Android de mídia expostos, bloquear infraestrutura defangada conhecida, revisar tráfego TLS/DNS incomum e substituir equipamentos sem atualização confiável. |
| Artefatos | Domínio C2 defangado 14emeliaterracewestroxburyma02132[.]su, domínio ENS pawsatyou[.]eth e servidor downloader 93.95.112[.]59. |
| Modelos citados | TV BOX, SuperBOX, HiDPTAndroid, P200, X96Q, XBOX, SmartTV e MX10 aparecem entre os dispositivos afetados. |
A Kimwolf é uma botnet voltada principalmente a dispositivos Android usados como TVs, set-top boxes e tablets, com concentração em ambientes residenciais. A escala observada é incomum para esse tipo de equipamento: a contagem diária de bots ativos chegou a aproximadamente 1,83 milhão de IPs, enquanto o volume operacional incluiu cerca de 1,7 bilhão de comandos de DDoS em apenas três dias, entre 19 e 22 de novembro de 2025. O domínio C2 14emeliaterracewestroxburyma02132[.]su ganhou visibilidade anômala no mesmo período, chegando a aparecer entre os domínios mais consultados em rankings públicos de tráfego.
O malware não se limita a negação de serviço distribuída. As amostras analisadas incluem funções de encaminhamento por proxy, shell reverso e gerenciamento de arquivos, o que amplia o valor dos dispositivos comprometidos para operadores criminosos. Em vez de usar apenas a capacidade de gerar tráfego contra alvos, a operação parece explorar a largura de banda residencial e a presença contínua desses dispositivos em rede para formar uma infraestrutura de proxy e monetização. Mais de 96% dos comandos observados estavam relacionados ao uso dos nós como serviço de proxy, sinalizando que a botnet pode ser usada tanto para DDoS quanto para mascarar tráfego ou revender capacidade de rede.
A operação também demonstra adaptação de infraestrutura. Domínios de comando e controle associados à Kimwolf teriam sido retirados do ar ao menos três vezes em dezembro, e versões recentes passaram a usar ENS, o Ethereum Name Service, em uma técnica conhecida como EtherHiding. Nesse modelo, o malware consulta um nome ENS, como pawsatyou[.]eth, para recuperar dados usados na resolução do endereço real do C2 por meio de contrato inteligente. Essa mudança não torna a botnet invisível, mas dificulta derrubadas baseadas apenas em domínio tradicional e obriga defensores a correlacionar DNS, tráfego TLS, consultas a infraestrutura blockchain e comportamento de endpoint.
Depois de executada no dispositivo comprometido, a Kimwolf tenta garantir que apenas uma instância do processo permaneça ativa. Essa etapa reduz conflitos locais, evita duplicação de tráfego e preserva o controle do bot dentro do equipamento. Em seguida, o malware decripta informações embutidas relacionadas ao C2 e usa DNS sobre TLS para obter o endereço de conexão. O canal de comunicação com o servidor de comando também utiliza TLS para receber instruções, o que reduz a visibilidade de inspeções simples baseadas apenas em conteúdo de rede.
As capacidades de DDoS abrangem métodos sobre UDP, TCP e ICMP, totalizando 13 formas de ataque descritas no material técnico. Os alvos citados ficam nos Estados Unidos, China, França, Alemanha e Canadá. O material analisado não informa uma lista completa de vítimas, não atribui publicamente a operação a um ator conhecido e não confirma o vetor inicial de propagação. Portanto, a análise defensiva deve separar três fatos: há grande volume de bots Android ativos, há comandos de DDoS e proxy em escala, mas a forma precisa pela qual os dispositivos são infectados ainda não está estabelecida.
A relação com a botnet AISURU aparece em múltiplos artefatos técnicos. Há similaridades em pacotes APK submetidos a repositórios de análise, uso compartilhado de certificado de assinatura em alguns casos e um servidor downloader ativo, defangado como 93.95.112[.]59, que continha referências a APKs das duas botnets. Entre setembro e novembro, as duas operações teriam usado scripts de infecção comuns e coexistido no mesmo lote de dispositivos. A conclusão operacional mais prudente é tratar Kimwolf e AISURU como ecossistemas fortemente relacionados, com possível reutilização de código e infraestrutura, sem assumir que todos os ataques atribuídos historicamente a uma única botnet tenham vindo exclusivamente dela.
A superfície de risco está concentrada em dispositivos Android de baixo custo ou de manutenção limitada, principalmente caixas de TV conectadas a redes domésticas. Equipamentos desse tipo costumam permanecer ligados continuamente, recebem pouca supervisão de inventário, podem rodar builds Android customizadas e frequentemente operam fora do ciclo de atualização de fabricantes reconhecidos. Em uma rede corporativa, o risco aumenta quando esse tipo de dispositivo é usado em recepção, sala de reunião, sinalização digital, alojamento, laboratório ou ambiente terceirizado sem segmentação adequada.
As maiores concentrações de infecção citadas incluem Brasil, Índia, Estados Unidos, Argentina, África do Sul e Filipinas. Isso não significa que todos os dispositivos desses países estejam vulneráveis, mas indica presença relevante de bots ativos nessas regiões. Como o vetor de propagação não está claro, equipes de defesa não devem focar apenas em uma vulnerabilidade específica. A abordagem correta é combinar inventário, análise de tráfego, revisão de firmware, segmentação e validação de origem dos aplicativos instalados.
Além dos modelos mencionados nominalmente, a classe afetada inclui dispositivos vendidos como TV boxes genéricas ou com marcas pouco auditáveis, especialmente quando expostos a redes sem monitoramento e com permissões amplas de instalação de APKs.
- Dispositivos citados: TV BOX, SuperBOX, HiDPTAndroid, P200, X96Q, XBOX, SmartTV e MX10.
- Ambientes de maior risco: redes residenciais, sinalização digital, salas com TVs Android e segmentos corporativos sem isolamento.
- Capacidades observadas: DDoS, proxy, shell reverso, gerenciamento de arquivos e cliente de comando em Rust para formação de rede proxy.
A investigação deve começar por ativos Android não gerenciados ou parcialmente gerenciados. Em redes corporativas, procure dispositivos com tráfego persistente para domínios incomuns, DNS sobre TLS não documentado e sessões TLS recorrentes para destinos sem relação com fornecedores autorizados. A Kimwolf criptografa dados sensíveis de C2 e usa comunicação TLS, então a ausência de payload legível não reduz a criticidade. O padrão de beaconing, a reputação de destino, a frequência de conexão e o volume de saída são mais úteis que a inspeção isolada de conteúdo.
Em roteadores, firewalls e sensores de DNS, a presença do domínio C2 defangado 14emeliaterracewestroxburyma02132[.]su deve ser tratada como sinal de comprometimento ou tentativa de resolução associada à operação. O uso de ENS também justifica atenção a consultas ou tráfego de dispositivos Android para infraestrutura blockchain sem justificativa operacional. Quando a telemetria permitir, correlacione picos de UDP, TCP ou ICMP saindo de TVs e set-top boxes com conexões anteriores para infraestrutura suspeita de C2.
No endpoint Android, a coleta pode ser limitada, mas ainda é possível revisar aplicativos instalados, certificados de assinatura desconhecidos, serviços persistentes, processos que tentam manter instância única e arquivos recém-criados por APKs fora de lojas confiáveis. Em ambientes com MDM ou EDR para Android, eventos de execução nativa via NDK, conexões de rede de aplicativos de mídia e uso inesperado de proxy devem receber prioridade.
- Resoluções ou conexões para
14emeliaterracewestroxburyma02132[.]su,pawsatyou[.]ethou93.95.112[.]59, sempre tratados em formato defangado. - Tráfego DNS sobre TLS originado de TVs Android, set-top boxes ou tablets sem política corporativa que autorize esse comportamento.
- Volume anormal de saída em UDP, TCP ou ICMP partindo de dispositivos de mídia, especialmente quando combinado com sessões TLS recorrentes.
- APK desconhecido com permissões amplas, assinatura não reconhecida ou comportamento de gerenciamento de arquivos e proxy em equipamento de TV.
A resposta deve priorizar contenção de ativos de mídia Android antes de qualquer tentativa de limpeza pontual. Dispositivos suspeitos devem ser isolados em segmento separado, ter tráfego de saída bloqueado para infraestrutura suspeita e passar por validação de firmware, aplicativos instalados e origem de atualização. Quando o fabricante não fornece imagem confiável, atualização verificável ou mecanismo de suporte, a substituição do equipamento costuma ser mais segura do que tentar restaurar confiança em um sistema possivelmente adulterado.
No perímetro, bloqueios baseados em domínios e IPs defangados ajudam, mas não são suficientes porque a operação já demonstrou mudança de C2 e uso de ENS. Controles mais resilientes incluem segmentação de IoT, negação padrão de saída para dispositivos que não precisam acessar a internet ampla, DNS corporativo obrigatório, bloqueio de DNS sobre TLS não autorizado e alertas para tráfego volumétrico saindo de classes de ativos que não deveriam gerar esse padrão.
Para organizações que usam Android TV em ambientes profissionais, a mitigação deve virar requisito de arquitetura: inventário com proprietário técnico, rede separada, atualização controlada, remoção de APKs não essenciais e telemetria mínima de rede. A ausência de vetor inicial confirmado torna imprudente esperar por uma única correção. O objetivo defensivo é reduzir a capacidade de persistência, limitar a comunicação com C2, impedir uso como proxy e evitar que equipamentos de baixo valor operacional se transformem em infraestrutura ofensiva.
- Isolar TVs Android e set-top boxes em VLAN ou segmento de IoT sem acesso lateral a estáções, servidores ou redes administrativas.
- Forçar resolução DNS por infraestrutura autorizada e bloquear DNS sobre TLS não documentado para dispositivos de mídia.
- Remover APKs de origem desconhecida, revisar certificados de assinatura e reinstalar firmware apenas a partir de canal confiável do fabricante.
- Criar alertas para picos de UDP, TCP e ICMP originados de dispositivos de TV, especialmente quando houver conexão prévia com domínios ou IPs suspeitos.
- Substituir equipamentos sem atualização verificável, sem fornecedor responsável ou com histórico de aplicativos pré-instalados não auditáveis.
0 Comentários