OWAReaper

CVE-2026-42897 was first an Exchange OWA flaw whose interim protection depended on the EM Service auto-mitigation. Two things changed. Proofpoint has now attributed in-the-wild exploitation to a named Russia-aligned actor and published the implant's full mechanics (Proofpoint, 2026-07-29), and the mitigation is no longer the remediation: the security updates are, with the mitigation now something Microsoft says administrators should remove (Microsoft Exchange Team Blog, 2026-07-14). NCSC-CH appended the Proofpoint reporting to its own advisory on 2026-07-30 (NCSC Switzerland, 2026-07-30).

The actor is TA488 (also tracked as Void Blizzard and LAUNDRY BEAR), the Russia-aligned email-espionage actor behind the Zimbra campaign that Proofpoint documented in a joint release with the NSA (Proofpoint, 2026-07-29). Proofpoint assesses OWAReaper as an evolution of that campaign's ZimReaper payload, citing shared code including the same sized, invisible pop-up and highly similar error handling (Proofpoint, 2026-07-29). Campaign activity began 2026-07-22 against government, telecommunications, finance, hospitality and aerospace targets across the US and Europe, using deliberately banal lure subjects with no call to action; Proofpoint says the unusual breadth may have been intentional blending with bulk mail. Its stated infrastructure-creation date of March 2026 precedes Microsoft's May disclosure by two months, which is the basis for its assessment that zero-day use is feasible; that is an inference from infrastructure dating, not a confirmed finding.

Execution. The flaw is a failure to sanitise HTML in the message body, so a loader script in an onload= handler reassembles a Base64 fragment from the rest of the message and evaluates it: no link click and no attachment open, only viewing the message in OWA. The exploit and payload fragments are hidden inside the message's social-media icon elements, with next-stage data placed after # fragment markers where the browser's Base64 image parser stops reading, so the payload is not visible to casual inspection of the HTML. On execution OWAReaper first rewrites the delivered message server-side to strip the exploit content and suppresses OWA pop-ups and right-click, then enumerates the victim's address, username and settings (Proofpoint, 2026-07-29).

Credential and token theft. It creates two invisible input elements and waits for the browser's own autofill to populate them with the saved OWA username and password. Separately it enumerates installed Outlook add-ins holding ReadWriteMailbox permission and, where one exists, abuses it to call GetClientAccessToken and obtain OAuth tokens (Proofpoint, 2026-07-29).

Persistence, in three independent layers. Client-side, the implant writes an encrypted copy of itself and a decryption wrapper into browser localStorage under a settings field of the legitimate PageDataPayload.OwaUserDefaultSettings key, which OWA itself evaluates during its own sync-restore flow, so every ordinary OWA tab-open re-launches it with no separate loader. A second client-side layer adds a hidden iframe to messages cached in OWA's offline IndexedDB store, so opening the cached message re-infects an endpoint even after a full re-image. The third is server-side and is the one that matters most: the implant calls UpdateFolder to grant Owner-level permission on every mail folder to the low-privilege "Default" preset alias that exists in every Exchange organisation. Proofpoint is explicit that this "requires deliberate removal from the Exchange server" and that credential rotation and re-imaging will not evict it (Proofpoint, 2026-07-29).

Command and control. Two channels, both over infrastructure defenders generally trust. The implant polls GitHub's public Commit Search API every 24 hours for crafted commit messages containing the target's own email address, decrypting matches to a four-character command header that selects toolkit replacement, C2-domain rotation, or one-off code execution; in parallel it re-parses cached inbound messages every five minutes for the same command structure. Exfiltration runs primarily over HTTPS with encrypted URI paths, either relayed through a set of legitimate image-CDN domains or sent directly to the actor-controlled server when those proxies fail; if the HTTPS method fails altogether, the implant switches to DNS label tunnelling, packing the data into the subdomain labels of ordinary DNS queries for an actor-controlled domain. Notably, Proofpoint states there is no mass mailbox exfiltration here, unlike the Zimbra campaign, so the mapped behaviour is browser-session and credential access rather than bulk email collection (Proofpoint, 2026-07-29).

Patching. The fix first shipped in the June 2026 Security Update (Microsoft Exchange Team Blog, 2026-06-09), and Microsoft now recommends the July 2026 Security Update, available as Exchange SE RTM publicly and for Exchange 2019 CU14/CU15 and Exchange 2016 CU23 only through the Period 2 Extended Security Update programme; organisations that were enrolled only in Period 1, which ended in April 2026 (Microsoft Exchange Team Blog, 2026-05-14), do not receive it (Microsoft Exchange Team Blog, 2026-07-14). Microsoft's own vulnerability record scores the flaw 8.1 and marks it exploited (Microsoft Security Response Center, 2026-07-14). Installing the update does not remove a previously applied mitigation: administrators who used the EM Service should remove the M2.1.0 IIS rules through the documented rollback, and those who ran the downloadable mitigation script should run its rollback (Microsoft Exchange Team Blog, 2026-07-14). The known operational side effects of the mitigation era (broken OWA calendar printing, inline-image rendering problems, OWA-light failing, and false-unhealthy calendar-proxy health alerts) are listed in the May post (Microsoft Exchange Team Blog, 2026-05-14), and the July post ties their clearing to installing the update and removing the mitigation (Microsoft Exchange Team Blog, 2026-07-14).

Triage: OWA legitimately reads and writes its own settings keys constantly, so the presence of localStorage activity is not the signal; the discriminator is the specific settings-field path carrying an encrypted blob, and its correlation with a message open. For the server-side artifact the discrimination is cleaner: administrators do grant folder permissions, but they grant them to named users or groups for a specific folder, not Owner rights to the built-in "Default" alias across an entire mailbox. Treat any such grant as compromise until proven otherwise.