Pontos principais
- JadePuffer é o nome que os pesquisadores de segurança da Sysdig deram ao que consideraram ser a primeira operação de ransomware documentada conduzida de ponta a ponta por um agente de IA autônomo, e não por um ser humano utilizando um conjunto de ferramentas.
- As técnicas em si não eram novas. O que mudou foi a velocidade da execução: o agente encadeou ações de reconhecimento, roubo de credenciais, movimento lateral e criptografia destrutiva, corrigindo uma tentativa de login malsucedida em 31 segundos.
- O agente gerou sua própria chave de criptografia e, em seguida, nunca a armazenou nem a transmitiu. Pagar o resgate não teria restaurado os dados.
- The damage reached configuration state and control-plane systems, as well as application data, a layer many recovery plans overlook.
- Recuperar-se de um ataque como esse significa comprovar que a empresa pode retomar suas operações com segurança, e não apenas restaurar um backup.
When I wrote about JadePuffer in July, two things stayed with me: how quickly the attacker adjusted, and the credentials it collected.Microsoft’s latest findingsbrought me back to both. They made me think harder about what those digital keys can reach, including resources a business may need to recover.
Revisiting JadePuffer
If you missed thefirst blog, JadePuffer is the name security researchers at Sysdig gave an attacker whose operation they assessed as being driven by an AI agent. Think of an agent as software that can work toward a goal, take actions, and adjust based on the results.Researchers observedthe agent exploit a vulnerable application, collect access credentials, and attack a separate database system. It made important application settings unreadable through encryption and deleted the original tables.
During that operation, a login check failed. Thirty-one seconds later, the agent issued a fix and tried again.
Researchers could not establish where the credentials for the final database target came from. They did document an operation that combined adaptation, credential collection, and destructive activity.
New FindingsMicrosoft Azure findingsshow what compromised access can enable. The report, published in September, describes activity from early June.
Microsoft tracks JadePuffer as Storm-3168 and identified two compromised service principals, the identities that applications use to access services. Their existing permissions enabled operations that included discovery, resource deletion, and collection of more access keys.
Software needs access to do its job. If an attacker takes over that identity, the same permissions can be used to do something the business never intended.
In roughly seven minutes, the attacker made more than 100 storage-account deletion attempts, most successful. These accounts hold digital information in Microsoft’s cloud. Attempts to remove recovery protection locks failed, and some storage protections blocked deletions.
Separate database deletion attempts failed because the attacker used an unsupported version of the technical interface. Microsoft observed no ransom note and did not confirm data theft. Its evidence supports coordinated automation without proving AI reasoning at every step.
What We Can Learn from JadePuffer
The protections that held are as instructive as the damage. They give us something to examine and test. An attacker’s mistake helps, but recovery plans cannot count on one.
JadePuffer also deserves attention alongside the recent disclosures thatOpenAI,AnthropiceGoogleagents took unauthorized actions during evaluations. Those incidents differ from one another, including failures to isolate test environments. None is the same as an attacker deliberately using AI for harm.
For a business, though, both raise a practical question: What can a system reach and change when it acts outside our intentions?
Imagine a damaged hotel where someone has obtained a master key. Replacing furniture and reopening the lobby would be progress. Before welcoming guests back, you would also want to know which doors that key opened, whether copies were made, and whether the locks were back under your control. A freshly made bed answers none of them.
Digital recovery needs that same attention. Restored information is useful when the right people and applications can access it safely. Recovering an account also means recovering its permissions and its connections to applications.
Getting an account back is one step. Knowing what it can do, and whether that access is appropriate, is part of getting the business working again.
Protecting Your Organization
Start by asking which accounts can change or delete the systems a critical business process depends on. Include the accounts used by software and automation. Then ask whether those same accounts can alter the backups or protections you are counting on for recovery. That shows how far one compromised identity could reach.
Next, pick a business activity, such as taking an order, and bring together the people who run the process and its technology. Then work through three questions:
- If the usual administrative accounts cannot be trusted, who can begin recovery?
- What needs to come back first?
- Who verifies that the attacker’s access has been removed and the restored permissions are correct?
Then test it. Process an order through the recovered systems and record what worked, what failed, and how long it took. That gives the business evidence and the team a list of fixes.
The 31-second adjustment caught my attention first. Microsoft’s findings made the access question harder to ignore. We can use that knowledge to check the permissions we have granted, protect the means of recovery, and prove the business can operate again. We can take those steps now, while the wider AI story unfolds.
FAQs
Q: What is JadePuffer?
A: JadePuffer is the name Sysdig gave to what it assessed as the first documented ransomware operation driven end-to-end by an autonomous AI agent, rather than a human attacker manually operating a toolkit.
Q: Did the attackers use a specific AI model?
A: Public reporting hasn’t confirmed which model or platform was used. The agent searched for API keys from multiple AI providers, but doesn’t show which one powered the attack.
Q: How did the attack start?
A: ThroughCVE-2025-3248, an unauthenticated remote code execution vulnerability in Langflow, an open-source AI agent framework, affecting versions before 1.3.0.
Q: Could the victim have paid the ransom to recover their data?
A: No. The encryption key was generated on the fly and never stored or transmitted, so there was no key available to recover, regardless of payment.
Q: What makes this different from typical ransomware?
A: The individual techniques weren’t new. What stood out was the speed and adaptability: The agent diagnosed a failed login attempt and corrected it in 31 seconds, far faster than a human operator typically works.
Q: What should security and recovery teams take away from this?
A: That recovery planning needs to extend beyond application data to configuration stores, service-discovery platforms, secrets, and identity systems.Chris Bevil is Principal Portfolio Marketing Manager at Commvault.
