ProxyLogon: pre-auth SSRF in Exchange

ProxyLogon is the bug that made "patch immediately" insufficient advice, because by the time most organisations patched they had already been backdoored.

#The bug

Exchange has a front-end/back-end split. The Client Access Service takes the request, works out which mailbox server should handle it, and proxies it onward. The back-end trusts the front-end — it has to, because the front-end has already done the authentication.

The front-end decided where to proxy based partly on a cookie the client supplied. Set the X-AnonResource-Backend cookie and you influence the destination of that internal request.

That is a server-side request forgery, and it is pre-authentication. But the important part is what it forges into: a request that arrives at the back-end already carrying the trust the front-end confers. The SSRF does not just let you reach internal hosts — it lets you reach Exchange's own back-end as Exchange, which means as a highly privileged identity inside the mail environment.

On its own that is a serious information-disclosure bug: read any user's mailbox without credentials.

#The chain

CVE-2021-26855 was disclosed alongside three others, and they were designed to be used together:

CVE	Role in the chain
2021-26855	Pre-auth SSRF — gets you in as Exchange
2021-26857	Insecure deserialisation in the Unified Messaging service — SYSTEM
2021-26858	Post-auth arbitrary file write
2021-27065	Post-auth arbitrary file write

The canonical path is 26855 → 27065: use the SSRF to satisfy the "authenticated" requirement of the file-write bug, then write a .aspx web shell into a directory that Exchange serves. Now you have unauthenticated RCE on a mail server, and mail servers are, by design, where the organisation's most sensitive content lives.

This is the part worth studying. Each individual bug is bounded. The chain is what makes it a 9.8 — a pre-auth SSRF supplying the authentication context that a post-auth file-write needs. When you triage a "medium" SSRF, the question is not what it reads; it is what it authenticates you as.

#Why the timeline mattered

Microsoft patched on 2 March 2021, out of band. Within days, exploitation went from a small number of targeted intrusions to indiscriminate mass scanning — multiple distinct groups spraying the entire IPv4 space and dropping web shells on anything that answered. Tens of thousands of servers were shelled in under a week, many belonging to organisations with no plausible intelligence value.

The result: patching after the fact did nothing for the already-compromised. A web shell dropped on 3 March survives the 8 March patch perfectly well. The FBI eventually obtained a court order to remotely remove web shells from US servers — an unprecedented intervention, and a fair measure of how badly the patch-only response had failed.

So the correct response was patch and hunt, in that order, assuming compromise until disproven.

#Detection

This one leaves excellent forensic evidence, which is the silver lining:

• IIS logs. The SSRF shows as requests to /ecp/ or /owa/ paths carrying an X-AnonResource-Backend or X-BEResource cookie. Look for POST to /ecp/y.js and similar — the public exploit chains used recognisable paths.
• Web shells on disk. Check the Exchange virtual directories, particularly \FrontEnd\HttpProxy\owa\auth\ and \aspnet_client\. Any .aspx in those paths with a recent timestamp that is not shipped by Exchange is the finding.
• Exchange logs. HttpProxy logs record the anonymous back-end requests; the ECP server logs record the file-write operations.
• Microsoft published a dedicated script (Test-ProxyLogon.ps1) and the Safety Scanner (MSERT) specifically for this, and they remain the fastest triage for a server that was exposed in early 2021.

#Fixing it

Patch to the March 2021 cumulative update or later. Then hunt, per the above — and if you find a shell, treat it as a full intrusion, not a file to delete. Credentials on that box, and every mailbox on it, should be considered read.

Structurally: on-premises Exchange is an enormous attack surface that must be internet-reachable to do its job. ProxyLogon was followed by ProxyShell, ProxyNotShell and ProxyNotFound, all in the same architecture. If the mail server is still on-prem, the front-end should be behind an identity-aware proxy so that pre-auth code paths are not exposed to the internet at all.

#What generalises

Internal trust boundaries that assume "this request came from our own front-end, so it is already authenticated" break the moment an attacker can make the front-end issue arbitrary requests. If a component's authorisation model rests on where a request came from rather than who it is from, an SSRF anywhere upstream collapses the whole model.

And: severity is a property of chains, not of individual findings.