name: JSP Web Shell File Creation in PTC Windchill Codebase Analytic
signatureid: EDR-NIX28-RUN
category: 'Persistence'
threatname: 'Server Software Component: Web Shell'
functionality: 'Endpoint Management Systems'
description: |
Detects the creation of JSP files within the PTC Windchill codebase directory tree, which is the
single point in the CVE-2026-12569 exploitation chain where either observed web shell family
touches disk. Following successful exploitation of the deserialization flaw in the Windchill
login servlet, operators write a JSP web shell into the Windchill codebase login directory using
hexadecimal filenames. Two conventions have been documented: sixteen hexadecimal characters for
Clop's custom Windchill-aware implant, and six hexadecimal characters for a simpler generic
command shell, with a third dpr_ prefixed convention of unconfirmed family association. This
rule also detects creation of flst.txt, the file vault enumeration artifact written by the
custom implant's L command, which is both a compromise indicator and a high-value forensic
scoping artifact because it records exactly what the operator inventoried.
This is the highest-value endpoint detection available for this campaign. Clop's custom implant
executes every one of its built-in commands in-process and spawns no child processes, meaning
process creation telemetry is silent against it by design. File creation is the only endpoint
signal it produces.
Sysmon For Linux EVID 11 (file create) is the required telemetry source.
reference:
- https://reliaquest.com/blog/clop-returns-with-custom-implant-in-mass-extortion-campaign/
- https://ransom-isac.org/blog/clop-windchill-flexplm-exploitation/
- https://www.bleepingcomputer.com/news/security/clop-created-custom-web-shell-for-windchill-data-theft-attacks/
- https://github.com/fluffybunnies-h4x/FT-Linux-Sysmon-Config
- https://attack.mitre.org/techniques/T1505/003/
- https://attack.mitre.org/techniques/T1190/
labels:
- attack.persistence
- attack.t1505
- attack.t1505.003
- attack.initial_access
- attack.t1190
- attack.collection
- attack.t1083
- Clop
- Cl0p
- FIN11
- CVE_2026_12569
- Windchill
- FlexPLM
- PLM
- Web_Shell
- Mass_Exploitation
logsource:
category: file_modification
product: linux
detection:
selection_windchill_codebase:
FilePath|contains:
- '/Windchill/codebase/'
- '/Windchill/tomcat/instances/'
selection_jsp_write:
FilePath|endswith:
- '.jsp'
selection_login_directory:
FilePath|contains:
- '/codebase/login/'
- '/rfa/jsp/login/'
selection_enumeration_artifact:
FilePath|endswith:
- '/flst.txt'
filter_legitimate_deployment:
# Windchill patching, ant-based deployment, and PTC installer activity legitimately
# write JSP resources into the codebase. Validate these against the local install.
Image|endswith:
- '/ant'
- '/rpm'
- '/dpkg'
- '/yum'
- '/dnf'
- '/tar'
- '/unzip'
condition: ((selection_windchill_codebase and selection_jsp_write) or (selection_login_directory and selection_jsp_write) or selection_enumeration_artifact) and not filter_legitimate_deployment
criticality: Critical
verbose_info:
violation_summary:
grouping_attribute: 'accountname'
level2_attribute: 'devicehostname'
level2_metadata_attributes:
metadata_attributes:TECHNICAL DETAILS
CRITICAL TUNING WARNING -- DO NOT FILTER JAVA AS THE WRITING PROCESS:
The instinctive filter here is to exclude java from Image, on the reasoning that the
JVM legitimately handles JSP resources. That filter would disable this rule.
The web shell is written by the deserialization gadget executing INSIDE the Method
Server JVM, so the JVM is the writing process for the malicious file. Tomcat's normal
JSP compilation produces .java and .class output in the work directory, not .jsp files
in the codebase, so a running JVM has no legitimate reason to create a .jsp there.
Filter deployment and patching tooling instead, as filter_legitimate_deployment does.
Detected artifacts:
[0-9a-f]{16}.jsp Clop custom Windchill-aware implant
[0-9a-f]{6}.jsp generic JSP command shell
dpr_[0-9a-f]{8}.jsp family association unconfirmed
flst.txt file vault enumeration output from the implant's L command
Observed filenames at time of reporting (hunt the pattern, not the list):
46b158b8607a4c00.jsp 4b57d0652345d383.jsp 56c9be44a436c4a2.jsp
64652883d9de3299.jsp 7c0a0a34c9d8d53b.jsp ec6ba805a076e709.jsp
Why flst.txt matters beyond detection:
It contains vault stream IDs, filenames, storage paths, and file sizes. Recovering it
gives a direct record of what the operator inventoried, which is a far stronger scoping
input during incident response than the volume claims in an extortion email. Preserve
it before remediation.
Sysmon for Linux configuration:
A scoped file-create rule for Windchill hosts:
<RuleGroup name="Windchill JSP drop" groupRelation="or">
<FileCreate onmatch="include">
<TargetFilename condition="contains all">/Windchill/codebase/;.jsp</TargetFilename>
</FileCreate>
</RuleGroup>
Adjust the path to the local install root. Sysmon supports scoping file monitoring by
extension, which makes .jsp creation in application directories a narrow, high-signal
rule rather than a broad file-monitoring burden. Reference config:
https://github.com/fluffybunnies-h4x/FT-Linux-Sysmon-Config
On-host hunt commands:
find /opt/ptc -path '*Windchill/codebase*' -name '*.jsp' -newermt '2026-06-01'
grep -rlE 'X-windchill-req|WTKeyStoreUtil|MethodContext|WTConnection' \
/opt/ptc/*/Windchill/codebase/
find / -name 'flst.txt' 2>/dev/null
Hunt window:
Ransom-ISAC assesses zero-day exploitation began in early June 2026. Patches shipped
June 17. Extortion emails began around July 20. A web shell planted before the patch
survives the update, so patch verification alone does not close this out. Scope
searches to June 1 2026 at the latest.
Response guidance on a confirmed hit:
Assume the entire Windchill keystore is exposed. The implant's S command decrypts the
LDAP manager password and every encrypted stored property using the application's own
decryption function. Rotate the LDAP manager password, site administrator keys, and
object storage credentials, and terminate existing sessions, since rotated passwords
leave valid tokens behind.
False Positives:
- Low outside change windows. Legitimate JSP writes into the Windchill codebase occur
during PTC patching, upgrades, and customization deployment. Correlate against the
change calendar; consider suppressing during approved maintenance rather than
permanently filtering, since suppression preserves the detection afterward.
- Sites that deploy custom JSP resources as part of routine development should scope
selection_windchill_codebase to the login subdirectories only, using
selection_login_directory alone, which sharply reduces the legitimate write surface.
Policy building walkthrough can be found in this previous post: