Resecurity’s latest OWAReaper writeup is a useful reminder that webmail compromise is not always an endpoint-malware problem. The reported campaign centers on CVE-2026-42897, a high-severity stored cross-site scripting flaw in on-premises Microsoft Exchange Outlook Web Access (OWA). In the scenario Resecurity describes, a malicious HTML email can execute attacker-controlled JavaScript when a victim opens the message in OWA, turning a normal browser session into the attacker’s operating environment.

That matters because the implant does not need to behave like traditional malware. OWAReaper is described as browser-resident JavaScript that abuses trusted Exchange and OWA functionality to collect mailbox metadata, steal authentication material, interact with Exchange APIs, and establish persistence through mailbox permission changes. If that assessment is accurate in a live environment, simply reimaging a workstation or forcing a password reset may not remove the attacker’s access.

Why this is different from ordinary phishing

Most defensive programs still treat email compromise as either credential theft, malicious attachment delivery, or user-clicked link execution. OWAReaper sits in a more uncomfortable category: exploitation of the webmail rendering path itself. The user interaction is minimal, the execution context is already authenticated, and the attacker can blend activity into legitimate Exchange and browser behavior.

For small businesses, local governments, schools, and government contractors still operating on-prem Exchange, the key lesson is this: patching the server closes the front door, but it does not prove nobody walked in before the patch landed.

Defensive takeaways

  • Treat internet-facing Exchange as Tier-0 infrastructure. OWA, ECP, EWS, and related services should have the same urgency as domain controllers and identity providers.
  • Patch quickly, then hunt. After applying vendor updates, review evidence of prior exploitation instead of assuming the update ended the incident.
  • Audit mailbox permissions. Look for unexpected folder-level grants, especially broad permissions assigned to default, anonymous, service, or unfamiliar accounts.
  • Revoke and refresh tokens. Password resets alone are weak remediation if OAuth tokens, browser sessions, or delegated mailbox access were exposed.
  • Increase Exchange telemetry retention. Mailbox audit logs, EWS activity, admin audit logs, OWA access logs, and identity sign-in data should be retained long enough to support post-patch review.
  • Reduce OWA exposure where possible. Put webmail behind conditional access, VPN, identity-aware proxying, device compliance checks, and geo/anomaly controls instead of exposing it broadly to the internet.
  • Inspect browser artifacts during response. Browser storage, cached OWA data, and suspicious session persistence can matter when the implant lives inside the authenticated webmail session.

Bulwark Black assessment

The practical risk is not just “an Exchange bug.” It is the combination of email delivery, authenticated browser execution, token theft, and server-side mailbox persistence. That chain breaks a lot of normal assumptions: no dropped executable, no obvious attachment detonation, no simple workstation-only cleanup path.

For organizations with on-prem Exchange, the proper response is a short, disciplined compromise review: confirm patch status, verify OWA exposure, audit mailbox permissions, revoke risky sessions/tokens, and hunt for unusual EWS or mailbox-access patterns. If those steps are not in the incident checklist, add them now — before the next Exchange advisory turns into a weekend emergency.

Original source: Resecurity — Inside OWAReaper: How CVE-2026-42897 Enables Persistent Exchange Mailbox Compromise