By Crystal Morin

Ransomware crews have always followed the money. For years, that meant targets like banks and hospitals organizations with high-value assets and sensitive data who couldn’t afford downtime. Now, it means AI models too.

A threat actor the Sysdig Threat Research Team (TRT) dubbed JADEPUFFER has already shown us where the future of ransomware is heading.

In the span of a few weeks, JADEPUFFER went from poorly executed (albeit successful) database extortion with throwaway scripts to deploying a compiled ransomware binary built for one purpose: destroying AI and machine learning (ML) assets.

That progression tells us what attackers now consider valuable.

From on-the-fly to a purpose-built weapon

JADEPUFFER’s first campaign was scrappy, but it worked. The operator broke into a Langflow instance through CVE-2025-3248, an unauthenticated remote code execution (RCE) flaw that CISA added to its Known Exploited Vulnerabilities (KEV) catalog in May 2025.

Langflow is a rich target because it holds LLM provider keys, cloud credentials, and connects to vector databases and object stores within the victim’s environment.

From there, the actor pivoted to a separate production database and encrypted 1,342 configuration items using the database’s own built-in Advanced Encryption Standard (AES) function, AES_ENCRYPT().

Here’s where the attack was a little rough around the edges: The database never appeared to be exfiltrated before it was destroyed. Additionally, the encryption key was generated randomly, printed once, and never saved or sent anywhere.

The ransom note claimed one type of encryption, but the ransomware actually used a different kind. Database recovery was impossible even if the victim paid.

Whether that was sloppiness or indifference, the outcome was still the same – destruction, not extortion.

What made this operation notable was not the ransomware itself, but that the entire operation was driven end to end by an AI agent. The agent narrated its own reasoning in plain language within the payloads.

When a step failed, the agent diagnosed the problem and issued a corrected version in seconds.

This is what an agentic threat actor (ATA) looks like in practice. These capabilities are delivered by the model, not typed by a human at a keyboard.

The second campaign is where JADEPUFFER’s intent became unmistakably clear. Still the same operator, confirmed by the same extortion contact address reused across both intrusions.

But this time, the improvised scripts were gone. In their place was a serious upgrade called ENCFORGE.

What ENCFORGE actually targets

ENCFORGE is a compiled, UPX-packed Go ransomware binary with a clean command-line interface (CLI) and a companion key generation (keygen) tool.

It uses hybrid encryption – AES-256 in counter mode, with the per-run key wrapped in an embedded RSA-2048 public key and encrypts files in regions rather than whole-file encryption like LockBit and BlackCat ransomware.

Additionally, encrypted files are renamed with a .locked extension. On paper, this looks like straightforward ransomware engineering at this point.

The target list makes this ransomware campaign particularly distinct. ENCFORGE goes after roughly 180 file extensions, all of which are the building blocks of AI systems: model formats, vector indices, training datasets, and more.

The binary’s own help text even references LoRA fine-tune adapter files and legacy model weights as explicit examples.

This is not a generic file encryptor. This was built with intention by someone who understands the value of the data sitting within the AI development pipeline.

Attackers have figured out that a fine-tuned AI model, a curated dataset, and a populated vector store are currently the most valuable assets an organization has, and the least protected.

When a human quits, an agent persists

Before JADEPUFFER was able to encrypt AI and ML infrastructure using ENCFORGE, it hit a wall. The operator had access to the victim environment, then attempted to fetch the ENCFORGE binary from its command-and-control (C2) server to continue the attack. But it failed.

Rather than moving on, the agent didn’t stop there. It built a container escape mechanism to carry the binary across a namespace boundary and run it directly on the host.

In only 5 minutes and 24 seconds, the agent iterated six Python scripts through the Langflow RCE channel, each one correcting a specific failure in the one prior.

The agent solved an infrastructure problem in real time because its intended plan didn’t work with the reality of the victim’s environment.

Why your model checkpoints are worth more than your servers

Take a step back and think about what sits in your targeted files. A production model checkpoint represents weeks or months of training, fine-tuning, and evaluation.

A vector store holds the embeddings that power your retrieval and search. A curated dataset reflects real engineering labor in collection, cleaning, and labeling. None of that is easy to reproduce overnight.

Rebuilding a production fine-tuned AI model can run between $75,000 and $500,000 once you account for compute and engineering time. And that assumes you still have the training data to rebuild from.

If those live on the same host as the models – and they often do – then ENCFORGE destroys both and you’re even worse off.

You cannot restore the model until you reconstruct the data first. That means the cost goes up.

This is why AI assets are such an attractive ransomware target. The recovery cost is enormous, and the leverage is real, even for an operator with no leak site or actual data theft. JADEPUFFER never exfiltrated anything with ENCFORGE.

It didn’t need to. Destroying the artifacts in place was the entire extortion strategy.

Conventional backups will let you down

Most backup strategies were designed for infrastructure and business data: restore the server, replay the transaction log, and you’re back to yesterday like nothing ever happened. That logic doesn’t hold for AI recovery.

The problem is the temporal gap. Your last backed-up model checkpoint might predate a month of fine-tuning runs and dataset curation.

Restoring it does not get you back to your current production model, it gets you back to a version of the model you already moved past.

Even worse, model artifacts tend to be large, and large files are frequently excluded from routine backup jobs precisely because of their size more often than anyone would like to admit.

Many teams only discover after an incident that their most expensive assets were never being backed up.

Standard backup verification also does not account for the dependency chain. A recovered model is useless without the matching tokenizer, configuration, and dataset lineage that produced it. If any link is missing, there’s no recovery.

Where JADEPUFFER leaves detection breadcrumbs

The good news is that this kind of attack is loud if you are watching the right layers.

Start with process behavior. A subprocess spawned under your Langflow or web application user that reaches out to the Docker Engine API to create or start containers is not normal.

Neither is nsenter targeting PID 1 from inside a container. Both are observable at runtime.

Next, watch your identities. JADEPUFFER began by harvesting provider keys and cloud credentials from a single compromised host, probed internal services to check their reachability, then replayed the credentials against internal databases and cache services to see what they would unlock.

A harvest-and-replay pattern is a cross-service authentication anomaly that runtime identity monitoring is built to detect.

Lastly, keep an eye on your filesystem. Mass creation of .locked files in directories that also contain model, vector, index, or dataset files is about as clear an indicator as you will get.

So is the sudden appearance of a ransom note. The catch is that by the time files are being renamed, your defensive window is closing.

Killing the process fast is the difference between losing a few checkpoints and losing the whole directory.

This is a runtime problem, and it must be caught and dealt with in real time.

Protecting the whole AI supply chain

Defending AI assets means treating the pipeline like the critical infrastructure it has become. Patch and harden your entry points. Langflow, for instance, should be on 1.3.0 or later.

Restrict access to the Docker socket, because most applications have no legitimate reason to talk to it.

Store your AI provider keys and cloud credentials outside of application runtime environments, and rotate anything a compromised service could have reached.

Then rethink recovery, specifically for AI. Keep offline or immutable snapshots of production model weights, and capture datasets, tokenizers, and configs together so a restore actually produces a working model, not a partial one.

Apply filesystem controls so a web application user cannot read or write your model directories in the first place.

You should also test your AI recovery the same way you test any other disaster recovery plan, because a backup you’ve never restored isn’t a plan, it’s a prayer.

The underlying lesson is an old one applied to a new target: assume breach. Treat your model servers with the same seriousness you give your databases and your cloud credentials, because attackers already do.

JADEPUFFER is not a warning shot. This is the new normal.

Crystal Morin is a Senior Cybersecurity Strategist at Sysdig. A former U.S. Air Force linguist and intelligence analyst, she translates complex threat research into practical guidance for security leaders and practitioners.

The post When Ransomware Targets AI Models: Defending the AI/ML Recovery Chain appeared first on Cyber Security News.