TuxBot v3 usa IA para criar botnet IoT com DDoS, C2 criptografado e 1.496 senhas

Pesquisadores da Unit 42, divisão de inteligência de ameaças da Palo Alto Networks, identificaram uma estrutura de botnet para dispositivos de Internet das Coisas chamada TuxBot v3 Evolution. O projeto apresenta sinais claros de que seu desenvolvedor utilizou um grande modelo de linguagem para gerar, adaptar e integrar partes do código malicioso.

O uso de inteligência artificial, no entanto, produziu resultados inconsistentes. Embora o modelo tenha ajudado a construir uma plataforma modular com diversos mecanismos de ataque, vários componentes analisados não funcionavam corretamente. O desenvolvedor também deixou nos arquivos comentários gerados pela IA, incluindo explicações sobre decisões de programação e até um aviso de segurança que dizia que o código deveria ser usado apenas para pesquisas autorizadas.

Segundo a Unit 42, uma revisão manual relativamente simples poderia ter identificado e corrigido os principais erros. Os pesquisadores avaliam, portanto, que versões mais completas e funcionais podem já existir ou ser produzidas com pouco esforço.

A estrutura recuperada estava aproximadamente 70% operacional. Funções centrais, como varredura de dispositivos, ataques de força bruta, persistência, comunicação com o servidor de comando e controle e execução de ataques distribuídos de negação de serviço, funcionavam na amostra examinada.

Botnet foi compilada para 17 arquiteturas

O TuxBot v3 Evolution foi desenvolvido para infectar uma ampla variedade de equipamentos conectados à internet, incluindo roteadores, câmeras IP, servidores compactos, dispositivos Android e outros sistemas embarcados baseados em Linux.

O agente malicioso é escrito principalmente em C e pode ser compilado para 17 arquiteturas de processadores. Entre elas estão ARM, ARM64, MIPS, MIPSEL, MIPS64, x86_64, PowerPC e RISC-V, além de outras plataformas utilizadas em equipamentos IoT.

Essa compatibilidade amplia o número potencial de dispositivos que podem ser incorporados à botnet. Depois de identificar a arquitetura do equipamento comprometido, a infraestrutura pode disponibilizar pela internet o binário apropriado para aquele processador.

Além do agente instalado nos dispositivos, a plataforma reúne um servidor de comando e controle escrito em Go, um painel para comercialização de ataques DDoS, uma máquina virtual personalizada para execução de exploits, ambientes de teste baseados em Docker e um sistema automatizado de compilação e implantação.

O material recuperado pelos pesquisadores incluía o código-fonte completo, binários compilados, configurações de Docker Compose, ambientes de emulação QEMU e 254 relatórios automatizados de testes de desempenho de ataques DDoS.

Força bruta testa 1.496 combinações de credenciais

Uma das principais formas de propagação do TuxBot é o ataque de força bruta contra serviços Telnet expostos à internet. O malware possui uma lista com 1.496 combinações de nomes de usuário e senhas, incluindo credenciais padrão ou fracas frequentemente encontradas em dispositivos IoT.

Quando encontra um equipamento acessível, o scanner tenta autenticar-se automaticamente utilizando essas combinações. Caso obtenha acesso, a botnet pode transferir e executar a versão do malware compatível com a arquitetura do dispositivo.

O framework também inclui scanners para SSH, interfaces HTTP e Android Debug Bridge, conhecido como ADB. De acordo com a análise, esses quatro mecanismos estavam funcionais na versão examinada.

O scanner HTTP consegue administrar até 128 conexões simultâneas para localizar painéis web vulneráveis. O TuxBot também contém códigos destinados a explorar vulnerabilidades conhecidas em mais de 30 famílias de dispositivos IoT.

Essa parte da estrutura, porém, apresentava limitações. A máquina virtual personalizada para exploits não funcionava corretamente, o mecanismo principal de exploração não era chamado durante a execução e determinadas cargas maliciosas utilizavam configurações incompatíveis ou endereços de servidores desativados.

C2 utiliza criptografia e cinco canais alternativos

Depois da infecção, os dispositivos comprometidos tentam estabelecer comunicação com o servidor de comando e controle, chamado de C2. O canal principal utiliza TCP com criptografia baseada em X25519 e ChaCha20-Poly1305, dificultando a inspeção direta das instruções transmitidas entre o servidor e os bots.

O TuxBot também possui uma arquitetura redundante de comunicação. Caso o canal principal deixe de funcionar, o malware pode recorrer a cinco mecanismos alternativos: um algoritmo de geração de domínios baseado em SHA-512, comunicação ponto a ponto, IRC, consultas DNS TXT e requisições HTTP periódicas.

O algoritmo de geração de domínios, ou DGA, pode produzir 20 endereços por dia. Esse mecanismo permite que os operadores registrem novos domínios para recuperar o controle da botnet caso os servidores originais sejam bloqueados.

Na comunicação P2P, comandos são distribuídos entre os dispositivos por um protocolo de propagação e assinados com Ed25519. A assinatura serve para que os bots verifiquem se as ordens foram emitidas pelo operador esperado.

Nem todos os canais alternativos estavam operacionais. A Unit 42 constatou que os mecanismos baseados em IRC e HTTP apresentavam erros, enquanto o canal principal, o DGA, o P2P e parte dos demais métodos estavam funcionais.

Painel oferece ataques DDoS como serviço

O servidor C2 do TuxBot foi escrito em Go e utiliza três portas TCP para diferentes funções.

A porta TCP 1999, ou 31337 dependendo da compilação, é usada para enviar comandos criptografados aos dispositivos infectados. A porta 2222 oferece uma interface SSH interativa para os operadores. Já a porta 9999 disponibiliza uma API baseada em JSON para acesso automatizado.

O painel SSH permite visualizar a quantidade de dispositivos conectados e emitir comandos de ataque. O sistema também impõe limites por usuário, incluindo número de ataques simultâneos, duração máxima e quantidade de bots disponíveis.

As contas, permissões e registros das operações são armazenados em um banco de dados MariaDB. Essa estrutura indica que o projeto foi planejado para funcionar como uma plataforma multiusuário de DDoS-as-a-Service, modelo no qual criminosos vendem ou alugam capacidade para derrubar sites, APIs, jogos e outros serviços online.

Entre os recursos funcionais estavam ataques de inundação por UDP, TCP e DNS. O código também continha componentes parcialmente adaptados do MHDDoS, uma ferramenta aberta em Python para geração de tráfego DDoS.

Ambiente de testes simulava jogos e serviços reais

O TuxBot inclui uma infraestrutura de testes baseada em Docker, criada para avaliar os ataques antes de sua utilização em ambientes externos.

Uma das configurações, chamada pelos desenvolvedores de “battle arena”, inicia um servidor C2, cinco réplicas de bots e um alvo executando nginx e listeners associados a serviços como Minecraft, TeamSpeak, FiveM e Xbox Live.

Os 254 relatórios encontrados mostram testes de 12 métodos de ataque contra três hosts controlados. O sistema media indicadores como quantidade de pacotes por segundo, volume de tráfego e taxas de erro.

Essas avaliações foram realizadas no início de janeiro de 2026, poucas semanas antes de uma amostra do TuxBot ser enviada ao VirusTotal em 20 de janeiro. O histórico do projeto indica que o desenvolvimento começou pelo menos em 3 de janeiro de 2025, quando o responsável clonou o repositório do MHDDoS no GitHub.

Ao ser executado, o TuxBot segue uma sequência de inicialização destinada a garantir sua permanência no equipamento e reduzir a possibilidade de análise.

O malware procura ferramentas de depuração e ambientes virtualizados, altera ou oculta o nome de seu processo e instala diferentes mecanismos de persistência. Entre eles estão serviços systemd, tarefas cron, scripts de inicialização e um processo watchdog que reinicia o bot caso ele seja interrompido.

O malware também tenta encerrar processos pertencentes a outras famílias de botnets. Essa prática, comum entre ameaças voltadas para dispositivos IoT, impede que concorrentes consumam os recursos de processamento, memória e largura de banda do mesmo equipamento.

Depois disso, o TuxBot inicializa scanners, módulos DDoS, canais alternativos de C2, um proxy SOCKS5 e um componente reservado para mineração de criptomoedas. Na amostra analisada, contudo, a função de mineração era apenas um placeholder e não estava operacional.

Um dos elementos mais incomuns encontrados pela Unit 42 foi a presença de extensos comentários produzidos pelo modelo de linguagem durante o desenvolvimento.

Os arquivos continham explicações sobre decisões de programação, interrupções no raciocínio e referências ao “usuário”, termo utilizado pela IA para descrever a pessoa que enviava os comandos. Esses registros apareceram principalmente durante tarefas de adaptação de módulos e conversão de código entre linguagens.

Todos os aproximadamente 60 arquivos em C do diretório principal também continham um aviso informando que o código era destinado a pesquisas educacionais e autorizadas e que seu uso indevido poderia ser ilegal. O texto provavelmente foi acrescentado automaticamente pelo modelo e não foi removido pelo desenvolvedor.

Em outro caso, o código afirmava implementar o algoritmo Argon2id para proteção de senhas. A função, entretanto, utilizava operações baseadas em SHA-256 e PBKDF2, mas formatava o resultado para que parecesse uma saída Argon2id.

Os pesquisadores também encontraram chaves XOR incompatíveis, erros na máquina virtual de exploits, componentes que nunca eram chamados e problemas nos canais de comunicação. A aparência organizada do código pode ter contribuído para que o responsável confiasse no conteúdo gerado sem realizar uma auditoria adequada.

Apesar das falhas, a Unit 42 conseguiu corrigir alguns dos problemas com poucos comandos direcionados a outro modelo de linguagem. Isso indica que os operadores também poderiam aprimorar rapidamente a plataforma.

A investigação relacionou a infraestrutura do TuxBot a ferramentas associadas ao ecossistema Keksec, conhecido por operar diferentes variantes de botnets IoT simultaneamente.

Um dos servidores de comando e controle foi identificado no endereço 209.182.237[.]133, hospedado em Singapura. A porta 2222 apresentava uma identificação compatível com o servidor SSH personalizado do painel de controle e foi observada pela primeira vez em 5 de março de 2026.

Outro endereço, 185.10.68[.]127, hospedava os binários utilizados para infectar diferentes arquiteturas. O mesmo servidor também distribuía amostras do Kaitori v3.9, variante associada às famílias Tsunami, Mirai e Gafgyt.

A Unit 42 também encontrou conexões com ferramentas AISURU. Embora TuxBot, Kaitori e AISURU sejam bases de código distintas, elas convergiam para a mesma infraestrutura de distribuição, o que sugere a atuação de um mesmo operador ou de agentes pertencentes ao mesmo ecossistema.

O TuxBot incorpora características de diferentes botnets, incluindo Mirai, AISURU e uma linhagem chamada Wuhan, além de adaptar funcionalidades do MHDDoS.

A proposta vai além de uma simples modificação do código do Mirai. O projeto adiciona comunicação C2 criptografada, geração automática de domínios, propagação P2P, múltiplos scanners, uma máquina virtual para exploits e um painel comercial de ataques DDoS.

Apesar das falhas, os componentes essenciais já permitem localizar dispositivos vulneráveis, testar credenciais fracas, manter persistência e utilizar os equipamentos comprometidos em ataques de negação de serviço.

A Unit 42 identificou seis novas amostras em sua telemetria interna em abril de 2026, compiladas para múltiplas arquiteturas e aparentemente mais próximas de versões de produção. A atividade indica que o projeto não ficou restrito a um ambiente experimental.

Para empresas e provedores, a descoberta destaca o risco representado por roteadores, câmeras, dispositivos Android e equipamentos embarcados expostos diretamente à internet. Credenciais padrão, serviços administrativos acessíveis externamente e firmware desatualizado continuam oferecendo meios eficientes para a formação de botnets.

A adoção de IA também pode reduzir o esforço necessário para que um único desenvolvedor combine recursos anteriormente encontrados apenas em projetos mantidos por equipes maiores. Ao mesmo tempo, o TuxBot demonstra que código gerado por modelos de linguagem pode conter falhas graves quando utilizado sem revisão técnica.