BOTNET KIMWOLF: Ataques DDoS Internos e como Mitigar agora (2026)
Mais uma vez, as redes dos ISPs estão sendo atacadas… mas agora o inimigo vem de dentro. Você já viu o call-center explodir com reclamações de lentidão sem explicação? Mal nos recuperamos do ataque que explorou as vulnerabilidades no SDK Realtek onde roteadores e ONUs eram comprometidos e usados para DDoS contra terceiros, e já estamos lidando com uma ameaça muito mais perigosa e disseminada: a botnet AISURU/Kimwolf. Essa botnet explora principalmente aparelhos Android baratos de IPTV, SmartTV e set-top-box instalados na casa dos usuários. Esses dispositivos viram zumbis que vendem proxy residencial e, em menor escala, participam de ataques DDoS a terceiros. O resultado? Problemas generalizados em várias frentes: RESULTADO: clientes frustrados, custo alto de suporte e risco de reputação pro ISP inteiro. Um ciclo vicioso que ninguém quer e que está crescendo rápido. UM VERDADEIRO CAOS! Abaixo deixo um compilado de perguntas e respostas do que já sabemos sobre o assunto. E no final algumas dicas de como se proteger ou mitigar. 1) De onde vem esse ataque, e por quê? Segundo os sites de segurança Xlab e Synthient, os atores envolvidos na botnet a utilizam para ganhar dinheiro com alguns tipos de serviço: Como eles têm controle completo de todos os dispositivos, utilizam os servidores de comando-controle para criar túneis para navegação, instalar apps e iniciar ataques DDoS contra terceiros. Já houve reportes também de coisas além da segurança, como passar imagens e vídeos de assuntos controversos (políticos, geo-políticos, etc.). 2) Já tem muita gente infectada? Dados da Synthient e da XLab indicam que, embora seja apenas uma fração das comunicações, foram mais de 12 milhões de IPs únicos (estimam cerca de 2 milhões de dispositivos). E a maior parte deles vem do Brasil (~15%), seguidos por Vietnã, Índia, EUA e Argentina. A empresa chinesa de segurança XLab identificou que a botnet Kimwolf havia comprometido entre 1,8 e 2 milhões de dispositivos, com forte concentração no Brasil, Índia, Estados Unidos da América e Argentina. Imagem: blog.xLab.qianxin.com 3) Como os equipamentos são infectados? Você já deve ter se perguntado como esses equipamentos podem ser tão baratos, né? Pois é. Algumas imagens de dispositivos que já vem infectados. Fonte: Synthient. Também já se constatou que eles não passam por um processo rigoroso de correção de vulnerabilidades, patches de segurança e atualizações/melhorias. É o prato cheio nas mãos de criminosos. A principal forma de infecção da Kimwolf é explorando uma falha nas SDKs dos aplicativos de proxy-residencial (como Byteconnect, IPIDEA e PYPROXY). O atacante aluga um proxy legítimo desses serviços, usa o túnel para “voltar” pela conexão do próprio aparelho e acessar a rede local interna onde encontra o ADB (Android Debug Bridge) exposto sem autenticação (porta 5555 e similares). Em segundos, ele manda comandos remotos, baixa o malware e instala tudo. Topologia de infecção via proxy residenciais. Fonte: Synthient. Existem algumas formas que o equipamento pode ser infectado (mas todas acabam convergindo nesse mecanismo principal): 1º) Vindo de fábrica Muitos aparelhos saem de fábrica já com aplicativos de proxy-residencial pré-instalados (sem o usuário saber), para monetizar a banda depois. Quando o dispositivo entra no pool de proxy (ex: IPIDEA, Byteconnect, PYPROXY), o atacante explora exatamente essa porta aberta.Este é o jeito principal de infecção é assim que a botnet Kimwolf mais se espalhou, com milhões de dispositivos comprometidos em meses. 2º) Através de instalação de apps não confiáveis Os usuários instalam aplicativos de terceiros (não verificados), e estes silenciosamente adicionam o SDK de proxy, ativando o caminho para a exploração via ADB. 3º) Portas vulneráveis ADB/Telnet Alguns desses IPTV já vêm com ADB exposto por padrão. Mesmo sem o SDK inicial, um pequeno scan/brute force em portas como 5555, 3222 ou 5858 permite acesso shell e instalação do malware. 4) O que são estes apps de proxy-residenciais? Basicamente são empresas que vendem navegação à internet através de seus “proxies” ao redor do mundo. Quando você compra um serviço com eles, você estabelece uma “VPN” até os seus servidores, e então a sua navegação sai pelo pacote escolhido (por exemplo, navegação por IPs residenciais do Brasil, do Vietnã, etc.). Eles ganham dinheiro cobrando alguns dólares por GB trafegado. Mas e o que fazer? Se quer uma resposta fácil, você não terá. Vamos ter que enfrentar esse problema em diversas frentes. Afinal, diferente de outras botnets onde o dispositivo estava no controle do ISP (o roteador, a ONU, etc), neste caso os equipamentos infectados em 99% dos casos são do próprio cliente. Na perspectiva do ISP, podemos enfrentar o problema em 4 ações: Ação 1: identificar clientes/equipamentos ofensores No github da Synthient (o link vai estar mais abaixo), há uma fração da lista de IPs/portas utilizadas na botnet. Mas eles já são a primeira etapa para identificação. Utilize esta lista e compare com as comunicações no seu software de netflow (de preferência o made4flow), vindos do seu BNG. Com isto, você já vai conhecer quem internamente está infectado. Ação 2: mitigar / contornar impactos Aqui entra a criatividade técnica. O básico é o bloqueio em firewall ou blackhole das comunicações (mas elas não duram por muito tempo e servem no máximo como band-aid – pois a botnet é tão capaz de trocar de IPs/redes quanto as TVs piratas de contornar bloqueios da Anatel). Feito isto, comece a pensar em soluções mais elaboradas. Se precisar de ajuda, nos chame! Ação 3: corrigir equipamentos infectados As recomendações dos sites de segurança são: destrua estes aparelhos. Ponto final. Mas sabemos da realidade. Não tem como destruir o aparelho de um cliente, e sim trabalhar na conscientização. Desenvolva um roteiro, tenha jogo de cintura, e vá visitar seu cliente. Mostre como a rede dele está sendo utilizada para cometer crimes. Mostre os sites, os artigos. Tente atualizar, resetar, remover aplicativos suspeitos. Use o site https://synthient.com/check para mostrar ao cliente que ele foi pego nas varreduras da botnet. Ação 4: implementar monitoramento constante Se você está lidando com isso na sua rede e quer trocar ideia sobre filtros, PBR ou monitoramento automático, me manda mensagem ou comentário aqui. Estamos ajudando vários ISPs a mapear e isolar esses dispositivos sem dor de cabeça extra. QUERO AJUDA #CyberSecurity #DDoS #Botnet #ISP #Kimwolf #ProvedorInternet #SegurancaDigital Referências do artigo https://synthient.com/blog/a-broken-system-fueling-botnetshttps://blog.xlab.qianxin.com/kimwolf-botnet-en/#backgroundhttps://synthient.com/checkhttps://github.com/synthient/public-research/blob/main/2026/01/kimwolf/README.mdhttps://krebsonsecurity.com/2026/01/the-kimwolf-botnet-is-stalking-your-local-network/https://krebsonsecurity.com/2026/01/who-benefited-from-the-aisuru-and-kimwolf-botnets/https://krebsonsecurity.com/2025/11/is-your-android-tv-streaming-box-part-of-a-botnet/
Testes de Desempenho CGN/BNG em Plataforma Huawei NE8000
Aprenda com Luiz Puppin, especialista em Huawei, como fazer uma análise técnica dos testes de desempenho (Forwarding Performance) realizados em um ambiente de laboratório com a plataforma Huawei NE8000, validando a capacidade do equipamento em operar como BNG+CGN integrado em alta carga. Os testes buscaram verificar: Objetivo dos Testes de Desempenho O objetivo foi comprovar que a solução Huawei consegue sustentar: Essas características são fundamentais para operações de ISPs e operadoras com alta concentração de assinantes atrás de CGN. Arquitetura Utilizada A topologia utilizada conecta: Metodologia 5. Evidências e Resultados A seguir estão as comprovações extraídas diretamente do arquivo de teste. 5.1. Assinantes autenticados com sucesso O relatório confirma a autenticação simultânea de milhares de assinantes PPPoE: O total validado foi de: 5.2. Criação de 32 milhões de sessões NAT O DUT atingiu o limite de escalabilidade previsto pelo fabricante: Ou seja, o equipamento suportou 32 milhões de fluxos simultâneos, sem degradação perceptível. 5.3. Tráfego Sustentado a 50 Gbps – Sem Perda de Pacotes Ou seja: 5.4. Tráfego Bidirecional 50 Gbps (25G + 25G) O laboratório validou a operação simultânea upstream e downstream: Novamente, com zero perda de pacotes: 5.5. Estabilidade da CPU A CPU permanece em níveis estáveis, sem atingir limites críticos. 5.6. Conclusão dos Testes de Desempenho Com base nas evidências, é possível concluir que: Portanto, a plataforma demonstra capacidade real para operar CGN/BNG em ambientes de larga escala, com alto volume de tráfego e grande densidade de assinantes. Este artigo foi desenvolvido em colaboração com a equipe de Gerentes de Produtos IP para ISP da Huawei Brasil, com agradecimento especial ao Thiago Sério e ao Natan Fernandes. Precisa de ajuda na configuração dos seus equipamentos Huawei? Nós podemos te ajudar! Quero conhecer mais
