NadMesh o botnet Go que rouba credenciais na nuvem e facilita o acesso a IA e Kubernetes

Um novo botnet escrito em Go, apelidado de NadMesh pelos investigadores, mudou o tradicional alvo de cripto-minaria por algo mais valioso para a economia atual: credenciais e acessos a serviços de IA e ferramentas de gestão rápidas de implantação. Em vez de se concentrar na potência bruta do GPU, este operador procura chaves de nuvem, tokens de Kubernetes e credenciais que permitam ao atacante pivotar de uma máquina comprometida até serviços gerenciados e modelos.

O quadro que mostram as análises públicas reflete uma campanha que combina digitalização em massa com extração seletiva de segredos: scanners tipo Shodan preenchem a cauda com instâncias de ComfyUI, Ollama, n8n, Open WebUI, Langflow e Gradio — serviços que muitos equipamentos arrancam rapidamente e que muitas vezes ficam expostos por defeito — enquanto os agentes tentam tirar ~/.aws/config, variáveis de ambiente, tokens de serviço k8s e arquivos de configuração de registries. O objetivo não é “a caixa” mas o que a caixa sabe ou pode se autenticar através dela.

O vetor técnico inclui velhos favoritos (socket de Docker exposto, consola de Jenkins, Redis sem autenticar, Telnet com senhas fracas) e chamadas a ferramentas remotas: nos dados observados prevalecem tentativas ao Docker API e a Jenkins, mas também aparece uma chamada mcp_cmd_execute para serviços que implementam MCP, um protocolo cuja especificação histórica deixou a autenticação fora do fluxo principal e cuja adoção parcial deixa muitas instâncias sem proteção adequada. A existência de serviços MCP abertos e de ferramentas que permitem executar comandos em remoto amplifica o risco para aqueles que expõem interfaces de administração sem controle.

A campanha mostra sofisticação operacional: múltiplas versões do agente em paralelo, ofuscação e empacotamento com Garble e UPX para que cada binário tenha assinatura diferente, mecanismos de persistência redundante e uma lógica de reescan e priorização que evita honeypots autoexcluyéndo-os após tentativas fracassadas. Por isso, assinaturas estáticas tradicionais e hashes únicos são insuficientes para detecção e remediação em grande escala.

As implicações são claras e práticas. Comprometer uma máquina com acesso à nuvem não é simplesmente perda dessa máquina: é possível o uso fraudulento de serviços cloud, extração de modelos, abuso de tokens para se mover lateralmente dentro de clusters Kubernetes e a exposição de segredos que permitem provisionar nova infraestrutura à custa da vítima. Um host exposto pode se transformar em passarela para centenas ou milhares de recursos na nuvem se não se age rapidamente e critério.

As medidas defensivas imediatas não requerem adesivos milagrosos: a prioridade é isolar e proteger as interfaces administrativas. Fechar o público os portos que a campanha rescanea primeiro (por exemplo 8188, 11434, 7860 e 5678), bloquear o socket Docker em 2375 de acesso remoto, garantir consoles de Jenkins e exigir autenticação em Redis e n8n Reduz enormemente a superfície de ataque. Além disso, a aplicação do controlo de acesso em serviços MCP e a activação de qualquer mecanismo de autenticação e autorização disponível deve ser tratada como urgente em instalações expostas.

Se suspeitar de compromisso, a resposta deve seguir uma ordem específica: isolar o host afetado, procurar rastros de persistência em locais como /dev/shm, /var/tmp, /tmp, /etc/cron.d e em ~/.ssh/authorized_keys, e somente depois de remover todos os traços de persistência, proceder a revogar credenciais e tokens. Revocar sem primeiro retirar as portas traseiras é dar as novas credenciais ao atacante.

A detecção deve ser complementada com telemetria: monitoree padrões de reescaneo, picos de tentativas de IPs que voltam a aparecer com frequência e chamadas a endpoints de execução remota. Dado que o operador evita contar publicamente certos roubos e que os binários mudam de marca, use indicadores de comportamento e de rede juntamente com listas de IOCs públicas (por exemplo, IPs de C2 ou domínios associados) e ferramentas de detecção na nuvem para correlacionar atividade anómala. Para referência ao alcance que você pode ter a digitalização de serviços remotos e censos de exposição veja Censys: https://censys.io.

Na camada de governo e arquitetura, a lição dura é aplicar o princípio de menor privilégio, rotação e separação de credenciais (evitar deixar chaves longas em variáveis de ambiente ou arquivos de configuração), e auditar o uso de ferramentas que habilitam execução remota sem autenticar. A documentação de Kubernetes sobre RBAC e como acotar permissões de contas de serviço é um bom ponto de partida para reduzir o alcance de tokens comprometidos: https://kubernetes.io/docs/reference/access-authn-authz/rbac/.

Também convém vigiar listas e catálogos de vulnerabilidades exploradas de forma ativa e priorizar adesivos para as peças que admitem exploração remota pré-autenticada. Para se manter atualizado sobre vulnerabilidades com exploração conhecida, a referência consolidada de CISA é útil: https://www.cisa.gov/known-exploited-vulnerabilities-catalog.

Finalmente, a observação operacional do relatório aponta para uma mudança de negócio criminal: extrair acesso à nuvem e a modelos é mais rentável e mais difícil de reverter que roubar ciclos de GPU ou minar criptomoedas no host. Defensores que tratem as máquinas como meros endpoints em vez de como chaves para sistemas maiores continuarão a perder a carreira. Inventário ativo, segmentação da administração, autenticação obrigatória e resposta coordenada a incidentes (aislar, eliminar persistência, revogar e revisar uso) são as ações que mais rapidamente reduzem o risco tangível que NadMesh e campanhas semelhantes colocam sobre as organizações.