A newly reported campaign against Microsoft Outlook Web Access should put Exchange and Microsoft 365 defenders on alert: in modern webmail intrusions, changing the password is not always enough. According to reporting on activity attributed by Proofpoint to the Russian-aligned actor tracked as Laundry Bear, also known as TA488, attackers are exploiting CVE-2026-42897, a cross-site scripting flaw in OWA, to run a browser-based implant called OWAReaper inside the victim’s webmail session.

The practical risk is straightforward. If an affected user opens a crafted email in a vulnerable OWA environment, malicious JavaScript can execute without the usual lure of a link or attachment. The implant then works from inside the trusted OWA browser context, where it can interact with mail, cached messages, add-ins, browser storage, and session data. That placement makes the incident response playbook more complicated than a routine credential-theft case.

What makes this campaign different

The campaign is notable for its “half-click” delivery model. The email does not need to convince the recipient to download a file, approve a macro, or visit an external website. The act of viewing the message in a vulnerable OWA client can be enough to trigger the exploit chain. Reported lures are intentionally bland, such as market metrics, research updates, and supply-chain analysis themes. That blandness is part of the tradecraft: a generic informational message is more likely to be opened, skimmed, and forgotten.

The same actor has recently been associated with similar exploitation against Zimbra Classic UI through CVE-2025-66376 and a related JavaScript payload dubbed ZimReaper. OWAReaper appears to be an evolution of that approach, adapted for Microsoft webmail and built to maintain access even after defenders take some common containment actions.

How OWAReaper persists

OWAReaper reportedly executes in the OWA reading pane and then cleans up evidence by rewriting the email on the Exchange server to remove exploit content. It also attempts to interfere with the user interface while it runs, including disabling OWA pop-ups and right-click behavior.

The implant’s persistence is the key defensive concern. It can store an encrypted copy of itself and a loader in browser localStorage, causing the code to run again when the victim opens OWA. It can also manipulate cached message content in IndexedDB by adding a hidden iframe, creating a reinfection path from the browser’s offline message cache. In addition, if Outlook add-ins with broad ReadWriteMailbox permissions are present, the malware can abuse them to obtain OAuth tokens and grant Owner-level permissions across mail folders.

That means remediation cannot stop at “reset the user’s password.” If the attacker has created server-side mailbox permissions or planted persistence in browser storage and cached content, access may survive credential rotation. In some cases, device re-imaging alone may also miss Exchange-side changes that must be deliberately removed.

Command and control inside normal workflows

The reported command-and-control design is also worth noting. OWAReaper can receive instructions through GitHub commit searches that contain target-specific data, and it can also parse attacker-sent emails for command material. Exfiltration primarily uses encrypted HTTPS paths, with DNS tunneling as a fallback. These choices can blend malicious activity into common enterprise traffic patterns and make simple domain-blocking less reliable.

For defenders, the lesson is not that every GitHub request or DNS anomaly is malicious. The lesson is that mailbox implants increasingly use services and protocols that already exist in the environment. Detection must correlate user context, browser behavior, Exchange audit events, add-in permissions, and unusual data movement rather than depend on a single network indicator.

Immediate defensive actions

First, confirm whether your OWA and Exchange environment is fully patched for CVE-2026-42897 and whether any compensating controls recommended by Microsoft are in place. Organizations that operate hybrid Exchange should not overlook internet-exposed OWA endpoints, legacy namespaces, or test systems that remain reachable.

Second, review Exchange and Microsoft 365 audit logs for unusual mailbox permission changes, especially Owner-level permissions, delegated access changes, or unexpected add-in activity. Pay close attention to add-ins with ReadWriteMailbox permissions and validate whether they are still required. Remove unnecessary add-ins and tighten consent policies so high-risk mail permissions require administrator review.

Third, treat suspicious OWA sessions as browser-context compromises. Clear localStorage, IndexedDB, service worker data, and cached OWA content for affected profiles. If a system is re-imaged, also verify mailbox permissions, OAuth grants, inbox rules, forwarding settings, and add-in authorization on the server side before considering the user recovered.

Fourth, tune detections for emails that appear harmless but contain unusual HTML structures, encoded fragments, suspicious image references, or message-body data hidden after fragment markers. The lack of attachments and links should not automatically reduce risk if the message is exploiting a rendering flaw.

Finally, prepare a containment workflow that includes password reset, session revocation, token revocation, mailbox permission review, add-in audit, browser storage cleanup, and hunting for similar messages across the tenant. The strongest response will combine endpoint, identity, and mail telemetry.

Bottom line

This campaign highlights a broader shift in email security: webmail is not only an inbox, it is also an application runtime with storage, APIs, extensions, and authentication tokens. When attackers gain execution inside that runtime, they may establish persistence in places that password resets and endpoint rebuilds do not touch. Security teams responsible for OWA should validate patch status immediately and update incident response checklists to account for browser-side and Exchange-side persistence.

Source: The Hacker News report