
AISURU, Kimwolf, JackSkid e Mossad abusavam de dispositivos IoT e redes proxy residenciais para gerar ataques hipervolumétricos globais e vender capacidade de DDoS como serviço.
| Componente | Infraestrutura de comando e controle das botnets IoT AISURU, Kimwolf, JackSkid e Mossad, associadas a dispositivos Android, DVRs, câmeras web, roteadores Wi-Fi, smart TVs e set-top boxes comprometidos. |
| Vetor | Comprometimento e alistamento de dispositivos IoT, incluindo aparelhos atrás de roteadores domésticos, com abuso de redes proxy residenciais e exposição de Android Debug Bridge em dispositivos locais acessíveis por provedores proxy como IPIDEA. |
| Impacto | As botnets foram usadas para ataques DDoS globais, incluindo tráfego de aproximadamente 30 Tbps, um pico atribuído de 31,4 Tbps por 35 segundos em novembro de 2025, além de campanhas com bilhões de pacotes por segundo e centenas de milhões de requisições por segundo. |
| Prioridade | Remover dependência de dispositivos IoT expostos ou não gerenciados, bloquear exposição de ADB, revisar uso de proxy residencial, monitorar telemetria de DDoS e validar se ativos domésticos, corporativos ou de clientes apresentam comunicação com infraestrutura C2. |
| Artefatos | A operação mirou servidores C2; quase 1.000 servidores ligados a AISURU e Kimwolf foram null-routed por uma das equipes participantes. |
| Escala | As quatro botnets somavam ao menos 3 milhões de dispositivos infectados no mundo, com centenas de milhares localizados nos Estados Unidos; Kimwolf sozinha alistou mais de 2 milhões de dispositivos Android. |
Uma operação autorizada judicialmente desarticulou infraestrutura de comando e controle usada por quatro botnets IoT identificadas como AISURU, Kimwolf, JackSkid e Mossad. A atividade investigada envolvia redes de dispositivos comprometidos usadas para lançar ataques distribuídos de negação de serviço contra vítimas em vários países. A escala operacional era incomum mesmo para o ecossistema Mirai e variantes relacionadas: os ataques observados chegaram à faixa de dezenas de terabits por segundo, com um evento atribuído a AISURU e Kimwolf medindo 31,4 Tbps durante 35 segundos em novembro de 2025.
O caso expõe uma mudança importante na superfície de DDoS. Parte da capacidade não vinha apenas de dispositivos diretamente visíveis na internet, mas também de aparelhos em redes domésticas que normalmente ficariam protegidos atrás de roteadores. O abuso de redes proxy residenciais e de dispositivos com Android Debug Bridge exposto permitiu que operadores alcançassem alvos internos dessas redes e alistassem smart TVs, set-top boxes e outros equipamentos Android de baixo custo. A infraestrutura resultante foi explorada em modelo de crime como serviço, com venda de capacidade de ataque a outros criminosos.
AISURU é descrita como uma botnet ativa desde pelo menos agosto de 2024, enquanto Kimwolf aparece como uma versão focada em Android e foi documentada posteriormente com mais de 2 milhões de dispositivos alistados. A base de vítimas incluía principalmente smart TVs Android e set-top boxes de marcas menos conhecidas, além de outros IoT como DVRs, câmeras web e roteadores Wi-Fi. Esses ativos são atraentes para operadores de DDoS porque costumam permanecer ligados, recebem pouca manutenção, executam firmware desatualizado e raramente são monitorados com a mesma disciplina aplicada a servidores corporativos.
O elemento técnico mais relevante é o caminho de acesso por redes proxy residenciais. Em vez de depender exclusivamente de varredura aberta na internet, Kimwolf aproveitou a presença de dispositivos comprometidos dentro de redes domésticas para alcançar ativos locais que não seriam acessíveis diretamente de fora. Quando ADB estava exposto em dispositivos Android dentro desse ambiente, o operador conseguia alistar novos nós e expandir rapidamente a botnet. O mesmo tipo de vulnerabilidade ou exposição foi associado também a JackSkid e Mossad, indicando que a técnica foi copiada por outras operações para crescer em escala semelhante.
Após o comprometimento, os dispositivos eram controlados por servidores C2 que recebiam ou distribuíam comandos de ataque. Documentos judiciais mencionam centenas de milhares de comandos DDoS emitidos pelas quatro variantes. Os ataques incluíam volumes acima de 30 Tbps, tráfego na ordem de 14 bilhões de pacotes por segundo e picos de 300 milhões de requisições por segundo em observações de campanhas hipervolumétricas. Em alguns casos, criminosos usaram a pressão operacional dos ataques para exigir pagamentos de extorsão das vítimas.
A superfície de risco cobre ambientes domésticos, pequenas empresas, provedores de internet, operadores de proxy residencial e organizações que dependem de mitigação DDoS em alta escala. O problema não se limita ao proprietário direto do dispositivo infectado: um aparelho comprometido pode virar recurso de ataque contra terceiros, consumir largura de banda local, prejudicar reputação de endereços IP residenciais e aumentar ruído operacional para provedores de conectividade.
O impacto para vítimas de DDoS é concentrado em disponibilidade. Ataques desse porte podem degradar infraestrutura de borda, saturar enlaces, afetar clientes downstream de ISPs e pressionar até serviços de mitigação em nuvem de alta capacidade. Para organizações que operam serviços públicos, APIs, jogos online, comércio eletrônico ou plataformas financeiras, a defesa precisa considerar não só requisições HTTP, mas também telemetria de pacotes, origem residencial distribuída, mudanças bruscas de método de ataque e uso combinado de volumetria L3/L4 com carga em camada de aplicação.
- Dispositivos Android de baixo custo, especialmente smart TVs e set-top boxes, aparecem como a maior base conhecida de Kimwolf.
- DVRs, câmeras web e roteadores Wi-Fi também integram o conjunto de dispositivos IoT infectados pelas quatro botnets.
- JackSkid registrou mais de 150.000 vítimas diárias nas duas primeiras semanas de março de 2026, com pico de 250.000 em 8 de março.
- Mossad manteve média superior a 100.000 vítimas diárias no mesmo período observado.
- Centenas de milhares de dispositivos infectados estavam localizados nos Estados Unidos, embora a base total fosse global.
A investigação defensiva deve separar dois planos: identificação de dispositivos que podem estar compondo a botnet e detecção de impacto DDoS nos serviços atacados. No primeiro plano, equipes de rede e provedores devem procurar dispositivos IoT com tráfego persistente para endpoints externos desconhecidos, padrões de beaconing incompatíveis com o uso normal do aparelho, tentativas de conexão associadas a ADB e atividade anômala originada de segmentos residenciais ou redes de clientes. Em ambientes corporativos, qualquer ADB acessível fora de estáções de desenvolvimento controladas deve ser tratado como exposição crítica.
No plano de DDoS, a telemetria deve priorizar mudanças repentinas de volume, diversidade de ASN e endereços residenciais, aumento simultâneo de pacotes por segundo e requisições por segundo, além de alternância entre vetores de camada de rede e camada de aplicação. Como as botnets foram usadas em modelo de serviço, diferentes clientes criminosos podem acionar padrões distintos a partir da mesma base de dispositivos. Isso exige correlação por janela temporal, assinatura comportamental e infraestrutura C2, não apenas por um único indicador estático.
- Conexões de dispositivos Android ou IoT para infraestrutura externa sem relação com serviços legítimos do fabricante.
- ADB exposto em redes internas, domésticas, laboratoriais ou de clientes atendidos por proxy residencial.
- Picos de tráfego em Tbps, Bpps ou Mrps com distribuição ampla por endereços residenciais.
- Mudança súbita no perfil de origem de requisições, com grande volume vindo de redes domésticas e provedores distintos.
- Sinais de que dispositivos atrás de NAT passaram a iniciar tráfego coordenado para destinos de ataque ou para C2.
A resposta deve começar pela redução da superfície explorável. Organizações que operam dispositivos Android, IoT ou ambientes de teste precisam desabilitar ADB quando não houver necessidade operacional, restringir o acesso a redes administrativas, segmentar dispositivos não confiáveis e impedir que aparelhos de consumo tenham comunicação livre com a internet corporativa. Provedores de proxy residencial devem revisar como clientes ou nós conseguem alcançar endereços locais, porque o caso mostra que o acesso a redes internas pode ser convertido em mecanismo de alistamento de botnets.
Para defesa contra DDoS, a prioridade é validar capacidade de absorção, regras de rate limiting, proteção em borda e runbooks de escalonamento com provedores de mitigação. A escala citada, acima de 30 Tbps e com centenas de milhões de requisições por segundo, torna insuficiente depender apenas de controles locais. Equipes devem testar contatos operacionais, limiares de ativação, coleta de amostras de tráfego, preservação de logs e coordenação com ISP antes de um incidente. Também é necessário revisar clientes ou ambientes que usam serviços de proxy residencial, pois a exposição de dispositivos internos pode criar risco indireto mesmo quando o serviço principal da empresa não está vulnerável.
A desarticulação de C2 reduz capacidade operacional imediata, mas não elimina a causa técnica. O volume de dispositivos vulneráveis ou mal configurados continua alto, e outras botnets já replicaram a técnica. A contenção durável depende de atualização de firmware, remoção de aparelhos sem suporte, bloqueio de serviços administrativos expostos, inventário real de IoT e colaboração entre provedores de nuvem, telecomunicações, fabricantes, operadores de DNS e equipes de resposta.
- Desabilitar ADB em dispositivos Android que não exigem depuração e bloquear acesso externo ou lateral não autorizado.
- Segmentar IoT em redes próprias, sem acesso amplo a ativos corporativos ou administrativos.
- Auditar uso de proxy residencial e impedir que o serviço exponha dispositivos locais a terceiros.
- Atualizar firmware de roteadores, câmeras, DVRs, smart TVs e set-top boxes quando houver suporte disponível.
- Revisar planos de mitigação DDoS para cenários hipervolumétricos acima da capacidade local.
- Coletar e preservar logs de borda, NetFlow, DNS, autenticação de proxy e telemetria de endpoint para correlação pós-incidente.
0 Comentários