MOVEit Transfer: When the File Transfer Server Becomes the Breach

Two weeks ago, on May 31, Progress Software disclosed a critical vulnerability in MOVEit Transfer, its managed file transfer product. By the time most customers read the advisory, attackers had already been using it. What has followed is one of the larger data-theft campaigns in recent memory, and it's still unfolding: new victims are being named almost daily, and a second set of vulnerabilities was announced just last Friday.

We're writing this mid-incident, so treat the details as the state of public knowledge in mid-June, not the final account.

What we know so far

• The vulnerability. CVE-2023-34362 is a SQL injection flaw in the MOVEit Transfer web application. It lets an unauthenticated attacker get into the database behind the application and, from there, run code on the server. Progress released patches for supported versions and, before patches were ready, advised customers to block HTTP and HTTPS traffic to their MOVEit Transfer servers.
• Exploitation started before disclosure. Security firms investigating victims have reported exploitation from late May, reportedly as early as May 27, which was a US holiday weekend. That timing isn't unusual; fewer people are watching.
• The attackers. Microsoft attributed the campaign to the group it tracks as Lace Tempest, associated with the Cl0p ransomware and extortion operation. Cl0p has since claimed responsibility and posted a notice telling victims to contact it before a deadline, or have their data published.
• The goal is data, not encryption. There's no ransomware locking systems here. Attackers dropped a web shell, widely reported as a file named human2.aspx (imitating a legitimate human.aspx file), and used it to pull data out of the MOVEit database and file store.
• The blast radius runs through suppliers. Some of the first organisations to go public, were hit because a service provider ran MOVEit, not because they did. The UK payroll provider Zellis was compromised, and several of its clients, including British Airways, the BBC and Boots, have had to tell staff that their payroll data may have been taken. Public bodies, including the government of Nova Scotia, have also confirmed exposure.
• It isn't over. On June 9, Progress disclosed additional SQL injection vulnerabilities found during a code review prompted by the first one, with another patch. If you patched two weeks ago, you likely need to patch again.

CISA and the FBI published a joint advisory on June 7 with indicators of compromise. If you run MOVEit Transfer, that advisory and Progress's own guidance come before anything in this post.

If you run MOVEit Transfer

In short, and deferring to the vendor's guidance:

1. Apply every patch, including the one released after June 9. Check your version against Progress's advisory pages; don't assume.
2. Assume compromise if you were exposed in late May or early June and hunt for it. Look for unexpected .aspx files in the MOVEit web root, unfamiliar accounts, and unusual large downloads in the logs. The joint advisory lists specific indicators.
3. Rotate credentials the application uses, including service accounts and database credentials.
4. Work out what data was on the server. Managed file transfer servers tend to accumulate files long after anyone needs them. If files were there, you may have notification obligations.

The pattern: file transfer at the edge

What makes this campaign worth studying, even for people who have never heard of MOVEit, is that it isn't new. The same group has run this play before: the Accellion File Transfer Appliance breaches in late 2020 and early 2021, and a zero-day in Fortra's GoAnywhere MFT earlier this year. The recipe is consistent: find a flaw in software that is internet-facing by design, holds sensitive files by design, and is run by many organisations that treat it as plumbing. Then exploit it across every exposed instance at once, quickly, before patches land.

That recipe works because of how these systems tend to be run:

• They're on the internet because partners need to reach them. You can't put them behind the corporate VPN without breaking the reason they exist.
• They're nobody's main job. A file transfer server is often set up once by someone who has since moved on, and it keeps working, so nobody touches it.
• They collect data. Files get uploaded for a partner and never deleted. A server meant as a pipe becomes an archive.
• They're patched on the "appliance" schedule, which in many organisations means rarely.

What to do even if you've never run MOVEit

Most organisations have something in this category: a file transfer tool, a VPN gateway, a remote-access portal, a self-hosted wiki someone exposed for a contractor. The questions to ask this week:

Do you know every internet-facing service you run? Not the ones in the architecture diagram, the ones that actually answer. Scan your own public IP ranges, list your DNS records and check what responds. Certificate Transparency logs (search your domain on crt.sh) are a quick way to discover forgotten hostnames, because nearly everything with HTTPS has a public certificate.

Does each one have an owner and a patch plan? For each exposed service: who is responsible, how would they hear about a critical advisory, and how fast can they apply it? "Within a day for critical, internet-facing" is a reasonable target. If the answer is "we'd see it in the news," that's worth fixing.

Does it need to be public at all? Many of these services only need to be reachable by a known set of partners. An IP allowlist in front of them turns an internet-wide mass exploitation into something that has to target you specifically.

Is data retained longer than it needs to be? A transfer server that deletes files after a week limits the damage from a breach to a week of data. The one that has kept everything since 2017 does not.

Would you notice a new file in the web root? The MOVEit attacks left artefacts: new files in directories that should never change. Integrity monitoring, or even a scheduled comparison of file listings, turns a silent compromise into an alert. The same goes for publicly visible content: pages and paths that change when nothing was deployed deserve a look.

Supplier risk is your risk

The Zellis angle deserves attention. Many of the organisations now writing to their employees never ran MOVEit themselves; a supplier did. When you send data to a vendor, the vendor's patch cadence becomes your patch cadence. Ask your data processors, especially payroll, HR and benefits providers, whether they were affected, and whether they can tell you what was held on the systems involved.

We said something similar after Equifax in 2017 and after Log4Shell: the hard part is rarely applying a patch. It's knowing, quickly and completely, where you're exposed.

Keep an eye on your perimeter

Know what you expose, patch it fast, and watch for changes you didn't make. External monitoring, from a service like CompleteStatus or your own tooling, is one piece of that: a regularly checked list of public endpoints and what they serve means a surprise shows up as an alert rather than as a letter from a regulator.