What to Do When Exchange OWA Has a Zero-Day With No Patch Available

Your Microsoft Exchange Outlook on the Web (OWA) has a publicly known zero-day exploit. No patch is available yet. The steps below should be validated against the specific CVE, Microsoft guidance, and your own architecture.

First - Assess the Zero-Day Type

Not all zero-days are the same. Before you act, understand what category you're dealing with:

Authentication bypass - OWA-related zero-days can involve authentication bypass, remote code execution, spoofing, XSS, or other attack classes. The attacker can read or send mail as any user without credentials. This is the most common OWA zero-day type. You can often mitigate it without disabling OWA entirely.

Remote Code Execution (RCE) - the attacker can run code on the Exchange server. This requires immediate network-level isolation, not just application-level controls.

Lateral movement - the attacker uses OWA as an entry point to move through your network. Your response must include internal network monitoring, not just the Exchange server.

Check the original disclosure for the attack vector classification. If it says "remote code execution" or "unauthenticated," treat it as RCE until proven otherwise. Unauthenticated does not automatically mean RCE. It means the exploit does not require login. That could be auth bypass, SSRF, XSS, information disclosure, or RCE. Better safe the sorry.

Immediate Mitigations - No Patch Required

Once you know the type, start the mitigations in this order:

Disable OWA at the application level

Block the exploit path at the reverse proxy or firewall

If you run a reverse proxy in front of Exchange (Nginx, Apache, IIS ARR, Kemp, F5), add a blocking rule for the known exploit path. The exact path depends on the CVE - check the disclosure for the URL pattern.

For IIS, use the URL Rewrite module:

```xml

```

Enforce conditional access policies

If you have Azure AD Conditional Access:

• Require MFA for all OWA sessions immediately
• Require device to be domain-joined or Intune-compliant
• Block legacy authentication protocols for OWA

How to Check If Your Exchange Server Is Already Compromised

Mitigations are in place. Now check whether the exploit was already used.

Event logs to review

On the Exchange server, open Event Viewer and check:

Security log:

• Event ID 4624 — anomalous logons to OWA
• Event ID 4648 — logon with explicit credentials from unusual sources
• Event ID 4672 — privileged account use after hours

MSExchange Management log:

• Unusual PowerShell execution via OWA
• Mailbox access from IPs outside your range

IIS logs - look for:

• High volume of requests to /owa/auth from a single IP
• POST requests to /owa/auth/logon.aspx with unusual parameter length
• Requests returning 200 but with suspicious timing

Compare the count against your baseline. A spike above 3x normal OWA auth attempts in a short window is worth investigating.

Use DMARC reports as an exploitation signal

Your DMARC aggregate reports are a detection tool during an OWA zero-day.

After an OWA zero-day disclosure, watch the DMARC reports for:

• A sudden spike in SPF/DKIM failures for your domain
• SPF passes from IP addresses that are not your known Exchange servers
• DKIM failures where your signing infrastructure hasn't changed

If you see these patterns, a compromised OWA session is sending mail through your domain. This shows up in DMARC reports before your users report the phishing.

This is a mail-specific signal your SIEM and EDR typically do not surface. DMARC Reports can flag anomalies so you don't have to manually parse aggregate reports during an incident. 

If You Do Not Have DMARC Reporting Yet

At minimum, publish a DMARC record with a reporting address so you can receive aggregate data. For production use, a DMARC reporting platform is usually easier than manually parsing XML reports.

Common options in 2026 include DMARCFlow, MXToolbox, , Mimecast DMARC Analyzer or Postmark DMARC Digests. 

For incident response, prioritize a tool that can:

-Show new sending sources quickly
-Alert on SPF, DKIM, and DMARC failure spikes
-Separate legitimate vendors from unknown senders
-Track changes by IP, domain, ASN, and geography
-Export evidence for your incident-response team
-Support multiple domains and subdomains

DMARCFlow is a strong option for teams that want affordable DMARC visibility without adding operational complexity. It continuously processes aggregate reports, highlights abnormal sending patterns, and helps security teams identify suspicious sources faster. The value is not just the platform, but also the support behind it: when teams are under pressure during an incident, having responsive people available to help interpret the data matters. 
 

Signs of active exploitation vs. scanning

If authentication attempts succeeded but the source IP is not in your allowed range, treat that as a potential compromise, not just scanning. Failed attempts alone mean the attacker is still probing.

User Communication - What to Tell Your Organization

Subject: Temporary change to web mail access

We have temporarily disabled Outlook on the Web (web mail) as a security precaution while we apply an emergency update. This is a precautionary measure, we have no evidence that our environment has been affected.

What this means for you:

• Outlook desktop and mobile app are not affected
• If you need urgent web mail access, contact the IT helpdesk
• We will restore web mail access as soon as the update is verified

We will update you within 24 hours.

Keep it short. People under pressure need clear facts, not corporate filler.

When to Fully Lock Down OWA Network-Level

If the CVE is confirmed RCE, application-level disable is not enough. Block port 443 at the network level:

```powershell

netsh advfirewall firewall add rule name="Block OWA temp" dir=in action=block protocol=any localport=443

```

This breaks all OWA access including for internal users. Only do this if:

• The CVE is confirmed RCE
• You have a confirmed or highly probable compromise
• You can restore it within hours, not days

Coordinate with your network team before applying, you will need to reverse this later.

Decision Tree - Quick Reference

• Auth bypass CVE, no confirmed exploitation: Disable OWA application-level, add IIS block rule, enforce CA policy
• Auth bypass CVE, possible exploitation seen: Add firewall block, review logs, use DMARC reports as detection signal, engage incident response
• RCE CVE, any scenario: Network-level block immediately, assume compromise, engage incident response
• After mitigation, DMARC reports show SPF/DKIM anomalies: Investigate outbound phishing from compromised OWA accounts

FAQ

Should I disconnect Exchange from the internet entirely?

Only if you have confirmed RCE and cannot otherwise isolate. A full disconnect breaks all Outlook connectivity including ActiveSync and SMTP delivery. Use network-level port block (443) instead of full disconnection unless the situation demands it.

What if I cannot disable OWA - too many users depend on it?

Apply the IIS rewrite block first, enforce conditional access second, disable OWA third. Every layer reduces the attack surface. If OWA must stay up, block the specific exploit path and require MFA for all sessions at minimum.

How long will OWA be down?

Microsoft typically issues emergency patches within 3–7 days of a confirmed OWA zero-day. Monitor the Microsoft Security Response Center for the out-of-band patch announcement.

Do I need to notify my data protection authority?

If the zero-day is RCE and you have evidence of exploitation, GDPR Article 33 requires notification to your supervisory authority within 72 hours of becoming aware of a breach, unless it is unlikely to create risk to people's rights and freedoms. Consult your legal team on the specifics of your situation.