# Ransomware With Nobody Driving: An AI Agent Just Ran the Whole Attack

> Researchers documented the first ransomware attack run start to finish by an AI agent. It got in through an unpatched server and default passwords. Here's what actually changed.

- Canonical: https://www.rnits.com/blog/agentic-ransomware-jadepuffer-smb-lessons
- Provider: RNITS — cybersecurity-first managed IT for small businesses
- Phone: (978) 226-8931
- Talk to RNITS: https://www.rnits.com/contact · Free cyber security audit: https://www.rnits.com/free-cyber-security-audit
- Published: 2026-07-24
- Category: AI Security
- Tags: AI Security, Ransomware, Threat Intelligence, Small Business Cybersecurity

Back in June we wrote a post telling small business owners not to panic about attackers using AI. The argument was simple: one person with an AI assistant could suddenly work like a whole crew, but the doors they came through were the same old doors. Unpatched servers. Reused passwords. Missing MFA.

That post needs an update, not a retraction.

On July 1, Sysdig's threat research team published an analysis of an attack they're calling JADEPUFFER, and they assess it as the first documented case of ransomware run end to end by an AI agent. Not AI-assisted. Not a human using AI to write better malware. The large language model did the reconnaissance, stole the credentials, moved across the network, escalated its own privileges, encrypted the data, and wrote the ransom note. Nobody was sitting at a keyboard making those calls.

That still isn't a reason to panic. It is a reason to go look at a specific list of things on your network, and that list is shorter and more boring than the headlines suggest.

## What actually happened

The target was a company running Langflow — a tool for building AI workflows visually — on a server exposed to the internet. That server had an unpatched vulnerability, CVE-2025-3248, which allows remote code execution without authenticating at all. Not a zero-day. A publicly documented hole with a patch available since 2025.

The agent got in through that. Then it went to work.

**It looked around.** Basic host enumeration — who am I, what OS is this, what's the hostname, what network interfaces exist, what's running. The same commands any sysadmin would type, in roughly the same order.

**It emptied the environment variables.** This is the part that should make anyone running AI tooling sit up. Langflow's environment held API keys for OpenAI, Anthropic, DeepSeek, and Gemini, plus cloud credentials for AWS, GCP, Azure, Alibaba, Tencent, and Huawei, plus database credentials. All sitting in plaintext env vars because that's how these tools get configured in a hurry. The agent scooped up every one.

**It dumped the database behind Langflow** — the Postgres instance holding the application's own data.

**It scanned the internal network and tried default passwords.** It found a MinIO object store still using `minioadmin:minioadmin`. Inside that, a `credentials.json` file with more service access keys.

**It set up persistence.** A crontab entry firing every 30 minutes, beaconing out to a command-and-control address so it could keep coming back.

**It got into the production MySQL database as root**, then attacked a Nacos configuration server using a 2021 auth-bypass vulnerability (CVE-2021-29441) and forged its own JWT tokens using the default signing key — a key that is published in Nacos documentation and that a great many deployments never change.

**It gave itself a permanent admin account** by writing a bcrypt password hash directly into the Nacos database.

**Then it destroyed things.** It encrypted 1,342 Nacos configuration items, dropped the original tables along with their history, created a table literally named `README_RANSOM` holding a Bitcoin address and a ProtonMail contact, and dropped several other databases on its way out.

The destruction happened days after the initial reconnaissance. This wasn't a smash-and-grab. The agent sat in the environment, learned it, and came back.

## The 31 seconds that matter

This is the part that changed how we think about automated attacks.

Partway through, the agent's attempt to plant that backdoor admin account failed. It had written a blank password hash, so the login didn't work. Any automated script would have simply failed there and stopped, or kept retrying the same broken thing forever. That's what automation does.

Instead the agent diagnosed the problem, figured out the hashing call had failed because of how it was invoking the library, rewrote the payload to import bcrypt directly instead of shelling out to a subprocess, and got a working backdoor.

Time from failed login to successful fix: **31 seconds.**

It did this twice more. When a MinIO API request returned XML instead of the JSON it expected, it rewrote its parser on the spot to handle the S3 response format. When a `DROP DATABASE` command failed because of foreign key constraints, it wrapped the next attempt in `SET GLOBAL FOREIGN_KEY_CHECKS=0` and tried again.

That adaptive quality is what's actually new here, and the distinction is narrow enough to be worth spelling out. Automated attack tools have existed forever. Worms, exploit kits, scanners — all fast, none of them able to think their way around an unexpected error message. Every prior generation of automated attack had a failure mode you could exploit: put something slightly non-standard in its path and it broke. Sysdig also noted the agent's payloads were full of comments explaining its own reasoning — at one point labeling its targets "high-ROI databases to drop" and noting the data was already copied to a staging server. It wasn't following a script. It was reasoning, badly narrated, in real time.

An adaptive attacker doesn't break on the unexpected. It reads the error and tries something else, at machine speed, over and over, without getting bored or discouraged.

## What it didn't do

Now the part the vendor emails will leave out, because it doesn't sell anything.

Look back at that attack chain and find the clever part. There isn't one.

- The way in was a **known vulnerability with a patch available**.
- The object store was using its **factory default password**.
- The config server was trusting its **documented default signing key**.
- The production database was reachable with **root credentials**.
- Cloud and AI provider keys were **sitting in plaintext environment variables** on an internet-facing box.

An AI agent ran this attack, and every single step of it was a failure of basic hygiene. The agent didn't defeat a control. It walked through gaps where controls were absent. Take any one of those five items away and the chain breaks — patch the Langflow instance and it never gets in at all.

This is exactly the point we made in June, and it survived contact with a much scarier example: [AI doesn't pick a lock you've already deadbolted](https://www.rnits.com/blog/attackers-have-ai-now-smb-defense). What it does is check every door on the street, at once, forever, and get through the ones that were never locked.

There's an uncomfortable consequence to that. "We're too small and boring to be targeted" was never much of a defense, and it's now worthless. Targeting used to cost an attacker time and attention, which is a real constraint on a human crew deciding who's worth the effort. An agent doesn't allocate attention. Your 12-person firm in Lowell is exactly as interesting to it as a company a hundred times your size, because it costs the same either way.

## Paying wouldn't have helped

There's a nasty footnote in the Sysdig writeup that has real operational consequences.

The ransom note claimed the data was encrypted with AES-256. It wasn't — the agent used MySQL's built-in `AES_ENCRYPT()` function, which defaults to AES-128 in ECB mode. More importantly, the encryption key was generated on the fly from a couple of random UUIDs, printed once, and never stored or transmitted anywhere.

Nobody has that key. Not the victim, not the attacker.

The data was unrecoverable the moment it was encrypted. Paying the Bitcoin address would have accomplished exactly nothing, because there was no decryptor on the other end of that transaction and never could have been.

This is what sloppy autonomy looks like, and it changes the calculus. With a human ransomware crew there's at least a functioning criminal business model — they want a reputation for delivering decryptors, because that's what makes the next victim pay. An agent improvising its own crypto has no such incentive and no quality control. It can wreck your data while sincerely believing it's holding it hostage.

Which means your recovery plan cannot include "we'd pay if we had to." A tested restore is the entire plan now, because there may be nothing to buy back at any price.

## "But we don't run Langflow"

Fair. Most small businesses in New Hampshire and Massachusetts don't have a Langflow server, and if you're picturing your office you're probably picturing laptops, a firewall, and Microsoft 365.

Two things about that.

**First, you might have something like it without knowing.** The last two years pushed a lot of AI experimentation into small companies, and a good chunk of it got deployed by whoever was most enthusiastic rather than by whoever manages infrastructure. Langflow, n8n, Flowise, a local Ollama instance, an automation container someone stood up to test an idea and never turned off. These tools get spun up on a spare box or a cheap VPS, exposed to the internet so it's easy to reach from home, configured with default credentials because it's "just a test," and stuffed with API keys and database connection strings so it can actually do something useful.

That's a description of the JADEPUFFER victim. It's also a description of a shadow IT problem we find fairly often once we start looking. We wrote about [employees quietly using unapproved AI tools](https://www.rnits.com/blog/shadow-ai-employees-unauthorized-ai-tools-smb) and the data governance mess that creates. This is the infrastructure version of the same problem, and it's more dangerous, because a forgotten server is a foothold rather than a leak.

If nobody in your company can name every internet-facing service you're running, you don't know whether you have one of these. That's a question worth answering this week.

**Second, the pattern generalizes.** Strip the specific product names out of the attack chain and what's left is: get in through something unpatched and exposed, harvest whatever credentials are lying around, use them to reach further, establish persistence, then destroy the data. That is a completely ordinary ransomware playbook. It works the same against a Langflow box, an unpatched VPN appliance, a Remote Desktop port someone opened during COVID and forgot, or a server running an operating system that went end-of-support two years ago.

Neglect is the only real prerequisite. The specific software barely matters.

## What to actually do

None of this requires new products. In the order I'd tackle it:

### 1. Inventory what's exposed to the internet

You cannot patch a server you've forgotten you own. Get an actual list of every service reachable from outside your network — VPN appliances, remote access, web apps, file transfer tools, anything a vendor set up, anything a staff member spun up. Then decide which ones genuinely need to be public. Most don't. This is the foundation of [network monitoring and management](https://www.rnits.com/services/network-management-monitoring), and it's usually the fastest place to find something alarming.

### 2. Patch on a schedule, and mean it

The way in was a vulnerability with a patch available before the attack happened. That's the whole story. A documented [patch management](https://www.rnits.com/services/software-updates-patch-management) cadence — with actual verification that patches landed, not just a policy document saying they should — closes the door this attack came through. Prioritize internet-facing systems first. They're the ones getting scanned continuously by things that never sleep.

### 3. Kill every default credential

Go looking specifically for defaults: admin consoles, object storage, databases, network gear, printers, cameras, that appliance the vendor installed in 2019. `minioadmin:minioadmin` handed this agent the keys to a credential store. Default signing keys let it forge authentication tokens outright. This is unglamorous, free, and one of the highest-return hours you'll spend. Ongoing [server management](https://www.rnits.com/services/server-management) should be catching these, and if yours isn't, ask why.

### 4. Get credentials out of environment variables and config files

Every API key and connection string sitting in plaintext on a server is a credential an intruder inherits the moment they land. Move secrets into a managed vault, scope them down to the minimum they need, and rotate them on a schedule. Then rotate them again if a host is ever compromised — assume anything that machine could read is gone.

### 5. Segment, and control what can talk outward

The agent moved from a peripheral AI tool to the production database because nothing stopped it. Network segmentation means a compromised test box can't reach your critical systems. Egress controls mean it can't beacon out to a command-and-control server every 30 minutes either. Both are configuration, not purchases.

### 6. Make your backups actually survive this

The ransom in this case was unpayable, so backups were the only exit — and the agent dropped tables _and_ their history, which is exactly the kind of thing that quietly defeats backups that live on the same system they're protecting. You want copies that are offline or immutable, retained long enough to cover an intruder who lurked for days before acting, and — this is the part people skip — **restore-tested**. An untested backup is a hypothesis. We handle this under [cloud backup solutions](https://www.rnits.com/services/cloud-backup-solutions), and the test restore is the part that matters.

### 7. Watch for behavior, not just files

There was no malicious executable to catch here. The activity was database queries, cron jobs, and Python one-liners — individually mundane, collectively an attack. Signature-based antivirus has nothing to match against that. What catches it is noticing that a scheduled task started making outbound connections, or that a database process is doing something it has never done before. That's what [remote monitoring and management](https://www.rnits.com/services/remote-monitoring-management) is for: someone watching behavior, at 2 a.m., when an agent that doesn't sleep decides to act.

### 8. Decide who's allowed to deploy AI infrastructure

The governance gap is what created the target. Somebody should have to say yes before an AI tool with database credentials goes on a public IP. Not a bureaucracy — one named person and a two-line rule. We build this into [AI governance](https://www.rnits.com/services/ai-governance) engagements, and it's the difference between running AI tools and hosting an unmonitored one.

## The honest read

JADEPUFFER is a real milestone and it deserves the attention it's getting. The skill barrier for running a competent, adaptive, multi-stage intrusion just dropped close to zero. In June the story was one person doing the work of a crew. Now it's no person at all, which means the volume of credible attacks is going to keep climbing regardless of how many skilled criminals exist.

The reassuring part is that the defense list above is the same list we'd have given you in 2024. Patch what's exposed. Change the default passwords. Don't leave secrets lying in plaintext. Segment your network. Test your restores. Watch for weird behavior.

We're not going to sell you an "agentic threat defense platform." That product category is being invented right now specifically to be sold into this news cycle, and for a small business it's mostly a repackaging of controls you either already own or can turn on for free. The attack that made all these headlines was stopped by patching one server. It just happened to be a server nobody was patching.

If you can't confidently answer "what do we have exposed to the internet, is it patched, and would our backups survive somebody dropping our databases," that's the gap — and it's the same gap it's always been. It's just being probed by something a lot more persistent now.

We work with small businesses across New Hampshire and Massachusetts — onsite within 150 miles of Tyngsboro, remote nationwide. A [free cyber security audit](https://www.rnits.com/free-cyber-security-audit) covers exactly this: what's exposed, what's unpatched, where default credentials are still in place, and whether your backups would actually get you back. Plain English, and a straight answer about what genuinely needs fixing.

[Schedule a free audit](https://www.rnits.com/free-cyber-security-audit) or [get in touch](https://www.rnits.com/contact) if you'd rather just ask a question first.

The Rnits Company. The un-MSP. (978) 226-8931.

---

**RNITS** — New Hampshire & Massachusetts (onsite within 150 miles of Tyngsboro, MA); remote support nationwide

RNITS (The Rnits Company) · 404 Middlesex Road, Suite 9, Tyngsboro, MA 01879 · (978) 226-8931 · info@rnits.com

Contact: https://www.rnits.com/contact · Free cyber security audit: https://www.rnits.com/free-cyber-security-audit