Fix Ransomware via ProxyShell (CVE-2021-34473) on Exchange

Quick answer: Isolate the server, patch CVE-2021-34473 (and its buddies CVE-2021-34523 and CVE-2021-31207), remove web shells, restore from a clean backup, and change every credential — in that order.

If you're reading this, your Exchange server probably got popped. ProxyShell isn't some exotic zero-day anymore — it's been weaponized since August 2021, and unpatched servers are still getting ransomware dropped on them in 2025. I had a client last month, a 30-person law firm, whose entire email system went dark because they hadn't patched since early 2021. The attackers used ProxyShell to drop a web shell, then a week later deployed LockBit. They didn't even notice until files started getting the .lockbit extension.

Why does this keep happening? ProxyShell chains three vulnerabilities: CVE-2021-34473 (path confusion), CVE-2021-34523 (privilege escalation), and CVE-2021-31207 (security feature bypass). Together they let an unauthenticated attacker run arbitrary code as SYSTEM. Once they're in, they usually drop a web shell like aspnet_client.aspx or owa/auth/errorFE.aspx — something that blends in. From there, it's a short walk to domain admin and then ransomware. The fix isn't just patching; it's cleaning up the backdoors they left behind.

Step-by-step fix

Disconnect the server from the network immediately. Pull the plug on the NIC or disable the switch port. Ransomware spreads laterally — don't give it a chance to encrypt your domain controller or file shares. If you have a backup internet connection, keep it off.
Identify the ransomware strain and scope. Check for ransom notes (README.txt, DECRYPT-FILES.html, etc.) and encrypted file extensions. Look at file timestamps to see when encryption started. This tells you how long the attackers had access. If you see .lockbit, .conti, .revil, or .blackbyte, you're dealing with a known group. Document everything — you'll need it for insurance and possibly law enforcement.
Patch Exchange to the latest cumulative update. The fix for ProxyShell is included inExchange Server 2016 CU21 and Exchange Server 2019 CU10 (or later). If you're on Exchange 2013, you're out of support — migrate or isolate it. Download the CU from Microsoft's Volume Licensing Service Center or the Microsoft Evaluation Center (yes, even if you have a license). Install it offline if possible. Here's the silent install command for Exchange 2019 CU12:

Setup.exe /IAcceptExchangeServerLicenseTerms /Mode:Install /Roles:Mailbox /InstallWindowsComponents

After patching, reboot. Don't skip this. Some exploits persist in memory until a restart.

Hunt for web shells. Attackers love dropping .aspx files in \inetpub\wwwroot\aspnet_client\ and \Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\. Search for files modified around the time of the breach. Use PowerShell to find recently modified .aspx files:

Get-ChildItem -Path "C:\inetpub\wwwroot\aspnet_client" -Recurse -Include *.aspx,*.ashx | Where-Object { $_.LastWriteTime -gt (Get-Date).AddDays(-30) } | Select-Object FullName, LastWriteTime

Also check \Program Files\Microsoft\Exchange Server\V15\ClientAccess\ and any OWA directories. If you find a shell, delete it. But first, copy it to a quarantine folder — you might need it for forensics.

Reset all credentials. Assume every account that touched the server is compromised. That includes domain admins, Exchange admins, and service accounts. Reset passwords twice — once to a temporary password, then again to a new strong one. Enable MFA on all admin accounts. If you have a KRBTGT account, reset its password twice (this invalidates Kerberos tickets).
Restore from a clean backup. If you have a backup from before the breach, restore it to a new server or a clean VM. Don't restore over the compromised server — you'll just bring back the web shell. Mount the backup offline, scan it with a reputable antivirus (Defender for Endpoint, CrowdStrike, etc.), then restore. If you don't have a clean backup, you're looking at data loss. Paying the ransom is a last resort — it funds criminals and doesn't guarantee recovery.
Re-enable services and monitor. Once restored, bring the server online. Watch for any unusual outbound connections. Set up logging for Exchange (enable audit logging if you haven't). Use a tool like Sysmon or Exchange Server Health Checker to catch anomalies.

If that doesn't work

Sometimes the ransomware is too deep, or you can't find a clean backup. Alternative fixes:

Rebuild Exchange from scratch. Install a fresh Exchange server, create new databases, and migrate mailboxes from a backup or from a surviving server. It's painful, but it guarantees no backdoors. You'll need to reconfigure all connectors, virtual directories, and certificates.
Use a decryption tool. Check No More Ransom for your strain. Some older ransomware (like REvil) have free decryptors. But if the attackers used a custom variant, you're out of luck.
Engage a professional incident response firm. If you're a small shop without a security team, call in experts. They can do forensic analysis, identify the entry point, and help with recovery. It's expensive, but often cheaper than downtime.

Prevention tip

Patch Exchange the day Microsoft releases a security update. Seriously — set a calendar reminder for Patch Tuesday and test updates in a staging environment if you can. Also, put Exchange behind a firewall that only allows traffic from your mail gateways or VPN. Block direct access to OWA from the internet unless you absolutely need it. And enable Extended Protection for Exchange — it's not a silver bullet, but it stops some ProxyShell variants cold. Most importantly, have offline backups that you test regularly. Ransomware can't encrypt what it can't reach.