Clop Says It Took 89GB From Shell. Shell Says It Is Investigating — And That Gap Is the Whole Business Model

Clop published a list this week. On it were 43 organisations, and the names at the top were the kind that make a campaign a news story rather than an advisory: Shell, General Electric, Philips, Fiserv. The claim against Shell alone is 89GB — engineering drawings, scans of facility testing reports, photographs of facilities, project plans, per Clop's own posting. From GE and Philips, the gang claims backups, system files, projects, drawings, diagrams, and blueprints.

Shell's response, in full, was this: "We are working with our security teams and relevant experts to investigate."

That is not evasion. It is very probably the honest and complete state of Shell's knowledge, six days in. And it is the single most important detail in this story — more important than the CVE, the patch date, or the victim count — because the gap between "they claim 89GB" and "we can confirm what left" is not a communications problem. It is the product Clop is actually selling.

What happened, briefly

The entry point was CVE-2026-12569, an unsafe-deserialization flaw in PTC Windchill and FlexPLM carrying a CVSS of 9.3. Windchill is product lifecycle management software — the system where aerospace, automotive, medtech and industrial manufacturers keep designs from concept through production.

The technical chain is unremarkable by 2026 standards: a pre-authentication information disclosure in the FlexPLM WSDL endpoint, chained into a flaw in the Windchill login servlet, producing unauthenticated remote code execution. Attackers dropped hex-named JSP webshells under /Windchill/login/, enumerated the filesystem to a staging file, and pulled engineering data out.

The timeline is the part worth writing down:

Date	Event
Early June 2026	Clop affiliates begin exploiting the flaw as a zero-day
June 17	PTC begins shipping patches
June 25	CISA adds CVE-2026-12569 to the Known Exploited Vulnerabilities catalog
July 20	Extortion emails begin
August 12–13	Victims start appearing on the leak site

Read left to right, that is roughly 56 days of silent collection before anyone was asked for money, and another three weeks before the names went public. Which means that for most of the organisations on that list, the first credible notification that they had been breached in June arrived in mid-August — from the people who did it.

The patch was not the failure

It is tempting to file this under slow patching, and that reading does not survive the dates. PTC shipped fixes eight days into public awareness. CISA had it in KEV eight days after that. By the standards we wrote about on Saturday, where a vCenter flaw was being exploited across 47 countries five days after disclosure, this vendor and this agency both moved quickly.

It did not matter, because the theft had already happened. Patching on June 17 closed a door that a webshell had already been carried through in the first week of June. Every organisation that applied the update on time, closed the ticket, and moved on did exactly the right thing and is still on the list.

This is the failure mode that patch metrics are structurally blind to. A patch changes your future exposure. It says nothing whatsoever about your past one, and for a zero-day campaign the entire loss sits in the past. The action item after a KEV listing is not "confirm patched." It is "confirm patched, then go and prove nobody was already inside" — and almost no organisation is equipped to run the second half.

Exfil-only extortion sells doubt, not damage

Clop stopped bothering with encryption years ago, and the reason is instructive.

Ransomware that encrypts gives the victim one unambiguous gift: certainty. The files are unreadable. You know precisely what was hit, when, and how bad it is, because the damage is sitting in front of you. You may not like the answer, but you have one, and you can make a decision.

Data theft gives you none of that. An email arrives from — per Ransom-ISAC's Brandon Parsons — randomly compromised accounts, blasted to hundreds of recipients inside your organisation, asserting a number. You now have to answer, under time pressure and with your board watching, a question you have no instrumentation for: is that true?

Consider what "89GB of engineering drawings" actually demands of a defender. You need egress records from an appliance most SOCs never onboarded. You need them from ten weeks ago, which means retention that outlives the average log budget. You need enough fidelity to distinguish a bulk exfiltration from legitimate CAD synchronisation and vendor collaboration, on a platform whose normal traffic pattern is large files moving to external parties. And you need to do this on a system your security team probably does not own — PLM lives with engineering, and it is not a coincidence that Clop's last four mass campaigns hit managed file transfer, then ERP, and now PLM. The pattern in target selection is not the technology. It is enterprise middleware that aggregates everything and belongs to no one in security.

Absent that evidence, the negotiation is not about data. It is about your uncertainty, and Clop prices it accordingly.

The asset class makes it worse

There is a second reason this campaign is harder than a PII breach, and it has nothing to do with detection.

A stolen customer database is terrible and well-understood: there is a notification trigger, a regulator, a remedy, a credit-monitoring line item, and a body of precedent. Stolen product designs have none of those. There is often no notification duty at all, because the data belongs to the company rather than to consumers. There is no reset — you cannot re-issue a turbine blade geometry, a bill of materials, or five years of supplier pricing. And there is no expiry date on the harm: a design leaked in 2026 is still a competitive gift in 2031.

That also means the public record of this campaign will stay thin, which compounds a trend we covered yesterday — only 24% of US breach notices in the first half of 2026 explained how the attack happened. Expect most of these 43 to resolve into silence. Note that even the victim count is contested in the reporting: some outlets counted 43 names, others "nearly 30." Nobody outside Clop can currently verify the list itself, which is a fairly complete summary of the problem.

What to do this week if you run Windchill or FlexPLM

Patch status is the easy half. The retrospective half:

• Hunt the artefacts, don't infer from patch state. Hex-named JSP files under /Windchill/login/, unexpected filesystem-enumeration output, and child processes spawned by the application server. These are cheap to search for and are the only positive evidence available to most victims.
• Pull egress records back to the first week of June, before retention rolls them off. If you cannot, that itself is the finding — write it down now, because it is the answer you will have to give your insurer.
• Inventory the tier, not the product. The question is not "do we run Windchill." It is: which internet-facing systems aggregate data across the business and sit outside the security team's ownership? That list is where the 2027 campaign is going.
• Decide the extortion-response process before the email arrives, including who is authorised to say "we cannot confirm that claim" and what evidence would change the answer.

Where Obiguard fits: SOC is what turns a claim into a finding

The uncomfortable thing about this campaign is that the decisive capability is not prevention or even detection — it is the ability to adjudicate someone else's claim about your own environment, weeks after the fact. That requires telemetry you collected before you knew you needed it.

Obiguard SOC is built around that artefact. Logs stream in from any Splunk HEC-compatible forwarder — Vector, Fluentd, Logstash, or your own agent — alongside host metrics and distributed traces over OpenTelemetry, with a one-command Kubernetes daemonset for EKS, GKE and AKS. Getting the unglamorous middle tier into that stream — the PLM appliance, the ERP host, the managed transfer box — is the entire precondition for answering an extortion email with evidence rather than a spokesperson's sentence.

Every incident then carries a full evidence timeline linked back to the raw log events that produced it, with an AI-written executive summary and business-impact assessment. That is precisely the artefact a 43-victim campaign demands: not an alert that fired in June, but a defensible reconstruction assembled in August of what actually moved and when. Detection is automatic from live log volume and rule matches, with no detection rules to author first — which matters for exactly the systems nobody wrote rules for.

On the exposure side, every connected repo is scanned on every push and once a day, and Threat Intelligence cross-checks findings against CISA KEV and FIRST.org EPSS on a schedule — so a CVE that moves into the actively-exploited column, as this one did on June 25, surfaces against your estate rather than in a newsletter. Before you upgrade, a compatibility risk report scores the change 0–100 with the cross-repo blast radius, because the fastest way to stall an emergency patch is one upgrade that takes production with it.

And the tier that Clop will hunt next is already being built. AI gateways and copilots are becoming the newest system that reaches into every repository, ticket queue, design store and wiki — usually deployed by a product team, usually on a static credential, usually with no security owner. That is the Windchill profile exactly. Obiguard Governance AI and its allow-lists bind each AI credential to specific model IDs, tools, external domains and invoking identities, while the audit ledger keeps an immutable per-call record — so the next aggregation layer arrives with an owner and a trail, instead of acquiring both during an incident.

Clop's leverage over 43 companies right now is not the 89GB. It is that none of them can say, today, whether the number is real. Explore Obiguard SOC or talk to us about whether your logs from June would settle the question.