Skip to main content

Hit by ransomware? Isolate affected systems now. Do not reboot or reformat.

SheMo Noransom舍末无勒

Ransomware family

JadePuffer Ransomware Decryption & Data Recovery

  • Active
  • High
  • No public decryptor

JadePuffer is the operation Sysdig disclosed in July 2026 and described as the first fully documented case of agentic ransomware. An LLM-driven agent moved from a Langflow flaw into an Alibaba Nacos configuration centre, then deployed the Go payload ENCFORGE (.locked) against AI model weights and training data.

First seen
2026-07
File extensions
.locked
Ransom notes
README
Affected platforms
Linux / Databases

Family profile

File extensions
  • .locked
Ransom notes
  • README
  • HOW_TO_DECRYPT
  • README_DECRYPT
Contact patterns
  • Anonymous proton.me mailbox (one letter plus eight digits), reused across both campaigns
  • Bitcoin address embedded in the first campaign's note (P2SH, starts with 3); the ENCFORGE note carries only the mailbox
  • In database cases no file is dropped: the note is written as a table named README_RANSOM
  • No Tor negotiation portal, no payment page, no data-leak site
Aliases / versions
JADEPUFFER、ENCFORGE、ENCFORGE 勒索病毒、encfile
First seen
2026-07
Status
Active
Operational status
Newly emerged
Threat level
High
Affected platforms
  • Linux
  • Databases
Tags
  • Emerging
  • Active
  • Exploits vulnerabilities
  • Targets databases
Decryptor
No public decryptor

No free public decryptor exists for JadePuffer or ENCFORGE, and neither No More Ransom nor vendor tool libraries list them.

The two campaigns handle keys differently but reach the same conclusion:

  • First campaign (Nacos configuration encryption). The agent generated an AES key as base64(uuid4().bytes + uuid4().bytes) and encrypted configuration fields in place with MySQL's AES_ENCRYPT(). Sysdig found the key was printed once to stdout inside the compromised environment and never persisted or transmitted. In other words, even paying would not produce a key, because the operators never held one. The Bitcoin address in that note is the example address from Bitcoin's own documentation, which tells you how little the payment path was ever meant to work.
  • Second campaign (ENCFORGE file encryption). The payload encrypts content with AES-256-CTR and wraps the session key with an RSA-2048 public key compiled into the binary. Without the private key there is nothing to reverse, and no offline key exists.

Note also that .locked is a generic extension reused by many families. Tools advertised as ".locked decryptors" almost always target something else, and running one against ENCFORGE output only damages the files further. Any recovery attempt must start with sample-level family identification.

Latest activity

  1. A Sysdig follow-up on agentic threat detection again cites JadePuffer as the first agentic ransomware operation, but adds no new victims or TTPs; no leak site or further public incidents as of September 2026.

    Sources

  2. Sysdig reported a second JadePuffer campaign: same Langflow entry, a Docker socket escape, then a Go payload named ENCFORGE covering ~180 extensions aimed at AI model weights and training data, appending .locked.

    Sources

  3. Sysdig TRT disclosed JadePuffer as the first documented agentic ransomware operation: the agent entered via Langflow CVE-2025-3248, encrypted 1,342 Nacos configs and dropped databases; the AES key was never retained.

    Sources

Overview

Sysdig's Threat Research Team published JadePuffer on 1 July 2026 and described it as the first fully documented agentic ransomware operation: the entire attack chain was executed by an LLM-driven agent, evidenced by extensive natural-language commentary in the scripts and a 31-second self-diagnosis and fix after a failed login. A note on naming: JadePuffer is Sysdig's designation for the threat actor (Malpedia catalogues it as an actor too) and the encryption payload is separately named ENCFORGE, project codename encfile; this page presents them as a single family entry.

Only two incidents are public. The first encrypted 1,342 Nacos service configurations before dropping databases outright; the second, disclosed on 20 July, deployed a Go payload named ENCFORGE against AI model weights and training data, using the same entry point and ransom contact.

The target set overlaps heavily with the cloud-native and AI stack common in Chinese enterprises - Langflow, Nacos, MinIO, MySQL - and reconnaissance hunted Alibaba, Tencent and Huawei Cloud credentials plus DeepSeek API keys. That is stack overlap, not evidence of prevalence in China: victim geography and industry were never disclosed, the technical detail comes from a single vendor that downstream reporting - NSFOCUS included - traces back to without adding local telemetry, and no domestic case is on record. As of September 2026, nothing new has been published since 20 July.

How to identify it

ENCFORGE file encryption. Files are renamed with a .locked extension and three English notes appear alongside them: README, HOW_TO_DECRYPT and README_DECRYPT, opening with "YOUR FILES HAVE BEEN ENCRYPTED", claiming military-grade encryption and a unique key, with a seven-day deadline and a proton.me address. The payload covers roughly 180 extensions weighted toward AI assets: .safetensors, .ckpt, .pt/.pth, .gguf, .onnx, .h5, .faiss, .parquet, .npy and similar. If model registries and dataset directories were hit rather than office documents, that alone is a strong indicator.

Database case (first campaign). No extension and no note file. Nacos configurations turn into ciphertext, config_info and the his_config_info history table are dropped, and a new MySQL table named README_RANSOM appears, opening with "YOUR DATA HAS BEEN ENCRYPTED".

Other artefacts (all from the published analysis of the first incident; the second report records none of them). A crontab entry on the Langflow host beaconing via Python every 30 minutes; a backdoor administrator with a bcrypt-hashed password inserted into the Nacos backing database; MinIO accessed with default credentials.

Bottom line. .locked is shared by many families and cannot attribute one on its own. Confirm from samples, combined with the entry point, the extension list, the note filenames and the contact pattern.

Infection vectors

Both campaigns entered the same way - an internet-exposed Langflow instance. CVE-2025-3248 (CVSS 9.8) is a missing-authentication flaw: versions before 1.3.0 expose /api/v1/validate/code, letting an unauthenticated attacker execute arbitrary Python.

From that foothold:

  • Credential harvesting. Environment variables and config files were enumerated for LLM API keys (OpenAI, Anthropic, DeepSeek, Gemini), cloud credentials (Alibaba, Tencent, Huawei, AWS, GCP, Azure) and database passwords; Langflow's backing PostgreSQL was dumped.
  • Default credentials. MinIO opened with minioadmin:minioadmin, yielding credentials.json and .env files.
  • Lateral movement. Internal scanning led to a second server running MySQL and Nacos - whether it was also internet-exposed is not stated publicly - attacked through the Nacos auth-bypass class of flaw (CVE-2021-29441, affecting versions before 1.4.1) and JWT forgery using the publicly known default signing key.
  • Container escape. In the second campaign the agent found a responsive Docker socket, wrote six escape scripts in-session and had a privileged container running 5 minutes 24 seconds later.
  • Persistence. A crontab beacon, plus a backdoor administrator planted in the Nacos database.

No zero-day is involved - only unpatched open-source components, default credentials and internet exposure. What changed is the tempo: unattended, advancing minute by minute.

Encryption behavior

The ENCFORGE payload is a static ELF built with Go 1.22.12 and packed with UPX; it had zero AV detections at analysis time. Content is encrypted with AES-256-CTR and the session key wrapped by an RSA-2048 public key compiled into the binary. Encryption is region-based rather than whole-file, traded for speed - which matters for large model weights and datasets, because untouched regions may survive inside each file. The payload terminates processes holding file locks, resumes idempotently, and takes an --include flag for custom extensions.

The binary also carries Windows-only anti-recovery code - vssadmin.exe for shadow copies, bcdedit.exe to disable boot recovery - and the extension list includes macOS artefacts like .keychain and .xcodeproj, yet only Linux samples have been recovered in the wild.

The first campaign's database encryption worked differently: MySQL's AES_ENCRYPT() encrypted Nacos configuration fields in place, measured as AES-128-ECB despite the note claiming AES-256; the agent then set FOREIGN_KEY_CHECKS=0, cascaded deletions across several application databases and dropped the configuration history table.

Exfiltration. Sysdig states ENCFORGE has no exfiltration capability, and no leak site or Tor portal was found; in the first campaign the agent only asserted exfiltration in its own code comments, with no independent evidence. Treat this as single extortion, while still running a proper exposure assessment.

Assess before you act

Recoverability assessment

Recoverability depends on the scenario and the samples. We do not pay ransoms and do not negotiate; our work is technical recovery and forensics.

1) Free decryptor. None. The first campaign's AES key was never retained even by the operators, and the second wraps session keys with RSA-2048, so payment is not a recovery path.

2) Repair space created by region-based encryption (depends on the pattern). ENCFORGE overwrites only parts of each file. Formats with clear chunking and indexes - safetensors, gguf, parquet, npz - can sometimes be parsed structurally to extract undamaged tensors or shards when headers and indexes survive; database files allow similar page-level extraction. To be clear, the published research confirms only that encryption is region-based and offers no recovery path; this layer is our own engineering judgement from file-format structure, not a publicly validated result. The yield depends on where the overwritten regions landed and must be measured.

3) Backups, snapshots and shadow copies. The Linux build was not observed destroying backups, so this layer usually delivers the highest ratio: object-storage versioning and retention, snapshots, untouched copies on the backup server, historical layers in the image registry. In the Nacos case, confirm immediately whether MySQL binlogs survive - the history table was dropped, but binlogs can support point-in-time reconstruction.

4) Unencrypted copies and log replay. Nacos clients keep a local configuration snapshot cache on each application instance, and instances that have not restarted still hold the active configuration in memory - the most realistic source after a database wipe, provided the pods are not restarted. Models may likewise survive in an internal registry, artefact stores, upstream open-source repositories or checkpoint directories, while configuration and infrastructure definitions are often versioned in a GitOps repo.

5) Low-level carving. ENCFORGE rewrites in place then renames, so more source data is overwritten than with families that create a new file and delete the original. Carving is weaker here but still worth attempting for deleted database and temporary files - provided writes to the affected volumes stop immediately.

We commit to a verifiable assessment and a clearly bounded recovery scope. We never claim "100% decryption", and no technique guarantees full recovery.

Our response plan

Hit by JadePuffer ransomware? What to do

  1. Containment and forensics - do not restart containers

    Take internet-exposed Langflow, Nacos, MinIO and MySQL off the public network and block known beacon destinations. The critical instruction is not to restart application pods, containers or VMs: the Nacos client-side snapshot cache and the live configuration held in instance memory are often the only surviving source of configuration after a database wipe, and a single rolling restart can erase both. Image or snapshot affected nodes, export container runtime logs, MySQL binlogs, audit logs and crontabs, and preserve three to five .locked files plus the original notes (or export the README_RANSOM table in database cases).

  2. Family identification and kill-chain reconstruction

    Confirm from the extension, the three note filenames, the extension coverage and file header/trailer structure whether this is really ENCFORGE rather than another family using .locked - everything downstream depends on it. In parallel, reconstruct the entry: check whether Langflow is below 1.3.0 and whether /api/v1/validate/code is reachable unauthenticated, whether Nacos still uses the default JWT signing key, whether MinIO still has default credentials, and hunt for the crontab beacon, rogue administrator rows in the Nacos backing database and an exposed Docker socket.

  3. Recoverability and impact assessment

    Inventory by asset type. For Nacos configuration, cross-fill from four sources: client snapshot caches, live instance memory, binlog-based reconstruction and the GitOps repository. For AI models and datasets, first establish whether copies exist in the internal registry, artefact store, training checkpoints or upstream repositories; only where none exist do we map the encrypted regions of the .locked files and sample-test how much can be extracted. Assess credential exposure at the same time - any cloud AK/SK and LLM API key the agent enumerated must be treated as compromised. Deliver a written assessment covering what is restored from copies, what needs structural repair, and what can only be retrained or rebuilt, with expected scope and timelines.

  4. Recovery execution and rebuild

    All work happens on images or copies with originals kept read-only. Restore in order: the configuration centre first so services can start (export client snapshots, reconcile them, load them into a freshly built clean Nacos instance), then databases and object storage, then models and datasets. Dropped application databases are rebuilt point-in-time from binlogs and reconciled against the application side. For model assets, prefer re-pulling or resuming from checkpoints, and commit to structural extraction only where no copy exists. After each batch, run integrity checks and business verification - configuration take-effect tests, application start-up, inference output comparison.

  5. Attribution, hardening and handover

    Upgrade Langflow to 1.3.0 or later and remove it from the public internet; keep AI orchestration, configuration services and object storage behind an internal network or zero-trust gateway. Replace the default Nacos JWT signing key and patch CVE-2021-29441, change MinIO's default credentials, and remove the backdoor administrator and crontab beacon. Rotate every cloud credential and LLM API key the agent enumerated. Tighten the container surface: no mounted Docker sockets, restricted privileged containers, least privilege for the MySQL service account and UDF capability disabled. Rebuild backups with versioning and immutable copies, bring configuration and model artefacts under rollback-capable version control, and close with an incident report and formal handover checklist.

Risk warning

What not to do

  • Do not restart or roll out application pods, containers or VMs - the Nacos client snapshot cache and the live configuration in instance memory are the most realistic recovery source after a database wipe, and a restart erases both.
  • Do not pay the proton.me address in the note: the first campaign's AES key was never retained by the operators and the Bitcoin address is the example from Bitcoin's own documentation, so the path does not exist.
  • Do not run downloaded ".locked decryptors" against original disks - .locked is shared by many families, a mismatched tool only causes further damage, and trials belong on copies.
  • Do not rush to drop or rebuild the encrypted MySQL databases, and do not disable or purge binlogs; they are often the only basis for point-in-time reconstruction of configuration and application data.
  • Do not patch Langflow and put it straight back on the internet: credentials were already harvested, a backdoor administrator may remain in Nacos, and the crontab beacon may still be active.
  • Do not delete the .locked files, the three ransom notes or the README_RANSOM table - they are the only basis for family identification and encryption mapping.

Emergency response

Data already encrypted? Stop and let an engineer look first

We do not pay ransoms and we do not negotiate with attackers. Engineers run a free assessment first, then propose a recovery plan and a firm quote.

+86 15639272850See contact details

Related scenarios

Related industries

Similar families

FAQ

JadePuffer Frequently asked questions

  • Can .locked files be decrypted?

    For JadePuffer's ENCFORGE payload there is no public decryptor: content is encrypted with AES-256-CTR and the session key is wrapped with an RSA-2048 public key compiled into the binary, so without the private key there is nothing to reverse. Be careful, though - .locked is a generic extension reused by many families, and your files may not be ENCFORGE at all; some older families using .locked do have working decryptors. The first step is always to identify the family from three to five encrypted files plus the note, not to go looking for a ".locked decryptor".

  • Our Nacos configuration was encrypted and databases dropped - would paying help?

    No, and there is concrete technical evidence for that. Sysdig's analysis shows the AES key was assembled from random UUIDs and printed once to stdout on the compromised host - never written to disk, never transmitted, so the operators never held it. The Bitcoin address in the same note is the example address from Bitcoin's own documentation. The realistic recovery directions are the live configuration in the memory of instances that have not restarted, the Nacos client-side snapshot cache, point-in-time reconstruction from MySQL binlogs, and configuration versions in the GitOps repository.

  • Our model weights and training data were encrypted - anything recoverable?

    Look for copies first, repair second. Check the internal model registry, artefact stores in MLflow or similar platforms, checkpoint directories on training nodes, object-storage versioning and retention, and upstream open-source repositories - many model files can simply be re-pulled. Only where no copy exists do we map the encrypted regions: ENCFORGE encrypts in regions rather than whole files, so formats with clear chunking and indexes such as safetensors, gguf and parquet can sometimes yield undamaged tensors or shards when headers and indexes survive. The recoverable proportion varies widely and has to be sample-tested first.

  • We run Langflow - how do we check ourselves quickly?

    Four checks. First, whether Langflow is below 1.3.0 and whether /api/v1/validate/code is reachable unauthenticated from the internet (CVE-2025-3248). Second, whether the host's crontab contains a scheduled Python callout and whether a Docker socket is mounted. Third, whether Nacos still uses the default JWT signing key, whether CVE-2021-29441 is patched, and whether any administrator row was recently added to the backing user table. Fourth, whether MinIO still has the minioadmin default credentials. If Langflow was ever internet-exposed, treat every cloud credential and LLM API key present on that host as compromised and rotate it.

  • How does agentic ransomware change incident response?

    Three things change. Speed: the chain advances unattended and self-corrects within tens of seconds, compressing the human response window to minutes. Behavioural instability: the agent improvises scripts, retries and leaves extensive natural-language commentary, so its footprint is less fixed than a traditional family's and IOC-based detection ages faster - though the logs often show unusually explicit intent. And more arbitrary destruction: in the first incident the key was never saved and the configuration history table was simply dropped, blurring the line between extortion and wiping, so never assume the other side retained anything tradable. In practice this means isolating earlier, working harder to preserve volatile evidence (memory, caches, binlogs), and moving credential rotation much further up the priority list.

Sources

External links are provided for reference only. The content is published by third parties and does not represent our position.

Updated