CVE-2021-34473 Explained: ProxyShell, the Pre-Auth Exchange RCE Chain
Three chained Exchange Server vulnerabilities enabling unauthenticated remote code execution. Mass exploitation within 48 hours of technical details going public. LockFile, BlackByte, and Hive ransomware all deployed via ProxyShell.
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
ProxyShell is an exploit chain combining three Microsoft Exchange Server vulnerabilities: CVE-2021-34473 (a pre-authentication path confusion), CVE-2021-34523 (an Exchange privilege elevation), and CVE-2021-31207 (a post-authentication arbitrary file write). Together, they allow an unauthenticated attacker with network access to an Exchange server to achieve remote code execution by deploying a web shell.
Discovered and presented by security researcher Orange Tsai at Black Hat USA 2021, ProxyShell went from public technical disclosure to mass exploitation within 48 hours. Multiple ransomware groups, including LockFile, BlackByte, Hive, and Conti, deployed ransomware via ProxyShell-planted web shells within weeks of the technique becoming public.
The Three-CVE ProxyShell Chain Explained
The ProxyShell chain exploits the architecture of Microsoft Exchange's Client Access Service (CAS), specifically, how the CAS acts as a proxy between external requests and Exchange's backend services.
CVE-2021-34473 is a pre-authentication path confusion vulnerability in the CAS. Exchange's URL routing treats explicit URL paths differently from normalized paths. By manipulating the URL with specific patterns, an attacker can reach the Exchange backend's PowerShell endpoint, which is normally only accessible from internal interfaces, through the externally exposed CAS without authentication.
CVE-2021-34523 is a privilege elevation flaw in the Exchange PowerShell backend. When the backend processes requests relayed through the CAS without valid authentication tokens, it fails to properly validate the identity, allowing the attacker to impersonate any Exchange mailbox user, including the SYSTEM account or a domain administrator with a mailbox.
With these two CVEs chained, the attacker has unauthenticated access to Exchange PowerShell running as an arbitrary user. CVE-2021-31207 completes the chain: a PowerShell cmdlet (New-MailboxExportRequest) can be abused to export a specially crafted mailbox message, containing embedded ASPX web shell code in its body, to a file path within Exchange's web root. The exported file has an .aspx extension, making it executable as a web shell by the IIS server hosting Exchange OWA.
Exploit CVE-2021-34473: Path confusion to backend
Send a crafted HTTPS request to the Exchange CAS using a URL pattern that exploits the path normalization difference, causing the CAS to proxy the request to Exchange's backend PowerShell endpoint without an authentication token.
Exploit CVE-2021-34523: Impersonate any user
With access to the backend PowerShell endpoint without a valid token, exploit the identity validation flaw to impersonate an arbitrary mailbox user. Commonly used to impersonate a Domain Admin account that has an Exchange mailbox.
Create a mailbox with web shell content
Send PowerShell commands to create or access a mailbox. Send an email to that mailbox whose body contains ASPX web shell code, a JSP-equivalent script that will execute when the file is requested via HTTP.
Export mailbox message to web root (CVE-2021-31207)
Use New-MailboxExportRequest to export the mailbox (containing the web shell email) to a .aspx file path in the Exchange web root. Exchange's export mechanism writes the mailbox content, including the embedded ASPX code, to the specified file.
Execute web shell
Request the exported ASPX file via HTTPS. IIS executes the embedded web shell code, providing persistent RCE on the Exchange server with Exchange service account privileges, typically NETWORK SERVICE or a highly privileged account.
Mass Exploitation and Ransomware Deployment
Microsoft patched the ProxyShell CVEs between April and May 2021, but technical details sufficient to reproduce the exploit were not public until Orange Tsai's Black Hat USA presentation in early August 2021. Within 48 hours of the presentation, security researchers had reconstructed working exploit code, and mass scanning for vulnerable Exchange servers began.
Within a week, multiple threat actors were deploying web shells on unpatched Exchange servers at scale. The subsequent weeks saw ransomware operators use ProxyShell-planted web shells for initial access:
LockFile ransomware used ProxyShell for access followed by PetitPotam exploitation for lateral movement. BlackByte ransomware operators were confirmed using ProxyShell in multiple enterprise intrusions. Hive ransomware affiliates used ProxyShell as one of their primary initial access vectors in the second half of 2021. Conti ransomware affiliates incorporated ProxyShell into their playbooks.
The rapid ransomware adoption reflects the high value of Exchange as a target: organizations running on-premises Exchange typically have it in a central network position with access to Active Directory, file shares, and other critical internal resources, making it an ideal pivot point for ransomware lateral movement.
“ProxyShell is a pre-authentication remote code execution exploit chain that allows any unauthenticated attacker to take over Microsoft Exchange. Attackers are actively scanning for and exploiting vulnerable systems.”
Orange Tsai, Black Hat USA 2021
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Patching and Detecting ProxyShell Compromise
Microsoft released patches between April and July 2021. Organizations that applied the May 2021 cumulative updates are protected. The following steps address both patching and post-exploitation detection.
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.
The bottom line
ProxyShell is the third in a trilogy of Exchange CAS architecture vulnerabilities discovered by Orange Tsai (after ProxyOracle and ProxyLogon). All three exploited the same fundamental architectural pattern: the Client Access Service's proxy behavior creating a path by which external requests can reach internal Exchange backend services with manipulated or absent authentication.
Microsoft has addressed the individual CVEs in each chain. The architectural root cause, the complexity of Exchange's multi-tier request routing, is not something a single patch cycle resolves. On-premises Exchange continues to present a large, complex attack surface that requires active patching, monitoring, and investigation.
The ProxyShell ransomware wave demonstrated that time from exploit publication to ransomware deployment is now measured in days, not weeks. Any organization running unpatched Exchange when a critical exploit goes public should operate on the assumption of compromise and investigate actively, not wait for symptoms to appear.
This analysis is generic — the platform version scores threats like this against your own stack.
Frequently asked questions
What is ProxyShell (CVE-2021-34473) and how does the exploit chain work?
ProxyShell is a three-vulnerability exploit chain in Microsoft Exchange Server. CVE-2021-34473 exploits path confusion in Exchange's Client Access Service to reach the backend PowerShell endpoint without authentication. CVE-2021-34523 then impersonates any mailbox user. CVE-2021-31207 abuses the New-MailboxExportRequest cmdlet to write an ASPX web shell to Exchange's web root. The result is unauthenticated remote code execution, a persistent web shell accessible from the internet, achieved through a sequence of three HTTP requests.
How do I fix CVE-2021-34473 (ProxyShell)?
Apply the May 2021 or later Cumulative Update for Exchange Server 2013, 2016, and 2019. All three ProxyShell CVEs are addressed. After patching, scan Exchange web directories for unauthorized ASPX files in C:\inetpub\wwwroot\aspnet_client\ and Exchange OWA auth directories. Search IIS logs for POST requests to /autodiscover/autodiscover.json with 200 responses from external IPs. Any Exchange server unpatched during August-September 2021 should be treated as potentially compromised.
Which ransomware groups used ProxyShell?
Multiple ransomware groups incorporated ProxyShell into their initial access playbooks. LockFile used ProxyShell combined with PetitPotam for lateral movement. BlackByte ransomware operators were confirmed exploiting ProxyShell in enterprise intrusions. Hive ransomware affiliates used ProxyShell as a primary initial access vector. Conti affiliates also incorporated it. The common pattern was: ProxyShell web shell planted, dormant for weeks, then ransomware deployment during the follow-on intrusion phase.
How does ProxyShell differ from ProxyLogon (CVE-2021-26855)?
Both ProxyShell and ProxyLogon are Exchange Server exploit chains that achieve unauthenticated RCE, but they exploit different architectural weaknesses. ProxyLogon (CVE-2021-26855) exploits a server-side request forgery flaw in Exchange's Client Access Service that allows bypassing authentication to reach the backend. ProxyShell (CVE-2021-34473) exploits path confusion in the same CAS architecture but chains three separate CVEs, including a privilege elevation and a file write, to plant a web shell. ProxyShell was disclosed after ProxyLogon but is a fully independent vulnerability chain, not a variant.
Is Microsoft Exchange Online (Office 365) affected by ProxyShell?
No. Exchange Online is Microsoft's cloud-hosted Exchange service, and its infrastructure is managed and patched by Microsoft. Only on-premises Exchange Server 2013, 2016, and 2019 are affected by ProxyShell. Organizations that had fully migrated to Exchange Online before the ProxyShell exploitation wave had no on-premises Exchange servers exposed. Organizations running hybrid configurations, where some mailboxes are on-premises and others are in Exchange Online, were at risk if their on-premises Exchange servers were unpatched.
How do I find ProxyShell web shells planted on my Exchange server?
Search for unauthorized ASPX files in key Exchange directories using: dir /s /b C:\inetpub\wwwroot\aspnet_client\ to find files in the classic web shell drop location; dir /s /b "C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\" for the OWA auth directory; and check the Exchange Autodiscover directory. Review IIS logs for POST requests returning HTTP 200 from external IPs to autodiscover and EWS URLs. Also audit Exchange PowerShell logs for New-MailboxExportRequest commands targeting web-accessible paths.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.