Cl0p MFT Mass-Exploit Pattern — From Accellion to Cleo, Why Indian Enterprises Keep Ending Up Downstream

If your bank, regulator, audit firm, or ratings agency runs MOVEit, Cleo, or GoAnywhere — and most of them do — your data has been at risk in at least one of the last three years. Cl0p figured out that managed-file-transfer software is the optimal supply-chain attack target: small product teams, large customer impact, file-transfer software always sees the most sensitive data in motion.

The four mass-exploit campaigns — chronological

Accellion FTA (Dec 2020 – Feb 2021) — CVE-2021-27101 / 27102 / 27103 / 27104. Cl0p exploited an end-of-life Accellion appliance still in heavy enterprise use. Victims included Reserve Bank of New Zealand, Singtel, Jones Day, Bombardier, multiple Indian government departments. ~100 named victims publicly.

GoAnywhere MFT (Jan 2023) — CVE-2023-0669. Fortra-developed product. Cl0p exploited the admin console (typically internet-exposed for “ease of deployment”). 130+ named victims including Crown Resorts, Procter & Gamble, several Indian IT services firms.

MOVEit Transfer (May–Jul 2023) — CVE-2023-34362. The defining campaign. Progress Software’s MOVEit had a SQL injection in the MOVEit Transfer web interface that gave full DB access. Cl0p ran a 6-week mass-exploit phase before public disclosure, hitting 2,700+ tenants. Documented victims include the US Department of Energy, UK’s Ofcom, HSBC, JLR, multiple Indian banks (via vendor pipelines), and an estimated 90M+ individuals’ data exposed.

Cleo Harmony / VLTrader / LexiCom (Oct–Dec 2024) — CVE-2024-50623, CVE-2024-55956. Cleo’s three managed-file-transfer products share a vulnerable autorun mechanism. Cl0p exploited it for at least 10 weeks before Cleo issued a complete patch. ~70 named victims, less public disclosure than MOVEit but materially the same pattern.

Why MFT software is the perfect target

1. Internet-exposed by design. The whole point of an MFT system is “trade partner uploads file via web/SFTP from outside corporate network.” Internet exposure is a feature, not a bug.
2. High-sensitivity payloads. Every file in transit is high-value: payroll data, M&A diligence, customer master data, claims files, regulatory submissions. Indiscriminate exfil yields immediate ransomware leverage.
3. Smaller engineering teams than the customer’s stack. Progress, Fortra, Cleo each have product teams in the hundreds, not thousands. Compared to compromising Microsoft Exchange or Cisco IOS, MFT vendors are an asymmetric target.
4. Long patching tail. MFT appliances are operationally critical; customers delay patches because “trade partners are in the middle of a payroll run.” Mean-time-to-patch in MOVEit telemetry was 12-18 days; mass-exploit was 6 weeks.
5. Concentrated customer base. A 0-day in MOVEit hits 5,000+ enterprises in one campaign. Time-to-monetise is days, not months.

Indian downstream impact — even when you don’t run the software

The MOVEit incident’s most painful Indian lesson: organisations that did not run MOVEit themselves still leaked data because their vendors, processors, and regulators did. Confirmed downstream patterns:

• Indian PSU bank submitted a quarterly compliance file to its regulator via the regulator’s MOVEit. The regulator was breached. The PSU bank’s data was in the leak.
• Multiple Indian IT services firms had client SOW data, employee PII, and financial reporting in MOVEit instances at their multinational customers. Both vendor and end-customer ended up extorted.
• An Indian fintech audited by a Big-4 firm had its diligence data in the audit firm’s MOVEit. Audit firm hit, fintech’s startup-stage cap table on BreachForums.

The strategic implication: third-party data residency questions are no longer optional in Indian DD. Every vendor agreement should now explicitly require disclosure of file-transfer infrastructure and notification of relevant CVE exposure. This used to be a US/EU concern. It is now table-stakes diligence in Indian enterprise procurement.

Detection — vendor-agnostic patterns

If you run any MFT software, the high-fidelity hunt patterns are:

• New web-shell file in the MFT install directory (moveit/wwwroot/, cleo/harmony/) named after a typical Cl0p artifact: human2.aspx, LEMURLOOT.dll, mscan.exe, service.dll with recent mtime.
• Outbound HTTPS connections from the MFT server to TOR exit nodes or unfamiliar Russia-routed CIDRs.
• Database query patterns: SELECT * FROM users, information_schema enumeration, large SELECTs that exceed daily baseline by 10x. Most MFT products bundle a database; query log review is the win here.
• Service account privilege escalation — the MFT service account suddenly running cmd.exe or PowerShell.

If you don’t run MFT but suspect downstream exposure: subscribe to your vendor’s CVE feed, ask in writing for confirmation of patch status, and run credential rotation for any data you’ve sent through the vendor’s MFT in the last 12 months as a precaution.

The strategic shift — treat MFT as a high-criticality service tier

The MFT pattern keeps recurring because the product category is structurally vulnerable. The shift required:

1. Treat MFT product upgrades like security patches, not feature releases. 24-48 hour patching SLA, not weeks.
2. Don’t expose admin consoles to the internet. Every successful exploit started with admin-console access. Put admin behind a VPN, even for “trusted” administrators.
3. WAF in front of every MFT — generic rules catch most of these SQL injections at the edge. Cloudflare, Akamai, or self-hosted ModSecurity rules.
4. Encrypt files at rest in the MFT with keys held outside the MFT product. Even if Cl0p exfils, they get ciphertext.
5. Kill data-at-rest in MFT after delivery. Files should leave the MFT within hours, not sit there for weeks “in case the trade partner needs to re-download.” Aggressive lifecycle deletion shrinks the blast radius.
6. Substitute MFT with cloud-native alternatives where feasible — AWS Transfer Family, Azure Files SFTP, GCP Filestore. Larger blast radius if compromised, but the security teams behind them are 100× the size of Cleo’s.

FAQ

How do I know if my organisation’s data was in the MOVEit leak?

HaveIBeenPwned added MOVEit data to its dump in mid-2023. Search by employee email. For organisational exposure, ask each vendor in writing whether they ran MOVEit and whether your data was in the affected tenant.

Are GoAnywhere, MOVEit, Cleo all bad? What should we use instead?

Not “all bad” — they’re targets because they’re widely deployed. Cloud-native MFTs (AWS Transfer Family, Azure SFTP) shift more security responsibility to the hyperscaler, which is a meaningfully larger team than Progress/Fortra/Cleo. For high-sensitivity workflows, encrypted-at-source then any transport works (PGP-encrypted files over plain SFTP).

Is Cl0p still active in 2026?

Yes. Late 2024 Cleo exploitation was their last named campaign. The same group has continued individual extortion against MOVEit holdouts that didn’t pay in 2023. Treat as ongoing threat.

What does CERT-In require for MFT incident reporting?

Under the April 2022 directive, ransomware incidents are reportable to CERT-In within 6 hours. MFT-specific data exfiltration that meets the “personal data breach” definition under DPDP §8(6) triggers separate notification to the Data Protection Board within 72 hours.

Should we tell our customers if their data was in our MFT and we got breached?

Under DPDP, yes — Section 8(6) requires notification to data principals “in such manner as may be prescribed.” Under contract, almost always — most enterprise NDAs have notification clauses. Strategic answer: yes, transparency is the lower-cost option vs. discovery later.

⚖️ Legal: CERT-In ransomware reporting required within 6 hours per April 2022 directive. DPDP breach notification within 72 hours per Section 8(6). Maintain a runbook with both contact paths pre-tested.