We Told You to Hunt Hex-Named JSP Files on June 26. Clop Started Dropping Them — Then We Forgot We'd Said It.
- Patrick Duggan
- 46 minutes ago
- 4 min read
Earlier today we published a post about Clop's new extortion campaign against PTC Windchill and FlexPLM. It contained this sentence:
"We have deep Clop coverage, but no Windchill indicators in our corpus before this week."
And later, about the medical device angle: "the same thesis arriving through a door we had not specifically watched."
Both wrong. We had watched that door. We had written the sign on it.
What we actually published, and when
On June 26, 2026 — the day CISA added it to the Known Exploited Vulnerabilities catalog — we published "The Manufacturing Brain Just Went on the KEV List. PTC Windchill CVE-2026-12569 Is Being Exploited Right Now."
That post told readers to do four things. Search web logs for suspicious JSP files. Scan for newly-created files with hex-string names. Check the timestamps against your patch date. Patch to 12.1.2 or 12.0.2, then read your login logs, because the patch does not evict anyone who was already inside.
On July 24, BleepingComputer reported that Clop's affiliates are deploying hex-named JSP webshells on Windchill instances.
We named the exact artifact twenty-eight days before the crew was named on it.
What that is worth, precisely
It is not a lead over CISA. They listed the CVE on June 26 and we published the same day. Zero gap. Anybody reading the KEV catalog had the same information at the same moment, and we have said many times that CVE disclosure is not a race we win.
What it is: detection guidance a month ahead of attribution. A defender who read us on June 26 spent late June hunting hex-named JSP files in their Windchill deployment while Clop was still working quietly. When the news broke on July 24 that a ransomware crew was doing exactly that, that defender had already looked.
That is the honest size of the claim and we are not going to inflate it. It is also, we think, a better claim than a scoop — because it is the kind that actually helps somebody. A scoop is a thing you win. A hunt instruction dated four weeks before the campaign is a thing somebody uses.
Why we missed our own post
The pre-publication check on this morning's Clop story queried our corpus for "Clop ransomware PTC Windchill FlexPLM data theft."
Zero hits. So we wrote that we had no prior coverage.
The June 26 post is not about Clop. It is about the CVE. It never mentions Clop, because on June 26 nobody knew Clop was involved — CISA's listing said "unknown attackers." So a query built out of today's campaign vocabulary could not reach a post written in the vocabulary of a month ago, and our own hybrid search ranked our own receipt off the results.
This is a known failure mode and we have written about it before. In June we swept twelve headlines, flagged three as gaps, and verified before publishing — two of the three collapsed because we already owned the story and search had just missed it. We built the verify-before-you-write discipline out of that exact experience.
Today the discipline ran and still missed, because the query was wrong. Searching for the campaign name finds campaign coverage. It does not find the vulnerability coverage that predates the campaign name existing. The fix is to query the CVE and the product as well as the actor, always, because the CVE is the thing that stays constant while the attribution changes.
The inverse of our last correction
Six days ago we published a correction titled "We Claimed a Two-Month Lead. Our Own Timestamp Says We Were One Day Late." That was an over-claim — we cited our own ingest time as though it were detection time, and Bitdefender had published a day before us.
This one runs the other way. Same root cause — not checking the comparator properly — opposite direction. Then we claimed something we had not earned. Today we disclaimed something we had.
We would rather publish both than pretend we run at a hundred percent, and we have a standing rule against ever claiming we do. The error rate is real. What we can control is whether we go back and mark it.
We re-checked the rest of the day's work
Four other posts went out today: the Hermes AI agent operation against Thailand's Ministry of Finance paired with the Dolphin X victim-ranking stealer, the hospitality Wi-Fi DNS poisoning campaign, SourTrade's browser-assembled per-victim binaries, and the UAC-0099 fake Notepad++ plugin chain.
We re-queried all four the correct way — by product, by technique, by CVE, by malware family, not just by campaign name.
All four are clean. No prior coverage we overlooked, and the "we did not have this, we are not claiming a lead" statements in each of them stand as written. One miss out of five.
What changes
The pre-publication corpus check now runs a second pass on the underlying vulnerability and product, not only on the campaign and actor. It is a small change and it would have caught this.
The July 25 Clop post has this correction linked from it. We are not quietly editing the sentence and moving on, because the interesting part is not that the sentence was wrong. It is that our own archive was ahead of us and we could not find it — and an archive you cannot search is worth a good deal less than one you can.
We are 95 percent confident this class of miss recurs, because it is a retrieval problem and retrieval problems are never fully solved. The remaining five percent is the version of us that stops writing posts about our own mistakes, which would be worse than the mistakes.
The June 26 Windchill post is still the operative guidance: hunt hex-named JSP files, check the timestamps, patch to 12.1.2 or 12.0.2, and read your login logs. It was right a month ago and the news has only made it more urgent.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Comments