Clop's Windchill implant borrows the app's own keystore, so app logs are the only witness

ReliaQuest's threat research team reports that Clop is exploiting CVE-2026-12569 on unpatched, internet-facing PTC Windchill and FlexPLM servers and dropping a custom JSP web shell into the Windchill codebase ^[1][2][3]. What matters is not the entry but what follows: the implant works through the application's own internal APIs, keystore and database connections, so the evidence that would convict it sits in application-layer telemetry, not in the network layer ^[5][9][10].

The control channel is a custom HTTP header, X-windchill-req, with parameters in X-windchill-prm ^[4]. According to ReliaQuest the implant exposes five single-character commands ^[21]. S reads configuration files and calls WTKeyStoreUtil.decryptProperty() to decrypt stored secrets, including LDAP administrator credentials ^[5]. L queries Windchill tables including ApplicationData, FVITEM, FVMOUNT and MasteredOnReplicaItem, then writes file IDs, names, paths and sizes to flst.txt ^[6]. G or D read the selected files, and the server GZIP-compresses the response on its way out ^[7]. J takes a Base64-encoded ZIP and loads additional Java bytecode directly into the Windchill process memory, with nothing written to disk ^[8].

Read that sequence as an inventory problem rather than a malware problem. The web shell runs inside the Windchill Java process, and its database queries use existing Windchill connection IDs rather than a new attacker account ^[9]. Decryption happens with the legitimate keystore and in-app calls ^[10]. The user-facing Windchill screen can keep running with no visible change, and no user action is required at any point ^[11]. Every privilege the implant needs is a privilege the service ID already had ^[9][10].

That is also why the detection story is uncomfortable. ReliaQuest notes that queries issued under the Windchill service ID are hard to distinguish from normal operations ^[13]. The signals that do stand out are all inside the estate rather than at its edge: unfamiliar JSP files with fresh creation or modification times, JSP source containing references to MethodContext, WTConnection and WTKeyStoreUtil, and the creation, reading and deletion of flst.txt ^[12]. The pattern to alert on is flst.txt appearing, followed immediately by file reads and large GZIP responses ^[12][7]. The campaign also assumes your WAF or proxy does not block non-standard headers or inspect abnormal response content, which makes header filtering the cheapest control available and a good test of whether your proxy is doing anything at all ^[14][15].

The stated outcome is plaintext secrets for LDAP administrators, Windchill administrators and object storage, an index of the vault covering product designs and intellectual property, and exfiltration of selected files ^[16]. ReliaQuest's inference is that those credentials extend the breach into Active Directory, email, VPN and databases ^[17]. Its hypothesis, clearly labelled as such, is that organisations refusing to pay may then see ransomware or longer-term persistence modules ^[18]. Email plays no part in initial intrusion; extortion mail carrying Clop contact details arrives afterwards, sent to employees ^[19].

Three things to check this week. Whether the vendor patch is applied and external access to Windchill and FlexPLM is restricted ^[15]. Whether you have codebase change monitoring or a JSP allowlist that would refuse the file at write time ^[15]. And whether your incident plan can actually revoke every secret in the Windchill keystore and terminate existing sessions, because that is the containment step ReliaQuest calls for if a breach is suspected, and it is the one nobody has rehearsed ^[15].