On May 31, Progress Software published CVE-2023-34362, a SQL injection flaw in MOVEit Transfer that let an unauthenticated attacker read, modify, and delete data straight out of the product's database. By the time the CVE existed as a public document, the exploitation had already happened. Cl0p — the extortion crew behind a string of file-transfer zero-days — ran automated attacks against internet-facing MOVEit instances over the Memorial Day weekend, dropped a webshell, and quietly harvested whatever sat in reach before anyone had a patch to apply.
Eleven weeks later, we are still watching the list of named victims grow. Cl0p runs a leak site with a countdown clock, and it has been adding organizations to that list weekly since June: a UK payroll processor whose breach cascaded into British Airways, the BBC, Boots, and Aer Lingus; the US Department of Energy, through contractor instances; a clearinghouse that handles enrollment data for a huge share of US colleges and universities; Johns Hopkins. None of those are our clients — we anonymize our own engagements as a rule — but the pattern across all of them is the one worth studying: nobody was breached because of a Microsoft misconfiguration. They were breached because of an edge appliance almost nobody in IT was watching.
That is the actual subject of this note. MOVEit is not a Microsoft product, and most of the Microsoft-centric estates we run don't touch it directly. But the shape of the problem — an internet-facing, vendor-owned file-transfer or EDI appliance, patched on somebody else's schedule, wired into AD service accounts and SharePoint or Exchange handoffs that the security team has never mapped — exists in nearly every estate we've touched this year. Third-party software risk has been a line item on every architecture review we've run since 2010. This is the summer it stopped being theoretical.
A file-transfer box nobody in IT remembers procuring
MOVEit Transfer is a managed file-transfer (MFT) product: it automates recurring file exchanges over SFTP, FTPS, and HTTPS, typically for exactly the kind of file a business unit needs to move on a schedule without asking IT to babysit it — payroll extracts to a processor, claims files to a third-party administrator, EDI batches to a manufacturing partner, statement files to a print vendor. It runs as an IIS-hosted Windows application, on a server that was very likely stood up by whoever owned the integration at the time, patched whenever that person remembered the vendor sent an email, and left alone for years once it worked.
That ownership pattern is the actual vulnerability, more than any single CVE. We have seen the shape of this box under different names for a decade: an EDI gateway procured by a manufacturing client's operations group, an SFTP drop-box a healthcare client's revenue-cycle vendor asked for and nobody in security ever reviewed, a "temporary" FTP server from a prior acquisition that outlived three CIOs. The common trait isn't the product name. It's that the appliance sits on the internet, holds a meaningful volume of sensitive data in transit, and reports to a business owner rather than to the same patch cadence as the rest of the server estate.
The three-weekend pattern: Accellion, GoAnywhere, now MOVEit
This is Cl0p's third run at almost exactly this playbook. Accellion's File Transfer Appliance was exploited the same way in December 2020 into January 2021. Fortra's GoAnywhere MFT went the same way in late January and early February of this year, via CVE-2023-0669, months before MOVEit. Each time: a pre-authentication vulnerability in a file-transfer product, mass automated exploitation before or immediately after disclosure, a webshell for persistence, and — this is the detail that keeps catching people off guard — no ransomware payload at all. Cl0p doesn't encrypt these victims. It copies the data, drops a shell, and later works down the list by hand, emailing organizations individually before naming them on its leak site.
The MOVEit specifics: CVE-2023-34362 came out May 31. Progress shipped a second and third round of patches on June 9 and June 15 (CVE-2023-35036 and CVE-2023-35708) once outside researchers started auditing the codebase properly — the first CVE was never the whole story, it just happened to be the one that got exploited first. CISA and the FBI published a joint advisory on June 7. Microsoft's threat intelligence team tracks the actor running this campaign as Lace Tempest, the same cluster associated with Cl0p and overlapping with the FIN11/TA505 activity our threat-intel vendors have been flagging for years. None of that lineage made the vulnerability easier to patch in April. It should make it easier to justify the inventory work now, because the pattern is not going to stop at three.
Building the vendor-software inventory you don't actually have
Ask most Microsoft-centric IT teams for an inventory of Azure AD accounts, server estate, and mailbox count, and you'll get a real answer inside a day — we've built that muscle across fifteen thousand-plus mailbox migrations and 700-server estates, and it shows. Ask the same team for a complete inventory of internet-facing, vendor-owned software running inside the perimeter, and the answer gets vague fast. That gap is the whole MOVEit lesson, and it's fixable with unglamorous work:
- Pull every inbound allow rule on the perimeter firewall and NSGs that isn't a documented, currently-used service, and chase down an owner for each.
- Cross-reference that list against your CMDB. Anything present in one and not the other is the finding.
- Check for service accounts whose name or description references transfer, EDI, or file exchange duty — this is usually the only place these appliances register in Active Directory at all.
# First pass: service accounts that hint at file-transfer or EDI duty.
# In estates we've audited, this is often the only AD trace a vendor MFT box leaves.
Get-ADServiceAccount -Filter * -Properties Description, ServicePrincipalNames, LastLogonDate |
Where-Object { $_.Name -match 'svc.*(transfer|sftp|edi|mft)' -or $_.Description -match 'transfer|EDI|file exchange' } |
Select-Object Name, LastLogonDate, Description
If you do run MOVEit Transfer specifically, the highest-value check is the one Progress and Microsoft both published: look for a webshell dropped into the application's web root around the exploitation window.
# Applies specifically to MOVEit Transfer installs.
# The published indicator (human2.aspx and variants) lands in wwwroot.
Get-ChildItem -Path "C:\MOVEit Transfer\wwwroot" -Recurse -Include *.aspx |
Where-Object { $_.CreationTime -gt (Get-Date '2023-05-25') } |
Select-Object FullName, CreationTime, LastWriteTime
An empty result is good news, not proof of anything long-term. Rotate the service account credentials and any embedded connection strings regardless; a clean shell check doesn't undo the SQL injection window before you patched.
Mapping what actually moved through the pipe
Finding the appliance answers the easy half of the question. The half that actually determines your notification obligations is what data classes crossed it, and for whom. In every engagement where we've pushed on this, the appliance's technical owner could describe the server. Almost none of them could describe the data without pulling logs first.
The practical technique doesn't require inspecting file contents, which is usually impossible after the fact anyway. Ninety days of transfer logs, classified by source folder and filename pattern rather than payload, gets you most of the way: a biweekly payroll export is obviously payroll data without opening it, a nightly claims file is obviously PHI, an invoice batch is obviously financial. Assign an owner to each recurring flow, not to the server — the server has an administrator, but the flow has a business owner who signed a contract with the counterparty, and that contract almost certainly already specifies breach-notification timelines you have not read recently.
| Flow | Data class | Counterparty | Owner |
|---|---|---|---|
| Payroll extract, biweekly | PII, pay data | Payroll processor | HR |
| Claims file, nightly | PHI | Third-party administrator | Benefits |
| Invoice batch, weekly | Financial | AP outsourcer | Finance |
That table is the deliverable. Not a network diagram — a list of flows, each with a data class and a name attached, that a privacy officer or outside counsel can act on inside a day instead of a month.
Whose pager goes off when it's not your code
Most incident response plans assume the vulnerability sits in something IT fully controls: patch it, verify it, move on. MOVEit-shaped events break that assumption, and the break is the actual operational lesson. Progress owns the patch. You own everything downstream of it: confirming exposure, isolating the box, rotating every credential and connection string that ever touched it, hunting for the published indicators, and — the step most runbooks skip — notifying the business owner of the data flow before notifying whoever usually gets the incident distribution list.
Our response sequence for a vendor-owned vulnerability, in order:
- Confirm the actual exposure: version, internet-facing or not, current patch level.
- Isolate or take the appliance offline pending a validated patch — don't wait for a maintenance window.
- Hunt for the specific published indicators for that product, not a generic scan.
- Rotate every credential, API key, and connection string the appliance held, whether or not you found evidence of misuse.
- Pull the data-flow map, loop in legal and communications on notification timelines, and start the clock from your discovery date, not the vendor's disclosure date.
- Patch, validate, and only then bring it back onto the internet.
The leak-site countdown is designed to make step five happen under pressure, on someone else's timeline. That's a reason to rehearse a vendor-breach scenario in a tabletop before it's live, not a reason to skip the sequence when it is. And when the postmortem is finally written, remember that Progress's postmortem covers Progress's code. Yours has to cover your exposure, your containment, and your notifications — independent of what the vendor publishes, and usually before they publish it.
If you're facing this
If you cannot currently produce a one-page list of every internet-facing, vendor-owned application running inside your Microsoft estate — with an owner and a data class for each — that is the finding, not a passing grade with an asterisk. We help Microsoft-centric IT teams build that inventory, map the data flows behind it, and stand up a response plan for the day the next one of these turns out to be a product you actually run. Bring us your architecture and your vendor list; we'll tell you honestly where the gaps are.