Uso de IA em operações ofensivas avança de prompts isolados para agentes com específicações estruturadas

Relatório técnico de janeiro e fevereiro de 2026 aponta malware Linux gerado com apoio de IDE com IA, abuso de arquivos de configuração de agentes, interesse em modelos locais sem restrições e risco recorrente de vazamento de dados em prompts corporativos.

Componente	Ecossistema de IA aplicado a operações ofensivas, incluindo o framework Linux VoidLink, fluxos agentic de desenvolvimento, arquivos CLAUDE.md, modelos locais sem restrições e uso corporativo de serviços GenAI.
Vetor	Adoção de IDEs comerciais com IA, agentes de codificação guiados por arquivos Markdown, configurações de projeto usadas para redefinir comportamento de agentes e envio de dados sensíveis a serviços externos de IA generativa.
Impacto	Produção acelerada de malware implantável, automação de tarefas de pesquisa ofensiva, tentativa de contornar salvaguardas de modelos e exposição de informação corporativa, código-fonte e dados regulados em prompts.
Prioridade	Tratar arquivos de configuração de agentes, repositórios com específicações Markdown, uso de IDEs com IA e tráfego para serviços GenAI como superfície de segurança monitorável e governada.
Artefatos	VoidLink, TRAE SOLO, eBPF, LKM, CLAUDE.md, Claude Code, RAPTOR, wizardlm-33b-v1.0-uncensored, openhermes-2.5-mistral, LoRA e Ollama.
Mitigação	Inventariar ferramentas GenAI, restringir dados em prompts, revisar políticas de agentes de codificação, auditar repositórios por instruções de override e ampliar detecção para artefatos de desenvolvimento, não apenas para binários finais.

Resumo técnico

A atividade observada em janeiro e fevereiro de 2026 indica uma mudança operacional no uso de IA por atores de ameaça: a etapa dominante deixou de ser apenas a tentativa de obter trechos de código malicioso por prompts diretos e passou a incluir fluxos estruturados de engenharia com agentes de codificação. O caso mais concreto é o VoidLink, um framework de malware para Linux com arquitetura modular de comando e controle, recursos de rootkit por eBPF e LKM, enumeração de nuvem e contêineres, além de mais de 30 plugins de pós-exploração. A qualidade de engenharia do conjunto levou inicialmente a uma leitura compatível com um esforço coordenado por uma equipe, mas artefatos internos de desenvolvimento expuseram um processo conduzido por um único operador usando TRAE SOLO, camada paga de uma IDE comercial com IA.

O ponto técnico central não é apenas a escolha de um modelo ou fornecedor, mas o método. O desenvolvimento do VoidLink foi guiado por específicações Markdown, critérios de aceite, padrões de codificação, planejamento por sprints e divisão lógica em equipes virtuais chamadas Core, Arsenal e Backend. O operador atuou como responsável por produto, direcionando e revisando entregas, enquanto o agente de IA implementava o código. O resultado recuperado chegou a mais de 88.000 linhas funcionais e produziu um primeiro implante operacional por volta de 4 de dezembro de 2025, aproximadamente uma semana após o início do trabalho. Para defensores, isso reduz a utilidade de inferir capacidade adversária apenas pelo volume de código, pela organização do projeto ou pela maturidade do binário final.

Fluxo técnico

O fluxo associado ao VoidLink começa com documentação estruturada, não com um prompt isolado. O operador define objetivos, restrições, arquitetura esperada, módulos e critérios de validação em arquivos Markdown. O agente interpreta esses arquivos como plano de execução, gera tarefas, implementa componentes, testa partes do projeto e itera sobre falhas. Esse modelo replica práticas legítimas de desenvolvimento assistido por IA adotadas por ferramentas como Cursor, GitHub Copilot, Claude Code e TRAE, nas quais documentos de projeto funcionam como camada de controle. Quando aplicado a malware, o mesmo padrão permite construir implantes, módulos de pós-exploração, backends e lógica de operação de forma incremental, com menos dependência de uma equipe tradicional de engenharia.

A técnica também aparece no abuso de agentes por configuração. Em vez de tentar convencer um modelo por um único prompt, operadores passaram a explorar mecanismos de inicialização e hierarquia de instruções. Um pacote divulgado como jailbreak para Claude Code usa o arquivo CLAUDE.md, normalmente empregado por desenvolvedores para descrever contexto do projeto, padrões e comportamento esperado do agente. Ao colocar instruções de override nesse arquivo, o agente pode tratar a configuração local como autoridade operacional e seguir uma definição de papel diferente da esperada. O efeito técnico é distinto de prompt injection conversacional: a manipulação ocorre na camada que orienta a ferramenta antes ou durante a execução do trabalho no repositório.

Há ainda um segundo eixo: modelos locais e sem restrições. Operadores em fóruns avaliam variantes como wizardlm-33b-v1.0-uncensored e openhermes-2.5-mistral para gerar ransomware, keyloggers, kits de phishing e código de exploração, motivados por privacidade operacional, ausência de moderação e menor risco de banimento. A prática, porém, ainda mostra limitações. Discussões citam custo entre US$ 5.000 e US$ 50.000 conforme desempenho desejado, prazos de treinamento entre 3 e 12 meses e alucinações suficientes para tornar resultados locais pouco confiáveis sem investimento alto. Técnicas como ajuste fino com LoRA aparecem mais como intenção do que como capacidade amplamente operacionalizada.

Superfície afetada

A superfície afetada não se limita ao endpoint comprometido por um binário de malware. Ela inclui repositórios, diretórios de projeto, arquivos Markdown que controlam agentes, IDEs com IA, pipelines de CI/CD, ambientes de desenvolvimento e políticas corporativas de uso de GenAI. Em organizações que permitem agentes de codificação, arquivos como CLAUDE.md e documentos equivalentes podem influenciar comportamento de ferramentas com acesso a código, testes, comandos locais e contexto do projeto. Quando esses arquivos são alterados por usuários não autorizados, inseridos em dependências internas ou aceitos sem revisão em pull requests, eles passam a ser uma camada de configuração com impacto direto sobre a execução assistida por IA.

A adoção corporativa de IA generativa também amplia exposição por fluxo de dados. A telemetria analisada no período indica que um em cada 31 prompts, aproximadamente 3,2%, apresentava alto risco de vazamento de informação sensível. Esses eventos incluíam possível envio de informação comercial confidencial, dados regulados, código-fonte e outros conteúdos internos para serviços externos de IA. O risco não ficou concentrado em poucos casos: 90% das organizações que usam GenAI regularmente tiveram atividade de prompt classificada como de alto risco, e 16% dos prompts continham informação potencialmente sensível. Em média, organizações usaram 10 ferramentas GenAI diferentes, enquanto um funcionário gerou 69 prompts por mês, elevando o volume de pontos de exposição.

• Ambientes Linux onde um framework como VoidLink pode operar com plugins de pós-exploração, enumeração de nuvem e contêineres, além de rootkits eBPF e LKM.
• Repositórios com arquivos Markdown usados como específicação ou configuração de agentes, incluindo CLAUDE.md e documentos de planejamento de sprints.
• Estáções de desenvolvimento com IDEs assistidas por IA e agentes capazes de ler arquivos do projeto, executar testes ou gerar código de forma autônoma.
• Contas corporativas que acessam múltiplas ferramentas GenAI e podem enviar código-fonte, dados regulados ou informação confidencial em prompts.

Hunting e telemetria

A detecção precisa cobrir a cadeia de desenvolvimento e a cadeia de execução. No endpoint Linux, operadores devem buscar sinais compatíveis com rootkits por eBPF ou LKM, criação anômala de hooks, módulos de núcleo carregados fora do fluxo esperado, enumeração incomum de metadados de nuvem, inspeção de sockets, varredura de namespaces de contêineres e execução de plugins de pós-exploração. Para VoidLink, o dado disponível confirma arquitetura modular, C2, recursos de rootkit e enumeração de nuvem e contêineres, mas não fornece hashes, domínios, endereços IP ou nomes específicos de arquivos implantados; portanto, a caça deve se apoiar em comportamento e não em IoCs estáticos inexistentes no material recebido.

No ambiente de desenvolvimento, a telemetria deve incluir auditoria de criação e alteração de arquivos de instrução para agentes, principalmente quando aparecem em commits de origem incomum, ramificações de baixa revisão, dependências internas ou diretórios que inicializam ferramentas de codificação. Termos como instruções para ignorar restrições, redefinir papel do agente, suprimir salvaguardas, gerar RATs, dividir tarefas para burlar filtros ou transformar explicações em código executável devem ser tratados como sinais de risco. O mesmo vale para padrões de prompts fracionados em ferramentas comerciais, nos quais o usuário começa pedindo explicações e progride para implementação, empacotamento ou evasão.

Para uso corporativo de GenAI, a telemetria precisa relacionar identidade, destino, tipo de ferramenta, volume de prompts e classificação de conteúdo. Consultas contendo segredos, chaves, tokens, credenciais, trechos de código proprietários, dados de clientes, informações reguladas, documentos internos e dumps de erro com valores sensíveis devem acionar bloqueio ou quarentena conforme política. A média de 10 ferramentas por organização indica que controlar apenas um provedor não cobre a exposição; proxies, CASB, DLP, logs de navegador, extensões de IDE e integrações SaaS devem compor uma visão única de risco.

• Alterações em CLAUDE.md ou arquivos Markdown equivalentes contendo instruções para ignorar políticas, redefinir funções do agente ou produzir artefatos ofensivos.
• Carregamento inesperado de módulos de núcleo, criação de programas eBPF sem origem administrativa conhecida e enumeração anômala de recursos de nuvem ou contêineres em servidores Linux.
• Uso de IDEs com IA ou agentes de codificação em projetos sensíveis sem associação a tickets, revisão de código ou aprovação de segurança.
• Prompts contendo código-fonte interno, segredos, dados regulados, informação comercial confidencial ou múltiplas etapas incrementais para chegar a código executável.

Mitigação

A resposta defensiva deve começar pelo inventário. Organizações precisam saber quais IDEs com IA, agentes de codificação, extensões de navegador, integrações SaaS e serviços GenAI estão em uso, por quais identidades e em quais repositórios. Em seguida, é necessário transformar arquivos de configuração de agentes em artefatos governados: CLAUDE.md, específicações Markdown e documentos de skills devem passar por revisão de código, controle de alteração, owners definidos e bloqueios contra commits não revisados em repositórios críticos. A política deve tratar esses arquivos como configuração executiva indireta, porque eles influenciam o comportamento de ferramentas capazes de gerar, modificar e testar código.

Para Linux e ambientes de nuvem, a contenção deve combinar hardening de kernel, monitoramento de módulos, auditoria de eBPF, limitação de privilégios, separação de permissões em workloads e verificação contínua de contêineres. A presença de um framework com rootkits eBPF e LKM exige que a investigação não dependa apenas de processos visíveis no espaço de usuário. Em incidentes suspeitos, a coleta deve preservar memória, lista de programas eBPF, módulos carregados, artefatos de persistência, logs de autenticação, chamadas para metadados de nuvem, inventário de namespaces e tráfego C2. Quando a integridade do núcleo estiver em dúvida, reconstruir a instância a partir de imagem confiável pode ser mais adequado do que tentar remover componentes em produção.

Para GenAI corporativa, a mitigação exige política aplicável em tempo real, não apenas orientação de uso. Controles de DLP devem bloquear ou mascarar segredos, dados regulados e código proprietário antes do envio a serviços externos. O acesso a ferramentas deve ser condicionado a SSO, registro centralizado e avaliação de risco por categoria de dado. Ambientes com engenharia de software devem definir quais repositórios podem ser usados com agentes de IA, quais comandos podem ser executados, quais arquivos podem ser lidos e quais mudanças exigem revisão humana. A validação final deve incluir testes de tentativa de bypass, revisão de logs e métricas de redução de prompts de alto risco.

• Colocar arquivos de configuração de agentes, incluindo CLAUDE.md, sob revisão obrigatória, CODEOWNERS e alertas para instruções de override ou geração de artefatos ofensivos.
• Bloquear envio de segredos, código-fonte sensível e dados regulados para GenAI com DLP em proxy, navegador, SaaS e extensões de IDE.
• Monitorar criação de programas eBPF, carregamento de LKM, enumeração de nuvem e comportamento de pós-exploração em servidores Linux e workloads de contêineres.
• Restringir agentes de codificação a ambientes isolados, com permissões mínimas, logs preservados, comandos permitidos explicitamente e revisão humana antes de merge ou execução em produção.