A ransomware crew turned mass extortion into an assembly line. The victims found out months later.

Ask anybody to picture a ransomware attack and you'll get roughly the same movie. Screens locking up across the office. A skull, maybe, or a countdown timer. A note demanding payment in cryptocurrency. Somebody in IT sprinting toward the server room while an executive asks how long until we're back up.

That picture has been wrong for a while, and this summer a crew called Cl0p spent three months proving exactly how wrong.

They broke into more than forty organizations, including Shell, General Electric, Philips, Fiserv, and Zebra. They took engineering drawings, project files, databases, and blueprints. Then they did nothing at all, which was the point. The files stayed unencrypted, the screens kept working, and nobody received a demand. For a lot of those companies, the first indication that anything had happened was seeing their own name published on a leak site in August, for data that walked out the door in June.

I've sat in rooms during the first hours of an incident, and there's a particular kind of quiet that settles over a leadership team when they learn the theft happened weeks ago and the attacker left long before anyone noticed. Containment doesn't apply. Neither does anything else that depends on moving quickly. The work in front of them is reconstructing what happened from logs that may not go back far enough to answer the question.

Cl0p Doesn't Hunt. It Manufactures.

Here's the thing worth understanding about this crew, and it has almost nothing to do with the specific software they broke into.

Extortion groups work one target at a time. They pick a company, find a way in, get access, and negotiate. That's craftsmanship, and craftsmanship doesn't scale, because you can only work so many jobs at once.

Cl0p figured out something different years ago and has been sharpening it ever since. Instead of picking a company, pick a piece of software that thousands of companies run. Find one serious flaw in it. Scan the entire internet for every organization that has it exposed. Hit all of them in a single coordinated window before anyone knows the flaw exists. Then work the extortion afterward, as a queue, dozens of victims deep.

You can trace the product line across five years. A file transfer appliance in 2021. Two more file transfer tools in 2023, including the MOVEit campaign that eventually touched thousands of organizations. Enterprise resource planning software after that. This summer, product lifecycle management platforms from a vendor called PTC.

The vulnerability changes every time, but the process never does. Same targeting logic, same tooling, same coordinated launch, same leak site, same slow public drip of victim names designed to pressure whoever hasn't paid yet.

There's an irony in this particular round I can't quite let go of. Product lifecycle management software exists to run a repeatable industrial process, from design through manufacturing to retirement. Cl0p fed it into one of their own.

The Warning Came at 2:30 in the Morning

The flaw at the center of this, CVE-2026-12569, was disclosed on June 17. Patches shipped the next day. CISA added it to its known-exploited catalog a week later and gave federal agencies three days to fix it.

The more telling detail came out of Germany. Around June 17, the BSI, the German federal cybersecurity agency, started calling PTC customers overnight to tell them to patch. One company reported a call at 2:30 in the morning, followed by an email at dawn. Three months earlier, for a different flaw in the same software, German police physically drove to companies to deliver the warning in person, which reporters at the time described as unprecedented.

When a government agency is waking up system administrators at 2:30 AM, they know something the rest of the market doesn't yet. In this case, what they knew was that Cl0p had already been inside for weeks. Investigators now assess with high confidence that the flaw was exploited as a zero-day in early June, before anyone outside the operation knew it existed.

Patching Closes the Door. It Doesn't Tell You Who Came In.

That timeline creates a problem most patch programs aren't built to handle. Picture a company that installed the fix in early July and moved on.

They closed a door that had been standing open for roughly a month. Good. Necessary. During that month, though, attackers were installing small pieces of software on the server that let them come back whenever they wanted. An update leaves those in place. They sit exactly where they were installed and keep working, while the patch report on your desk says the vulnerability is remediated.

This is the disconnect I see constantly, and it's a project management failure more than a technical one. Patching has a completion date, and somebody can put it on a status report and mark it green. Figuring out whether anyone got in during the exposure window has no completion date, requires people you probably don't have sitting idle, and produces an answer nobody wants to receive. So one of those two things reliably happens and the other one reliably doesn't.

The organizations that showed up on Cl0p's leak site in August weren't all the ones who failed to patch. Some of them patched and stopped there.

Why It Was This Software, and What That Says About Yours

Cl0p's target selection follows a pattern, and the pattern gets uncomfortable once you see it.

Look at what they've gone after: file transfer systems, ERP platforms, and now product lifecycle management. What these share is that they hold enormous amounts of valuable data while receiving a fraction of the attention that customer databases get. A PLM platform doesn't come up in board conversations, and it has no compliance regime built around it the way payment data does.

For a manufacturer, though, that platform holds the actual crown jewels: engineering drawings, bills of materials, test results, supplier contracts. The complete instructions for how a physical product gets built. The victims skewed heavily toward aerospace, automotive, manufacturing, and apparel, and that distribution reflects who runs the software rather than any strategic choice on Cl0p's part. They picked the platform, and the industries came attached.

One more property of this stolen data separates it from the usual breach. A stolen credit card gets canceled in an afternoon and a stolen password gets rotated, but a stolen design for a product with a fifteen-year production run stays valuable for fifteen years, and no incident response process on earth makes it un-stolen. The companies on that leak site are absorbing this rather than recovering from it.

What This Means for Everyone Who Isn't a PTC Customer

If you run this specific software, the immediate work is straightforward and your vendor has published it. Patch, go looking for what came through before you did, then rotate every credential that system could reach.

For everyone else, the useful exercise is broader and takes about an hour.

Make a list of every system in your environment that holds something you'd be genuinely unhappy to see published, and mark the ones that don't generate alerts anybody reads. That intersection is Cl0p's target profile. Attackers aren't drawn to obscurity for its own sake, but an assembly line needs an exposure window that stays open long enough to run the process, and the systems nobody watches are where it does.

Then ask a harder question about everything on that list. If somebody took all of it tomorrow and told you about it in ten weeks, would you have any way to confirm it?

That's a logging question, a retention question, and a monitoring question at once, and for a lot of organizations the honest answer is no. Which means the leak site is the detection mechanism, and that's a hell of a thing to outsource to your attacker.

The last piece is the one people skip because it feels like paperwork. Build the assumption of silent theft into your incident plan. Most plans start at the moment of discovery and assume discovery arrives as an alert or a demand. This campaign is a clear argument that discovery might arrive as a reporter calling for comment, and the plan should have a page for that.

The Next One Is Already Being Built

Cl0p is running this again. That isn't a prediction so much as a description of what a functioning business does. Somewhere right now they're evaluating the next piece of widely deployed enterprise software with a lot of data behind it and not much scrutiny in front of it. They'll find something, they'll sit on it, and a few months from now a government agency will start making phone calls at an unreasonable hour.

Coming through it in decent shape has less to do with patch speed than with three things that have to exist beforehand: knowing which systems hold what, keeping logs long enough to answer questions about a window that opened months ago, and not waiting for a ransom note to start looking.

The movie version of ransomware at least had the courtesy to tell you it happened.