The MOVEit Breach: How SQL Injection Gave Cl0p Access to 2,773 Organisations Without Deploying Ransomware

‍​​​‌​​‌‌‌​​​​​​‌‌‌​​​​‌‌​​‌‌​​‌‌‌‌‌‌‌‌​​​​‌‌​‌‌‌​‌​​​‌​‌​‌​​​‌​‌‍Between 27 May and mid-June 2023, a single SQL injection vulnerability in a file transfer application gave one criminal group access to data from 2,773 organisations. The breach affected 95.8 million individuals across 78 countries. The estimated financial impact sits at USD 15.8 billion. At least 144 class-action lawsuits have been filed, and litigation against Progress Software remains ongoing as of 2025.

No ransomware was deployed at any stage of the campaign. No files were encrypted on any victim system. The entire operation was data theft, followed by extortion threats published on a leak site. The group behind it, Cl0p, had done this twice before with different file transfer products. MOVEit was the third and largest in a pattern that started in 2020.

What everyone thinks happened

The common version of the story goes like this: a ransomware group found a vulnerability in MOVEit Transfer, deployed ransomware, encrypted files, and demanded payment. That version is wrong on almost every technical point.

Cl0p didn't encrypt anything on any victim's systems. They didn't deploy ransomware at all during this campaign. The word "ransomware" in their name reflects their history, not their method for this campaign. What they did was exploit a SQL injection to gain administrative access, deploy a custom web shell to extract data, and then threaten to publish that data unless victims paid.

That distinction matters because the defences against data theft are different from the defences against encryption-based ransomware. Organisations that had strong backup strategies but poor egress monitoring would've recovered from a ransomware attack quickly. Against Cl0p's actual method, those backups were irrelevant because nothing was encrypted. The damage was the stolen data itself, and you can't restore your way out of that.

What actually happened

The vulnerability: CVE-2023-34362

MOVEit Transfer is an enterprise managed file transfer (MFT) application built by Progress Software. Thousands of organisations use it to move sensitive files between systems, partners, and clients. It runs on Microsoft IIS with an ASP.NET backend and Microsoft SQL Server (or MySQL or Azure SQL) as the database.

The vulnerability was a SQL injection flaw, classified as CWE-89. The National Vulnerability Database (NVD) assigned it a CVSS v3.1 score of 9.8 out of 10, the highest severity band. The vector string tells the story: network accessible, low attack complexity, no privileges required, no user interaction needed, and high impact across confidentiality, integrity, and availability.

The root cause was straightforward but deeply embedded. The UserGetUsersWithEmailAddress() function in the MOVEit Transfer web application concatenated user-supplied input directly into SQL queries without proper sanitisation. A session variable called SelfProvisionedRecips was split on commas but never cleaned before insertion into the query string. Any value placed in that variable would flow directly into the SQL statement.

Every version of MOVEit Transfer before the patches released in May and June 2023 was vulnerable. That includes both on-premises and MOVEit Cloud deployments.

The exploitation chain

The SQL injection itself was only the entry point. Cl0p's exploitation was a sophisticated four-stage chain that turned a SQL injection into full remote code execution.

Stage one involved session variable injection against the application layer. The MOVEit Transfer application had a header parsing bug in its action_m2 endpoint. By sending a malformed xX-siLock-Transaction header (note the lowercase "x" prefix, which bypassed header validation), attackers could access the machine2.aspx endpoint with transaction=session_setvars. From there, they injected arbitrary session variables through X-siLock-SessVar headers, placing their SQL injection payload into the SelfProvisionedRecips variable.

Stage two: SQL injection via the guest access endpoint. The corrupted session variables flowed through the unauthenticated guestaccess.aspx endpoint, following the call chain from SILGuestAccess through MsgEngine.MsgPostForGuest() into UserGetUsersWithEmailAddress(). The SQL payload executed against the MOVEit database. The attackers avoided commas in their payloads (because the variable was split on commas) by chaining sequential SQL statements using INSERT and UPDATE rather than comma-separated syntax.

Stage three was sysadmin token acquisition through the database. With SQL injection access to the database, the attackers configured MOVEit Transfer to trust a malicious external identity provider. They inserted entries into the trustedexternaltokenproviders table pointing to an attacker-controlled certificate hosting endpoint, then created a crafted RS256 JSON Web Token (JWT). Authenticating through the /api/v1/auth/token endpoint with session_grant=external_token gave them a sysadmin-level API access token.

Stage four used deserialisation to achieve full remote code execution. Using the sysadmin token, the attackers initiated a resumable file upload to /api/v1/folders/<folder_id>/files?uploadType=resumable. The Comment field of the upload contained a ysoserial.net BinaryFormatter payload using the TypeConfuseDelegate gadget. Through SQL injection, the encrypted comment was copied into the State field of the upload record. When the upload was resumed, the DeserializeFileUploadStream() function deserialised the payload and executed arbitrary code. The encryption requirement was satisfied because the payload had been encrypted by MOVEit's own system during the initial upload step.

That chain, from a header parsing bug through SQL injection through identity provider manipulation through deserialisation, isn't a simple exploit. The individual components (SQL injection, JWT manipulation, deserialisation attacks) are well-known techniques. Chaining them together against a specific application's architecture required detailed knowledge of MOVEit Transfer's internals.

The web shell: LEMURLOOT

After achieving remote code execution, Cl0p deployed a custom web shell that CISA and the FBI named LEMURLOOT. It was tailored specifically for the MOVEit Transfer environment.

LEMURLOOT was deployed as human2.aspx, mimicking the legitimate human.aspx component that ships with MOVEit Transfer. Authentication to the web shell required a 36-character password sent via the X-siLock-Comment HTTP header, a value that was hard-coded into the shell.

The web shell imported MOVEit's own .NET libraries (MOVEit.DMZ.ClassLib, MOVEit.DMZ.Application.Files, MOVEit.DMZ.Application.Users) to interact with the database and file system natively. It could enumerate files and folders, download data, create and delete administrator accounts, retrieve Azure configuration settings, and return data in gzip-compressed format. If the web shell found no existing account with permission level "30", it created one with a randomly generated username and set the LoginName and RealName to "Health Check Service."

CISA published 50 SHA256 file hashes for LEMURLOOT samples and documented 94 malicious IP addresses used during the campaign. Four YARA detection rules were provided for identifying LEMURLOOT variants in both ASPX source files and compiled DLL form.

The extortion model

Cl0p didn't deploy encryption at any stage of the campaign. The operation was pure data theft followed by public extortion.

On 6 June 2023, a post on the CL0P^_-LEAKS data leak site claimed responsibility for the MOVEit campaign and threatened to publish stolen data if victims did not pay an extortion fee. Victims were given deadlines, and those who did not pay had their data published on the leak site. Approximately 2.5% of victims paid the ransom demands that followed.

This was not new behaviour for the group. Cl0p had run the same model against Accellion FTA devices in late 2020 (using a different web shell called DEWMODE, approximately 100 organisations affected) and against Fortra GoAnywhere MFT in January 2023 (approximately 130 organisations affected). The MOVEit campaign was the third iteration of the same playbook: find a zero-day in a managed file transfer product, exploit it at mass scale, deploy a custom web shell to extract data, and extort victims through a leak site.

The scale of impact

The numbers from the Emsisoft breach tracker, which has been the most thorough public record of MOVEit victims, show 2,773 organisations and 95,788,491 individuals affected as of June 2024. Geographic distribution was heavily weighted toward the US at 78.9%, with Canada at 13.5%, Germany at 1.3%, and the UK at 0.7%.

The sector breakdown shows education at 39.1%, healthcare at 20.1%, and finance and professional services at 13.3%. The largest individual victim disclosures came from Maximus (11.3 million individuals), Welltok (10 million individuals), and Delta Dental of California and affiliates (6.9 million individuals).

In the UK, the BBC, British Airways, and Boots were all affected through their payroll provider Zellis, which used MOVEit Transfer for data handling. Shell was also listed among the affected UK organisations. In the US, the Department of Energy and multiple other federal agencies were affected. The National Student Clearinghouse breach affected universities across the country.

Supply chain amplification was a major factor in the total impact. Many of the 2,773 affected organisations weren't direct MOVEit Transfer users. They were affected because a supplier, payroll provider, or data processor in their chain used MOVEit. Zellis processing payroll for the BBC, British Airways, and Boots is the clearest example: one compromised intermediary exposed employee data from three major UK organisations simultaneously.

Myth vs fact

Myth: Cl0p deployed ransomware in the MOVEit attack. (referenced in the revised assurance benchmarking report).

Cl0p is classified as a ransomware group based on their history, and the name carries that association. But no ransomware was deployed during the MOVEit campaign. No files were encrypted on any victim's systems. The operation was entirely data theft and extortion. This matters for defence planning: if your incident response assumes encrypted systems as the primary impact, the MOVEit model catches you from a different direction. The data is gone, not locked, and restoring from backups changes nothing.

Myth: The MOVEit vulnerability was discovered quickly and patched before widespread damage.

The earliest evidence of exploitation dates to 27 May 2023. Progress Software received its first customer support call about unusual activity on 28 May. The investigative team discovered the zero-day on 30 May, and a public advisory with a patch followed on 31 May. That 48-hour response from discovery to patch was swift, but exploitation had been underway since at least 27 May. More importantly, two additional critical SQL injection vulnerabilities (CVE-2023-35036 on 9 June and CVE-2023-35708 on 15 June) were discovered during the investigation period. Three critical SQL injection CVEs in 16 days suggest the original codebase had systemic input validation weaknesses across multiple endpoints, not a single isolated flaw.

Myth: This was an unprecedented type of attack that couldn't have been anticipated.

Cl0p had run this exact playbook twice before. The Accellion FTA campaign in late 2020 exploited a zero-day in a file transfer product, deployed a custom web shell (DEWMODE), and extracted data for extortion. Approximately 100 organisations were affected across multiple sectors. The Fortra GoAnywhere MFT campaign in January 2023 did the same thing via CVE-2023-0669, hitting approximately 130 organisations. MOVEit was the third and largest iteration of this playbook. The pattern of MFT zero-day exploitation followed by mass data theft was well-documented before the MOVEit campaign started. The Canadian Centre for Cyber Security's profile of TA505 (the threat actor group that operates Cl0p) explicitly documents this progression.

Myth: Only large enterprises were at risk.

Education was the most affected sector at 39.1% of victims. Many of those weren't large enterprises with dedicated security teams. Supply chain amplification meant that organisations with no direct relationship to MOVEit Transfer were still affected. If your payroll provider, your student records clearinghouse, or your healthcare claims processor used MOVEit, your data was at risk regardless of your own security posture. The question wasn't whether you used MOVEit, but whether anyone in your data supply chain did.

What would have reduced the impact

The MOVEit vulnerability was a zero-day with no available patch. Patching alone could not have prevented the initial exploitation because no patch existed before 31 May 2023. But several controls would have either prevented exploitation or limited the damage.

Web Application Firewall (WAF) with SQL injection detection on the MOVEit Transfer web endpoints could have detected and blocked the crafted payloads targeting guestaccess.aspx and machine2.aspx. The exploitation involved concatenated SQL statements passed through HTTP headers and session variables. Generic SQL injection signatures in a properly configured WAF would have caught the manipulation patterns, even without specific MOVEit rules.

Network segmentation between the web application and database tiers would have limited what an attacker could reach after compromising the web server. Many victims had MOVEit Transfer directly exposed to the internet without additional network controls between the application and its database. Separating those tiers with firewall rules restricting database access to the application server only would have constrained the exploitation chain.

Egress monitoring and data loss prevention (DLP) would have detected the actual data theft in progress. LEMURLOOT was extracting data from MOVEit Transfer databases and returning it in gzip-compressed format to external IP addresses. Monitoring for unusual volumes of outbound data from MOVEit Transfer servers, particularly to IP addresses outside normal transfer partner ranges, would have flagged the exfiltration even after the initial compromise succeeded.

Restricting internet exposure of MOVEit Transfer instances would have eliminated the attack surface for many organisations. Placing the application behind a VPN or restricting access to known IP ranges rather than making it directly internet-accessible reduces the pool of attackers who can even reach the vulnerable endpoints. For a file transfer application that handles sensitive data, the question of whether it needs to be directly addressable from the open internet deserves scrutiny.

Rapid patching within the zero-day window mattered significantly. Organisations that applied the 31 May patch within hours reduced their exposure window considerably. Those that delayed remained vulnerable through the discovery of the second and third SQL injection CVEs on 9 and 15 June. The 48-hour window between Progress's discovery and patch release was tight, but the weeks that followed tested every organisation's ability to apply emergency patches to production systems.

Supply chain visibility is the hardest control on this list. Many victims weren't MOVEit Transfer users themselves. They were affected because someone in their data processing chain used MOVEit. Knowing which third-party suppliers handle your data, what software they use for that handling, and what their patching cadence looks like requires procurement and vendor management processes that most organisations haven't built. The Zellis payroll example demonstrates this: BBC, British Airways, and Boots were all exposed through one intermediary that most of their employees wouldn't have been aware of.

What changed after

Progress Software's response and legal aftermath

Progress Software's initial response was swift by industry standards. Forty-eight hours from discovering the vulnerability to publishing an advisory and patch is a tight turnaround for a zero-day. The company engaged Huntress as a third-party cybersecurity partner to assist with discovering additional vulnerabilities, which led to the patches for CVE-2023-35036 and CVE-2023-35708.

The SEC (Securities and Exchange Commission) issued a subpoena to Progress Software on 2 October 2023 as part of a fact-finding inquiry. In August 2024, the SEC notified Progress that the Division of Enforcement had concluded its investigation and did not intend to recommend enforcement action. That outcome suggests regulators assessed Progress's disclosure and response as adequate given the circumstances.

The financial impact on Progress itself has been relatively contained. The company incurred approximately USD 6.2 million in cyber incident response costs during fiscal year 2023, against revenue of USD 694 million. Cybersecurity insurance covered USD 3.7 million of those costs.

But 144 class-action lawsuits have been filed, consolidated into a multidistrict litigation (MDL) in the US District Court for the District of Massachusetts. Thirty-eight customers have sent letters indicating intent to seek indemnification. In July 2025, the judge largely denied motions to dismiss in two bellwether cases, allowing claims for negligence, breach of contract, unjust enrichment, and state consumer protection violations to proceed. Other defendants in the MDL have already settled: National Student Clearinghouse for USD 9.95 million, Cadence Bank for USD 5.25 million, and Arietis Health for USD 2.8 million. Litigation against Progress Software itself continues as of 2025.

Attribution and the threat actor

Microsoft Threat Intelligence attributed the attacks to Lace Tempest (DEV-0950) on 5 June 2023. Mandiant initially tracked the activity under UNC4857 before merging it into FIN11 based on infrastructure and targeting overlaps. The Canadian Centre for Cyber Security assesses the group (tracked broadly as TA505) as "almost certainly a financially motivated, Russian-speaking, ransomware-as-a-service cybercrime group" likely based in a Commonwealth of Independent States (CIS) nation.

The group has been active since at least 2014. Beyond Cl0p, TA505 has operated as an affiliate or developer for LockBit, Hive, Locky, and REvil ransomware. They also function as initial access brokers and have operated the Dridex banking malware botnet.

On 16 June 2023, the US State Department announced a USD 10 million reward through its Rewards for Justice programme for information linking Cl0p or associated actors to foreign government sponsorship.

The MFT security conversation

The MOVEit breach brought managed file transfer security into focus in a way the Accellion and GoAnywhere incidents hadn't, largely because of the scale. Three mass exploitation campaigns against three different MFT products in three years by the same threat group established a pattern that was difficult to ignore.

The US Cyber Safety Review Board (CSRB) noted the significance of the incident. The broader industry conversation shifted toward questioning why enterprise file transfer applications that handle highly sensitive data are routinely exposed directly to the internet, often with minimal additional security controls between the application and the data it processes.

For organisations still running MFT products, the questions that emerged from MOVEit haven't gone away. Where is the application deployed and what is its internet exposure? What sits between the web application and the database? What monitoring exists for data leaving the MFT environment? And perhaps most critically, what happens to your data if a supplier in your chain uses an MFT product that gets compromised?

Those questions are operational, not theoretical in nature. Cl0p has demonstrated three times that they'll find and exploit zero-days in file transfer products. The likelihood of a fourth campaign against a different MFT product isn't speculative, it's an established pattern that shows no signs of stopping.

---

---

Related articles

• The SolarWinds SUNBURST Attack: How Clean Source Code Produced a Backdoor
• The JLR Cyber Attack: How a Single Breach Contracted UK GDP
• The WannaCry Ransomware Attack: How a Kill Switch Stopped a Global Worm
• The County Mayo Water Hack: How a Default Password Took 180 Homes Offline

netsec-canary-d03b1ba9f21b.