In January 2021, on-premises Exchange servers started falling to a chain of four vulnerabilities that required no credentials and no user interaction. By early March, mass exploitation was underway from at least ten distinct threat groups, including state-sponsored ones.
The technical detail is worth understanding even now, because the root causes are not Exchange-specific.
The four bugs
The chain was published as CVE-2021-26855, -26857, -26858, and -27065. They matter in a specific order:
| CVE | Type | Role in the chain |
|---|---|---|
| CVE-2021-26855 | SSRF | Bypass authentication |
| CVE-2021-26857 | Deserialisation | Escalate to SYSTEM |
| CVE-2021-26858 | Arbitrary file write | Drop the web shell, authenticated |
| CVE-2021-27065 | Arbitrary file write | Drop the web shell, unauthenticated |
The SSRF that starts everything
The entry point is a server-side request forgery in the Client Access Service. Exchange front-end components use a cookie — X-BEResource — to decide which back-end server handles a request. The value is deserialised without adequate validation.
The practical consequence: by setting the cookie to a value pointing at the local back end, an attacker can issue requests that appear to come from a trusted internal source. Authentication checks that live in the front end are bypassed entirely.
GET /ecp/DDI/DDIService.svc/GetObject HTTP/1.1
Host: mail.example.com
Cookie: X-BEResource=localhost~1942062522
Content-Type: application/json
Once that works, the attacker is effectively an authenticated ECP user without ever holding a credential — which is why the write primitives behind it (CVE-2021-27065 in particular) were exploitable unauthenticated.
Dropping the shell
CVE-2021-27065 lives in the ECP “logon page” settings. The ExternalUrl field was not validated, so writing a value containing a path traversal put attacker-controlled content anywhere the ECP application pool could reach:
POST /ecp/DDI/DDIService.svc/SetObject?schema=VirtualDirectory&msExchEcpCanary=...
The payload placed an .aspx file into a scriptable directory, and the attacker then requested it directly. From there it was a normal web shell: command execution as the Exchange application pool, which is a highly privileged account in most deployments.
Why it was so damaging
Three factors compounded:
- Internet-facing by design. Exchange Web Services, OWA, and ECP are routinely published without a reverse proxy that could have broken the
X-BEResourcehandling. - Default configurations were vulnerable. No unusual settings required.
- Post-exploitation was trivial. Once you have code execution as the Exchange service account, you can read mailboxes directly from the database, and that account typically has broad AD read rights.
The last point is the one people underestimate. Mailbox access is not a secondary impact — for many organisations it is the entire impact.
What to take from it
For defenders, the lessons that generalised:
- Patch exchange servers the day updates land. Not the sprint after.
- Check for web shells after patching, not instead of it. A survey after the fact found thousands of unpatched servers that had already been compromised; patching closed the door but left the intruder inside.
- Don’t publish ECP to the internet. It is an administrative interface. Treat it like one.
- Hunt for the artefacts, not the CVE: unexpected
.aspxfiles in Exchange virtual directories,w3wp.exespawningcmd.exeorpowershell.exe, and outbound connections from Exchange to new hosts.
For anyone studying vulnerability chains, this is a good case study in how three mediocre bugs become critical when a fourth removes authentication from the equation.