Microsoft Exchange — Hafnium ProxyLogon

What happened

On 2 March 2021, Microsoft published patches for four critical vulnerabilities in on-premises Microsoft Exchange Server — Exchange 2013, 2016, and 2019 — and simultaneously published a blog post attributing active exploitation to a Chinese state-sponsored threat actor it called Hafnium. The four vulnerabilities, quickly nicknamed ProxyLogon after the primary bug (CVE-2021-26855), could be chained together to allow an unauthenticated remote attacker to read emails from any mailbox on the server and to install persistent web shells enabling ongoing remote access.

Hafnium had been exploiting the vulnerabilities since at least January 2021, using them for targeted espionage against research institutions, defence contractors, law firms, and infectious-disease researchers. But the story did not end with Hafnium. In the period between Microsoft’s advance notification of the patches to selected partners and the public patch release — a window intended to give critical organisations time to prepare — the vulnerabilities became known to other Chinese-linked threat actor groups. By the time patches were publicly released on 2 March, multiple other groups were already conducting mass exploitation, and within days an estimated 60,000 or more on-premises Exchange servers globally had been compromised with web shells and other persistent access.

CISA issued an Emergency Directive on 3 March requiring all US federal civilian agencies to patch immediately. The scale of compromise among small and medium-sized organisations — who lacked the operational capacity to patch within hours — was substantial. In April 2021, the FBI obtained a court order authorising it to remotely access and remove Hafnium-linked web shells from hundreds of compromised US Exchange servers without the owners’ knowledge or consent, in an operation described as the first of its kind. The US, UK, EU, and NATO governments collectively attributed the Hafnium campaign to China’s Ministry of State Security in July 2021.

How it worked

The four vulnerabilities chained together in ProxyLogon addressed separate stages of the attack path. CVE-2021-26855 was a server-side request forgery (SSRF) vulnerability in Exchange’s authentication handling that allowed an attacker to send requests as if they were the Exchange server itself, bypassing authentication. CVE-2021-27065, used in combination with the SSRF flaw, was a post-authentication arbitrary file write vulnerability. Together with two additional privilege-escalation vulnerabilities (CVE-2021-26857 and CVE-2021-26858), the chain allowed an unauthenticated attacker who could reach port 443 on an Exchange server to authenticate as the server, read any mailbox, and write files anywhere on the filesystem.

The practical attack sequence was: use the SSRF to authenticate as the Exchange server; use the file write to drop a web shell (most commonly a variant of China Chopper, a small ASPX file) into a publicly accessible web directory on the server; then use the web shell for persistent command execution, further lateral movement, and data exfiltration, entirely independently of the original Exchange vulnerabilities.

The web shell persistence was the element that made the mass-exploitation scenario so damaging and so difficult to remediate. Even organisations that patched Exchange promptly after 2 March may have already had web shells installed during the preceding days’ exploitation window. Patching the Exchange vulnerabilities did not remove existing web shells; each web shell had to be identified and removed separately. Many organisations did not realise they had been compromised, meaning web shells installed during the window remained in place for weeks, months, or indefinitely in some cases.

The advance notification window — the period during which Microsoft informed selected partners of the patches before public release — became a controversial element of the post-incident analysis. Evidence suggested that the vulnerability details leaked from within that window, triggering the mass exploitation by non-Hafnium actors before patches were publicly available. This created a structural tension between the benefit of advance notification (giving large and capable organisations time to prepare) and the risk (the information becoming available to threat actors before the general population can defend themselves).

Timeline

• January 2021 — Hafnium begins exploiting ProxyLogon vulnerabilities against targeted organisations including universities, defence contractors, and infectious-disease researchers.
• 5 January 2021 — DEVCORE security researcher “Orange Tsai” reports the ProxyLogon SSRF vulnerability to Microsoft.
• Mid-to-late February 2021 — Evidence suggests vulnerability information leaks; multiple Chinese-linked groups begin exploitation beyond Hafnium’s targeted operations.
• 26 February 2021 — Volexity researchers, who had been tracking Hafnium activity independently, contact Microsoft with their findings; exploitation is already widespread.
• 2 March 2021 — Microsoft releases emergency out-of-cycle patches; publishes Hafnium attribution; CISA issues Emergency Directive 21-02.
• 3 — 9 March 2021 — Mass exploitation accelerates; KrebsOnSecurity reports at least 30,000 US organisations compromised; global estimate reaches 60,000+. Ransomware groups begin exploiting web shells left by earlier actors.
• 13 April 2021 — US Department of Justice announces court-authorised FBI operation to remotely remove web shells from hundreds of US Exchange servers.
• July 2021 — US, UK, EU, NATO, and allies collectively attribute the Hafnium campaign to China’s MSS; the US formally charges four MSS officers.

What defenders should learn

ProxyLogon’s most important lesson is about the architecture of on-premises infrastructure exposure. An on-premises Exchange server is, by design, internet-accessible: it needs to accept email from the outside world and to serve Outlook Web Access to remote users. This means that a critical vulnerability in Exchange is exposed to every attacker on the internet the moment it is known. The patch window — measured in hours if the vulnerability is already being exploited — is far shorter than the operational cycle most IT teams are accustomed to for routine patching. For internet-exposed critical infrastructure, patching speed is itself a security control, and organisations that cannot achieve hours-to-patch cadence for critical internet-facing components are accepting a material risk.

The web shell persistence problem illustrates the difference between patching a vulnerability and remediating an incident. Patching Exchange stopped new compromises; it did nothing about the web shells already installed. Any organisation that runs internet-facing infrastructure should have a process for confirming that no web shells, scheduled tasks, or other persistent access mechanisms exist — especially in the aftermath of a widely-publicised mass-exploitation event. The FBI’s court-authorised remote remediation operation acknowledged, implicitly, that a large fraction of the affected population had not detected and removed their web shells weeks after the public disclosure.

The advance-notification window dilemma has not been fully resolved. Microsoft and other vendors continue to use advance notification programmes that give critical organisations — government agencies, large infrastructure operators — time to prepare patches before general release. The ProxyLogon episode demonstrated that this creates a leak risk that can result in mass exploitation before the majority of the affected population can defend themselves. The tension between targeted advance preparation and mass-market exposure risk is an unresolved challenge in the coordinated vulnerability disclosure ecosystem.

Finally, ProxyLogon is one of the strongest arguments for accelerating migration from on-premises Exchange to cloud-hosted email. Microsoft 365’s Exchange Online was not affected by the ProxyLogon vulnerabilities; the attack surface exists only on on-premises installations. The breach significantly accelerated migration decisions among mid-sized organisations that had been delaying on-premises-to-cloud transitions. The organisational argument against migration — cost, data residency, control — looks different when the alternative is maintaining an internet-exposed server that depends on patch cadence for its security posture.