Microsoft's patch cadence is not the problem

The pattern repeats

Microsoft pushed an out-of-band advisory for an unauthenticated remote code execution flaw in on-premises Exchange Server. Within 48 hours, honeypots logged exploitation attempts from at least four distinct clusters of activity. Shadowserver’s scans showed roughly 100,000 internet-exposed Exchange servers still unpatched a week in. This is the fifth time since ProxyLogon in March 2021 that the same playbook has run: a flaw in Exchange, mass exploitation before defenders can react, a scramble of patches and mitigations, and another wave of compromised mailboxes and dropped web shells.

The interesting question is not how this specific bug works. The interesting question is why the same class of incident keeps producing the same outcome. The answer is structural, and it has very little to do with Microsoft’s patch cadence.

What actually got hit

The flaw lives in the way Exchange’s Client Access services deserialize untrusted data from authenticated and, in some configurations, unauthenticated requests. An attacker reaching the OWA or ECP endpoints on port 443 can trigger code execution as the Exchange server process, which on most deployments runs with privileges that allow reading every mailbox and writing to Active Directory through Exchange’s own management interfaces.

The early intrusions follow a predictable script. Initial access via the bug. Drop a small ASPX web shell into the Exchange virtual directory. Dump Exchange’s configuration to enumerate mailboxes. Pull NTDS.dit or extract service account credentials. Move laterally. By the time the patch is applied, the attacker is no longer on the Exchange server. They are inside the domain.

If you are reading this and you still operate Exchange on-premises, assume the server was compromised before you patched. The forensic record on prior Exchange zero-days is clear: the gap between exploitation and patch application averaged 11 days for the median organization. Eleven days is a long time when web shells take 90 seconds to install.

Why Exchange keeps being the target

Exchange is the worst-case target by design. It is internet-facing because email has to be. It holds the most sensitive content in most organizations because email is where contracts, credentials, and conversations live. It runs with broad Active Directory privileges because that is how Microsoft built the integration. And on-premises Exchange has accumulated 25 years of code in a deployment model that assumes the operator will patch promptly, configure carefully, and segment properly.

Three of those assumptions are usually wrong.

The systemic vulnerability is not the deserialization bug. The systemic vulnerability is that Exchange Server is a domain-trust-bearing, internet-exposed application maintained by IT teams whose primary job is keeping email flowing, not running a hardened edge service. The architecture treats the Exchange server as a trusted member of the directory. The threat model treats it as a hostile internet endpoint. Those two facts cannot both be true, and the gap between them is what attackers monetize.

The patch cycle is not the problem

A common reading of these incidents is that organizations need to patch faster. That reading is incomplete. Patching faster helps with the next bug. It does nothing about the current one, because the current one was exploited before the patch existed.

Look at the timeline of every major Exchange zero-day since 2021. Initial exploitation precedes public disclosure by weeks or months in every case. ProxyLogon: at least two months of in-the-wild exploitation before patches. ProxyShell: similar. The 2022 chain, the 2023 chain, and now this one all follow the same shape. Patching is necessary. It is not sufficient. Any defense strategy that assumes you will patch before exploitation has already failed for this class of bug.

The useful question is not “how fast can we patch?” It is “what do we lose if exploitation happens before the patch ships?” If the answer is “the entire domain,” the architecture needs to change.

Mitigations that actually reduce blast radius

Five concrete steps, in order of impact.

1. Move off on-premises Exchange. This is the unpopular answer and the correct one. Exchange Online is not invulnerable, but the attack surface that this class of bug exploits - the Client Access service running on a domain-joined server you manage - does not exist in the hosted product. Microsoft’s security team has more visibility into exploitation against their own tenant than any individual organization will have against their own deployment. If migration is impossible for regulatory or contractual reasons, document why and budget accordingly. The total cost of ownership calculations for on-premises Exchange routinely omit the cost of one bad incident, which for a mid-size organization runs $2-5 million before counting reputational damage.

2. Put Exchange behind a reverse proxy with request inspection. Direct internet exposure of OWA and ECP is the default and it is wrong. A reverse proxy that terminates TLS, inspects requests for known exploit patterns, and rate-limits authentication attempts buys time during the window between exploitation and patch availability. F5, Citrix, Cloudflare, and several open-source options all support this. The proxy itself becomes a target - pick one with a better security track record than Exchange, which is a low bar.

3. Constrain Exchange’s Active Directory privileges. Out of the box, Exchange holds rights that allow account takeover across the domain. The split-permissions model that Microsoft documents but rarely enables in practice limits this. Implementing it requires planning. It also means that an attacker who owns the Exchange server cannot trivially own the domain controller. Whether that is worth the operational complexity depends on what you have to lose.

4. Treat the Exchange server as compromised by default in your detection strategy. Log every process spawned by w3wp.exe. Alert on any ASPX file written to the Exchange virtual directories outside of patch windows. Monitor for unusual outbound connections from the Exchange host. The web shells dropped in these campaigns are not subtle once you are looking for them. Most organizations are not looking because the Exchange server is treated as an appliance rather than a critical asset that requires the same monitoring as a domain controller.

5. Have a tested plan for “Exchange is on fire, now what.” Tabletop the scenario where you find a web shell on an Exchange server tonight. Who isolates it? Who notifies legal? Who calls the cyber insurance carrier before the 72-hour notification clock starts? Who decides whether to take the server offline and accept the email outage versus leave it running and accept ongoing exfiltration? If those decisions get made for the first time during the incident, they will get made badly.

What the emergency advisories miss

CISA’s advisory says to patch, hunt for indicators of compromise, and apply mitigations. That is correct guidance for the next 72 hours. It does not address the underlying question, which is whether your organization should still be operating this class of system in 2026.

The honest answer for most organizations is no. Email is a commodity. Self-hosting Exchange to maintain control made sense when the alternative was a less capable cloud service. The alternative is now more capable, more closely monitored, and faster to patch than your team can manage. The exceptions are real - sovereign data requirements, air-gapped environments, specific regulated industries - but they are narrower than the current installed base would suggest. Most organizations still running Exchange on-premises are doing so because of inertia, not because of a current evaluation of the trade-offs.

What to do this week

Apply the patch. Do an indicator-of-compromise sweep using the hashes and behavioral signatures Microsoft and the major DFIR firms have published. Check the Exchange virtual directories for unexpected ASPX files. Review web server logs for the request patterns associated with this exploit chain. Rotate the Exchange service account credentials and any account that has logged into the Exchange server in the last 30 days. Assume the machine account is burned and plan accordingly.

Then put a calendar entry for 60 days from now and use it to revisit the question of whether you should still be running Exchange on-premises at all. The next zero-day in this product is not a possibility. It is a scheduling problem.

The pattern, restated

A complex, internet-facing application with broad directory privileges, maintained by teams without dedicated security headcount, gets a critical vulnerability exploited before the patch ships. Defenders scramble. Organizations that had reduced the blast radius before the incident recover. Organizations that hadn’t make the news.

This happened in 2021. It happened in 2022. It happened in 2023. It is happening now. The bug changes. The pattern does not. The decision in front of you is whether the pattern is going to happen to your organization again the next time, or whether you are going to use this incident as the reason to change something structural.