KadNap compromete roteadores Asus e outros dispositivos de borda para formar botnet de proxy

Malware usa uma variante customizada de DHT Kademlia para localizar infraestrutura de comando, manter controle descentralizado e transformar mais de 14 mil dispositivos em nós de proxy residencial.

Componente	Malware KadNap em roteadores Asus e outros dispositivos de rede de borda, com suporte a processadores ARM e MIPS.
Vetor	Dispositivo de borda previamente comprometido baixa o script aic.sh de um servidor C2 defangado, cria persistência via cron e executa um binário ELF renomeado como kad.
Impacto	Nós infectados entram em uma rede P2P usada para localizar C2, receber comandos, baixar arquivos adicionais e oferecer tráfego por proxy residencial associado ao serviço Doppelgänger.
Prioridade	Atualizar roteadores SOHO, trocar senhas padrão, restringir interfaces de administração, reiniciar equipamentos sob suspeita e substituir modelos sem suporte.
Artefatos	Arquivos citados incluem aic.sh, .asusrouter, kad, fwr.sh e /tmp/.sose; infraestrutura citada inclui 212.104.141[.]140 e doppelganger[.]shop.
Escopo	Mais de 14 mil dispositivos infectados foram observados; mais de 60% das vítimas estão nos Estados Unidos, com ocorrências menores em Taiwan, Hong Kong, Rússia, Reino Unido, Austrália, Brasil, França, Itália e Espanha.

Resumo técnico

KadNap é um malware voltado a dispositivos de rede de borda, com foco observado em roteadores Asus, mas sem limitação exclusiva a esse fabricante. A atividade foi detectada em ambiente real desde agosto de 2025 e alcançou mais de 14 mil dispositivos infectados. A função operacional da botnet é transformar equipamentos SOHO e outros nós de borda em infraestrutura de proxy, permitindo que terceiros encaminhem tráfego por endereços residenciais ou de pequenos ambientes corporativos. O uso desse tipo de nó dificulta bloqueios simples por reputação, pois o tráfego pode parecer originado de conexões domésticas legítimas.

O aspecto técnico mais relevante é o uso de uma versão customizada do protocolo Kademlia Distributed Hash Table. Em vez de depender apenas de comunicação direta e estática com servidores de comando e controle, a botnet usa uma camada P2P para localizar pares e alcançar infraestrutura de controle. Essa arquitetura reduz a eficácia de bloqueios pontuais, porque a lógica de descoberta fica distribuída entre dispositivos comprometidos. O resultado é uma rede mais resiliente contra remoção de servidores individuais e mais difícil de mapear por monitoramento tradicional baseado apenas em conexões conhecidas para C2.

Os dispositivos comprometidos são associados ao serviço de proxy Doppelgänger, apresentado publicamente como oferta de proxies residenciais em mais de 50 países e vinculado no contexto a uma possível reestruturação do serviço Faceless, já associado ao malware TheMoon. A presença de coinfecções em roteadores Asus e outros dispositivos de borda limita a atribuição de cada atividade maliciosa observada a uma única família ou operador, mas o papel de KadNap na montagem de uma rede de proxy descentralizada é tecnicamente consistente com os artefatos descritos.

Fluxo técnico

A cadeia começa após o comprometimento inicial do dispositivo, ponto em que o contexto não detalha a exploração ou credencial usada para obter acesso. A partir desse estado, o equipamento baixa o script aic.sh de um servidor C2 defangado identificado como 212.104.141[.]140. O script estabelece persistência criando uma tarefa cron que busca novamente o mesmo conteúdo no minuto 55 de cada hora, renomeia o arquivo para .asusrouter e executa a lógica baixada. Esse comportamento indica tentativa de recuperar controle após remoções parciais, reinicializações ou falhas de download.

Depois da persistência, o script obtém um arquivo ELF malicioso, renomeia esse binário como kad e o executa. O suporte a arquiteturas ARM e MIPS é compatível com o alvo pretendido: roteadores e dispositivos de rede embarcados, nos quais essas arquiteturas são comuns. O malware também consulta um servidor NTP para obter o horário atual e armazena esse valor junto com o uptime do host. Esses dados são usados como base para gerar um hash que ajuda o nó a localizar outros pares na rede descentralizada, receber comandos ou baixar arquivos adicionais.

Dois artefatos complementares, fwr.sh e /tmp/.sose, aparecem com funções relevantes para controle do ambiente infectado. Eles incluem capacidade de fechar a porta 22, normalmente associada a SSH, e extrair uma lista de combinações IP:porta de C2 para conexão. Fechar a porta de administração remota pode reduzir interferência externa, limitar acesso de administradores legítimos ou competir com outras infecções presentes no mesmo equipamento. A análise também indica que nem todos os dispositivos comprometidos se comunicam com todos os C2, sugerindo segmentação por tipo de dispositivo ou modelo.

Superfície afetada

A superfície principal é formada por roteadores SOHO, especialmente modelos Asus observados como alvo recorrente, além de outros dispositivos de borda. Esses ativos ficam frequentemente expostos por longos períodos, têm ciclos de atualização irregulares e podem operar com senhas padrão, firmware antigo ou interfaces de administração acessíveis por redes não confiáveis. O contexto não informa a vulnerabilidade inicial nem versões específicas afetadas, portanto a avaliação defensiva deve se concentrar em sinais pós-comprometimento e higiene operacional dos equipamentos.

A distribuição geográfica mostra concentração elevada nos Estados Unidos, com mais de 60% das infecções observadas, mas há presença também em Taiwan, Hong Kong, Rússia, Reino Unido, Austrália, Brasil, França, Itália e Espanha. Para organizações brasileiras, o ponto técnico não é assumir campanha direcionada ao país, e sim reconhecer que dispositivos de borda locais podem ser integrados a uma infraestrutura global de proxy caso estejam expostos, desatualizados ou sem controles mínimos de administração.

• Roteadores Asus usados como alvo principal observado, sem exclusividade confirmada para esse fabricante.
• Dispositivos de borda com processadores ARM ou MIPS capazes de executar o binário ELF descrito.
• Ambientes SOHO com firmware antigo, senhas padrão, administração remota exposta ou equipamentos sem suporte do fabricante.
• Nós que apresentem tarefas cron incomuns, arquivos ocultos semelhantes a .asusrouter ou binários renomeados em caminhos temporários.

Hunting e telemetria

A investigação defensiva deve priorizar telemetria de roteadores, gateways, DNS, NetFlow, logs de firewall e qualquer inventário que capture configuração persistente em dispositivos de borda. Em muitos ambientes SOHO, a visibilidade local é limitada; por isso, sinais indiretos como aumento de conexões de saída, tráfego P2P atípico, conexões para infraestrutura defangada conhecida e alterações inesperadas na disponibilidade de SSH podem ser mais realistas do que análise completa de endpoint. Sempre que o equipamento permitir, a revisão de tarefas agendadas, arquivos temporários e processos ativos ajuda a identificar a execução da cadeia descrita.

A botnet usa DHT customizado para misturar descoberta de pares com tráfego P2P, o que reduz a utilidade de regras estáticas isoladas. A defesa deve correlacionar comportamento: conexões recorrentes para múltiplos IPs e portas, resolução ou acesso a domínio de proxy defangado, downloads periódicos no mesmo minuto de cada hora, execução de ELF incompatível com operações normais do roteador e mudanças de firewall local que bloqueiem a porta 22. Em redes corporativas que gerenciam filiais ou usuários remotos com roteadores próprios, a telemetria de borda deve ser tratada como fonte de risco e não apenas como infraestrutura fora do escopo.

O contexto também descreve uma ameaça Linux separada, chamada ClipXDaemon, voltada a usuários de criptomoedas em sessões X11. Ela opera em memória, monitora a área de transferência em intervalos curtos e substitui endereços de carteiras por valores controlados pelo operador, sem lógica de C2 ou beaconing. Esse ponto não altera a prioridade de KadNap, mas reforça a necessidade de diferenciar malware de borda, que monetiza conectividade por proxy, de clipper Linux, que monetiza diretamente transações copiadas pelo usuário.

• Tarefas cron criadas para recuperar aic.sh no minuto 55 de cada hora e executar conteúdo renomeado como .asusrouter.
• Presença de binário ELF renomeado como kad em dispositivo ARM ou MIPS sem relação com firmware legítimo.
• Conexões para 212.104.141[.]140, para doppelganger[.]shop ou para combinações IP:porta extraídas por arquivos como /tmp/.sose.
• Alteração inesperada de regras locais que fechem a porta 22 em roteadores onde SSH deveria estar disponível para administração.
• Padrões de tráfego P2P incomuns em equipamentos que normalmente deveriam atuar apenas como roteador, gateway ou ponto de acesso.

Mitigação

A resposta deve começar pelo inventário de dispositivos de borda e pela separação entre equipamentos suportados e modelos em fim de vida. Roteadores e gateways ainda suportados devem receber atualização de firmware, redefinição de senhas administrativas e revisão de exposição da interface de gerenciamento. Administração remota deve ficar restrita a redes confiáveis ou VPNs administradas, com autenticação forte quando o equipamento suportar. Equipamentos sem suporte ou sem capacidade de auditoria devem ser substituídos, porque a ausência de correções e telemetria torna a recorrência provável.

Em dispositivos suspeitos, uma reinicialização pode interromper parte da execução em memória, mas não deve ser tratada como correção completa quando há persistência via cron ou artefatos gravados. A equipe deve validar se tarefas agendadas, arquivos ocultos e binários não autorizados foram removidos, além de confirmar que o firmware instalado é legítimo e atualizado. Quando houver gerenciamento centralizado, é recomendável comparar configurações contra uma linha de base conhecida, incluindo regras de firewall, estado de SSH, DNS configurado e destinos de saída recentes.

Como a botnet é usada para proxy, a contenção também envolve reduzir abuso de reputação da rede. Organizações que detectarem seus próprios links como origem de tráfego suspeito devem isolar o equipamento, preservar logs disponíveis e revisar credenciais administrativas associadas ao roteador. Não há no contexto uma vulnerabilidade específica, CVE ou versão afetada; portanto, a mitigação não deve depender de uma correção única. A prioridade é reduzir exposição, eliminar persistência, atualizar firmware, substituir hardware sem suporte e reforçar monitoramento de saída para tráfego P2P anômalo.

• Atualizar firmware de roteadores SOHO e gateways de borda que ainda recebam suporte do fabricante.
• Trocar senhas padrão e remover administração remota exposta diretamente à internet.
• Revisar tarefas cron, arquivos ocultos e binários ELF suspeitos, especialmente aic.sh, .asusrouter e kad.
• Reiniciar dispositivos sob suspeita apenas como etapa de contenção, seguida de validação de persistência e atualização completa.
• Substituir modelos em fim de vida que não recebam correções ou não permitam auditoria operacional adequada.