A mitigation blocks a path. OWASSRF found another door.

When ProxyNotShell hit Exchange in late 2022, Microsoft did what vendors do when a patch isn’t ready: it published mitigations, URL-rewrite rules to block the malicious requests at the Autodiscover endpoint, and told admins to apply them in the meantime. Plenty of organizations did, and reasonably felt covered. Then CrowdStrike documented OWASSRF: a new exploit chain using CVE-2022-41080 that achieved the same server-side request forgery through Outlook Web Access instead of Autodiscover, sidestepping the URL-rewrite mitigation entirely. Play ransomware used it as an entry vector. The mitigation blocked the path Microsoft knew about; the attackers used a different one.

This is the flip side of a companion lesson about mitigations: when there’s no patch, mitigations are the plan, and you should deploy them fast. But a mitigation is not a fix, and OWASSRF is the cautionary half of that pairing.

What the bug is

CVE-2022-41080 is a privilege-escalation / SSRF flaw in Microsoft Exchange Server, chainable with CVE-2022-41082 (the same PowerShell-remoting RCE that was the second half of ProxyNotShell) to achieve remote code execution. The OWASSRF chain’s first step is an SSRF equivalent to the Autodiscover technique from ProxyNotShell, but reached through OWA, and the second step is the familiar PowerShell-remoting code execution. The result is unauthenticated RCE on the Exchange server. CrowdStrike confirmed the November 8, 2022 update KB5019758 stopped the attack, while the pre-patch URL-rewrite mitigations did not. CISA added CVE-2022-41080 to the Known Exploited Vulnerabilities catalog on January 10, 2023, with the ransomware flag.

Why the mitigation failed, and what that teaches

The URL-rewrite mitigations were precise: they matched and blocked the specific request patterns at the specific endpoint (Autodiscover) that the original ProxyNotShell exploitation used. That precision is also their weakness. A mitigation typically blocks a known path to the vulnerability, not the vulnerability itself, so it holds exactly as long as the attacker uses the path it anticipated. OWASSRF reached the same underlying SSRF behavior through a different endpoint, and the targeted rules simply didn’t apply there.

The general lesson is a two-part rule for living with mitigations:

• Deploy vendor mitigations immediately when there’s no patch. They genuinely reduce risk during the gap, and skipping them is a real exposure. This is the right move and you should make it.
• Treat the patch as the actual remediation, and apply it the moment it ships. A mitigation buys time; it doesn’t close the bug. Plan to replace every mitigation with the patch as soon as it’s available, and don’t let “we applied the mitigation” downgrade the urgency of “we still need to patch.” The window where you’re relying on a mitigation is a window an attacker can try to route around, and capable actors will.

For Exchange specifically, this also reinforces a hard-won truth: on-premise Exchange has been one of the most relentlessly targeted products of the past several years, and its mitigations have a track record of being bypassed. Treat its patches as emergency-grade and its internet exposure as something to minimize.

What to do

• Apply the November 2022 Exchange update (KB5019758) and stay current. This is the fix for the OWASSRF chain. If you relied on URL-rewrite mitigations and never applied the patch, you may have been exposed the whole time.
• Don’t trust a mitigation as a substitute for patching. Track which of your systems are running on mitigations rather than patches, and close that gap aggressively. A mitigation-only posture should be temporary by design.
• Minimize internet-facing Exchange. Where business needs allow, front OWA and other web endpoints with additional access controls, and accelerate plans to reduce on-premise Exchange exposure given its threat history.
• Assume compromise on systems that ran unpatched through late 2022. Play ransomware used OWASSRF for initial access. Hunt for web shells, the Exchange process spawning PowerShell or other shells, and the lateral movement that follows. Investigate before trusting a server that was exposed and only mitigated.

The reframe is about the relationship between mitigations and patches. They’re not interchangeable, and the failure mode is treating them as if they are: deploying the mitigation, closing the ticket, and never circling back for the fix. A mitigation says “we’ve blocked the way we’ve seen this attacked.” The patch says “the bug is gone.” OWASSRF is the proof that the distance between those two statements is exactly where a determined attacker operates. Apply mitigations fast, replace them with patches faster, and never let a blocked path convince you the door is closed. We track these mitigation-bypass entries closely, because they’re the cases where “we mitigated it” was the most dangerous thing a team believed.

Sources

• CISA Known Exploited Vulnerabilities Catalog
• NVD CVE-2022-41080 — 2022-11
• Microsoft MSRC: CVE-2022-41080 — 2022-11-08
• CrowdStrike: OWASSRF, new exploit method bypassing ProxyNotShell mitigations — 2022-12
• Rapid7: Observed exploitation of OWASSRF in Exchange for RCE — 2022-12-21
• Help Net Security: New Microsoft Exchange exploit chain lets ransomware attackers in (CVE-2022-41080) — 2022-12-21