Cl0p Til you Drop - 6 Years, 10 Campaigns, 8 Zero-Days

PART I: Operational Profile and Campaign Analysis

1. The MFT Targeting Pattern

Cl0p's defining operational characteristic is a sustained and systematic focus on internet-facing applications that hold or move valuable data. Across ten known campaigns, the group has targeted Accellion FTA, SolarWinds Serv-U, Fortra GoAnywhere MFT, PaperCut MF/NG, Progress MOVEit Transfer, SysAid ITSM, Cleo MFT (Harmony, VLTrader, LexiCom), Oracle E-Business Suite, Gladinet Centrestack/TrioFox and, most recently, PTC Windchill and FlexPLM. Managed file transfer (MFT) remains the core of the pattern. The exceptions — PaperCut (print management), SysAid (IT service management), Oracle EBS (enterprise resource planning) and Windchill/FlexPLM (product lifecycle management) — share the same architectural profile: an internet-facing application that processes, stores or transfers sensitive files.

Windchill sharpens the picture. PLM platforms hold engineering schematics, design data and other proprietary product information rather than the personal or health records most breach programs are built around. Cl0p's target selection is best understood through the value of the data an edge application holds, not just its product category.

This consistency is significant for two reasons. First, it indicates strategic specialization rather than opportunistic exploitation: the group has invested in developing or acquiring zero-day capabilities for this class of application, deploying zero-day exploits in eight of ten campaigns. Second, it defines a bounded, defensible attack surface. Organizations that operate these platforms can identify themselves as potential targets and implement category-specific protections — a defensive advantage that is uncommon against most ransomware groups.

2. Exploitation Timeline

The chronological record of Cl0p campaigns reveals a distinctive operational tempo: extended dormancy periods punctuated by concentrated bursts of activity.

The group's longest dormancy — approximately 14 months between the SolarWinds Serv-U exploitation in late 2021 and the Fortra GoAnywhere campaign in January 2023 — was followed by its most active phase: four campaigns across four separate technologies in ten months, three of them (GoAnywhere, PaperCut and MOVEit) in the first five months of 2023. This burst-and-pause cadence suggests a development cycle in which the group acquires or develops exploits, executes campaigns in rapid succession, and then withdraws to prepare for the next cycle. A second long pause of roughly 12 months followed SysAid before Cleo in October 2024.

The first edition of this report used 10- to 14-month intervals as a rough forecasting baseline and noted, as of mid-2026, that the next cycle might be approaching. It arrived sooner than that baseline implied: Windchill exploitation began in early June 2026, about seven months after Centrestack. Taken together, Oracle EBS, Centrestack and Windchill represent three campaigns in roughly ten months — a burst comparable to 2023.

FORECASTING IMPLICATION: Long dormancy periods remain characteristic of Cl0p, but they are not a safe planning assumption. The recent cycle has compressed. Defenders should treat the period immediately after a campaign as a preparation window for the next one, not a quiet period.

3. Seasonal and holiday clustering

When campaigns are mapped by calendar quarter, Q4 is the dominant operational window. Five of ten confirmed campaigns were initiated during October through December — as many as all other quarters combined. This clustering is operationally meaningful: Q4 coincides with major holidays in the United States and Europe, periods when security operations centers are typically operating at reduced capacity and organizational response times are extended.

The underlying pattern is holiday timing, not only the calendar quarter. The Centrestack campaign's initial compromises occurred on Thanksgiving Day 2025 (27 November), and MOVEit exploitation in 2023 coincided with the US Memorial Day weekend. The inverse also appears to hold: following Centrestack, attacker infrastructure hosting a test Centrestack instance went offline around 7 January — Orthodox Christmas — when analyses of leaked ransomware group chats show activity dropping sharply. Cl0p appears to attack during defenders' holidays and pause during its own.

PLANNING INDICATOR: Treat Q4 as a high-confidence risk window, and extend heightened monitoring to US and European holiday weekends throughout the year.

4. Pre-Attack Reconnaissance

One of the most strategically significant findings in this analysis is the extent to which Cl0p conducts advance reconnaissance against eventual targets. This behavior has been confirmed in at least two campaigns and is assessed as likely present but undetected in others.

4.1 MOVEit: Two Years of Pre-Attack Scanning

Following the MOVEit exploitation in May 2023, Kroll published research documenting reconnaissance activity against MOVEit infrastructure extending back approximately two years. Kroll was able to do this because it held a data source with unusually long retention. IP address 45.129.137[.]232 conducted automated probing of the MOVEit moveitisapi.dll endpoint in July 2021. A second IP, 92.118.36[.]233, performed similar scanning in April 2022. Both addresses were subsequently linked to active Cl0p operations.

Critically, the 45.129 address was simultaneously involved in the SolarWinds Serv-U campaign in 2021. Cl0p was conducting offensive operations against one target while actively preparing its next campaign, using overlapping infrastructure for both. The 92.118 subnet showed the same dual use: it participated in the Fortra GoAnywhere attacks in February 2023, having conducted MOVEit reconnaissance ten months earlier.

Implication: Had defenders searched their MFT access logs for the indicators published after the GoAnywhere campaign (February 2023), they could have found MOVEit scanning from April 2022 — roughly three months before MOVEit was exploited.

4.2 Oracle EBS: Recon-to-Extortion Timeline

This sequence — probing, dormancy through patch release, exploitation from alternate infrastructure, and victim notification via extortion email — represents a mature operational workflow. The gap between successful exploitation in August and victim awareness in late September underscores the detection deficit many organizations face with edge-device compromises. Google was unable to determine whether the pre- and post-patch activity was related.

4.3 Hunting beyond your own stack

The MOVEit example carries a lesson that is easy to miss. An organization that did not run Serv-U, searching its logs for the 45.129 address in 2021, would have found that IP probing a MOVEit endpoint instead. Relevance does not depend on running the product under current attack. When a new set of Cl0p indicators is published — most recently for Windchill — every organization should search its WAF, proxy and firewall logs for them, as far back as retention allows, and ask what those addresses were hitting: which endpoints, which URIs, and how often. The answers can reveal preparation for a future campaign against a different product.

5. Infrastructure Analysis

To quantify Cl0p's infrastructure practices, all publicly reported indicators of compromise were mapped to their associated Autonomous System Numbers and correlated across campaigns. The resulting dataset encompasses 79 unique ASNs. MOVEit accounts for by far the largest publicly reported infrastructure footprint, followed by GoAnywhere; Windchill has a sizeable footprint for a recent campaign, while Cleo, Oracle EBS and SolarWinds are smaller. Infrastructure is distributed globally — Romania, Hong Kong and Latvia all appear — but a substantial share is hosted in the United States.

5.1 Hosting provider preferences

Hostzealot, a Bulgarian-based hosting provider that operates under country-specific ASN names (HZ-US, HZ-BG), is the most frequently observed provider across Cl0p campaigns. It has been associated with infrastructure in the Accellion, GoAnywhere, MOVEit, Cleo MFT and Windchill campaigns — five of ten total.

Providers reused across three or more campaigns include Colocrossing, Datacampus, Datahome, Ghostnet and OVH. Some of these — OVH in particular — are large, widely used providers whose presence is partly attributable to market prevalence. Others, such as Datacampus and Datahome, are more distinctive signals.

5.2 Diversification Assessment

The central finding of the infrastructure analysis is that Cl0p practices strong operational security through infrastructure diversification. Approximately two-thirds — 53 of 79 — of observed ASNs were used in only a single campaign. Standing up new hosting accounts and servers for each campaign takes effort, and Cl0p has become very good at it. IOC-based detection anchored exclusively to historical infrastructure will therefore fail to detect most new campaign activity.

However, the one-third reuse rate (26 of 79 ASNs) remains a non-trivial detection surface, particularly when combined with behavioral and temporal signals. A rolling blocklist of ASNs observed in Cl0p operations within the preceding 180 days is a pragmatic, data-backed defensive layer — imperfect but meaningful.

5.3 Long-lived IP reuse

Diversification at the ASN level does not mean every burned address is retired. The IP address 79.141.160[.]78, hosted by HZ Hosting (a Hostzealot network), appeared in the GoAnywhere and MOVEit campaigns in 2023 and appeared again in the Windchill campaign more than three years later. Cl0p appears to keep using infrastructure that works.

This runs against common practice. The “pyramid of pain” treats IP addresses as the cheapest indicators for an adversary to change, and many programs age them out of threat intelligence platforms and SIEM watchlists within weeks or months. For a high-impact actor such as Cl0p, that practice discards a useful signal.

RECOMMENDATION: Separate blocking windows from retention. Block on a rolling 180-day window of Cl0p-associated infrastructure, but retain every published Cl0p indicator for watchlisting and retro-hunting indefinitely, or for at least as long as log retention allows.

5.4 OFAC Sanctions Intersection

The ASN associated with certain reconnaissance infrastructure (AS215929, Data Campus) is numerically proximate to AS215829, registered to Smart Digital Ideas DOO. This entity was identified as part of the AEZA hosting group and designated by the U.S. Treasury's Office of Foreign Assets Control in November 2025. More broadly, several hosting providers in Cl0p's infrastructure have ownership links to sanctioned entities. The intersection of Cl0p infrastructure with OFAC-sanctioned entities creates compliance considerations for organizations engaged in incident response, ransom negotiation or infrastructure procurement involving these networks, and makes OFAC listings a practical starting point for watchlists (see 11.4).

6. Monetization and the notification gap

Cl0p's recent campaigns are data-theft operations. In the Oracle EBS campaign, the group exfiltrated data without encrypting endpoints, then contacted victims weeks later. The 29 September 2025 extortion emails claimed that the recipient's E-Business Suite had been breached and directed victims to contact addresses at pubstorm[.]com and pubstorm[.]net. In the Windchill campaign, public reporting describes extortion emails sent from compromised accounts to hundreds of users within each victim organization. Victims were first listed on Cl0p's leak site with partial names, then, from 12 August 2026, with full names; more than 40 organizations had been named by mid-August.

The consequence for defenders is a consistent notification gap. Windchill was patched on 17 June 2026, but extortion emails did not begin arriving until July. With Oracle EBS, the gap between confirmed exploitation in August and extortion on 29 September was several weeks. Many victims learn of a compromise only when Cl0p's email arrives, and must then reconstruct the intrusion from whatever logs remain.

The model also does not scale easily. After MOVEit, Cl0p publicly acknowledged it could not respond to every victim who contacted it. The group appears to prefer a slower negotiation pipeline to expanding its membership — consistent with a small, closed operation.

IMPLICATION: An absence of alerts after a critical disclosure is not evidence of safety. Assume a lag of weeks to months between compromise and extortion, and preserve application and web server logs on affected systems before retention ages them out.

7. Behavioral profile: operational discipline

Cl0p's operational behavior diverges markedly from the broader ransomware ecosystem. The group maintains no known public communication channels, does not engage in forum-based self-promotion, and has not been observed participating in inter-group disputes. It has also never rebranded: samples referencing Cl0p first appeared in late 2019 or early 2020, and the group has used the same brand since — unusual for a ransomware operation of this age.

That restraint has been tested. After the Oracle EBS campaign, members of the Scattered Spider / ShinyHunters collective publicly disparaged Cl0p on Telegram and posted an Oracle EBS exploit in their channel; Oracle later listed that exploit among its indicators of compromise for the CVE. Cl0p offered no public response. In September 2026, Cl0p's data leak site began displaying messages attributed to ShinyHunters, who claimed to have compromised the site and threatened to extort Cl0p; the site's .onion address changed shortly afterward. How Cl0p responds, and whether the incident affects its operations, is worth monitoring.

Restraint extends to campaign tempo. Cl0p has maintained dormancy periods of 12 months or more — a level of patience that is exceedingly rare among financially motivated actors — although the most recent cycle has been faster. The combination of zero-day capability, targeting discipline, infrastructure diversification and communication restraint produces a profile that more closely resembles a state-sponsored operation than a conventional cybercriminal enterprise, though all available evidence indicates financially motivated operations.

Ten campaigns, six years, one class of target. The consistency is the opening: an adversary this repeatable can be planned against.

PART II: Defensive Analysis and Countermeasures

The exploit varies. The architectural weakness does not.

8. Architectural vulnerability analysis

The persistent success of Cl0p's campaigns is enabled by a recurring architectural flaw common to most managed file transfer deployments: the internet-facing web application coexists with encryption key material and file storage within a single trust boundary. When the web application is compromised — regardless of the specific exploit used — the attacker inherits the application's own ability to decrypt stored data.

The MOVEit compromise illustrates this clearly. The attack chain progressed from SQL injection to web shell deployment (LEMURLOOT), after which the web shell invoked MOVEit's native GetBaseKeyProvider() function to decrypt files using the application's own key management. AES-256 encryption at rest, the primary data protection control, was functionally irrelevant because the encryption and decryption capability resided on the component that was compromised. That control protects against physical disk theft — a threat model that bears no relationship to Cl0p's operations. When a vendor offers encryption at rest as reassurance, it does not address this attack.

This is not a vulnerability in any single product. It is a design pattern replicated across MFT and similar edge data platforms. Cl0p has exploited it using SQL injection, deserialization attacks, configuration file access and other techniques. The Windchill campaign followed the same shape: an unauthenticated deserialization flaw led to JSP web shells and direct theft of engineering and design data from the application itself.

9. WAF default-deny: application-layer access control

Organizations routinely implement default-deny at the network layer by closing all ports except those explicitly required. At the HTTP layer, by contrast, most organizations let the WAF apply its default rules and allow everything else — which is why so many arbitrary URIs on these devices return a 200 response. The same default-deny principle can and should be applied to high-risk MFT devices.

A typical managed file transfer application exposes approximately 15 legitimate URI paths. External users require access to the login page. Partner organizations may need specific API endpoints for file transfers, and these can be restricted to known IP ranges. All remaining paths — including those historically exploited by Cl0p — can be blocked at the web application firewall.

# ALLOW only these paths:

ALLOW  GET   /MFT/Login

ALLOW  POST  /MFT/Login

ALLOW  POST  /api/v1/transfers/* # only from partner IP ranges

ALLOW  POST  /api/v1/uploads/*   # only from partner IP ranges

# BLOCK everything else:

DENY   *     /moveitisapi/*

DENY   *     /guestaccess.aspx

DENY   *     /human2.aspx

DENY   *     /*                  # default deny

# LOG + ALERT on every blocked request = high-fidelity recon detection

 APPLIED TO MOVEIT CVE-2023-34362: The SQL injection targeted /moveitisapi/moveitisapi.dll — blocked at the WAF. The LEMURLOOT web shell was planted as /human2.aspx — unreachable. All reconnaissance probes would generate 403 responses, producing a high-fidelity detection signal.

This approach yields a dual benefit. Offensively, it renders current and future zero-day exploits ineffective unless they target one of the small number of allowlisted paths. Defensively, every blocked request to a non-allowlisted path becomes a high-confidence indicator of reconnaissance or exploitation activity — a signal largely absent from default WAF configurations.

Allowlisting is not a complete answer. The Windchill intrusions placed web shells under the /Windchill/login/ path and exploited a flaw in the login servlet — a path that would normally be allowlisted. Public reporting indicates, however, that attackers chained that flaw with a pre-authentication information disclosure in the FlexPLM WSDL endpoint to reach unauthenticated code execution. Restricting that endpoint to known partners would likely have broken the chain, and any external request to it would have raised an alert. Allowlisting shrinks the exploitable surface and turns what remains into a well-defined set of paths to monitor closely.

10. The zero-day protocol: retro-hunt first

When the next MFT zero-day is disclosed, do not limit the response to patching. The first action after patch deployment should be retroactive log analysis for evidence of pre-exploitation reconnaissance.

Cl0p has demonstrated a consistent pattern of scanning target infrastructure weeks to years before deploying exploits. A newly disclosed vulnerability in an MFT or comparable edge data platform should trigger immediate retro-hunting for anomalous URI patterns targeting the affected application, traffic from ASNs historically associated with Cl0p, and probe attempts from any IP that has appeared in a Cl0p campaign. Log review should extend as far back as retention allows. Patching addresses the vulnerability; retro-hunting determines whether it was already exploited.

The trigger should be broader than disclosures affecting your own products. Every new release of Cl0p indicators — whether or not you run the targeted software — should prompt the same search, because the infrastructure attacking today's target may already be probing tomorrow's (see 4.3). Any critical vulnerability in an MFT product also warrants immediate priority on its own: Cl0p has a history of fast n-day exploitation as well as zero-days.

11. Operational playbook: immediate priorities

11.1 Asset identification

Enumerate all internet-facing MFT applications and other edge platforms holding sensitive or proprietary data — including PLM, ERP, HR and applicant systems, and shadow IT. Organizations of 1,500 employees or more should assume at least one file transfer service exists. Cover both SaaS and on-premises deployments, and classify each by the value of the data it holds, not only personal data.

11.2 Retention: logs and data

Confirm access logs for all identified assets are retained a minimum of 12 months, 24 preferred; with reconnaissance up to two years ahead of exploitation, short windows eliminate effective retro-hunting. Separately, audit the data stored on each device. Many file transfer platforms are meant to hold files only briefly, yet stale data from years earlier often remains. Purge what is not needed; data that is not there cannot be stolen.

11.3 Traffic baselining

Establish baseline URI access patterns per device so novel paths generate alerts. Baseline outbound transfer volumes hourly and daily, and alert on anomalous egress — particularly during Q4 and holiday weekends. Rather than attempting this across the whole estate, start with critical MFT devices and extend to other critical edge devices such as VPNs.

11.4 Watchlist updates

Seed watchlists in order of confidence: OFAC-sanctioned ASNs, then known bulletproof hosting providers, then ASNs recurring in Cl0p campaigns. Block on a rolling 180-day basis; retain all published Cl0p IPs for hunting indefinitely (see 5.3).

11.5 Graduated early warning

Score scanning activity against high-risk assets by accumulating signals rather than alerting on any one: a new URI hitting an MFT; the source ASN has Cl0p history; the source returns repeatedly; the source sits in the same /24 as recently reported Cl0p exploitation. Each additional signal raises priority, giving an early warning before an exploit is public.

11.6 Treat edge devices as sensors

Internet-facing MFT devices are continuously probed. With a WAF allowlist and URI baseline in place, they effectively become production honeypots: every unexpected request is intelligence about who is scanning for what.

12. Case study: Gladinet Centrestack, 2025–26

The Centrestack campaign illustrates, in close to real time, the operational patterns documented in Part I.

12.1 Initial detection

On 18 December 2025 the Curated Intelligence community published an advisory reporting active Cl0p targeting of Centrestack file servers, noting that port scan data showed at least 200 exposed instances. Team Cymru's review of all traffic reaching Centrestack devices globally corroborated this reporting: a significant surge in traffic, predominantly from proxy infrastructure, began on 27 November 2025 — Thanksgiving Day in the United States.

12.2 Exploitation sequence

Huntress subsequently published an analysis confirming that initial compromises occurred on 27 November. The exploitation targeted the web.config file, with attack traffic originating from IP address 147.124[.]x.x. The logs show failed attempts — which Huntress associated with the earlier CVE-2025-14611 — before a new exploit succeeded, indicating iterative refinement by the attacker. Gladinet released a critical out-of-band security update on Saturday 29 November, two days after the initial compromises. An out-of-band critical patch released on a holiday weekend is itself a strong signal that exploitation is under way.

12.3 Post-exploitation infrastructure

From 5 to 8 January 2026, the same 147.124 address that Huntress observed conducting the exploitation hosted a Centrestack login page. The most plausible explanation is exploit development or testing — standing up the target application to refine attack techniques. The instance went offline around 7 January, Orthodox Christmas, consistent with the holiday downtime seen across Russian-speaking ransomware groups.

PATTERN CONFIRMED: Q4 initiation on a US holiday, a file-server target, a two-day patch gap, and post-campaign exploit testing — the Centrestack campaign reproduced every behavioral marker documented in Part I.

13. Case study: PTC Windchill / FlexPLM, 2026

13.1 Timeline

13.2 Exploitation and targeting

CVE-2026-12569 is an unauthenticated deserialization vulnerability in PTC Windchill PDMLink and FlexPLM. In observed intrusions, attackers chained it with a pre-authentication information disclosure in the FlexPLM WSDL endpoint, deployed JSP web shells under /Windchill/login/, enumerated the file system and staged engineering and design data for theft. Confirmed victim sectors include manufacturing, automotive, aerospace and retail/apparel. It is the first Windchill vulnerability known to have been exploited in the wild.

The data targeted matters. PLM systems hold product designs and engineering schematics — intellectual property that many organizations do not include when they inventory high-risk data. This is intelligent targeting: Cl0p selected a platform whose data is highly valuable to its owners and is often protected less rigorously than regulated personal data.

13.3 Infrastructure

Windchill infrastructure again included Hostzealot, the fifth campaign in which the provider appears, and the IP 79.141.160[.]78, previously seen in GoAnywhere and MOVEit in 2023 (see 5.3). Organizations that had retained 2023 Cl0p indicators could have matched Windchill activity to known Cl0p infrastructure immediately.

PATTERN CONFIRMED — AND EXTENDED: A zero-day in an internet-facing data platform, reused infrastructure, data theft without encryption and a delay of weeks before extortion all match the established playbook. What is new is the target class, a shorter gap since the previous campaign, and proof that a single IP remained useful to the group for more than three years.

14. Conclusions and strategic recommendations

Cl0p has provided the defender community with an unusually rich operational dataset. Over six years the group has demonstrated consistent targeting preferences, predictable seasonal and holiday patterns, identifiable infrastructure reuse, and repeated exploitation of the same fundamental architectural weakness. This consistency is a strategic advantage for defenders — provided the intelligence is operationalized. Much of it also depends on indicators published by incident responders and researchers; organizations able to share Cl0p indicators should do so, because each release improves every defender's ability to hunt.

• Elevate MFT and edge data security to a distinct program
• MFT devices and other edge platforms holding high-value data — including PLM and ERP — warrant dedicated controls, monitoring and IR procedures. Any critical vulnerability in them should trigger the zero-day protocol regardless of attribution.
• Implement seasonal and holiday monitoring
• Treat Q4 as a high-risk period: tighten outbound transfer thresholds, increase log review frequency, and staff security operations accordingly from October through January. Apply the same posture to holiday weekends year-round.
• Deploy WAF allowlisting on MFT devices
• Default-deny at the HTTP layer is the single highest-impact measure available. It mitigates current exploits, blunts future zero-days, and generates high-fidelity detection signals.
• Institutionalize retro-hunting
• Every new MFT disclosure — and every new release of Cl0p indicators, whether or not you run the affected product — should trigger retroactive log analysis as far back as retention allows. The cost of retro-hunting is low; the cost of missing a pre-existing compromise is not.
• Keep Cl0p indicators for years, not weeks
• Block on a rolling 180-day window, but retain every published Cl0p IP and ASN for watchlisting and hunting. One IP returned after more than three years.
• Address the architectural root cause

Long-term risk reduction requires separating internet-facing web components from decryption key material and file storage. Until that separation is achieved, encryption-at-rest controls on MFT devices provide a false sense of security against application-layer attacks.

Cl0p operates with the discipline of a business, executing a visible and repeatable playbook over a multi-year time horizon. The corollary is that a visible, repeatable playbook is also a defendable one — if the intelligence it provides is translated into operational controls.

WORK THE RAW DATA

Every pivot in this report is reproducible in Recon.

Pure Signal™ Recon gives analysts raw NetFlow and PDNS with no vendor interpretation between the observation and the query. Request a working session with our research team.

Talk to an expert

team-cymru.com · support@cymru.com

SOURCES

This report is based on research presented at FIRSTCON Denver 2026 and the Team Cymru webinar “Turning Cl0p's Operational Playbook Into Detection Opportunities.” Author: Eli Woodward, Team Cymru Threat Research. First published on the Team Cymru blog, 12 August 2026; updated October 2026. With thanks to Ransom-ISAC, Huntress, Curated Intelligence, Kroll and Mandiant, whose published research and indicators made this analysis possible. Interactive infrastructure visualization: eliwoodward.github.io/clop-campaigns

‍