Patching On-Prem Exchange After ProxyLogon Is Only the First Step

On March 2, Microsoft shipped out of band security updates for Exchange Server that fix vulnerabilities that were already being exploited. Ten days later, the guidance around that release has grown into a pile of blog posts, scripts, scanner updates, extra updates for older builds, and a federal emergency directive. If you run Exchange on your own servers, here’s what Microsoft and CISA have actually said, turned into an order of operations.

I’m sticking to Microsoft’s own blogs, its Security Update Guide, its official scripts repository, and CISA. I’m not covering how the attacks work or who is behind them. You don’t need either to defend a server.

What was fixed and who is affected

The four vulnerabilities being used together are CVE-2021-26855, CVE-2021-26857, CVE-2021-26858, and CVE-2021-27065. The MSRC post, Multiple Security Updates Released for Exchange Server, says they affect Exchange Server 2013, 2016, and 2019, that Exchange Server 2010 is also being updated for defense in depth, and that Exchange Online is not affected. It adds that Exchange 2010 is only impacted by CVE-2021-26857, which isn’t the first step in the attack chain. Exchange 2003 and 2007 aren’t believed to be affected, but they’re out of support, and Microsoft’s advice is to upgrade anyway.

The key point in that post is about the chain. The first step needs an untrusted connection to the Exchange server, but the later steps can be triggered by someone who already has access some other way. That’s why Microsoft says restricting connections or putting Exchange behind a VPN only partially mitigates the problem, and that patching is the only complete fix.

The patch has prerequisites

Exchange security updates install only on specific cumulative updates. According to the Exchange Team’s release post, the March updates require CU 23 for Exchange 2013, CU 19 or CU 18 for Exchange 2016, and CU 8 or CU 7 for Exchange 2019. The Exchange 2010 update needs SP3 or any SP3 rollup. If you’re behind, the recommended path is to install a supported CU first and then the security update. The same post points to the Exchange Server Health Checker script on GitHub, which will tell you whether a server is behind on updates (it doesn’t support Exchange 2010).

Since getting current on CUs can take a while, Microsoft started releasing security updates for older cumulative updates on March 8, and yesterday it said that list is final. They contain only fixes for these four CVEs, with no other security fixes, and installing one doesn’t make an unsupported CU supported. Microsoft calls them a temporary measure. There’s also a trap: if you install one of these and then move to a later CU that doesn’t include the March fixes, the server is vulnerable again.

The Exchange Team says that if you install the .msp manually, it has to be run from an elevated command prompt, and it points you to the Known Issues section of the KB article. The older CU post also says the update needs a reboot even if the installer doesn’t ask for one, and the server isn’t protected until that reboot happens. Security updates install faster than a CU, but Microsoft still says to plan for some downtime.

On order, the Exchange Team notes that exploitation requires HTTPS access over the internet, so it recommends patching the servers that publish Outlook on the web and the Exchange Control Panel first, then the rest.

If you can’t patch today

On March 5, Microsoft published Microsoft Exchange Server Vulnerabilities Mitigations for people who need more time. It is blunt that installing the update is the only complete mitigation, and that none of the interim options will remove an attacker who is already in.

The interim mitigations are an IIS URL Rewrite rule that filters malicious requests, plus disabling Unified Messaging, the Exchange Control Panel virtual directory, and the Offline Address Book virtual directory. Each one costs something. Voicemail stops working, admins lose the web console and have to use remote PowerShell, Outlook can’t download the offline address book, and Exchange’s Managed Availability monitoring gets switched off so it doesn’t undo the changes. A script called ExchangeMitigations.ps1 can apply and roll these back. It needs the IIS URL Rewrite module, and Microsoft warns that putting the newer module version on older IIS can make IIS and Exchange unstable. The recommendation is to apply all of the mitigations at once and treat them as temporary.

The other lever is network access. Microsoft’s guidance says that for the highest assurance, you should block access to vulnerable Exchange servers from untrusted networks until they’re patched or mitigated. The Security Update Guide entry for CVE-2021-26855 says the same thing in terms of port 443: restrict untrusted connections or put Exchange behind a VPN, with the caveat that this only protects against the initial part of the chain. My advice is to go further than the emergency. If your users don’t truly need Outlook on the web and the admin console reachable from the whole internet, keep them behind a VPN after you’ve patched, too.

Check whether you were already hit

This matters most for a server that sat unpatched on the internet. Microsoft says to update and investigate in parallel, and if you have to choose, patch first. But a patched server can still be a compromised one.

Microsoft’s official tools live in the Security folder of the CSS-Exchange repository. The main one is Test-ProxyLogon.ps1, which Microsoft describes as checking Exchange servers for signs of compromise from these vulnerabilities, largely by scanning Exchange’s own logs. It’s meant to run from an elevated Exchange Management Shell, and the README’s typical usage checks every server and saves the reports:

Get-ExchangeServer | .\Test-ProxyLogon.ps1 -OutPath $home\desktop\logs

CISA’s alert AA21-062A, updated March 10, strongly encourages organizations to run that script as soon as possible, and recommends looking for signs of compromise from at least January 1, 2021 through today. So don’t only scan the last few days of logs.

The second tool is the Microsoft Safety Scanner, also known as MSERT. Microsoft added detections for known malware related to these vulnerabilities, and its guidance is to run the scanner on every Exchange server in your environment. The Exchange Team adds that the tool is updated regularly, so download a fresh copy often. The same repository also has an nmap script that Microsoft says can check whether a server is still vulnerable, which is a quick way to confirm your patches or mitigations took effect.

If any of this turns something up, Microsoft says to keep the logs and use details like timestamps and source IPs to drive the investigation, to run your incident response plan, and to consider bringing in experienced incident response help. It also advises coordinating the response through isolated identities and communication channels until you’re sure an attacker can’t read them. CISA’s alert goes a step further: if you find exploitation, assume your network identity is compromised and follow your incident response procedures. The alert also notes that an attacker with authenticated access to Exchange may be able to reach the Active Directory environment, so a cleanup that stops at the Exchange box isn’t really a cleanup.

What CISA ordered agencies to do

CISA issued Emergency Directive 21-02 on March 3. It says neither the vulnerabilities nor the exploitation are currently known to affect Microsoft 365 or Azure cloud deployments. Its required actions apply to federal civilian agencies, but they’re worth reading anyway.

Agencies had to find every on-premises Exchange server. Those with the expertise had to forensically triage each one, collecting system memory, web logs, Windows event logs, and registry hives, and look for signs of compromise. Only if they found none were they to apply Microsoft’s patches immediately. Agencies that found signs of compromise, or that lacked the expertise to check, had to disconnect their Exchange servers immediately and were not allowed to rejoin them to the domain until CISA directed a rebuild. Every agency had to report its status to CISA by noon Eastern on Friday, March 5.

The lesson I’d take from that is the default. When the federal government couldn’t tell whether a server was clean, the answer was to unplug it, not to patch it and hope.

Is on-prem mail still worth it?

Exchange Online wasn’t affected, and the servers in the worst spot right now are internet-facing ones that were too far behind on CUs to take the fix on day one. Moving to the cloud doesn’t end this overnight, though. The Exchange Team’s FAQ says hybrid customers still have to apply these updates to their on-premises Exchange server, even if it’s only kept for management.

If you do keep Exchange on-premises, the real cost isn’t the license or the hardware. It’s staying on a supported CU so emergency fixes install the day they ship, keeping the web endpoints off the open internet where you can, and having someone who can read logs and run an investigation when Microsoft publishes an update like this one. If that isn’t something your team can commit to, that’s a strong argument for letting Microsoft run the mail servers.

The short version

Patch internet-facing servers first, on a supported CU, from an elevated prompt, and reboot. If you truly can’t patch today, apply Microsoft’s interim mitigations and cut off untrusted access. Then run Test-ProxyLogon.ps1 and a fresh copy of the Safety Scanner on every Exchange server, and if a server was unpatched and reachable from the internet, treat it as possibly compromised until the evidence says otherwise.