O atacante de 31 segundos: o que o primeiro ataque de ransomware autônomo significa para a recuperação

Quando o atacante deixou de precisar de um humano

Em 1º de julho de 2026, a equipe de pesquisa de ameaças da Sysdig (Sysdig Threat Research Team) publicou sua análise de uma operação de ransomware que batizou de JADEPUFFER. Nas palavras da Sysdig, trata-se de "what we assess to be the first documented case of agentic ransomware: a complete extortion operation driven end-to-end by a large language model (LLM)" (o que a empresa avalia ser o primeiro caso documentado de ransomware agêntico: uma operação de extorsão completa conduzida de ponta a ponta por um modelo de linguagem de grande porte, LLM).

Esta não é mais uma história sobre e-mails de phishing escritos por IA ou chamadas de voz com deepfake. Nos payloads capturados pela Sysdig, o agente explorou uma aplicação exposta à internet, coletou credenciais, passou para um segundo servidor, assumiu o controle do serviço de configuração desse servidor, criptografou e apagou dados e deixou um pedido de resgate. Quando uma etapa falhava, ele diagnosticava a falha e tentava de novo sem esperar instruções.

Na BackupSec, achamos que o JADEPUFFER importa menos como incidente isolado e mais como prévia. É um dado inicial para uma pergunta que toda arquitetura de backup e recuperação vai precisar responder cedo ou tarde: o que acontece quando o ciclo de decisão do outro lado encolhe de horas para segundos?

Por dentro da cadeia de ataque do JADEPUFFER

Em linhas gerais, esta é uma kill chain contra a qual as equipes de segurança se defendem há anos. A própria Sysdig diz isso: "None of the individual techniques were novel or sophisticated" (nenhuma das técnicas, isoladamente, era nova ou sofisticada). A novidade está em quem as executou. A sequência abaixo segue o relatório da Sysdig:

1. Acesso inicial. O agente explorou a CVE-2025-3248 no Langflow, um framework open source para criar aplicações com LLM. O NVD a descreve como injeção de código no endpoint /api/v1/validate/code que permite a "a remote and unauthenticated attacker" (um atacante remoto e não autenticado) executar código arbitrário, com pontuação CVSS 9,8. A correção saiu no Langflow 1.3.0, em 31 de março de 2025, e a CISA incluiu a falha em seu catálogo Known Exploited Vulnerabilities em 5 de maio de 2025. O patch existia; só não tinha sido aplicado.
2. Coleta de credenciais. No host do Langflow, o agente fez o levantamento do sistema e varreu o ambiente atrás de chaves de API de provedores de LLM, credenciais de nuvem, carteiras de criptomoedas e credenciais de banco de dados, e depois fez o dump do próprio banco Postgres do Langflow. Encontrou um object store MinIO acessível a partir do host, entrou com as credenciais padrão do MinIO (minioadmin:minioadmin) e listou buckets que, segundo a Sysdig, incluíam "application data, backups, ML artifacts, and a terraform-state bucket" (dados de aplicação, backups, artefatos de ML e um bucket de estado do Terraform). De um deles, extraiu um arquivo credentials.json com um par access key/secret.
3. Persistência. Instalou uma entrada de crontab no host do Langflow que envia um beacon para a infraestrutura do atacante a cada 30 minutos.
4. Chegada ao alvo real. Segundo a Sysdig, o verdadeiro alvo da operação era outro servidor de produção, exposto à internet, rodando MySQL e um serviço de configuração Alibaba Nacos. O agente se conectou à porta exposta do MySQL como root. A Sysdig não observou de onde vieram essas credenciais de root: "Their origin is unknown" (a origem delas é desconhecida).
5. Tomada do Nacos. O agente atacou o Nacos por vários caminhos ao mesmo tempo: a família de bypass de autenticação da CVE-2021-29441 (segundo o NVD, no Nacos anterior à versão 1.4.1 o filtro de autenticação pode ser contornado com um cabeçalho user-agent falsificado), um JSON Web Token forjado com a chave de assinatura padrão do Nacos, que é documentada publicamente, e uma conta de administrador backdoor gravada diretamente no banco de dados do Nacos usando o acesso root. O caminho do JWT falhou ("custom secret in use", ou seja, havia um segredo personalizado em uso) e foi abandonado. A conta backdoor funcionou, depois da correção de 31 segundos descrita mais abaixo.
6. Impacto. O agente criptografou todos os 1.342 itens de configuração do Nacos com a função AES_ENCRYPT() do MySQL, apagou as tabelas originais de configuração e de histórico e, em seguida, apagou schemas inteiros do banco. A nota de resgate afirma usar AES-256; a Sysdig observa que AES_ENCRYPT() usa AES-128-ECB por padrão, a menos que o servidor tenha sido reconfigurado. O detalhe que mais pesa para a recuperação: a chave foi impressa uma única vez e nunca foi armazenada nem enviada, então, nas palavras da Sysdig, "The victim cannot recover the encrypted configurations even with payment" (a vítima não consegue recuperar as configurações criptografadas nem mesmo pagando). Só uma cópia feita antes do ataque, e mantida fora do alcance do atacante, poderia trazer esses dados de volta.
7. Extorsão. Criou uma tabela README_RANSOM com a exigência, um endereço de Bitcoin e um contato no Proton Mail.

A ressalva honesta

Queremos ser precisos sobre o que "autônomo" significa aqui, porque exagerar isso enfraqueceria o argumento que vamos apresentar.

A Sysdig aponta duas coisas que não consegue ver. Ela não observou como o agente obteve as credenciais de root do MySQL usadas na etapa quatro. E declara ter "no visibility into JADEPUFFER's system prompt or agent configuration" (nenhuma visibilidade sobre o system prompt ou a configuração do agente do JADEPUFFER), portanto não pode dizer que objetivo ou recursos um humano deu ao agente antes de ele rodar. Alguém o construiu, configurou e colocou em execução.

O que a Sysdig documenta é o comportamento dentro das sessões que capturou: mais de 600 payloads distintos, código que narra o próprio raciocínio e falhas diagnosticadas e corrigidas em segundos. Com base nessa evidência, conclui que "the evidence points to an autonomous agent driving the operation rather than a human operator or a fixed toolkit" (as evidências apontam para um agente autônomo conduzindo a operação, e não para um operador humano ou um kit de ferramentas fixo).

Essa distinção importa, e achamos que ela reforça o argumento em vez de enfraquecê-lo. Mesmo uma cadeia em que um humano define o objetivo e o agente cuida da execução elimina a maior fonte de latência de uma operação de ransomware tradicional: o tempo que um operador humano passa pensando, consultando um controlador e decidindo o que tentar em seguida.

Por que 31 segundos importam mais do que parece

Os 31 segundos não são a duração total do ataque. A Sysdig não publica uma duração de ponta a ponta para a cadeia, e nós não vamos inventar uma. O que ela publica é uma sequência com carimbos de tempo da tomada do Nacos. O agente inseriu sua conta de administrador backdoor, tentou fazer login às 19:34:36 UTC e falhou. Testou duas causas possíveis em paralelo e, às 19:35:07, enviou um payload corretivo de 15 linhas que recriou a conta do jeito certo. O login funcionou às 19:35:18. Nas palavras da Sysdig: "The window between the failed login and the correct multi-step fix is 31 seconds" (o intervalo entre o login que falhou e a correção correta em várias etapas é de 31 segundos). A Sysdig relata o mesmo padrão em outros pontos da sessão. Quando uma requisição devolveu XML em vez de JSON, o payload seguinte passou a fazer parsing de XML. Quando um DROP DATABASE falhou por causa de uma restrição de chave estrangeira, o seguinte desativou essa verificação primeiro.

Compare isso com o comportamento de um operador humano quando uma etapa falha. Ele para. Reavalia. Numa operação estruturada de ransomware como serviço, pode mandar mensagem a um controlador e esperar orientação. Tenta de novo num prazo medido em minutos ou horas, às vezes atravessando uma troca de turno. Essa latência, o intervalo entre uma falha e a tentativa seguinte, sempre foi uma das poucas coisas a favor dos defensores. É por isso que um alerta das 2h da manhã ainda pode ser triado por um humano às 8h sem que o incidente tenha necessariamente piorado muito nesse meio-tempo.

Um agente que reduz esse intervalo a 31 segundos não é apenas mais rápido. Ele elimina a premissa embutida em quase todo runbook de resposta a incidentes: a de que existe uma janela em escala humana entre a primeira tentativa fracassada do atacante e a próxima, e de que um processo de detecção e resposta operando em escala de tempo humana parecida pode razoavelmente esperar intervir dentro dela.

Os números que já valiam antes da IA aparecer

A infraestrutura de backup não virou alvo por causa da IA agêntica. Ela já era alvo, e os dados sobre isso são dois anos anteriores ao JADEPUFFER.

• O 2024 Ransomware Trends Report da Veeam, uma pesquisa com 1.200 respondentes de organizações que sofreram pelo menos um ataque de ransomware em 2023, constatou que "backup repositories are targeted in 96% of attacks, with bad actors successfully affecting the backup repositories in 76% of cases" (os repositórios de backup são visados em 96% dos ataques, e os criminosos conseguem afetá-los em 76% dos casos). A Veeam repete o número de 96% em seu próprio blog.
• A pesquisa da Sophos de 2024 sobre backups comprometidos, baseada em 2.974 profissionais de TI e cibersegurança cujas organizações foram atingidas por ransomware no ano anterior, constatou que "The median overall ransomware recovery costs for organizations whose backups were compromised ($3M) came in eight times higher than that of organizations whose backups were not impacted ($375K)" (o custo mediano total de recuperação de ransomware para organizações cujos backups foram comprometidos, US$ 3 milhões, foi oito vezes maior que o das organizações cujos backups não foram afetados, US$ 375 mil).

Esses números descrevem um mundo de atacantes humanos que já tinham entendido que destruir ou criptografar a camada de backup é o movimento de maior alavancagem disponível depois que uma operação de ransomware ganha uma posição inicial. Nada na IA agêntica muda esse cálculo. O que muda é quem, ou o quê, consegue executá-lo em escala, 24 horas por dia, sem precisar dormir, fazer pausa de turno ou esperar a aprovação de um controlador antes de testar a próxima credencial.

O IBM 2026 X-Force Threat Intelligence Index acrescenta a linha de tendência. O IBM X-Force observou um aumento de 44% nos ataques que começaram pela exploração de aplicações expostas ao público, exatamente o vetor de entrada que o JADEPUFFER usou, e os grupos ativos de ransomware e extorsão cresceram 49% em relação ao ano anterior. A superfície de ataque já estava crescendo antes de qualquer parte disso precisar de um operador autônomo.

De janelas de detecção a certeza de recuperação

Explorar uma vulnerabilidade conhecida já é a forma mais comum de entrar. O mesmo relatório da IBM diz que a exploração de vulnerabilidades "became the leading cause of attacks, accounting for 40% of incidents observed by X-Force in 2025" (tornou-se a principal causa de ataques, respondendo por 40% dos incidentes observados pelo X-Force em 2025). A distância entre vulnerabilidades conhecidas e vulnerabilidades corrigidas é grande demais, e se renova continuamente, para que a prevenção perfeita seja realista. O JADEPUFFER se encaixa no padrão: a Sysdig observa que o ataque ao alvo real "leaned on years-old issues, a 2021 Nacos auth-bypass and an unchanged default signing key" (apoiou-se em problemas de anos atrás, um bypass de autenticação do Nacos de 2021 e uma chave de assinatura padrão nunca alterada). O JADEPUFFER não muda esse argumento. Ele o deixa mais afiado.

Se a premissa de trabalho do setor tem sido a de que um processo de detecção e resposta em ritmo humano pode razoavelmente esperar pegar uma intrusão em algum ponto entre o acesso inicial e o impacto irreversível, um agente que se autocorrige em 31 segundos é um desafio direto a essa premissa. A resposta não pode ser "detectar e responder mais rápido que uma máquina", porque essa não é uma corrida que os defensores podem esperar continuar vencendo indefinidamente. A resposta precisa ser arquitetural: tornar sobrevivível o resultado de uma intrusão rápida e adaptativa, não importa quanto o atacante fique mais rápido.

Na prática, as propriedades que importam para a infraestrutura de backup e recuperação não mudam porque o atacante é um agente de IA e não um humano. Elas deixam de ser aspiracionais e passam a ser inegociáveis:

• Separação de credenciais e identidades que não dependa de um humano perceber a tempo uma atividade incomum. Se as credenciais que chegam ao seu ambiente de backup são as mesmas que um agente consegue coletar em segundos num host comprometido, o isolamento precisa ser estrutural, não procedimental.
• Imutabilidade validada, e não apenas configurada. Um bloqueio de retenção que uma credencial com privilégios suficientes consegue desativar silenciosamente é um controle que pressupõe que o atacante humano vai hesitar. Um agente não vai.
• Testes de recuperação que partam do princípio de que o atacante já conhece o seu ambiente. O agente do JADEPUFFER se adaptou em tempo real às etapas que falharam. Um plano de recuperação testado apenas contra um único cenário de falha esperado é um plano feito para um adversário mais lento e mais previsível do que aquele que agora está comprovadamente possível.

O que isso significa para os líderes de risco corporativo

O JADEPUFFER é uma campanha documentada, não a prova de que toda operação de ransomware agora é autônoma. Mas, se a avaliação da Sysdig se sustentar, algo que antes era teórico agora foi observado: um agente de LLM conduzindo uma cadeia de ataque real contra um alvo real, com um ciclo de autocorreção medido em segundos.

Para os líderes de risco, a questão prática não é mais se o ransomware agêntico vai se tornar mais comum. A Sysdig diz que os defensores "should expect the volume and breadth of such campaigns to rise as agentic tooling matures" (devem esperar que o volume e a amplitude dessas campanhas cresçam à medida que as ferramentas agênticas amadurecem), e o IBM X-Force "expects adversaries to automate complex tasks like reconnaissance and advanced ransomware attacks" (espera que os adversários automatizem tarefas complexas, como reconhecimento e ataques avançados de ransomware). A questão prática é se as premissas da sua arquitetura de recuperação foram construídas para um adversário em ritmo humano ou para um que não precisa mais ser assim.

Onde a BackupSec entra

Na BackupSec, construímos nossa abordagem sobre uma premissa que o JADEPUFFER torna mais urgente: a prevenção vai falhar, e a camada que decide o resultado é aquela construída para sobreviver à falha, não importa a velocidade do que a causou.

• O ZeroMON monitora o Veeam Backup & Replication. É implantado on-premises como OVA, conecta-se com uma conta somente leitura e não envia nada para a BackupSec nem para terceiros. Acompanha a saúde dos jobs de backup, registra as mudanças de configuração no Veeam (quem mudou o quê, e quando), mostra o status de imutabilidade conforme as próprias configurações de repositório do Veeam o informam e mantém à vista o checklist do Security Analyzer do Veeam. Suas regras de alerta cobrem as ações do lado do Veeam que um invasor faz contra os backups, como mudanças de credenciais, edições de retenção e de agendamento, jobs desativados e sessões de exclusão. Os alertas são enviados por e-mail e por notificação no próprio aplicativo. O ZeroMON observa o Veeam: ele não enxerga coleta de credenciais em outros hosts, e lê as configurações de imutabilidade do Veeam em vez de verificar os bloqueios no próprio storage.
• O ZeroTAM dá à sua equipe um consultor dedicado de segurança de backup: revisão de arquitetura, planejamento de recuperação contra ransomware, capacidade e suporte prioritário numa crise. É onde colocar à prova se a sua separação de identidades, a sua imutabilidade e o seu isolamento foram projetados para um atacante em ritmo humano.
• O ZeroPEN é um teste de penetração orientado a ameaças do Veeam Backup & Replication, do Veeam ONE e do Enterprise Manager. Simula uma kill chain de ransomware em oito etapas mapeadas no MITRE ATT&CK, do acesso inicial e abuso de credenciais, passando pelo acesso ao repositório e pela neutralização do backup, até uma prova de capacidade de criptografia. O trabalho inclui verificação da integridade de restore e da imutabilidade e entrega evidências prontas para auditoria, com um reteste para as descobertas críticas. É não destrutivo: o ZeroPEN "never deletes real backups, performs real encryption, or stops production or backup services" (nunca apaga backups reais, nunca executa criptografia real nem interrompe serviços de produção ou de backup).

A pergunta que o JADEPUFFER levanta não é se as suas defesas são rápidas. É se a sua arquitetura de recuperação foi construída para não depender de que elas sejam rápidas.

Fale com a BackupSec sobre como validar sua arquitetura de recuperação →

Esta análise se baseia na pesquisa da Sysdig de julho de 2026 sobre o JADEPUFFER, no IBM 2026 X-Force Threat Intelligence Index, no 2024 Ransomware Trends Report da Veeam e na pesquisa da Sophos de 2024 sobre backups comprometidos, com detalhes de vulnerabilidades do NVD e da CISA. A interpretação e o framework apresentados aqui são da própria BackupSec. Para conversar sobre como esta análise se aplica ao seu ambiente, fale com a nossa equipe →