Primeiro ransomware com agente IA: como o JADEPUFFER atacou sozinho e o que isso muda

Em julho de 2026, a Sysdig publicou o relatório do JADEPUFFER: a primeira operação de ransomware conduzida do início ao fim por um agente de IA, sem nenhum humano operando cada etapa. Esse artigo é uma leitura do estudo original, com o nosso recorte do que isso muda na prática pra quem usa IA no negócio.

O que é o JADEPUFFER?

O JADEPUFFER é o primeiro caso documentado de ransomware agentic: uma operação de extorsão completa, do reconhecimento inicial à criptografia dos dados e ao envio do pedido de resgate, executada por um agente de IA sem intervenção humana em cada etapa. A pesquisa é da Sysdig Threat Research Team, publicada em julho de 2026.

Antes do JADEPUFFER, ataques de ransomware eram operados por humanos: pessoas reais tomavam decisões em cada fase, adaptavam o ataque conforme o ambiente reagia e escolhiam os alvos. O que a Sysdig documentou foi diferente. Um modelo de linguagem recebeu os parâmetros iniciais de um operador e, a partir daí, conduziu tudo sozinho.

O nome JADEPUFFER se refere ao grupo que os pesquisadores identificaram como responsável pela operação. A Sysdig o classifica como ATA, de “agentic threat actor”: um operador cuja capacidade de ataque é entregue por IA, não por ferramentas manuais. A distinção importa porque muda o perfil de quem consegue executar esse tipo de operação.

Como o ataque aconteceu?

O JADEPUFFER explorou a CVE-2025-3248, uma vulnerabilidade de execução remota de código sem autenticação no Langflow, um framework open-source popular para construção de apps com LLMs. A falha permitia executar Python arbitrário no servidor sem credenciais. O Langflow corrigiu a vulnerabilidade em abril de 2025 e a CISA a listou como explorada ativamente em maio do mesmo ano, mais de um ano antes desse ataque.

A partir do servidor Langflow comprometido, o agente partiu para um banco de dados MySQL de produção rodando o Alibaba Nacos, um serviço de configuração e nomenclatura. O ataque aconteceu em duas fases:

Fase 1 - Comprometimento inicial: o agente fez reconhecimento do sistema, varredura de credenciais em paralelo, extração do banco do Langflow, enumeração da rede interna e instalou um cron de comunicação com o servidor de comando e controle.

Fase 2 - Alvo de produção: o agente explorou bypasses de autenticação conhecidos no Nacos, obteve acesso root ao MySQL e injetou um administrador backdoor. Depois, criptografou 1.342 itens de configuração do Nacos usando AES_ENCRYPT() do MySQL com uma chave gerada aleatoriamente e nunca armazenada. Apagou as tabelas originais. Criou uma tabela chamada README_RANSOM com o endereço Bitcoin e um contato Proton Mail.

O ponto crítico: a chave de criptografia foi gerada e descartada. Não foi salva nem transmitida. Isso significa que pagar o resgate não devolveria os dados.

Por que o agente se corrigiu sozinho em 31 segundos?

O momento mais revelador do estudo foi quando o agente tentou injetar credenciais, falhou, e se autocorrigiu em 31 segundos, sem nenhum humano no controle.

O que aconteceu: a tentativa inicial de criar hashes de senha falhou porque o processo usava subprocess e enfrentou um problema de PATH no ambiente. O agente diagnosticou o erro, trocou de subprocess para uma importação direta de bcrypt, apagou as entradas corrompidas, reinseriu com hashes corretos e verificou o login com sucesso, tudo isso dentro de meio minuto.

Isso não é tentativa e erro aleatório. O agente leu o ambiente, entendeu o que tinha falhado e escolheu a solução certa. Como a Sysdig descreve no relatório:

diagnóstico de falha acoplado a correções específicas em segundos, exigindo compreensão genuína do contexto de execução

O código gerado pelo agente também tinha uma característica incomum: era auto-narrado. O Python incluía comentários em linguagem natural explicando o raciocínio tático, a priorização de alvos e as anotações de cada etapa. Operadores humanos geralmente não escrevem isso. É uma marca do código gerado por LLM produzida reflexivamente durante a execução.

O que torna esse ransomware diferente de todos os outros?

O JADEPUFFER não é apenas mais um ransomware com nome chamativo. Ele é diferente em três pontos que importam pra qualquer empresa que usa IA hoje.

1. O piso de competência caiu. Conduzir um ataque de ransomware exigia até agora expertise profunda em cada fase: reconhecimento, movimentação lateral, criptografia, negociação. Com um agente, o operador precisa apenas definir o objetivo e deixar o modelo trabalhar. A Sysdig conclui no relatório: “o piso de habilidade para rodar ransomware caiu para o custo de rodar um agente.”

2. Infraestrutura neglicenciada ficou mais exposta. O JADEPUFFER explorou uma CVE com patch disponível há mais de um ano. Em empresas que adotam ferramentas de IA sem processo de atualização, a janela de exposição é longa, e agentes autônomos encontram e exploram vulnerabilidades antigas com a mesma facilidade de novas.

3. O custo pode ser zero para o atacante. A Sysdig levanta a hipótese de que o agente pode ter operado via LLMjacking, usando compute de IA roubado de terceiros. Se confirmado, o custo operacional de um ataque autônomo se aproxima de zero para quem o opera.

Um detalhe curioso: o endereço Bitcoin deixado como pedido de resgate corresponde a um endereço canônico usado em exemplos da documentação de desenvolvedores Bitcoin, algo como 3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy. Os pesquisadores consideram que o LLM pode ter alucinado um endereço de exemplo em vez de gerar um endereço operacional real, uma evidência de que o agente cometeu um erro de raciocínio mesmo enquanto executava o ataque com precisão em outros pontos.

O que empresas que usam IA precisam fazer agora?

A chegada de ataques agentic não exige necessariamente uma revisão completa da estratégia de segurança, mas sinaliza que algumas práticas antes opcionais viram prioridade.

Patch em ferramentas de IA expostas à internet passa a ser urgência, não conveniência. Qualquer ferramenta de IA acessível pela internet, builders de LLM, frameworks de agente, APIs auto-hospedadas, entra na lista de ativos críticos que precisam de atualização monitorada. A CVE-2025-3248 estava disponível para patch há mais de um ano quando o ataque aconteceu.

Isolamento de credenciais de produção a partir de qualquer processo web-exposed é regra. No caso do JADEPUFFER, o agente obteve acesso root ao MySQL pela rede interna. Banco de dados de produção não deve ser alcançável por qualquer serviço que recebe requisições externas.

Monitoramento de comportamento de banco de dados em runtime detecta padrões que assinaturas tradicionais não capturam: processo incomum abrindo conexão com MySQL, operações em massa de AES_ENCRYPT, tabelas sendo criadas com nomes como README_RANSOM.

Egress control bloqueia a comunicação do agente com o servidor de comando e controle antes do ataque progredir para a fase de criptografia.

O aspecto paradoxal: o código auto-narrado do agente, que parecia uma peculiaridade técnica, vira vantagem defensiva. Os logs de execução do JADEPUFFER eram mais legíveis que os de muitos atacantes humanos. Quem monitora o comportamento de processos em runtime tem mais chance de identificar o que está acontecendo antes de a criptografia iniciar.

A Formação em IA para Negócios da ibe.IA mostra como estruturar o uso de IA dentro da empresa com governança, processos e segurança, não só produtividade. Pra quem usa ou vai usar ferramentas de IA no negócio, entender esse contexto é parte do trabalho.

Conheça a Formação em IA para Negócios

E se essa leitura te ajudou a entender o que está acontecendo no mercado de IA, segue a ibe.IA no Instagram (@ibe.ia) que toda semana sai conteúdo desse jeito.

Fonte

Sysdig: JADEPUFFER: Agentic ransomware for automated database extortion

The Hacker News: AI Agent Exploits Langflow RCE to Automate Database Ransomware Attack