Cl0p-Affiliates nutzen CVE-2026-12569 in PTC Windchill und FlexPLM für unauthentifizierte Codeausführung, legen JSP-Webshells ab und exfiltrieren Konstruktionsdaten.
Unsere DFIR-Bereitschaft ist rund um die Uhr erreichbar — auch ohne bestehenden Vertrag.
+49 89 2000 7683Betroffen sind PTC Windchill PDMLink und PTC FlexPLM in allen Ständen vor Release 11.0 M030. Windchill wird typischerweise in Fertigung, Automotive und Luftfahrt eingesetzt, FlexPLM im Handel sowie in der Bekleidungs- und Konsumgüterindustrie.
PTC stellt Patches für folgende Stände bereit (Stand: eSupport-Artikel CS473270):
Wichtiger als der Versionsstand ist die Frage, ob bereits eine Webshell liegt. Die beobachtete Kampagne legt JSP-Dateien mit hexadezimalen Namen unterhalb von /Windchill/login/ ab:
# Verdächtige JSP-Dateien im Login-Verzeichnis
find /opt/ptc -path "*/Windchill/login/*" -name "*.jsp" -newermt "2026-06-01" -ls
# Artefakt der Dateisystem-Enumeration
find / -name "flst.txt" -type f 2>/dev/nullAus der Kampagne im März 2026 (CVE-2026-4681) stammen zusätzlich diese Dateinamen: GW.class, Gen.class sowie JSP-Dateien im Muster dpr_<8 Hex-Zeichen>.jsp.
Die aktuelle Kampagne kettet zwei Schwachstellen aneinander. Zuerst greift eine Informationspreisgabe im WSDL-Endpunkt von FlexPLM vor der Authentifizierung (CVSS 7.5). Die daraus gewonnenen Informationen nutzen die Angreifer gegen das Login-Servlet von Windchill. Dort führt eine unsichere Deserialisierung nicht vertrauenswürdiger Daten zu Codeausführung ohne jede Anmeldung (CVE-2026-12569, CVSS 9.8).
Danach folgt ein Muster, das Cl0p seit MOVEit, Cleo und Oracle EBS unverändert führt: JSP-Webshells mit hexadezimalen Namen unter /Windchill/login/, anschließend Enumeration des Dateisystems mit Ablage einer Ergebnisliste als flst.txt, dann Exfiltration. Erpresst wird doppelt. Parallel gehen Massenmails an hunderte Mitarbeitende der betroffenen Organisation, Betreff sinngemäß ein gemeldetes Datenleck im PDMLink-Modul, versendet über kompromittierte Fremdkonten.
Der Zielwert ist hier nicht die Verfügbarkeit, sondern das geistige Eigentum. PLM-Systeme halten Konstruktionsdaten, Stücklisten, Lieferantenkonditionen und Produktentwicklungsstände. Genau das lässt sich am wirksamsten für Erpressung nutzen.
Das eigentliche Problem ist nicht der Patch, sondern der Zeitraum davor. Cl0p war nach heutigem Kenntnisstand vier bis sechs Wochen unterwegs, bevor PTC den Patch veröffentlicht hat. Wer sein System jetzt aktualisiert und danach abhakt, hat die Lücke geschlossen und die Webshell behalten. Bei dieser Gruppe ist das kein theoretisches Restrisiko, sondern das dokumentierte Vorgehen. Patchen ohne anschließende Kompromittierungsprüfung ist bei diesem Fall die falsche Reihenfolge.
PLM wird als Nebenschauplatz behandelt und ist keiner. In den Umgebungen, die wir sehen, läuft Windchill häufig außerhalb der normalen Patch- und Monitoring-Routine. Betreut von der Konstruktion oder einem externen Dienstleister, technisch alt, mit einer Lieferantenanbindung nach außen, weil es anders nicht funktioniert. Genau diese Kombination sucht Cl0p seit Jahren. MOVEit war Filetransfer, Cleo war Filetransfer, Oracle EBS war ERP. Das Muster ist immer dasselbe: geschäftskritisch, exponiert, außerhalb der Sicherheitszuständigkeit.
Zur Erpressungsmail. Der Massenversand an hunderte Mitarbeitende ist kein Beweis für eine Kompromittierung. Cl0p verschickt breit, auch an Organisationen, bei denen die Exfiltration nicht gelungen ist. Wer eine solche Mail erhält, sollte deshalb weder in Panik verfallen noch sie ignorieren, sondern die Systeme forensisch prüfen. Die Mail ist ein Anlass, kein Befund.
Zur deutschen Lage. Der deutsche Mittelstand im Maschinen- und Anlagenbau ist hier überdurchschnittlich betroffen, weil Windchill in genau diesen Branchen stark verbreitet ist. Anders als bei MOVEit gibt es hier zudem keinen schnellen Ersatz. Das System lässt sich nicht kurzfristig abschalten, ohne die Entwicklung anzuhalten.
/Windchill/login/ durchsuchen sowie auf flst.txt, GW.class, Gen.class und dpr_*.jsp.Unsere Erkennung setzt an drei Stellen an: Ablage der Webshell, Ausführung durch den Applikationsserver und Nachlauf der Enumeration.
Die aussagekräftigste Suche. Legitime Prozesse schreiben dort keine neuen JSP-Dateien:
#event_simpleName = /.*FileWritten/i
| FileName = /\.jsp$/i
| FilePath = /Windchill\/login/i
| groupBy([ComputerName, FilePath, FileName, TargetProcessId], limit=max)#event_simpleName = /.*FileWritten/i
| FileName = /GW\.class/i or FileName = /Gen\.class/i or FileName = /dpr_.*\.jsp/iErgänzend die Dateinamen aus dem IOC-Dokument:
#event_simpleName = /.*FileWritten/i
| in(field="FileName", values=["Gen.java","GW.java","HTTPRequest.java","HTTPResponse.java","IXBCommonStreamer.java","IXBStreamer.java","MethodFeedback.java","MethodResult.java","WTContextUpdate.java"])#event_simpleName = /.*FileWritten/i
| FileName = /^flst\.txt$/iEine ausgeführte Webshell zeigt sich daran, dass der Java-Prozess des PLM-Systems eine Shell startet. Das ist im Normalbetrieb praktisch ausgeschlossen:
#event_simpleName = ProcessRollup2
| ParentBaseFileName = /^java(\.exe)?$/i
| FileName = /^(cmd\.exe|powershell\.exe|sh|bash|whoami|net\.exe)$/i
| groupBy([ComputerName, ParentBaseFileName, FileName, CommandLine], limit=max)Die neun bekannten SHA256-Hashes aus dem IOC-Dokument gehören dauerhaft in das IOC-Management, damit aus der einmaligen Suche eine bleibende Schutzmaßnahme wird. In der Falcon-Konsole unter Endpoint Security > IOC Management > Add Hashes, Plattform Windows und Linux:
F2C8EB4A4F4BB2344DC0E41C2717B7B0D22F923A1CDBBE61EBF415759F757DAD,330433BC430CB40E7BC4D17BEBABD521572AD5077F614484FEE9442EEE793477,1CB7A011880958A1A8797D720495646BA8B0601AF09352E4118FCB0E09475E95,E697AFEAF83ED975D5B5D2A6604F08E7496D99F9775F33407B0B02530516D88D,AFEDA8E680639FE58343AE7A67B92C36E44A67A6BB7DC3C1FC239DF29CF225E0,AD388F887F2EB0114AA672EC0D9EE9201916F257EB982C96EC4867727C52082C,305241D4D27B07CFDD566AA16B22CF79116EE9BC254D6D8A8032443ABA2EC985,69E41E4B68A1097143C394DE25B2E1D33A819AED0C61F3DF891485A98B5AAA07,78473ABBECDFF2BDC30BCB96B0B3EAC3BD6493E6960D11D03277509EFDA188F2Action und Severity nach eigenem Ermessen. Wo ein Block zu riskant erscheint, ist Detect Only die Alternative.
Die Detections weiter oben sind nicht abgeschrieben. Wir haben sie gebaut, in echten Umgebungen getestet und stellen sie hier offen zur Verfügung.
Wer Falcon selbst betreibt, kann das direkt übernehmen. Wer dabei Unterstützung braucht oder einen Verdacht forensisch geklärt haben will, erreicht uns rund um die Uhr.
Gezielte Prüfung Ihrer Windchill- oder FlexPLM-Umgebung auf Webshells, Persistenz und Hinweise auf Exfiltration. Ergebnis ist ein Bericht mit klarer Aussage zur Betroffenheit und konkreten Handlungsempfehlungen. Wie lange das dauert, hängt an Umgebungsgröße und Befundlage. Den Rahmen legen wir im Kick-off verbindlich fest.
Bei konkretem Verdacht, gefundenen Artefakten oder eingegangener Erpressungsmail: +49 89 2000 7683. Rund um die Uhr, auch ohne bestehenden Vertrag.
Sie betreiben Falcon NG-SIEM selbst? Die Queries oben können Sie frei übernehmen. Wenn Sie sie als gepflegtes Regelwerk in Ihre bestehende Struktur eingebunden haben wollen, inklusive Tuning gegen Fehlalarme, machen wir das.
Der Patch verhindert eine erneute Ausnutzung. Er entfernt keine Webshell, die vorher abgelegt wurde. War Ihr System vor dem 17.06.2026 aus dem Internet erreichbar, gehört eine Kompromittierungsprüfung dazu.
Nicht zwingend. Cl0p verschickt diese Mails breit, auch an Organisationen ohne erfolgreiche Exfiltration. Die Mail ist ein Anlass zur Prüfung, kein Nachweis. Antworten Sie nicht und prüfen Sie zuerst die Systeme.
PTC hat für selbst gehostete Kundeninstanzen Maßnahmen ergriffen und kontaktiert Betroffene bei zusätzlichem Handlungsbedarf direkt. Für eigenbetriebene Installationen liegt die Verantwortung vollständig bei Ihnen.
Beides sind Deserialisierungslücken in denselben Produkten, aber unterschiedliche Schwachstellen. CVE-2026-4681 wurde im März 2026 bekannt. CVE-2026-12569 wurde ab Anfang Juni 2026 von Cl0p als Zero-Day genutzt und im Juni gepatcht. Ein Patch für die eine Lücke schützt nicht vor der anderen.
Der wirksamste Sofortschritt ist, die Erreichbarkeit aus dem Internet zu beenden. Zusätzlich lässt sich der betroffene Publish-Servlet-Pfad auf Ebene des Webservers sperren. Beides ersetzt den Patch nicht, kauft aber Zeit.
Das hängt vom Fall ab: Größe der Umgebung, Anzahl betroffener Systeme, verfügbare Datenlage und vor allem die Befundlage. Die Datenerhebung selbst ist schnell, die Auswertung bestimmt die Dauer. Einen verbindlichen Rahmen nennen wir im Kick-off, sobald der Umfang klar ist.