ProxyShell Step by Step: How Three Exchange Flaws Chain Into Remote Code Execution in a Lab

Microsoft Exchange runs the email of thousands of organisations, usually exposed to the internet, usually holding highly privileged network positions. ProxyShell is the name for a chain of three Exchange vulnerabilities that together let an unauthenticated attacker execute code on the server. This article explains the chain step by step for a lab, with detection and a verified fix.

Disclosure: This article was researched and written with AI assistance, and it was checked for accuracy and originality before publishing.

Everything below is for an isolated lab you own, built with an unpatched Exchange version you install only for training. Never run these steps against a real mail server you do not own or have explicit written permission to test. Exchange exploitation in the wild has led directly to ransomware, so treat any real world sign of it as an incident.

The vulnerability, explained simply

ProxyShell chains three publicly disclosed vulnerabilities.

1. CVE 2021 34473, a pre authentication path confusion in the Autodiscover service that lets an attacker reach backend URLs as the Exchange machine account.

2. CVE 2021 34523, a privilege elevation flaw in the Exchange PowerShell backend that lets the attacker impersonate a privileged user.

3. CVE 2021 31207, a post authentication arbitrary file write that lets the attacker write a file the server will execute, which is how a web shell is planted.

The first two were patched in April 2021 in KB5001779 and the third in May 2021 in KB5003435, although the advisories for the first two were only published in July 2021. That gap is part of why so many servers stayed exposed. A clear public chain analysis is in the Mandiant and Google Cloud writeup at https://cloud.google.com/blog/topics/threat-intelligence/pst-want-shell-proxyshell-exploiting-microsoft-exchange-servers and in the Rapid7 analysis at http://www.rapid7.com/blog/post/2021/08/12/proxyshell-more-widespread-exploitation-of-microsoft-exchange-servers/

The core idea is trust confusion. Exchange front end and backend services decide who you are in different ways. The path confusion tricks the front end into forwarding a request the backend treats as coming from the server itself, with system level trust. Once the backend believes the request, privilege elevation supplies a user identity, and the file write turns that access into code execution.

Lab setup

Build this lab fully isolated. Exchange is heavy, so give the machines real resources and snapshot often.

1. Create a virtual domain with a domain controller and a separate Exchange Server virtual machine, installed at a version below the April and May 2021 security updates, on an isolated virtual network with no internet route.

2. Create one normal mailbox user and one administrator mailbox for identity steps, both owned by you.

3. Snapshot both machines in the clean unpatched state.

4. Use a third machine on the same isolated network as the attacker machine, with a browser, a proxy and scripting tools.

5. Turn on IIS logging, Exchange PowerShell logging and file integrity watching on the Exchange web directories before you begin.

Confirm normal mail flow inside the lab first, so later failures are attributable to the exploitation steps and not to a broken install.

Exploitation, step by step

Step 1. Probe Autodiscover. Send the lab server an Autodiscover request shaped so that the explicit logon part of the URL is removed during normalisation, which is the path confusion at the heart of CVE 2021 34473. Public analyses describe this as accessing an arbitrary backend URL as the Exchange machine account. In the lab, a backend response that should require authentication is your first success signal.

Step 2. Learn a target identity. Use the Autodiscover access to obtain the distinguished name of your lab mailbox user, then use the MAPI HTTP path described in public incident analyses to obtain that user security identifier. Both values belong to your own lab accounts. Record them exactly, because the next step needs them.

Step 3. Elevate through the PowerShell backend. Send a request to the PowerShell backend carrying the identity token material described in public analyses, so the backend restores the session as your lab administrator. A successful PowerShell session in the lab, obtained without that administrator password, proves CVE 2021 34523 in your build.

Step 4. Write the shell file. Use the privileged PowerShell access to export a mailbox item to a path inside a web accessible Exchange directory, which is the arbitrary file write of CVE 2021 31207. In the lab, the exported content contains a simple marker that prints a fixed word when called. Keep the marker harmless and unique.

Step 5. Call the marker. Browse to the written file from your attacker machine. If the fixed marker word returns, the full chain has produced remote code execution in the lab. Stop there. Do not dump credentials, do not move laterally and do not install persistence, even in the lab. The chain is proved.

Step 6. Preserve evidence and reset. Save the IIS logs, the PowerShell logs and the written file name, restore the snapshots, and repeat the detection review below against your own logs so you learn what each step looks like.

What the attacker gains

A successful ProxyShell chain gives code execution as SYSTEM on the Exchange server. In real incidents documented by Mandiant and others, attackers used that position to plant web shells, steal credentials, install ransomware and return to the same unpatched server repeatedly. Exchange also holds mailbox data directly and often sits close to domain privilege, so the blast radius is far larger than one web server.

How defenders detect it

1. Hunt IIS logs for Autodiscover requests with unusual backend paths and for PowerShell backend access from external addresses, using the status code and path patterns described in the Mandiant writeup linked above.

2. Watch Exchange web directories for new script files, especially outside patching or deployment windows.

3. Enable and review PowerShell module, script block and transcription logging, and deploy endpoint detection on every Exchange server.

4. Use file integrity monitoring on web roots, because the file write step must land somewhere the server serves.

5. Assume compromise if an unpatched server was internet facing during an exploitation wave. Patching alone does not remove a shell that is already planted, so run a dedicated shell hunt and credential review.

How to fix it and verify the fix

Install the Exchange security updates that close all three flaws, KB5001779 and KB5003435, or a later cumulative update that includes them, and confirm the build number matches the patched level using the Microsoft version reference named in the Mandiant guidance.

Where patching must wait hours rather than days, reduce exposure by restricting internet access to the Exchange server at the network edge. That is a short emergency measure only. It is not a fix.

Verify the fix in three ways. First, confirm the installed Exchange build number is at or above the patched build. Second, repeat the lab Autodiscover path confusion probe against the patched lab build and confirm the backend no longer answers as the machine account. Third, run a web shell hunt across the Exchange directories and review PowerShell and IIS logs for the period the server was unpatched, and only then close the finding.

Closing takeaways

ProxyShell is a chain, not a single bug. Defenders who rated each flaw alone underestimated the combined result, which is unauthenticated code execution on a critical server.

Patch delay was the real enabler. The fixes existed before the public exploitation wave, and servers that applied them early were not part of that wave.

Verify with both a build check and a behaviour check, and hunt for shells whenever an unpatched server was exposed. A patched server with a planted shell is still a compromised server.

Sources credited in this article: the Mandiant and Google Cloud ProxyShell writeup and the Rapid7 ProxyShell analysis, both linked in the body above. All research is based on publicly disclosed material only, and all exploitation steps are described for an isolated lab only.

Tags: Cybersecurity, ProxyShell, Microsoft Exchange, Penetration Testing, Vulnerability Management

Written by Muhammad Asim Shahzad, SVP Head Application Security and VAPT at UBL, with thirteen plus years in offensive security, HackerOne Top 100 history, Synack Red Team experience and CVE 2021 31521 to his name. More writing and services at protector47.com. Connect with Asim on LinkedIn at https://www.linkedin.com/in/protector47 and find his public researcher history through HackerOne under the name protector47.