ProxyShell Exploit on Exchange: Stop Remote Code Execution Fast

Quick Fix (30 Seconds): Check Your Patch Status

Before anything else, see if you're already patched. Open PowerShell as admin and run:

Get-HotFix -Id KB5001779, KB5003435, KB5005013

If any of those show up, you're patched for CVE-2021-34473 — but don't stop yet. That patch alone isn't enough if the exploit already ran. I had a client last month who had the patch but still got hit because the attacker dropped a web shell before the update.

If nothing shows, your server is wide open. Skip to the moderate fix below — you need to patch now.

Moderate Fix (5 Minutes): Block the Exploit with IIS URL Rewrite

While the patch installs, you can block the exploit path immediately. ProxyShell abuses the Autodiscover endpoint and the PowerShell virtual directory. Here's the quickest way to shut it down:

1. Open IIS Manager.
2. Go to your Exchange site (usually 'Default Web Site').
3. Double-click 'URL Rewrite' (if not installed, install the IIS URL Rewrite Module 2.1 from Microsoft.com).
4. Click 'Add Rule(s)' > 'Request Blocking'.
5. Set the rule: Pattern: .*autodiscover.*powershell.* (case-insensitive, regex).
6. Action: 'Abort request'.
7. Apply and restart IIS with iisreset.

That blocks the specific path the exploit uses. It's not a permanent fix — you still need the patch — but it buys you time. One of my clients had 500+ Exchange servers and this rule stopped the bleeding while the patch rolled out.

Advanced Fix (15+ Minutes): Full Cleanup and Hardening

If you suspect the exploit already ran — and honestly, if you're not sure, assume it did — do this:

Step 1: Kill Active Malicious Processes

Open PowerShell as admin. Run:

Get-Process -Name w3wp, powershell | Where-Object { $_.StartTime -gt (Get-Date).AddHours(-2) } | Format-List Id, StartTime, ProcessName

Look for any w3wp.exe or powershell.exe that started recently but doesn't match expected time windows. Kill suspicious ones by PID:

Stop-Process -Id [PID] -Force

Step 2: Scan for Web Shells

ProxyShell drops web shells into Exchange directories. Check these folders for any .asp or .aspx files that don't belong:

• C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy
• C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess
• C:\inetpub\wwwroot

Use PowerShell to find recent files:

Get-ChildItem -Path 'C:\Program Files\Microsoft\Exchange Server\V15' -Recurse -Include *.asp, *.aspx | Where-Object { $_.LastWriteTime -gt (Get-Date).AddDays(-7) }

Delete anything suspicious. I once found a file named shell.aspx that was 2KB — attacker's backdoor.

Step 3: Apply the Correct Patch from Microsoft

Download and install the Security Update for Microsoft Exchange Server 2016/2019 corresponding to your build. For Exchange 2016 CU22, it's KB5005013. For Exchange 2019 CU11, same KB. Reboot after install.

Step 4: Lock Down the PowerShell Virtual Directory with ACL Changes

ProxyShell works because the PowerShell virtual directory allows unauthenticated access via Autodiscover. Change that:

1. Open Exchange Management Shell as admin.
2. Run: Get-PowerShellVirtualDirectory | Set-PowerShellVirtualDirectory -InternalUrl $null
3. Then: Get-PowerShellVirtualDirectory | Set-PowerShellVirtualDirectory -ExternalUrl $null

This disables remote PowerShell access entirely if you don't need it. If you do, use a VPN or restricted ACL.

Step 5: Verify Exploit Chain Is Broken

After patching and cleanup, test the exploit path. Open a browser and try:

https://your-exchange-server.com/autodiscover/autodiscover.json?Email=test@test.com&Protocol=PowerShell

If you get a 404 or 500, you're good. If you get any data back, something's still open — double-check the URL rewrite rule and patch.

Extra Insurance: Block Outbound Traffic from Exchange

ProxyShell attackers often use the server to phone home. Block outbound ports 80 and 443 from your Exchange server in the firewall — it doesn't need them. Only let it talk to internal DNS and domain controllers. This saved a client of mine whose patch was delayed by a week.

That's it. You're patched, locked down, and cleaned up. ProxyShell is nasty, but it's a solved problem — you just have to do the work.