MOVEit was the textbook case of a supply-chain attack where the attacker did not compromise the vendor — they exploited a vulnerability in the vendor’s product running on customer infrastructure. The product’s purpose (moving files between organisations) meant that every successful compromise yielded not just one organisation’s data but the data of everyone they shared files with. This post reconstructs the technical attack chain, the campaign timeline, and the durable lessons every organisation deploying internet-facing MFT, VPN, or similar shared-services infrastructure must internalise.
What happened — the SQL-injection-to-shell pipeline
MOVEit Transfer is a managed-file-transfer product used by tens of thousands of organisations to securely exchange files with external partners — payroll providers receiving employee data, hospitals exchanging patient records, banks communicating with custody partners. CVE-2023-34362 was a pre-authentication SQL injection in MOVEit’s web interface — specifically in the handling of guest-token requests — that allowed an unauthenticated attacker to inject arbitrary SQL into the backend Microsoft SQL Server. Cl0p chained the SQLi into a multi-stage exploit: first dropping a custom ASP.NET web shell named LEMURLOOT to human2.aspx in the MOVEit web root; then using LEMURLOOT to enumerate stored files, MFT user credentials, and the customer-managed encryption keys; finally exfiltrating the file contents to attacker-controlled infrastructure. The web shell was sophisticated — it included anti-detection measures (random strings in tokens, conditional execution paths), session-tracking to avoid duplicate enumeration, and self-deletion capabilities. Defenders who only checked for the obvious file would miss variants the attackers had deployed in defence-in-depth fashion.
The scale — 2,700+ organisations, 95M+ individuals, billions in damages
Emsisoft, the firm tracking the campaign in the most detail, documented over 2,700 confirmed victim organisations as of mid-2024. Notable victims by sector: Government: US Department of Energy, US Department of Health and Human Services, multiple US state governments (Oregon, Louisiana, Maine, Missouri, Illinois, Colorado, and others), the UK’s pension regulator, Canadian provinces. Education: 100+ US universities including the University of California system, City of New York Department of Education (45,000 students), and the National Student Clearinghouse (which then propagated downstream to thousands of US universities). Healthcare: Johns Hopkins University, multiple US hospital systems, pharma companies. Financial services: Aon, Marsh, several large pension funds, multiple banks. Media: BBC, Sony Interactive Entertainment. Professional services: EY, PwC, Deloitte (regional), Aon, Marsh. Estimated economic impact: IBM estimated the total damages at $12-15 billion across direct response costs, regulatory fines, class-action settlements, business interruption, and downstream impact on data subjects. The downstream-victim count is the troubling part — National Student Clearinghouse alone propagated to 900+ US colleges, each of which had its own students-as-data-subjects affected.
How Cl0p operationalised the campaign — speed, scale, and shaming
Cl0p is a Russian-speaking ransomware-as-a-service (RaaS) group historically attributed to TA505 / FIN11. Their MOVEit campaign was operationally distinctive in three ways. (1) Vulnerability hoarding. Pre-disclosure investigation by Mandiant suggested Cl0p had access to the MOVEit vulnerability for months before mass exploitation began — possibly purchased from an exploit broker, possibly developed in-house. The group waited until they had infrastructure ready to handle the data flood before triggering wide exploitation. (2) Campaign acceleration. When Cl0p triggered, they exploited approximately 600 MOVEit instances within 48 hours. The infrastructure to handle 600 simultaneous exfiltrations from disparate victims is non-trivial — multiple cloud regions, automated triage, deduplication of overlapping data sets. (3) Shaming-driven extortion. Cl0p maintained a public dark-web leak site where they posted victim names with a countdown timer; non-paying victims had data progressively published. The shame model is more effective than encryption-only ransomware because the data exists outside the victim’s control whether they pay or not — public exposure is the only lever attackers can pull, but it is sufficient. (4) Refusal of standard ransom workflow. Unlike many RaaS groups, Cl0p did not target encryption of the victim’s own systems via MOVEit. They exfiltrated data, then demanded payment to delete it. This is “extortion as a service” — operationally simpler, legally distinct from ransomware in some jurisdictions, and harder for victims to defend with backup-and-restore strategies.
Timeline — months of stealth followed by 48 hours of chaos
February-April 2023: Cl0p reportedly tests the exploit against small targets, refining the LEMURLOOT shell. 27-29 May 2023: Mass exploitation begins. Attackers deploy LEMURLOOT to hundreds of internet-facing MOVEit instances simultaneously over the US Memorial Day long weekend (a deliberate timing choice to exploit reduced defender staffing). 30-31 May: Multiple security firms (Huntress, Mandiant, Rapid7, GreyNoise) detect the exploitation pattern and begin coordinating with Progress Software. 31 May 2023: Progress publicly discloses CVE-2023-34362 with an emergency patch. CISA issues advisory. 1-7 June: Defenders rush to patch; attackers continue exploitation of remaining unpatched instances; first victims (Zellis, BBC, BA, Boots) become public. 5 June 2023: Cl0p posts public extortion notice on their leak site, gives victims until 14 June to begin negotiation. 14 June – August 2023: Cl0p progressively publishes victim names; many organisations disclose under regulatory pressure; class-action lawsuits begin filing in US federal courts. September 2023 – 2024: Long tail of disclosures as downstream-impacted organisations realise they were affected via partners. Settlement negotiations and regulatory enforcement actions continue. 2024-2025: Multiple class-action settlements totaling hundreds of millions of dollars; Progress Software faces shareholder lawsuits; Cl0p continues operations with new campaigns (GoAnywhere MFT, Accellion FTA, JetBrains TeamCity).
The deeper architectural problem — internet-exposed MFT
The MOVEit campaign exposed a category of risk that the security industry had been ignoring: managed-file-transfer products as a class are uniquely dangerous because they sit at the intersection of three high-risk properties. (1) Internet-facing. By design, MFT products must be reachable by partners outside your network. Customer-perimeter VPN-only deployments exist but are operationally cumbersome, so most deployments expose MFT to the internet directly. (2) High-trust data. The data exchanged is by definition high-value — payroll, financial records, personal information, business-critical operational data. (3) Centralised aggregation. A single MFT instance often holds files from hundreds of upstream and downstream organisations. Compromise yields not one organisation’s data but a fan-out across the entire B2B ecosystem the MFT serves. The MOVEit incident was followed by similar mass exploitations of other MFT products: Fortra GoAnywhere MFT (CVE-2023-0669, also Cl0p), Accellion FTA (2021, Cl0p), Cleo Harmony / VLTrader / LexiCom (CVE-2024-50623, late 2024). The pattern is structural — Cl0p has built an operational specialty in MFT exploitation. Other groups will follow. The strategic implication: if your organisation runs internet-facing MFT, you are running a category of infrastructure that has become a regular target for nation-state-grade exploitation campaigns. The product choice matters but the pattern is platform-agnostic.
Indicators of compromise and detection — what to look for in MOVEit and similar
For MOVEit Transfer specifically, the public IoCs included: Filenames: human2.aspx in MOVEit web root, plus variants _human2.aspx, _human.aspx, files with double-extensions like file.txt.aspx. Database changes: new accounts created with names matching pattern Health Check Service or random GUIDs; modified activesessions table entries; modified users table entries. Outbound connections: traffic to attacker-controlled IPs (Mandiant published a list; the IPs rotated frequently). Process behaviour: w3wp.exe spawning unusual child processes, particularly cmd.exe or PowerShell. Generalisable indicators for any MFT product: alert on (1) file-system changes in the application web root from outside normal deployment processes, (2) database authentication from unusual source IPs, (3) bulk-export operations to remote destinations, (4) creation of administrative accounts outside change-management processes, (5) outbound TLS connections from MFT servers to non-partner destinations. SOC teams should treat any anomaly in MFT infrastructure as high-priority — the blast radius of compromise is extreme.
Mitigations — practical steps for MFT operators
A 10-item action list for organisations running internet-exposed MFT products. (1) Patch within 24 hours of vendor advisory. MFT products are CVE-of-the-month targets; the assumption “I have time to test” is wrong. (2) Restrict internet exposure. Where possible, place MFT behind a VPN or zero-trust gateway requiring authentication before reaching the application. (3) IP allowlist partner-source addresses. Almost every MFT use case has known partner IPs; allowlist them, deny everything else. Block all consumer-ISP and data-center IPs unless explicitly required. (4) WAF in front of MFT. Cloudflare, Akamai, AWS WAF — any major WAF blocks the 90th-percentile of generic SQLi and shell-upload attempts even before patches deploy. (5) File-system integrity monitoring. Tools like OSSEC, Tripwire, AIDE, or Wazuh detect unauthorised file changes in web roots within minutes. (6) Database activity monitoring. See queries against MFT databases — bulk SELECT operations, UNION-based injection patterns, anomalous account creations. (7) Outbound-traffic monitoring. Egress filtering on MFT servers — they should communicate only with database servers, partner endpoints, and configured update services. Anything else is suspicious. (8) Account audit quarterly. Review every MFT user; revoke unused accounts; rotate service-account passwords. (9) Backup verification. Critical — but for extortion attacks like Cl0p’s, backups don’t help (data was exfiltrated, not encrypted). Add tabletop scenarios for “data is public regardless of payment.” (10) Vendor-relationship reviews. Treat MFT vendor as critical-infrastructure supplier. Demand security commitments, breach-notification SLAs, and the right to audit security controls in the contract.
India context — DPDP, sectoral overlays, and Indian victim universe
Indian impact from MOVEit was significant but underreported in international coverage. Confirmed Indian victims (or Indian operations of multinational victims) included: multiple Indian operations of EY, PwC, Deloitte; Indian subsidiaries of UK and US-headquartered firms; Indian universities exchanging student data with international partners; Indian healthcare organisations sharing data with international research collaborators. Specific Indian implications: (1) DPDP Act 2023. Indian Data Fiduciaries who used MOVEit and had Indian data subjects affected face DPDP liability for the breach, regardless of MOVEit being a third-party product. The “data processor” defence is limited under DPDP — the Data Fiduciary remains accountable. (2) Cross-border data flow. The MOVEit breaches involved data that had crossed Indian borders to international partners. Under DPDP’s prescribed-country list framework (when fully operational), such flows may be restricted; consent records become critical for defending the legitimacy of data movements. (3) Sectoral implications. RBI’s 2024 outsourcing guidelines for Indian banks specifically address third-party software risks; the MOVEit campaign is cited in industry forums as the canonical example. SEBI similarly tightened expectations for capital-markets firms’ third-party risk management. (4) CERT-In response. CERT-In issued multiple advisories during 2023; Indian organisations were required to report any MOVEit-related incidents within 6 hours under the April 2022 Directions. Compliance was uneven; expect tighter enforcement going forward.
Lessons learned — six durable takeaways
(1) MFT is critical infrastructure; treat it as such. Internet-facing managed file transfer products are platform-agnostic targets for nation-state-grade exploitation campaigns. They deserve the security investment commensurate with critical infrastructure, not the “boring B2B utility” treatment they often receive. (2) Pre-disclosure exploitation is the new normal. Cl0p had MOVEit access for weeks-to-months before public disclosure. Trust no vendor’s “we patched within X days of disclosure” — real defence requires assumptions of N-day exposure. (3) Ransomware vs extortion are different threat models. Backup strategies defend against encryption ransomware; they do not defend against data-exfiltration extortion. The 2024-2025 trend is exfiltration-only; defenders need data-loss-prevention strategies plus backup. (4) Supply chain risk extends through B2B data exchange. Your security perimeter is the union of every vendor your data touches. MFT compromises propagate downstream to every partner the MFT served. Map this dependency graph; demand security from your suppliers. (5) Public shame is the dominant extortion lever. Cl0p’s leak-site model has been copied by other groups (LockBit, ALPHV/BlackCat, Cuba, Royal). Defenders must plan for the “data is public” scenario — communications, customer notifications, regulatory disclosures, business continuity in the face of brand damage. (6) Regulatory cost outpaces operational cost. The eventual cost of MOVEit-class breaches is dominated not by remediation expense but by class-action settlements, regulatory fines, and downstream business loss from customer attrition. Cyber insurance policies have been re-priced accordingly; expect 30-50% premium increases through 2026.
What to do this week — 7-day MFT security audit
Day 1: Inventory. List every file-transfer mechanism in your organisation — formal MFT products (MOVEit, GoAnywhere, Cleo, IBM Sterling, Globalscape, Axway, Cerberus, Serv-U), homegrown SFTP servers, S3-based exchange buckets, ad-hoc Dropbox / Google Drive shared with partners. Day 2: Internet exposure audit. For each MFT, determine: is it reachable from the internet? What WAF or upstream filter sits in front? What IPs are allowlisted? Is the latest security patch applied? Day 3: Account audit. Every MFT user account: who is it, are they still active, last login date, what permissions do they have? Disable unused accounts; rotate service-account credentials. Day 4: Logging and detection. Verify MFT logs ship to your SIEM. Build alerts for: unusual login geography, bulk file enumeration, configuration changes, account creation/modification. Day 5: Egress filtering. From MFT servers, what outbound connections are permitted? Lock down to only the destinations required for legitimate operation; alert on anything else. Day 6: Tabletop exercise. Walk through an “MFT compromise discovered Friday afternoon” scenario. Who calls the vendor? Who notifies partners? Who handles customer notifications? Who briefs legal and the board? Day 7: Vendor relationship review. For each MFT vendor, review the contract — security commitments, breach-notification SLAs, indemnification, audit rights. Schedule a meeting with your account manager to demand any missing protections at next renewal.
Wider implications — how MOVEit reshaped the supply-chain security conversation
The MOVEit campaign is one of the inflection points that defines how the security industry talks about supply chain risk. (1) SBOM mandates accelerate. US Executive Order 14028 and similar EU initiatives on software bill of materials gain teeth as legislators cite MOVEit-class incidents to justify mandatory transparency about software components. (2) MFT consolidation. Many organisations are moving away from on-premises MFT toward fully-managed cloud equivalents (AWS Transfer Family, Azure Data Factory, GCP Storage Transfer Service) where the vendor takes responsibility for vulnerability management. The trade-off is data residency and customisation; the business case has shifted toward managed services. (3) Insurance underwriting tightens. Cyber insurance applications now ask specifically about MFT inventory, internet exposure, patch cadence — and policy pricing reflects answers. Some insurers exclude MFT-related claims if the customer was running unsupported product versions. (4) Class-action precedent. US federal courts certified MOVEit-related class actions across multiple jurisdictions; settlement amounts are setting precedent for damages in mass-exfiltration cases. Future similar campaigns will inherit this legal framework. (5) Regulatory expectation alignment. CISA, ENISA, India’s CERT-In, and other national CERTs increasingly publish coordinated advisories with shared IoCs; the “fragmentation” of national cyber response that hampered earlier mass-exploitation campaigns is reducing. The MOVEit incident will be cited in security curricula, vendor risk management frameworks, and executive briefings for years — it is the canonical modern supply-chain breach.
FAQ
Is MOVEit safe to use now?
Patched MOVEit instances with proper security configuration are safe in the same sense any internet-facing application is — i.e., as long as the next vulnerability is not yet disclosed. Multiple MOVEit CVEs have followed the original CVE-2023-34362; treat MOVEit as a high-attention asset that needs same-day patching for security advisories.
Should I switch from MOVEit to a different MFT product?
Not based on this incident alone. Comparable products (Fortra GoAnywhere, Accellion FTA, Cleo Harmony) have all suffered similar mass-exploitation campaigns. The structural risk is MFT category, not specific product. If you switch, switch toward managed cloud services or zero-trust file exchange architectures rather than another on-premise MFT product.
Did paying Cl0p's ransom protect victims?
Inconsistent. Some who paid had data removed from the leak site; some did not. Cl0p later sold or leaked data from organisations that had paid. Payment provides no enforceable guarantee. US OFAC sanctions also create legal risk for organisations paying entities like Cl0p.
Are Indian organisations actively scanning for MOVEit-class risks?
CERT-In issued multiple advisories; sectoral regulators (RBI, SEBI) have formalised expectations. Indian regulated entities are increasingly attentive but maturity is uneven. Smaller and mid-tier Indian organisations remain at higher risk due to less resourced security functions.
How can I check if my data was in the MOVEit breaches?
There is no comprehensive lookup. If you held an account with any of the 2,700+ confirmed victim organisations during 2023, assume your data was exposed. Many victims sent direct breach notifications; check your records and credit-monitoring alerts. Have I Been Pwned has indexed some MOVEit-related datasets.
📰 Note: This analysis is compiled from public reporting (Reuters, Bloomberg, court filings, threat-intel firm publications) and is intended for security education. Some technical details remain disputed in ongoing legal proceedings; we have attributed claims where the source is established and noted where matters remain contested.
Get a free attack-surface review
We check what an attacker would see about your business — leaked credentials, exposed services, dark-web mentions. 30 minutes, no obligation.