Framework modular utiliza código gerado por inteligência artificial com avisos de segurança não removidos e raciocínio interno exposto, visando múltiplas arquiteturas e canais de comando e controle redundantes.
| Componente | TuxBot v3 Evolution (agente bot em C, servidor C2 em Go, VM de exploit personalizada) |
| Vetor | Ataques de força bruta em Telnet (1.496 pares de credenciais) e exploração de vulnerabilidades conhecidas em mais de 30 famílias de dispositivos IoT |
| Impacto | Comprometimento de dispositivos IoT para ataques DDoS, proxy SOCKS5, mineração de criptomoedas e estabelecimento de infraestrutura botnet resiliente |
| Prioridade | Aplicação de correções em dispositivos IoT, alteração de credenciais padrão e bloqueio de portas não padrão (1999, 2222) em firewalls de perímetro |
Pesquisadores de cibersegurança divulgaram detalhes sobre um framework de botnet da Internet das Coisas (IoT) até então não reportado, denominado TuxBot v3 Evolution, que apresenta fortes indicativos de ter sido desenvolvido com auxílio de Modelos de Grande Linguagem (LLM). A análise técnica revela que, embora a inteligência artificial tenha cumprido o pedido de gerar código para o botnet, o desenvolvedor falhou ao remover avisos de segurança e trechos de raciocínio interno (chain-of-thought) que foram deixados literalmente nos comentários do código fonte. Esses vestígios incluem interrupções automáticas, decisões de codificação e referências ao 'usuário', o que comprova o uso de automação na construção do malware.
Apesar do auxílio da IA, várias funções nas amostras analisadas apresentam falhas operacionais, indicando ausência de revisão manual rigorosa. O framework é composto por um ecossistema modular que inclui um agente bot escrito em linguagem C, capaz de compilação cruzada para diversas arquiteturas de processador, e um servidor de Comando e Controle (C2) desenvolvido em Go, integrado a um painel de DDoS sob demanda. A adoção de IA sugere uma tentativa de acelerar o desenvolvimento de recursos complexos, permitindo que um único operador produza um conjunto de ferramentas multifacetadas, embora a implementação atual ainda contenha erres técnicos significativos.
O agente do TuxBot é projetado para infectar uma ampla gama de hardwares, oferecendo suporte a compilação para arquiteturas ARM, MIPS, MIPSEL, MIPS64, x86_64, PowerPC e RISC-V. Após a infecção inicial, o botnet segue uma sequência de inicialização predefinida que carrega o endereço do C2 a partir de uma arquitetura de múltiplas camadas, utilizando um canal primário e cinco mecanismos alternativos de comunicação para garantir resiliência contra táticas de desativação. O malware implementa proteções contra depuração e ambientes de máquina virtual (anti-VM), verificando a presença de ferramentas de análise comuns antes de prosseguir com a execução de submódulos maliciosos.
A comunicação com o servidor C2 é realizada através de um canal TCP criptografado, utilizando a porta 1999 ou 31337 para o despacho de comandos. A porta 2222 é exposta para fornecer um shell interativo para os operadores via SSH. Caso a comunicação direta falhe, o bot emprega algoritmos de geração de domínio (DGA) baseados em SHA512, protocolo P2P (gossip) com comandos assinados via Ed25519, Internet Relay Chat (IRC), consultas DNS TXT e polling HTTP como mecanismos de fallback. Essa redundância torna o takedown da infraestrutura de controle significativamente mais difícil em comparação com botnets tradicionais baseadas exclusivamente em TCP hardcoded.
O TuxBot possui linhagem técnica traçada a partir de botnets conhecidos, como Mirai, AISURU e Wuhan, além de portar parcialmente funcionalidades do toolkit de DDoS MHDDoS, escrito em Python. A superfície de ataque inclui roteadores, câmeras IP, set-top boxes Android e servidores com proteções insuficientes. O componente de disseminação ativo inclui um scanner HTTP capaz de gerenciar até 128 conexões simultâneas para identificar interfaces web vulneráveis, bem como scanners para os protocolos Telnet, SSH e Android Debug Bridge (ADB).
Para a propagação, o malware utiliza 1.496 pares de credenciais padrão em ataques de força bruta contra o serviço Telnet e incorpora código de exploração para mais de 30 famílias de dispositivos IoT. Uma vez estabelecido, o agente garante persistência por meio de serviços systemd, entradas cron e um processo watchdog (keepalive) que monitora e reinicia o binário malicioso em caso de terminação. As cargas úteis suportadas incluem o lançamento de ataques DDoS, término de processos concorrentes de outras malwares, estabelecimento de proxy SOCKS5 e execução de placeholder para mineração de criptomoedas.
- Dispositivos IoT nas arquiteturas ARM, MIPS, x86_64, PowerPC e RISC-V
- Serviços Telnet, SSH, HTTP e ADB expostos na internet
- Ambientes suscetíveis a exploração de vulnerabilidades conhecidas em mais de 30 famílias de dispositivos
A detecção do TuxBot v3 Evolution requer monitoramento de comportamentos anômalos em dispositivos de borda e IoT. As equipes de segurança devem investigar tentativas de conexão de saída para portas não padrão, especificamente TCP 1999, 31337 e 2222, especialmente se o tráfego for criptografado e não corresponder a aplicações legítimas conhecidas na rede. A presença de processos que tentam se comunicar via DNS TXT ou IRC a partir de dispositivos IoT é um forte indicador de comprometimento (IoC), dado o uso desses protocolos como canais de backup C2.
Na camada de host, a análise forense deve procurar pela criação de novos serviços systemd ou entradas cron não autorizadas que mantenham a persistência do malware. A identificação de binários ELF contendo trechos de texto em inglês que se assemelhem a avisos de segurança ou raciocínios lógicos sobre desenvolvimento de software pode indicar a presença desta variante específica de botnet auxiliada por IA. Além disso, o uso excessivo de recursos de rede ou CPU, associado a scanners operando com alta concorrência (ex: 128 conexões), pode sinalizar uma fase de varredura ativa ou ataque DDoS em andamento.
- Conexões de saída não autorizadas para portas TCP 1999, 31337 e 2222
- Tráfego DNS anômalo com consultas TXT incomuns ou uso de IRC por dispositivos IoT
- Criação de serviços systemd e tarefas cron para manutenção de processos suspeitos
- Binários ELF com strings contendo avisos de segurança ou comentários sobre desenvolvimento de código
A contenção do TuxBot exige a aplicação imediata de princípios de higiene de cibersegurança em dispositivos IoT. É fundamental alterar as credenciais padrão de fábrica de todos os roteadores, câmeras e dispositivos conectados, desabilitando serviços de gerenciamento remoto como Telnet e SSH quando não forem estritamente necessários ou restringindo seu acesso por ACLs. A atualização de firmware para corrigir as vulnerabilidades conhecidas exploradas pelo botnet é a medida corretiva mais eficaz para eliminar o vetor de infecção.
Na camada de rede, recomenda-se a segmentação de dispositivos IoT em VLANs isoladas, impedindo que se comuniquem livremente com a internet ou com sistemas críticos. Regras de firewall devem ser implementadas para bloquear o tráfego de saída para as portas C2 identificadas e para limitar a capacidade de scanner dos dispositivos infectados. Equipes de resposta a incidentes (IR) devem realizar varreduras ativas na rede para identificar dispositivos que estejam tentando contatar infraestruturas conhecidas do grupo Keksec, associado a essa campanha, e isolar os hosts comprometidos para análise remediação.
- Alteração de senhas padrão e desabilitamento de Telnet/SSH em interfaces expostas
- Segmentação de rede para isolar dispositivos IoT em VLANs dedicadas
- Bloqueio de portas TCP 1999, 31337 e 2222 no firewall de perímetro e saída
- Atualização de firmware para mitigar as mais de 30 vulnerabilidades exploradas pelo malware
0 Comentários