When the Attacker Stopped Needing a Human
On July 1, 2026, the Sysdig Threat Research Team published its analysis of a ransomware operation it named JADEPUFFER. In Sysdig's words, it is "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)."
This is not another story about AI-written phishing emails or deepfake voice calls. In the payloads Sysdig captured, the agent exploited an internet-facing application, harvested credentials, moved to a second server, took over its configuration service, encrypted and dropped data, and left a ransom demand. When a step failed, it diagnosed the failure and tried again without waiting for instructions.
At BackupSec, we think JADEPUFFER matters less as a single incident than as a preview. It is an early data point for a question every backup and recovery architecture will eventually have to answer: what happens when the decision loop on the other side shrinks from hours to seconds?
Inside the JADEPUFFER Attack Chain
In outline this is a kill chain security teams have defended against for years. Sysdig says as much: "None of the individual techniques were novel or sophisticated." What was new is what executed them. The sequence below follows Sysdig's write-up:
- Initial access. The agent exploited CVE-2025-3248 in Langflow, an open-source framework for building LLM applications. NVD describes it as code injection in the
/api/v1/validate/codeendpoint that lets "a remote and unauthenticated attacker" execute arbitrary code, and scores it CVSS 9.8. The fix shipped in Langflow 1.3.0 on 31 March 2025, and CISA added the flaw to its Known Exploited Vulnerabilities catalog on 5 May 2025. The patch existed; it had not been applied. - Credential harvesting. On the Langflow host, the agent enumerated the system and swept the environment for LLM provider API keys, cloud credentials, cryptocurrency wallets and database credentials, then dumped Langflow's own Postgres database. It found a MinIO object store reachable from the host, logged in with MinIO's default credentials (
minioadmin:minioadmin), and listed buckets that Sysdig says included "application data, backups, ML artifacts, and a terraform-state bucket." From one of them it pulled acredentials.jsonfile holding an access-key/secret pair. - Persistence. It installed a crontab entry on the Langflow host that beacons to attacker infrastructure every 30 minutes.
- Move to the real target. According to Sysdig, the operation's true target was a separate, internet-exposed production server running MySQL and an Alibaba Nacos configuration service. The agent connected to the exposed MySQL port as root. Sysdig did not observe where those root credentials came from: "Their origin is unknown."
- Nacos takeover. The agent attacked Nacos through several paths at once: the authentication-bypass family of CVE-2021-29441 (per NVD, in Nacos before 1.4.1 the authentication filter can be skipped with a spoofed user-agent header), a JSON Web Token forged with Nacos's publicly documented default signing key, and a backdoor administrator account written straight into the Nacos database with its root access. The JWT path failed ("custom secret in use") and was abandoned. The backdoor account worked, after the 31-second correction described below.
- Impact. The agent encrypted all 1,342 Nacos configuration items with MySQL's
AES_ENCRYPT(), dropped the original configuration and history tables, and went on to drop entire database schemas. The ransom note claims AES-256; Sysdig points out thatAES_ENCRYPT()defaults to AES-128-ECB unless the server was reconfigured. The detail that matters more for recovery: the key was printed once and never stored or sent, so, in Sysdig's words, "The victim cannot recover the encrypted configurations even with payment." Only a copy taken before the attack, and kept out of the attacker's reach, could bring that data back. - Extortion. It created a
README_RANSOMtable holding the demand, a Bitcoin address and a Proton Mail contact.
The Honest Caveat
We want to be precise about what "autonomous" means here, because overstating it would undercut the argument we are about to make.
Sysdig names two things it cannot see. It did not observe how the agent obtained the MySQL root credentials it used in step four. And it has "no visibility into JADEPUFFER's system prompt or agent configuration", so it cannot say what objective or resources a human gave the agent before it ran. Someone built, configured and launched it.
What Sysdig does document is behaviour inside the sessions it captured: more than 600 distinct payloads, code that narrates its own reasoning, and failures diagnosed and corrected in seconds. On that evidence it concludes that "the evidence points to an autonomous agent driving the operation rather than a human operator or a fixed toolkit."
That distinction matters, and we think it strengthens the argument rather than weakens it. Even a chain where a human sets the objective and the agent handles execution removes the largest source of latency in a traditional ransomware operation: the time a human operator spends thinking, checking with a handler, and deciding what to try next.
Why 31 Seconds Matters More Than It Sounds
The 31 seconds is not a total attack duration. Sysdig does not publish an end-to-end duration for the chain, and we are deliberately not going to invent one. What it does publish is a timestamped sequence from the Nacos takeover. The agent inserted its backdoor admin account, tried to log in at 19:34:36 UTC and failed. It tested two possible causes in parallel, then at 19:35:07 issued a 15-line corrective payload that rebuilt the account properly. The login succeeded at 19:35:18. In Sysdig's words: "The window between the failed login and the correct multi-step fix is 31 seconds." Sysdig reports the same pattern elsewhere in the session. When a request returned XML instead of JSON, the next payload parsed XML. When a DROP DATABASE failed on a foreign-key constraint, the next one switched the check off first.
Compare that to how a human operator behaves when a step fails. They pause. They reassess. In a structured ransomware-as-a-service operation, they may message a handler and wait for guidance. They try again on a timeline measured in minutes or hours, sometimes across a shift change. That latency, the gap between a failure and the next attempt, has always been one of the few things working in defenders' favor. It is the reason a 2 a.m. alert can still be triaged by a human at 8 a.m. without the incident having necessarily gotten dramatically worse in the interim.
An agent that closes that gap to 31 seconds does not just move faster. It removes the assumption embedded in almost every incident response runbook: that there is a human-scale window between an attacker's first failed attempt and their next one, and that a detection-and-response process operating on a similar human timescale can reasonably expect to intervene inside it.
The Numbers That Were Already True Before AI Showed Up
Backup infrastructure did not become a target because of agentic AI. It already was one, and the data on this predates JADEPUFFER by two years.
- Veeam's 2024 Ransomware Trends Report, a survey of 1,200 respondents from organizations that suffered at least one ransomware attack in 2023, found that "backup repositories are targeted in 96% of attacks, with bad actors successfully affecting the backup repositories in 76% of cases." Veeam repeats the 96% figure on its own blog.
- Sophos's 2024 research on compromised backups, drawn from 2,974 IT and cybersecurity professionals whose organizations had been hit by ransomware in the previous year, found that "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)."
Those numbers describe a world of human attackers who already understood that destroying or encrypting the backup layer is the single highest-leverage move available once a ransomware operation gains a foothold. Nothing about agentic AI changes that calculus. What it changes is who, or what, can execute on it at scale, around the clock, without needing to sleep, take a shift break, or wait for a handler's approval before trying the next credential.
IBM's 2026 X-Force Threat Intelligence Index adds the trend line. IBM X-Force observed a 44% increase in attacks that began with the exploitation of public-facing applications, which is exactly the entry vector JADEPUFFER used, and active ransomware and extortion groups rose 49% year over year. The attack surface was already growing before any of it needed an autonomous operator.
From Detection Windows to Recovery Certainty
Exploiting a known vulnerability is already the most common way in. The same IBM report says vulnerability exploitation "became the leading cause of attacks, accounting for 40% of incidents observed by X-Force in 2025." The gap between known and closed vulnerabilities is too large, and too continuously replenished, for perfect prevention to be realistic. JADEPUFFER fits the pattern: Sysdig notes that the attack on the real target "leaned on years-old issues, a 2021 Nacos auth-bypass and an unchanged default signing key." JADEPUFFER does not change that argument. It sharpens it.
If the industry's working assumption has been that a human-paced detection-and-response process can reasonably expect to catch an intrusion somewhere between initial access and irreversible impact, an agent that self-corrects in 31 seconds is a direct challenge to that assumption. The response cannot be "detect and respond faster than a machine," because that is not a race defenders can expect to keep winning indefinitely. The response has to be architectural: make the outcome of a fast, adaptive intrusion survivable regardless of how much faster the attacker gets.
Concretely, the properties that matter for backup and recovery infrastructure do not change because the attacker is an AI agent instead of a human. They become non-negotiable instead of aspirational:
- Credential and identity separation that does not depend on a human noticing unusual activity in time. If the credentials that reach your backup environment are the same ones an agent can harvest from a compromised host in seconds, isolation has to be structural, not procedural.
- Immutability that is validated, not merely configured. A retention lock that a sufficiently privileged credential can quietly disable is a control that assumes a human attacker will hesitate. An agent will not.
- Recovery testing that assumes the attacker already knows your environment. JADEPUFFER's agent adapted to failed steps in real time. A recovery plan that has only ever been tested against a single, expected failure scenario is a plan built for a slower, more predictable adversary than the one now demonstrably possible.
What This Means for Enterprise Risk Leaders
JADEPUFFER is one documented campaign, not evidence that every ransomware operation is now autonomous. But if Sysdig's assessment holds, something that was previously theoretical has now been observed: an LLM agent running a real attack chain against a real target, with a self-correction loop measured in seconds.
For risk leaders, the practical question is no longer whether agentic ransomware will become more common. Sysdig says defenders "should expect the volume and breadth of such campaigns to rise as agentic tooling matures," and IBM X-Force "expects adversaries to automate complex tasks like reconnaissance and advanced ransomware attacks." The practical question is whether your recovery architecture's assumptions were built for a human-paced adversary or for one that no longer needs to be.
Where BackupSec Comes In
At BackupSec, we built our approach around a premise that JADEPUFFER makes more urgent: prevention will fail, and the layer that decides the outcome is the one built to survive the failure, however fast the thing that caused it was moving.
- ZeroMON monitors Veeam Backup & Replication. It deploys on-premises as an OVA, connects with a read-only account, and sends nothing to BackupSec or any third party. It tracks backup job health, logs configuration changes in Veeam (who changed what, and when), shows immutability status as Veeam's own repository settings report it, and keeps Veeam's Security Analyzer checklist in view. Its alert rules cover the Veeam-side moves an intruder makes against backups, such as credential changes, retention and schedule edits, disabled jobs and delete sessions. Alerts go out by email and in-app notification. ZeroMON watches Veeam: it does not see credential harvesting on other hosts, and it reads Veeam's immutability settings rather than checking locks on the storage itself.
- ZeroTAM gives your team a dedicated backup security advisor: architecture review, ransomware recovery planning, capacity, and priority support in a crisis. It is where to pressure-test whether your identity separation, immutability and isolation were designed for a human-paced attacker.
- ZeroPEN is a threat-led penetration test of Veeam Backup & Replication, Veeam ONE and Enterprise Manager. It simulates a ransomware kill chain in eight stages mapped to MITRE ATT&CK, from initial access and credential abuse through repository access and backup neutralization to a proof of encryption capability. The engagement includes restore-integrity and immutability verification and delivers audit-ready evidence with a retest for critical findings. It is non-destructive: ZeroPEN "never deletes real backups, performs real encryption, or stops production or backup services."
The question JADEPUFFER raises is not whether your defenses are fast. It is whether your recovery architecture was built so that it does not depend on them being fast.
Talk to BackupSec about validating your recovery architecture →
This analysis draws on Sysdig's July 2026 research on JADEPUFFER, IBM's 2026 X-Force Threat Intelligence Index, Veeam's 2024 Ransomware Trends Report and Sophos's 2024 research on compromised backups, with vulnerability details from NVD and CISA. The interpretation and framework presented here are BackupSec's own. To discuss how this analysis applies to your specific environment, get in touch with our team →
