Segundo a Unit 42, agente de IA realizou reconhecimento, selecionou exploits e mudou de estratégia após uma única instrução enviada pelo operador

Pesquisadores da Unit 42, divisão de inteligência de ameaças da Palo Alto Networks, identificaram uma campanha na qual um ator de ameaça de língua chinesa utilizou o modelo DeepSeek, integrado ao framework de código aberto Hermes Agent, para automatizar etapas de reconhecimento e exploração de sistemas expostos à internet.
O operador, monitorado pelos apelidos knaithe e KnYuan, teria iniciado uma das atividades por meio de uma instrução enviada pelo Telegram. A partir desse comando, o agente procurou sistemas vulneráveis, avaliou possíveis vetores de ataque, baixou códigos de exploração disponíveis publicamente e tentou comprometer os alvos.
De acordo com os pesquisadores, não foram encontradas novas intervenções do operador durante a sessão analisada. Isso indica que, após receber a instrução inicial, o agente executou as demais etapas do fluxo de forma autônoma.
Ao todo, a campanha envolveu tentativas de exploração contra mais de 460 alvos, combinando operações autônomas e procedimentos convencionais conduzidos manualmente.
Hermes Agent permitia execução de comandos pelo Telegram
O Hermes Agent é um framework que fornece aos modelos de inteligência artificial acesso ao terminal, ferramentas reutilizáveis e capacidade de executar tarefas sem acompanhamento contínuo.
A própria documentação do projeto informa que o agente pode receber comandos pelo Telegram, executar instruções no sistema operacional e agendar atividades para serem realizadas de forma autônoma.
Na infraestrutura analisada pela Unit 42, o DeepSeek funcionava como o principal modelo responsável pelo raciocínio e pela tomada de decisões. Os pesquisadores também identificaram uso limitado do Claude Code e do Qwen Code.
Diretórios relacionados ao desenvolvimento de exploits apresentavam ainda indícios de utilização do Codex. No entanto, a Unit 42 não conseguiu confirmar se a ferramenta foi realmente empregada, pois os registros das conversas correspondentes não estavam disponíveis.
Agente buscou sistemas Langflow vulneráveis
Em uma sessão recuperada de maio de 2026, o agente baixou um exploit público para a vulnerabilidade CVE-2026-33017, uma falha de injeção de código que afetava o Langflow.
O Langflow é uma plataforma utilizada para criar agentes e fluxos de trabalho baseados em inteligência artificial.
Utilizando o mecanismo de busca FOFA, voltado à identificação de ativos expostos à internet, o agente encontrou 84 instâncias do Langflow. Entre elas, uma executava a versão 1.3.4, considerada vulnerável.
A tentativa, entretanto, não avançou porque o sistema não estava com a opção auto_login habilitada e também não apresentava um identificador público de fluxo que pudesse ser aproveitado pelo exploit.
O Langflow corrigiu a CVE-2026-33017 na versão 1.9.0.
DeepSeek mudou de estratégia e selecionou o n8n
Após concluir que o primeiro caminho não era produtivo, o agente abandonou a tentativa contra o Langflow e passou a avaliar outros possíveis alvos.
Segundo a Unit 42, o DeepSeek analisou dez famílias de produtos, procurou no GitHub repositórios recentes contendo provas de conceito e selecionou o n8n, plataforma de automação de fluxos de trabalho.
Para tentar comprometer os sistemas, o agente obteve uma cadeia de exploração que combinava duas vulnerabilidades:
- • CVE-2026-21858, falha de acesso não autenticado a arquivos;
- • CVE-2025-68613, vulnerabilidade de injeção de expressões.
Durante a sessão, o FOFA retornou 25.209 sistemas n8n expostos na China. O agente analisou uma amostra de aproximadamente 100 endereços, realizou testes em cerca de 40 e encontrou três instâncias que executavam versões vulneráveis.
Um dos sistemas apresentava três formulários publicamente acessíveis, mas todos exigiam autenticação. Outros 50 alvos também não possuíam formulários públicos que pudessem ser utilizados na cadeia de ataque.
Como resultado, nenhuma instância do n8n foi comprometida nessa etapa da operação.
A CVE-2026-21858 foi corrigida pelo n8n na versão 1.121.0. Já a CVE-2025-68613 recebeu correções nas versões 1.120.4, 1.121.1 e 1.122.0. Dessa forma, a versão 1.121.1 foi a primeira versão citada nos avisos de segurança que corrigia simultaneamente as duas vulnerabilidades utilizadas na tentativa.
Operações manuais teriam resultado em comprometimentos
Embora as tentativas autônomas contra Langflow e n8n não tenham sido bem-sucedidas, a Unit 42 também identificou operações convencionais conduzidas pelo mesmo ator.
Segundo o relatório, dados de três organizações teriam sido exfiltrados por meio da CVE-2026-3055, vulnerabilidade de leitura indevida de memória que afeta determinados equipamentos NetScaler ADC e NetScaler Gateway.
A falha atinge dispositivos gerenciados pelos próprios clientes quando configurados para funcionar como provedores de identidade SAML.
Os pesquisadores também relataram a execução de comandos em 11 instâncias da plataforma Marimo por meio da CVE-2026-39987. A vulnerabilidade foi corrigida na versão 0.23.0 do software.
O relatório, porém, apresenta uma divergência nos números. Em outro trecho, a Unit 42 afirma ter confirmado apenas três alvos explorados com sucesso em toda a operação. As informações publicadas não esclarecem como esse total se relaciona com as três organizações afetadas pelo NetScaler e as 11 instâncias do Marimo.
Erro operacional expôs scripts, chaves de API e registros
A campanha foi descoberta após o próprio Hermes Agent iniciar inadvertidamente um servidor HTTP com o comando:
python3 -m http.server 8888
O servidor foi executado a partir do diretório /home/worker e deixou diversos arquivos da operação acessíveis pela internet.
Entre os dados expostos estavam:
- • configurações dos modelos de inteligência artificial;
- • chaves de API;
- • scripts de exploração;
- • listas de alvos;
- • histórico de comandos do terminal;
- • registros das sessões autônomas.
A exposição permitiu que os pesquisadores reconstruíssem parte significativa das atividades realizadas pelo agente e analisassem como o operador utilizava diferentes modelos de IA durante a campanha.
Operador pode estar baseado em Zhuhai
A Unit 42 avalia que o operador estaria baseado em Zhuhai, na China. A análise considera informações encontradas em perfis públicos associados aos apelidos utilizados na campanha.
Um perfil no GitHub exibe o nome “KnYuan Knaithe”, enquanto um blog mais antigo registrado com o mesmo identificador descreve seu autor como um pesquisador de segurança especializado em análise de binários e localizado em Zhuhai.
Essas informações são compatíveis com a avaliação dos pesquisadores, mas não confirmam de forma independente a identidade legal do operador. Também não existem evidências públicas suficientes para estabelecer ligação entre o ator e o governo chinês.
Organizações devem reduzir a exposição de interfaces críticas
O caso demonstra como frameworks de agentes de IA podem acelerar atividades ofensivas, automatizando desde a busca por alvos até a seleção e execução de exploits disponíveis publicamente.
Ao mesmo tempo, as tentativas contra Langflow e n8n mostram que a automação ainda depende das condições encontradas em cada ambiente. Configurações específicas, mecanismos de autenticação e a ausência de endpoints públicos impediram que as explorações fossem concluídas.
Para reduzir os riscos, as organizações devem atualizar sistemas Langflow, n8n e Marimo para versões suportadas que contenham as correções de segurança. Equipamentos NetScaler ADC e Gateway gerenciados pelos clientes também precisam receber as versões corrigidas indicadas pela Citrix.
Administradores do NetScaler podem verificar a presença de configurações de provedor de identidade SAML procurando pelo padrão:
add authentication samlIdPProfile .*
Também é recomendável remover o acesso público desnecessário a interfaces de automação, notebooks e ferramentas de construção de fluxos de trabalho. Monitoramento contínuo, autenticação robusta, proteção adequada de chaves de API e revisão dos serviços expostos à internet são medidas importantes para limitar a superfície de ataque.
O episódio reforça que o uso ofensivo de agentes de inteligência artificial não representa apenas uma possibilidade teórica. Essas ferramentas já estão sendo incorporadas a operações reais para acelerar reconhecimento, seleção de vulnerabilidades e tentativas de exploração em larga escala.
Para saber mais, clique aqui.