MOVEit: One File Transfer Flaw, Thousands of Organizations

Last Wednesday the vendor of a widely deployed managed file transfer product published an advisory about a critical vulnerability being actively exploited. By yesterday the BBC, British Airways and Boots had confirmed that staff data was taken — not from their own systems, but from a payroll provider that used the product. Over the weekend the Clop extortion group claimed the campaign and told victims to make contact. Dozens of organisations have now disclosed. Nobody credibly knows the total, and anyone quoting a number this week is guessing, because most victims have not finished establishing what was on the server.

This is the third time in thirty months that a file transfer product has become the front door to hundreds of organisations at once. It is no longer an accident; it is a category

The pattern is specific and recent. A managed file transfer appliance was mass-exploited at the turn of 2021, exposing universities, law firms, retailers and regulators. In February this year, a different file transfer product was exploited by the same extortion group, with well over a hundred organisations named in the weeks that followed. Now this. Three separate products, three vendors, one product class, one attacker playbook. Treating the current incident as a vendor failure misses what the sequence is telling you.

Why this category, and why it keeps happening

It is internet-facing by design. A file transfer server that counterparties cannot reach is useless, so it sits at the perimeter with an inbound listener, permanently. It holds the payload. The reason to compromise a file transfer appliance is not lateral movement. It is that the bulk personal and financial data of an entire organisation passes through it, in files assembled precisely because someone needed everything in one place. It accumulates. Almost every organisation discovers, during the investigation, that transferred files were never deleted. The product is understood as a pipe and behaves as an archive. It is owned by nobody in particular. Application teams do not own it, because it is infrastructure. Infrastructure teams do not treat it as an application. It is patched on the infrastructure cycle, which is slower than the application cycle, which is slower than attackers. It aggregates counterparties. One compromised instance reaches every organisation that exchanges files with the operator, which is why the victim list in each of these events is a list of the operator's clients rather than the operator itself.

The organisations in the headlines were not running the software

This is the part worth dwelling on. The named employers had no instance of the product, no patch to apply and no configuration to review. Their exposure came through a payroll processor, and the vulnerability sat in that processor's chosen file transfer product. Your third-party register almost certainly lists the payroll bureau. It almost certainly does not record which file transfer technology that bureau uses, where the appliance sits, or how long your employees' files remain on it after collection. That is the fourth-party question, and this week it is the one that decides whether you are in the news.

What to do this week

If you operate the product, patch immediately and treat any internet-facing instance that was unpatched during the exploitation window as compromised until proven otherwise. Hunt for the webshell artefacts described in the vendor and responder advisories, review service account activity, and check egress volumes for large outbound transfers in the last two weeks. Rotate every credential, key and connection secret held on the appliance, including the ones for the systems it connects to, because those were available to whoever held the server. Then answer the harder question: what was actually sitting on it. In most of these incidents the volume of data recoverable from the appliance is far larger than anyone expected, because deletion after transfer was never configured. If you do not operate the product, write to every provider that receives bulk files from you and ask three things in writing: which file transfer technology they use, whether it was affected, and what data of yours was resident on it. Ask this week, while they are already assembling the answer for someone else.

The structural fix is retention, not replacement

The instinct after an event like this is to change product. That rarely helps, since the replacement belongs to the same category with the same exposure profile. What changes the outcome is treating the transfer server as a data store that happens to move things. Delete files on collection or within a defined short window, automatically, with monitoring for the exceptions. Encrypt at rest with keys that are not held on the appliance, so that a compromised server yields ciphertext. Segment it so that holding it does not yield credentials into the estate. Run its service accounts with narrow, specific rights rather than broad domain privileges. And keep an inventory of who exchanges what with it, because that list is your notification list on the bad day.

Practical Guidance for File Transfer Security Review

• Inventory every file transfer instance, including ones in subsidiaries.
• Ask providers in writing which transfer product they operate.
• Configure deletion on collection, with monitored exceptions.
• Hold encryption keys off the appliance.
• Narrow service account rights and remove domain-wide privileges.
• Monitor egress volume, not only inbound attempts.
• Map statutory and payroll file flows first; they carry the densest data.
• Keep a counterparty list ready to serve as a notification list.

The Regional Angle

Three factors make this event more consequential for groups operating here than the coverage suggests. The first is that bulk file transfer is how regional organisations talk to the state and to their banks. Salary files submitted under wage protection requirements are the clearest case: one file, produced monthly, containing every employee's identifier, bank details and pay, transmitted to a bank or an agent and onward to a ministry. Add to that end-of-service calculations, visa and labour filings handled by public relations officers, customs documentation, and bank payment files in fixed formats. These flows are mandatory, high frequency, and carry the densest personal data in the organisation, yet they are usually treated as compliance plumbing rather than as a security surface. If you inventory only one thing this month, inventory the statutory file flows, because a compromise there exposes the entire workforce in a single document and the notification consequences reach every employee at once. The second is that the vulnerable appliance in a regional group is frequently owned by an entity the group security function does not manage. A typical structure has mainland companies, free zone subsidiaries with their own technology arrangements, joint ventures where the partner runs infrastructure, and acquisitions that were never integrated. Central inventories reflect the head office estate and stop at the corporate boundary. An internet-facing transfer server in a trading subsidiary, installed six years ago by an integrator who is no longer engaged, will not be on any list and will not be patched this week. The work is unglamorous: an external scan of every domain and address range the group owns, mapped against the legal entity register rather than against the IT asset register, which is how this class of asset is actually found. The third is provider concentration. A comparatively small number of payroll bureaus, public relations service providers and document clearing agents serve a very large share of employers in the Gulf, which means a single compromise at one of them reaches a substantial slice of a national labour market at once. Regional supplier due diligence rarely probes this, because it tends to stop at a certificate: a valid information security certification is treated as the answer rather than as the beginning of the question. A certificate does not tell you which transfer product the provider runs, whether files are deleted after collection, or whether your data sits on a shared instance with forty other employers. Those three questions fit in one email, and this is the week in which you will actually get answers to them.

The objection worth taking seriously

The strongest objection is that this argument over-reaches from a single vulnerability. Patch velocity is the control that would have prevented most of the damage here, it is measurable, and organisations that patch internet-facing systems within days of an advisory will survive the next one too. Re-architecting inter-company data flows because a vendor shipped a flaw is an expensive response to a problem that a maintenance window solves. And the realistic alternatives to managed file transfer are worse: bespoke integrations that nobody maintains, or spreadsheets sent by email, which is how this data moved before these products existed. All of that is right, and patch velocity on perimeter systems remains the highest-return security investment available to most organisations. The qualification is in the pattern. Three mass exploitations of one product category in thirty months means the next advisory is not a hypothetical, and even excellent patching leaves a window between exploitation and disclosure — a window the current campaign appears to have used, since exploitation preceded the advisory. What determines the severity of that window is not how fast you patch but how much data was resident when it opened. Retention, key custody and segmentation are configuration changes rather than programmes, they cost a fortnight of effort, and they convert a catastrophic breach into a manageable one. Patch fast and delete aggressively; the second is what makes the first survivable.

Common Questions

We patched immediately. Are we safe?

You are protected going forward. Whether you were already compromised is a separate question that requires looking for the artefacts, because exploitation appears to have begun before the advisory was published.

Our provider says they were not affected. Is that sufficient?

Ask for it in writing, with the product and version named. A verbal assurance given in the first week of an incident is frequently revised in the third.

Should we notify before we know what was taken?

Check your contracts before checking the regulations. Customer and banking agreements in this region often impose notification windows shorter than any statutory requirement, and they are the obligations most commonly missed.

What should we expect over the next twelve months?

Expect the disclosed victim list to grow considerably over the coming weeks as forensic work completes, and expect several organisations to learn they were affected from the extortion site rather than from their provider. Expect this campaign to remain theft and extortion without encryption, which removes the downtime that usually forces a fast response and makes publication the only pressure the attacker holds. Expect further vulnerabilities in the same product class, because the category is now a proven target and researchers and attackers are both looking. And expect file transfer to start appearing as a named question in insurance proposals and large customer security questionnaires before the year ends.

---

File Transfer Security Review — we find every transfer instance across your legal entities, fix retention and key custody, and get written answers from the providers holding your payroll files.