The Exchange ProxyLogon Attack: How Four Zero-Days Gave HAFNIUM Access to 250,000 Servers

‍‌‌‌​‌​​‌​‌‌‌‌‌​‌​‌‌​​​‌‌​​‌​​‌‌‌​‌‌‌‌‌‌​​‌‌‌​‌​‌‌‌‌‌‌‌​​‌​​​‌​‌​‍On 2 March 2021, Microsoft released emergency patches for four zero-day vulnerabilities in Exchange Server. All four were already being exploited in the wild. More than 250,000 servers were affected across the world. At least 30,000 organisations in the United States alone were compromised. The UK's National Cyber Security Centre (NCSC) described it as "the most significant and widespread cyber intrusion against the UK and allies ever observed."

The attack required no authentication. An attacker needed nothing more than network access to port 443 on an Exchange server and knowledge of which email account to target. A server-side request forgery (SSRF) vulnerability bypassed authentication entirely. A chain of post-exploitation bugs then delivered remote code execution as the SYSTEM user. Web shells deployed through the chain gave persistent access for credential dumping, lateral movement, and data theft.

Exchange Online wasn't affected by any of the four CVEs. Every compromised server was running on-premises Exchange 2013, 2016, or 2019. That distinction reshaped how the industry talks about self-hosted email infrastructure.

What everyone thinks happened

The typical version of this story focuses on HAFNIUM as a Chinese state-sponsored espionage group that targeted a handful of high-value organisations. That part is true, but it's only the first chapter.

What most accounts miss is the transition. HAFNIUM's initial campaign was targeted espionage, hitting defence contractors, law firms, higher education institutions, policy think tanks, and infectious disease researchers. That profile fits standard intelligence collection operations exactly. But around 26-27 February 2021, days before Microsoft released patches, exploitation went from targeted to indiscriminate. Tens of thousands of servers were compromised in a matter of days.

Then the situation deteriorated in a way nobody predicted. Within three weeks of the public disclosure, multiple additional threat groups adopted the exploit. The vulnerabilities were being used for ransomware deployment, cryptocurrency mining, and backdoor installation by criminal groups with no connection to the original espionage campaign. A set of bugs discovered by intelligence-grade operators ended up as commodity attack tools.

The other gap in the common narrative is timing. The researcher who found the vulnerability reported it to Microsoft on 5 January 2021. Patches from Microsoft didn't arrive until 2 March, nearly two months later. HAFNIUM was actively exploiting the bugs from at least 3 January, two days before the report even reached Microsoft. How did multiple groups obtain the exploit before the patch was even available? That question has never been fully resolved.

What actually happened

The vulnerability: CVE-2021-26855

Microsoft Exchange Server's Client Access Service (CAS) acts as a reverse proxy between external clients and internal backend services. Every Outlook Web Access (OWA) login, every ActiveSync connection, every Autodiscover request passes through this layer. The whole architecture is built to be internet-facing by default.

The vulnerability, CVE-2021-26855, was an SSRF in the CAS. The NVD gave it a CVSS v3.1 score of 9.8 out of 10, the highest severity band possible. The CVSS vector breaks it down: network accessible, low attack complexity, no privileges needed, no user interaction needed, high impact across confidentiality, integrity, and availability.

The root cause sat in the GetTargetBackEndServerUrl method, which calculated backend URLs for proxied requests. An attacker could send a crafted HTTP request to the frontend CAS. That request would be forwarded to any internal backend service. Because the backend trusts anything arriving from the CAS frontend, the attacker's requests were treated as authenticated server-to-server traffic. It's a classic trust boundary failure, and it should have been caught in code review.

Every version of Exchange Server from 2013 through 2019 was vulnerable. Microsoft also shipped a defence-in-depth update for Exchange Server 2010, which had already reached end of support in October 2020. The fact that they patched a product six months past end-of-life tells you how bad this was.

The exploitation chain

Orange Tsai, a researcher at DevCore (a Taiwanese security firm), independently discovered CVE-2021-26855 on 10 December 2020. By 27 December, DevCore had demonstrated that the SSRF could be escalated to a full authentication bypass granting administrator-level access. On 30 December, they discovered CVE-2021-27065, a post-authentication arbitrary file write that completed the chain from SSRF to remote code execution (RCE).

DevCore reported both vulnerabilities to Microsoft on 5 January 2021. Microsoft confirmed they'd received the report the following day.

The name "ProxyLogon" came from Orange Tsai because the chain exploited the Exchange proxy architecture and the internal /proxyLogon.ecp endpoint. All four vulnerabilities were logic bugs rather than memory corruption. That matters because logic bugs produce reliable, consistent exploitation across different Exchange versions and configurations.

Step one was the SSRF itself. The attacker sent a crafted request to the CAS on port 443. The GetTargetBackEndServerUrl method incorrectly calculated the backend URL from attacker-controlled cookie values, allowing the request to reach any internal Exchange service. This effectively gave the attacker the ability to make arbitrary HTTP requests as the Exchange server itself.

Step two was authentication bypass through an internal API. Using the SSRF, the attacker accessed the /proxyLogon.ecp endpoint on the backend Exchange Control Panel (ECP). The msExchLogonMailbox header wasn't blocked by the frontend when handling static resource requests. That let the attacker specify themselves as the SYSTEM user and generate a valid ECP session with full admin privileges. The frontend and backend disagreed about which headers should be filtered. That disagreement was the entire authentication bypass.

Step three was arbitrary file write to deploy a web shell. With admin access to ECP, the attacker changed Exchange virtual directory settings. They set the external URL of a virtual directory to contain web shell code. When Exchange saved that config change, it wrote the code to an ASPX file on disk. CVE-2021-27065 was the bug that allowed this file write. The result: a working web shell, accessible through the web server, sitting right alongside legitimate Exchange files.

Step four was post-exploitation with SYSTEM-level access. The web shell ran with Exchange server privileges, which means SYSTEM. From there, attackers dumped credentials using Procdump and Mimikatz. They stole copies of the Active Directory database (NTDS.DIT) for offline password cracking. They downloaded the Exchange offline address book, which contains org structure and contact details. They added new user accounts for persistent access. They moved laterally across the network. Once you have SYSTEM on the mail server, the domain is usually next.

The web shells

HAFNIUM deployed variants of the China Chopper web shell, a well-known tool that's been in use since at least 2012. China Chopper is notable for its size: many variants are a single line of ASPX code. That brevity makes detection harder because the web shell blends with legitimate Exchange ASPX files.

Microsoft documented multiple web shell deployment methods used across the campaign. Attackers wrote web shells using the echo command to create files directly. They also used certutil.exe to decode and place files, and powershell.exe for file creation. Common deployment paths included the Exchange ClientAccess and FrontEnd\HttpProxy directories, where the files would sit alongside hundreds of legitimate ASPX files.

The Cybersecurity and Infrastructure Security Agency (CISA) published seven Malware Analysis Reports identifying specific web shells associated with the campaign. Microsoft also released the Safety Scanner (MSERT) tool specifically updated to detect and remove these web shells from Exchange servers.

The timeline problem

The timeline is where this incident becomes particularly concerning.

Volexity, a security firm, detected the earliest known exploitation on 3 January 2021. Their monitoring service flagged unusual activity on two Exchange servers. Large volumes of data were being sent to IP addresses nobody recognised. Through memory analysis, Volexity worked out that the attacker was using the SSRF to steal mailbox contents.

DevCore reported the vulnerabilities to Microsoft on 5 January. Between January and late February, exploitation appeared targeted, focused on the sectors HAFNIUM typically pursues: defence, policy, healthcare, education, and legal.

Then around 26-27 February 2021, the pattern changed completely. On the same day Microsoft told DevCore that patches were nearly ready, security firms saw exploitation spike. The shift from targeted espionage to mass exploitation happened overnight. Tens of thousands of servers were hit in a matter of days. The timing raises an obvious question that nobody has publicly answered.

Microsoft released emergency patches on 2 March 2021, a week ahead of the scheduled Patch Tuesday. But mass exploitation had been running for several days before those patches existed.

By 5 March, investigative journalist Brian Krebs reported that at least 30,000 US organisations had been compromised. The victims included small businesses, local governments, towns, and cities alongside the higher-profile targets.

The spread beyond HAFNIUM

Within three weeks of the public disclosure, Microsoft's threat intelligence team documented multiple additional threat groups adopting the ProxyLogon exploit. The vulnerabilities that began as a state-sponsored espionage tool became commodity attack infrastructure.

The DearCry (DoejoCrypt) ransomware appeared on compromised Exchange servers, marking the transition from espionage to criminal exploitation. Cryptocurrency miners were deployed on vulnerable servers. Additional backdoors and implants were installed by groups with no apparent connection to the original HAFNIUM campaign.

This pattern of state-developed exploits cascading into criminal use has happened before and it'll happen again. Once the vulnerability details were public, capable attackers reproduced the exploit chain within days. At what point does detailed vulnerability disclosure stop being responsible and start being a blueprint?

Myth vs fact

Myth: Only large enterprises and government agencies were targeted.

HAFNIUM's initial campaign did focus on high-value targets: defence contractors, law firms, policy think tanks, and infectious disease researchers. But the mass exploitation phase that began around 26-27 February was entirely indiscriminate. At least 30,000 US organisations were compromised, and that figure included small businesses, local governments, and educational institutions with no intelligence value. The NCSC issued tailored advice to over 70 affected UK organisations, and the worldwide total exceeded 250,000 servers. If you had an internet-facing Exchange server, you were a target regardless of your size or sector.

Myth: Patching Exchange was sufficient to resolve the incident.

Applying the March 2021 patches closed the vulnerabilities but did nothing about servers that had already been compromised. Any Exchange server that was internet-facing before the patch was applied needed forensic investigation to determine whether web shells had been deployed. CISA's Emergency Directive ED 21-02 explicitly required federal agencies to perform forensic triage, search for indicators of compromise, and report any findings. The gap between "patched" and "clean" was the whole problem. Too many organisations treated patching as the end of their response when it should have been the start of forensic investigation.

Myth: Exchange Online was equally vulnerable.

Exchange Online, the cloud-hosted version included with Microsoft 365, was not affected by any of the four ProxyLogon CVEs. The vulnerabilities were specific to the on-premises Exchange Server architecture. The CAS proxy layer that made the exploit chain possible doesn't exist in the same form in the cloud version. That distinction drove the on-premises vs cloud debate for years. Moving to Exchange Online removes these specific attack vectors, but swaps them for different risks around tenant misconfiguration and supply chain trust in Microsoft's own infrastructure.

Myth: The exploit was extremely complex and impossible to anticipate.

The individual vulnerability classes involved were all well-documented. SSRF (CWE-918) has been in security taxonomies for years. Insecure deserialisation (CWE-502) is in the OWASP Top 10. Arbitrary file write through path traversal (CWE-22) is a textbook vulnerability class. What made ProxyLogon dangerous was the chaining of these bugs into a reliable unauthenticated RCE. They were logic bugs, not memory corruption, which made exploitation consistent across different targets. The architectural pattern of a frontend proxy that trusts backend services is a known risk area. Any security review of that design pattern should flag it.

What would have reduced the impact

Restricting direct internet access to Exchange servers would have eliminated the attack surface for most victims. The SSRF required network access to port 443 on the Exchange CAS. Placing Exchange behind a reverse proxy, a WAF, or a VPN cuts the pool of attackers who can reach the vulnerable endpoints. Does your mail server really need to be reachable from every IP address on the internet? For most organisations the answer should be no.

Network segmentation between the Exchange server and Active Directory would have limited lateral movement. After deploying web shells, attackers routinely dumped credentials and stole NTDS.DIT copies. If the Exchange server couldn't directly access domain controllers, the path from email server compromise to full domain takeover gets much harder. Most organisations don't segment this way, though. It's one of those things that's easy to recommend and hard to implement without breaking legitimate Exchange functionality.

Monitoring for indicators of compromise on Exchange servers would have caught the web shells before they were used. Unexpected ASPX files appearing in Exchange web directories, unusual child processes from the IIS worker process (w3wp.exe), and POST requests to OWA endpoints with suspicious parameters were all documented indicators. File integrity monitoring or EDR tooling on the Exchange server directories would have flagged these. But how many organisations were actively monitoring their Exchange server file system in 2021?

Emergency patching capability would have narrowed the exposure window. Microsoft released patches on 2 March 2021. Every day between patch release and patch application was a day of exposure. CISA's Emergency Directive required immediate action from federal agencies. Organisations with tested emergency patching processes applied updates within hours. Organisations without those processes were still exposed when criminal groups started mass exploitation days later.

Post-patch forensic investigation would have caught compromises that happened before patching. The patch closed the door. It didn't check whether someone had already walked through it. Microsoft released Test-ProxyLogon.ps1 to help organisations check whether their servers were compromised. The One-Click Mitigation Tool (EOMT), released on 15 March, automated both mitigation and scanning. Organisations that patched without investigating were running clean code on infrastructure that was already owned.

What changed after

Microsoft's response

Microsoft's response covered multiple fronts over the following weeks. The emergency out-of-band patches on 2 March were released a week ahead of the scheduled Patch Tuesday, reflecting the severity of active exploitation. The company published attribution analysis through the Microsoft Threat Intelligence Centre (MSTIC), linking the campaign to HAFNIUM with high confidence.

Over the following weeks, Microsoft released several more tools. The One-Click Mitigation Tool (EOMT) on 15 March gave organisations a quick path if they couldn't apply full patches right away. The Safety Scanner (MSERT) was updated to find and remove web shells from this campaign. Test-ProxyLogon.ps1 let admins check whether their servers had been compromised. Detailed guidance on checking for indicators of compromise came alongside the patches. (referenced in the quarterly triage benchmarking report).

Microsoft renamed HAFNIUM to Silk Typhoon in 2023 under their weather-based naming system. Silk Typhoon is still active as of 2025. They've shifted tactics toward IT supply chain attacks, abusing OAuth applications and service principals to steal data through the Microsoft Graph API.

Government response

CISA issued Emergency Directive ED 21-02 on 3 March, the day after patches dropped. It required all federal civilian agencies to either update or disconnect their Exchange servers. Alert AA21-062A followed with technical details and indicators of compromise. Supplemental directions on 31 March and 13 April required agencies to run Microsoft's forensic scripts and apply the April security update.

So here's where the response took an unusual turn. On 13 April 2021, the DOJ announced a court-authorised operation where the FBI accessed hundreds of vulnerable Exchange servers across the United States. They copied and removed web shells that server operators hadn't cleaned up themselves. Federal law enforcement actively logging into private servers under court order to remove malicious code was something that had never happened before in the US.

International attribution

On 19 July 2021, the UK, US, EU, and NATO jointly attributed the campaign to actors connected to China's Ministry of State Security (MSS). The NCSC assessed with high confidence that HAFNIUM, associated with the Chinese state, was responsible. Getting that many nations to agree on public attribution is rare. The coordinated statement was one of the strongest collective responses to state-sponsored cyber operations to date.

The DOJ later indicted Xu Zewei and Zhang Yu, both Chinese nationals, for computer intrusions between February 2020 and June 2021 that included the HAFNIUM campaign. The indictment named officers of the MSS's Shanghai State Security Bureau as directing the activity. Whether indictments against individuals operating under state protection achieve anything meaningful is another question entirely.

ProxyShell: the sequel

ProxyLogon wasn't the end of Exchange proxy architecture vulnerabilities. Orange Tsai's broader research uncovered at least eight vulnerabilities in Exchange's proxy layer. Three of them formed a second exploit chain called ProxyShell.

ProxyShell chained three bugs: CVE-2021-34473 (pre-authentication SSRF, CVSS 9.8), CVE-2021-34523 (privilege escalation to Exchange PowerShell, CVSS 9.8), and CVE-2021-31207 (arbitrary file write via mailbox export, CVSS 7.2). The result was another unauthenticated RCE chain against Exchange Server.

Microsoft patched the ProxyShell CVEs in April and May 2021. Orange Tsai presented the research publicly at Black Hat USA in August 2021. Mass exploitation started immediately after the talk. CISA issued an urgent alert on 21 August specifically warning about active ProxyShell exploitation.

Both ProxyLogon and ProxyShell appeared in CISA's Top Routinely Exploited Vulnerabilities lists for 2021 and 2022. Organisations were still running unpatched Exchange servers years after fixes were available. As of January 2025, Exchange Online started throttling inbound mail from on-premises Exchange 2019 servers that still lacked ProxyLogon patches. Nearly four years after the original disclosure, and some servers still weren't patched.

The cloud migration conversation

The fact that Exchange Online was unaffected while on-premises installations were devastated accelerated conversations about self-hosted email infrastructure across every sector. Microsoft offered FastTrack migration assistance for eligible customers with 500 or more licences.

The incident didn't settle the on-premises versus cloud debate, but it changed the terms permanently. Running on-premises Exchange now means justifying the security burden of patching internet-facing infrastructure against state-sponsored zero-days. For organisations without dedicated security teams, that burden is probably too heavy. Whether the trade-off of trusting Microsoft's cloud security instead is actually better is a question that still doesn't have a clean answer.

---

---

Related articles

• The MOVEit Breach: How SQL Injection Gave Cl0p Access to 2,773 Organisations
• The SolarWinds SUNBURST Attack: How Clean Source Code Produced a Backdoor
• The WannaCry Ransomware Attack: How a Kill Switch Stopped a Global Worm
• The Colonial Pipeline Attack: How DarkSide Shut Down US Fuel Distribution

netsec-canary-34777e721956.