A Single LLM Agent Handled Recon, Credential Theft, Lateral Movement, and Extortion With No Human at the Keyboard
Researchers at Sysdig say they’ve caught the first fully documented ransomware operation run end-to-end by an AI agent, with no human operator directing the attack. The campaign, dubbed JadePuffer, used an AI agent that handled every stage on its own: reconnaissance, credential theft, lateral movement, persistence, privilege escalation, and the deployment of a ransom payload against a live production database.
An Old Langflow Bug Was the Way In
JadePuffer’s entry point was CVE-2025-3248, an unauthenticated remote code execution flaw in Langflow, an open-source framework for building LLM applications. The vendor patched the bug in April 2025, and CISA flagged it as actively exploited the following month. Langflow servers make an attractive target because they are frequently internet-facing, lightly hardened, and loaded with provider API keys and cloud credentials.
Once it had code execution, the agent enumerated the host, dumped Langflow’s own Postgres database, and swept the environment for secrets spanning OpenAI, Anthropic, and several other LLM providers, along with cloud credentials and cryptocurrency wallets. It then found a MinIO object store using the service’s default admin credentials, pulled a credentials file from an internal bucket, and installed a cron job that beaconed to the attacker’s server every 30 minutes.
The Real Target Was a Separate Production Database
The Langflow host turned out to be a stepping stone. Using MySQL root credentials whose origin researchers could not trace, the agent pivoted to a separate internet-facing server running Alibaba’s Nacos configuration service. It combined a known 2021 authentication bypass with Nacos’s long-documented default JWT signing key to forge admin access, then inserted a rogue administrator account directly into the database.
It Debugged Its Own Failed Login in 31 Seconds
The clearest sign that a model, not a fixed script, was driving the attack showed up when something broke. The agent’s first attempt to log in with its new admin account failed because a subprocess call meant to generate a password hash returned nothing. Rather than repeating the same command, it tested a competing theory, switched to importing the hashing library directly, confirmed the fix worked, deleted the broken account, and recreated it with a working password. The whole sequence, from failed login to working access, took 31 seconds.
A similar pattern showed up later in the attack. When a database drop command failed silently because of a foreign-key constraint, the next payload disabled the constraint check, ran the drop, and turned the check back on. Sysdig describes these as targeted fixes to specific failure causes rather than generic retries, the kind of behavior associated with reasoning rather than a fixed toolkit.
The Ransom Note May Be as Hollow as the Bitcoin Address
After probing for a way to escape the database container, the agent encrypted 1,342 configuration items using MySQL’s built-in AES_ENCRYPT function, dropped the original tables, and created a ransom table with a payment demand, a Bitcoin address, and a Proton Mail contact. The note claimed AES-256 encryption, but Sysdig notes the function defaults to a weaker cipher unless a server has been specifically configured otherwise.
More importantly, the encryption key was generated randomly, printed once to the screen, and never stored or transmitted anywhere, meaning the victim’s data could not be recovered even by paying. The Bitcoin address in the note is also the canonical example address that appears throughout public Bitcoin developer documentation, exactly the kind of string an LLM would reproduce from training data.
But it isn’t inert: blockchain records show it has handled 737 confirmed transactions and roughly 46 BTC over its history, with deposits swept out immediately. Sysdig says it can’t determine whether the agent hallucinated a famous example address that a third party happens to sweep, or whether the operator configured a wallet they actually control that happens to match the textbook example.
Sysdig Calls This an "Agentic Threat Actor"
Sysdig’s term for what it observed is an agentic threat actor, or ATA: an operator whose capability comes from an AI agent rather than a human-driven toolkit. The implication is that running a damaging, multi-stage ransomware operation no longer requires deep expertise in any single step, just the ability to point a capable model at exposed infrastructure.
There is a defensive upside, too. Because the agent narrated its own reasoning inside the code it generated, that self-narration gives defenders a detection signal that human-written attack scripts rarely provide.
What Your Security Team Should Do Now
None of the techniques JadePuffer relied on were exotic, meaning that the same handful of fixes closes off nearly every stage of this attack chain.
- Patch and isolate AI orchestration tools. Update Langflow and avoid exposing code-execution or validation endpoints to the internet.
- Keep credentials off web-reachable hosts. Provider API keys and cloud credentials belong in a secrets manager, not in the environment of an internet-facing AI orchestration server.
- Harden Nacos and similar config services. Rotate the default signing key, never expose the service to the internet, and don’t let it connect to its database as root.
- Lock down database admin access. Administrative accounts should never be internet-facing; enforce strong, unique credentials and source-IP restrictions.
- Apply egress controls. A compromised host shouldn’t be able to beacon out to arbitrary attacker infrastructure.
- Watch database processes for malicious behavior, not just the network layer. Much of this attack lived inside ordinary-looking SQL sessions.
- Monitor for the published indicators of compromise, including scheduled tasks that make outbound network calls and other beaconing behavior.
None of this requires anticipating what an AI agent might try next; it just means closing off the same exposed, over-permissioned infrastructure that any attacker, human or automated, is already scanning for.
Sources: Sysdig | BleepingComputer
