Cl0p

CISA added the PTC Windchill PDMLink / FlexPLM pre-auth deserialization RCE (CVE-2026-12569) to its Known Exploited Vulnerabilities catalog on 2026-06-25, confirming active in-the-wild exploitation, the operational shift from the disclosure we deep-dived on June 20 (The Hacker News, 2026-06-26).

Reported post-exploitation deploys JSP web shells to /Windchill/login/<16-hex>.jsp plus a flst.txt persistence marker, concrete hunt artefacts beyond the earlier abstract RCE description. ENISA's EUVD entry corroborates the unauthenticated deserialization root cause (ENISA EUVD EUVD-2026-37831). The driver for Swiss/EU manufacturing, pharma and aerospace operators running Windchill is the confirmed exploitation and the web-shell pattern, not the US-only federal remediation date; patch per PTC CS473270 and hunt web-server logs for .jsp creation under /Windchill/login/.

The PTC Windchill / FlexPLM deserialization RCE this pipeline covered when CISA confirmed exploitation has moved from quiet data theft into open extortion. From 20 July a joint advisory by Ransom-ISAC, eCrime.ch and DEFUSED records that it "began observing an alleged Cl0p ransomware (aka Graceful Spider, Chubby Scorpius, FIN11, Lace Tempest) data extortion campaign sending emails with a subject line, “Windchill PDMLink module serious data leak” to an unknown number of affected organizations" (Ransom-ISAC / eCrime.ch / DEFUSED, 2026-07-22). The delivery pattern is the operationally useful part: the messages are sent from randomly compromised accounts and go to hundreds of recipients inside the victim organisation at once, carrying the attacker's current contact addresses; an approach the same advisory notes is consistent with the Oracle E-Business Suite campaign of last year apart from the new addresses (same advisory).

Two facts bound the response window. First, no victim has been named: "As of 22 July, Cl0p ransomware has not begun listing victims of this latest campaign on their dark web data leak site or has publicly claimed credit for this latest campaign" (same advisory), so an affected organisation's first and possibly only warning is the staff-wide email, not a leak-site entry. Second, attribution is unsettled and the two reporting streams disagree in a way worth carrying: the joint advisory treats this as Cl0p affiliate activity, while ReliaQuest, quoted by BleepingComputer, states that "The actor behind these attacks remains unconfirmed. however, the observed tradecraft shares characteristics with previous Cl0p campaigns targeting enterprise applications and high-value data repositories" (BleepingComputer, 2026-07-24). The underlying access route is unchanged from the June coverage, a pre-authentication information disclosure in the FlexPLM WSDL endpoint chained with the Windchill login-servlet flaw, followed by JSP web shells and staged data theft (Ransom-ISAC / eCrime.ch / DEFUSED, 2026-07-22).

One correction to how this pipeline previously framed remediation, because it changes who is still exposed: there is no version floor above which an installation is safe. PTC ships a patch per version, and its own change log records the older Windchill lines being patched between 18 and 19 June (13.0.2 on 18 June, and 11.0 M030 alongside 13.1.1 on 19 June) while the SUPs for 13.1.2 and 13.1.3, and the first release naming FlexPLM as well as Windchill, only arrived on 14 July 2026 (PTC, 2026-07-14). 11.0 M030 appears in that patch list as a version that receives a fix, not as a boundary below which systems are safe, and there is no lower bound at all: NVD states the flaw "also impacts Windchill and FlexPLM releases prior to 11.0 M030", and above that it enumerates discrete affected releases rather than a continuous range, topping out at Windchill 13.1.3 and FlexPLM 13.0.3. The practical consequence is narrower than a version number suggests but sharper for those it catches: an estate on 13.1.2 or 13.1.3 had no patch available between CISA's KEV confirmation on 25 June and the SUP release on 14 July, whereas a 13.1.1 estate could have patched from 19 June. Neither a high version number nor a version above 11.0 M030 is therefore evidence of remediation, and only the per-version list in PTC's eSupport article CS473270 answers the question.

Triage: the extortion email is itself a detectable event with a clean discriminator. A legitimate internal security notice originates from a known internal sender and the organisation's own mail infrastructure; this pattern is a large recipient set inside one organisation receiving mail from a compromised account with no prior relationship to it, referencing a specific internal application by name. Mail-flow telemetry showing that fan-out to a wide internal distribution list from a previously-unseen sender (rather than the message content) is the signal, and it should route to incident response rather than to the phishing-report queue.

The entry on Cl0p's mass-extortion campaign against internet-exposed PTC Windchill and FlexPLM deployments recorded that no victims had yet been listed on the group's leak site. Victims are now being listed, and the shape of the batch (rather than any individual name) is the delta.

Read directly from the Ransomware.live tracker's recent-victims feed this run, 44 named Cl0p listings were all first recorded by the tracker on 2026-08-12 (Ransomware.live, 2026-08-12). The tracker's own record timestamps advance at a near-constant 33 to 40 seconds apart, which is its crawl cadence rather than anything about the leak site, so the feed establishes that these listings were picked up in one sweep, and nothing at all about when Cl0p actually posted them. This entry therefore makes no claim about a publication window. The country codes attached to the records include Switzerland, the Netherlands, Finland, the United Kingdom, Italy, Slovakia, Hungary and France alongside a larger United States contingent; the tracker files the Dutch listing under healthcare and the Swiss one under retail and e-commerce. That tracker mirrors what the leak site publishes and verifies none of it; the company descriptions it prints alongside each record are machine-generated and are not used here. What the feed establishes is that the listings exist, when they appeared, and that European organisations are among them, nothing about whether any of those organisations was in fact compromised.

On whether this batch is the Windchill campaign, the honest answer is that nobody has said so. Foresiet reviewed a batch of 42 masked Cl0p listings and published on 2026-08-10, noting that the advertised data categories recurred with unusual consistency (project repositories, databases, CAD files, engineering drawings, backups and product documentation, with three listings spelling the Windchill product name directly) and that this pattern resembles product-lifecycle-management content more than a general file share. Its conclusion is carefully bounded: it assesses a possible relationship with the broader Cl0p activity involving CVE-2026-12569, while stating that "the available leak-site information alone cannot establish the initial-access vector used against each listed organization", and that it had no forensic access to any affected environment (Foresiet, 2026-08-10). Foresiet's batch is an earlier, masked one; whether the 12 August named batch is the same set unmasked is not stated by any source read this run, and is not asserted here.

What is independently confirmed is the underlying vulnerability's status. CVE-2026-12569, the unauthenticated deserialization remote-code-execution flaw in PTC Windchill PDMLink and FlexPLM, has been in the CISA Known Exploited Vulnerabilities catalog since 2026-06-25 and carries "Known" in its ransomware-campaign-use field, checked directly against catalog version 2026.08.11 (CISA KEV catalog, 2026-08-11). Foresiet also restates the post-exploitation behaviour PTC itself documented: web shells planted under the Windchill login directory, which provide persistent access and command execution after the initial exploitation and which survive patching unless separately found and removed (Foresiet, 2026-08-10).

Yesterday's entry recorded that no organisation named in Cl0p's batch had confirmed a compromise and that leak-site information alone could not establish an access route for any listed victim. Two of them have now spoken, and a second security vendor has published the first post-exploitation detail for the campaign.

Philips, the Netherlands-headquartered health-technology group, describes the incident as an attempted cyberattack on a specific company server containing internal data, says it has since been brought under control, and states it has no impact on customer environments (NL Times, 2026-08-13). Shell told BleepingComputer it is aware of a potential incident and is working with its security teams and relevant experts to investigate (BleepingComputer, 2026-08-14). Neither statement confirms the volumes Cl0p advertises: the group claims 89 GB from Shell and 13.5 GB from Philips, figures that reach the reporting through a leak-site monitoring platform which cautions they come directly from the attackers and are not independently verified (NL Times, 2026-08-13). BleepingComputer counts Shell among 43 new victims Cl0p listed, likely targeted through internet-exposed PTC Windchill and FlexPLM instances via CVE-2026-12569, and reports General Electric named in the same batch with no comment yet from GE, Philips or PTC to that outlet (BleepingComputer, 2026-08-14).

The genuinely new defender-facing detail is the tradecraft. BleepingComputer reports the campaign confirmed independently by the Ransomware Information Sharing and Analysis Centre and by ReliaQuest, which says the actors have been deploying JSP webshells that let them steal sensitive data from victims' compromised PLM platforms (BleepingComputer, 2026-08-14). Until now this campaign was visible only as an exploited CVE at one end and a leak-site listing at the other; a webshell on the application server is the middle of the chain, and it is a durable artefact that outlives the patch. The same report notes PTC warned customers of heightened threat activity on 26 June and that CISA subsequently confirmed active exploitation and added the flaw to its Known Exploited Vulnerabilities catalog.

Triage: PLM platforms legitimately serve large volumes of engineering drawings and CAD content, so bulk document retrieval alone is weak signal. The discriminators are the requester and the path: retrieval driven by requests to a JSP endpoint absent from the vendor's shipped file manifest, and document access that does not correspond to any authenticated product-lifecycle user session.

The campaign's post-exploitation tooling now has a published mechanism, and it is not a generic web shell. ReliaQuest's threat research team released a reverse-engineering analysis on 2026-08-18 of the implant deployed after exploitation of CVE-2026-12569 in PTC Windchill, stating that "This activity was highly likely conducted by the Clop extortion group" (ReliaQuest, 2026-08-18). The prior entry recorded only that JSP web shells were being deployed; what follows is the mechanism, which changes what a defender can look for.

Background. Cl0p's pattern is well documented over several years and is the reason a single flaw in a data-holding enterprise platform reliably becomes a mass-extortion wave rather than an isolated intrusion. ReliaQuest places this implant in a lineage: the group deployed the custom web shell DEWMODE after exploiting CVE-2021-27101, and LEMURLOOT after exploiting CVE-2023-34362 (ReliaQuest, 2026-08-18). BleepingComputer's account of the group's history adds the platform list those campaigns ran through (Accellion FTA, GoAnywhere MFT, SolarWinds Serv-U FTP, Cleo and MOVEit Transfer, the last of which affected more than 2,770 organisations) along with an Oracle E-Business Suite zero-day campaign from early August 2025 (BleepingComputer, 2026-08-17). Each followed the same order: pick software that stores other people's sensitive data, exploit it at scale immediately after disclosure, deploy a purpose-built shell, then extort from the stolen data rather than from encryption.

What the implant does

The single most consequential command is a credential dump. ReliaQuest states that "A single \"S\" command to the web shell returns Windchill's directory-management and administrative credentials in plaintext" (ReliaQuest, 2026-08-18), implemented by an internal function the analysis calls gs in three steps: read Windchill's ieStructProperties.txt configuration file, decrypt the LDAP manager password from the application keystore, then iterate every stored local property decrypting the remaining encrypted values, administrative account credentials, object-storage credentials and all site administrator keys. Because LDAP credentials in most estates govern directory authentication for Active Directory, mail, VPN and whatever else federates against it, ReliaQuest's reading is that this turns one application compromise into an enterprise-wide credential compromise. A separate command exfiltrates the result.

Discovery is equally application-aware. A function fl, backed by a class the analysis names Flst1, queries Windchill's database for vault stream identifiers, filenames, storage paths and file sizes, writing the result to a file named flst.txt, a ready-made index of the repository from which the operator picks what to steal. The helper that opens that database connection uses Windchill's own internal Java classes, and this is the detection problem rather than a footnote: the implant connects through the application's MethodContext and WTConnection classes, so "its queries run under the application’s existing database identity rather than through a separately configured attacker account" (ReliaQuest, 2026-08-18). Database telemetry attributes the theft to the application's normal service account.

The third component is what makes the shell open-ended. A custom Java class loader the analysis calls Cldr takes attacker-supplied code as a Base64-encoded ZIP: "It accepts a Base64-encoded ZIP file containing compiled Java bytecode, loads it directly into memory, and executes it" (ReliaQuest, 2026-08-18). Nothing is written to disk, and the capability set is therefore not fixed at deployment; ReliaQuest notes the same channel could carry propagation tooling or file-encrypting payloads, which is a stated possibility rather than observed activity and is carried here as such.

Why ordinary monitoring misses it

Commands travel in a custom HTTP request header, X-windchill-req, rather than in a URL or a request body, and responses are GZIP-compressed so the returned data looks like ordinary compressed web content. ReliaQuest is explicit about what that costs a defender: controls inspecting only URL paths or body parameters see no command traffic at all, and controls that log headers without decompressing responses "will capture the instructions but miss the data being returned". Its conclusion is a three-part requirement, "Identifying this activity requires header logging that captures non-standard values, response decompression, and TLS inspection; without all three, coverage against this web shell's traffic is partial at best" (ReliaQuest, 2026-08-18). The analysis contrasts this with China Chopper, which it offers as the reusable-shell baseline: widely available, application-agnostic, and carrying the known patterns signature-based controls are built around. This implant carries none of them, because it behaves like the application.

Hunting and response

The hunt has three independent footholds, and the file-system one is the cheapest. ReliaQuest's own guidance is to "Review the windchill/codebase/login directory and other Windchill codebase paths on all Windchill servers for unexpected JavaServer Pages (JSP) files that could be web shells", prioritising recent modification timestamps, unfamiliar filenames, or content referencing the X-windchill-req header, MethodContext, WTConnection or WTKeyStoreUtil (ReliaQuest, 2026-08-18). In web-tier telemetry, the signal is requests to Windchill carrying a non-standard request header at all; the header name is the artifact, and an estate that logs only method, path and status will not have recorded it. In file and database telemetry, the creation of flst.txt on a Windchill server and vault-table enumeration queries that select stream identifiers and storage paths in bulk are both discoverable, as is a large outbound transfer following shortly after.

Triage: every one of these signals has a benign twin on a healthy PLM server, which is why the sequence rather than any single event is the discriminator. Windchill queries its own vault tables constantly and always under the service identity, so identity is useless as a filter and volume nearly so; what does not happen normally is a bulk enumeration of stream identifiers, filenames and sizes landing in a text file in a codebase directory, followed by an outbound transfer, followed by authentication attempts elsewhere in the estate using the LDAP manager account. Likewise, JSP files legitimately live in Windchill's codebase, a recently modified one with an unfamiliar name that references the application's keystore utility class does not.