Microsoft patched the cross-site scripting flaw in Exchange Server’s Outlook Web Access two months ago, yet for one Russian state-linked group the patch changed almost nothing. According to new research from Proofpoint, the actor tracked as Void Blizzard (also known as Laundry Bear and TA488) has spent the past week using a JavaScript implant called OWAReaper to plant a foothold inside government and enterprise mailboxes that survives the two remedies security teams reach for first: rotating credentials and re-imaging the endpoint.
A vulnerability that outlived its own patch
CVE-2026-42897 is a cross-site scripting vulnerability in the on-premises builds of Exchange Server: Exchange Server 2016, Exchange Server 2019, and Exchange Server Subscription Edition. Microsoft has said an attacker can exploit it by sending a specially crafted email that executes arbitrary JavaScript in the browser once the message is opened in Outlook Web Access, with no attachment or link click required. Exchange Online was never affected. Microsoft shipped a fix on June 10, 2026, and pointed customers still on older builds toward its Exchange Emergency Mitigation Service and the Exchange on-premises Mitigation Tool as interim cover.
Proofpoint’s telemetry shows Void Blizzard built the infrastructure for this campaign in March, two months before that patch existed, then went dark between February and July 22, when the group resumed activity with a wave of “half-click” lures against government agencies in the United States and Europe, plus targets in telecommunications, financial services, hospitality, and aerospace. The generic, informational-sounding subject lines are designed to blend into bulk mail rather than stand out to a filter.
A group Microsoft has tracked since 2024
Void Blizzard is not a new name to Microsoft’s threat intelligence team. The company has tracked the group, also called Laundry Bear, since at least April 2024, assessing with high confidence that it is Russia-affiliated, and it says the group disproportionately targets NATO member states and Ukraine, along with government, defense, transportation, aviation, healthcare, and education organizations, concentrated in Europe and North America. Historically the group’s initial-access playbook has been comparatively unsophisticated: stolen credentials bought from criminal marketplaces, high-volume password spraying, and, since April 2025, typosquatted phishing pages built on the Evilginx framework. Once inside, Microsoft says the group abuses legitimate cloud APIs, including Exchange Online and Microsoft Graph, to enumerate mailboxes and pull emails and files in bulk.
OWAReaper marks a jump in sophistication from that baseline. Instead of relying only on the cloud API layer, the implant builds its persistence directly into Exchange’s on-premises permission model, a target Void Blizzard had not previously been documented attacking with this level of technical depth.
Why patching and password resets are not enough
A foothold that lives on the server, not the endpoint
What makes OWAReaper unusual is where it stores itself. Proofpoint found the implant encrypts its own payload and stores it inside browser localStorage, tucked into fields OWA already uses for legitimate settings, so it runs automatically the next time the mailbox syncs. From there it steals OAuth tokens through malicious Outlook add-ins granted ReadWriteMailbox permission, then calls Exchange’s UpdateFolder API to hand the built-in “Default” user Owner-level rights on every folder in the mailbox. That single API call is the actual persistence mechanism: it lives in Exchange’s server-side permission model, not on the device the victim uses to read mail.
Reinfection through the offline cache
The implant also plants hidden iframe elements inside messages held in OWA’s offline IndexedDB cache. If a victim’s device is wiped and rebuilt from a clean image, opening the same poisoned message again reinfects the browser. Proofpoint’s summary is direct: credential rotation and even full re-imaging of the targeted user’s device will not evict the actor. Removing OWAReaper means auditing and revoking Exchange Web Services tokens, stripping the folder permission grants made to the Default user, and clearing the browser’s IndexedDB and localStorage on every affected endpoint, in that order.
What it means for the security leader
The operational lesson here is not really about Exchange. It is about which recovery actions actually evict an attacker once a webmail client has been used as the entry point. Standard incident-response playbooks lean on two levers: force a password reset, reimage the box. Void Blizzard’s design specifically defeats both, because the access it built lives in server-side mailbox permissions and a browser-level cache rather than in credentials or the local disk. A CISO whose incident-response runbook stops at “rotate credentials” is, against this actor, declaring victory before the fight is over.
This also raises the bar for what “patched” means. An organization can apply Microsoft’s June update and still be compromised if the implant landed before the patch went in and nobody checked mailbox-level permissions or add-in grants afterward. Vulnerability management dashboards that track only patch status, not post-compromise persistence, will miss this category of exposure entirely.
The pattern is not new to webmail platforms specifically. CyberTech has tracked a similar five-month persistence campaign against Zimbra’s webmail client, also attributed to a Russian state-linked actor. Together the two campaigns point to webmail interfaces, not endpoints, as the persistence layer nation-state groups are now building for.
What to do now
Security teams running on-premises Exchange, patched or not, should treat this as a hunt, not a patch check:
- Confirm the June 10, 2026 update (or a later cumulative update) is installed on every Exchange 2016, 2019, and SE server; where it is not, enable the Exchange Emergency Mitigation Service immediately.
- Audit Exchange Web Services and OAuth tokens tied to Outlook add-ins for unexpected ReadWriteMailbox grants, and revoke anything unrecognized.
- Review folder-level permissions across mailboxes for Owner-level access assigned to the Default user, a setting that should almost never carry elevated rights.
- Clear IndexedDB and localStorage in OWA sessions on endpoints that accessed mail during the exposure window, particularly for government, telecom, finance, hospitality, and aerospace accounts in the US and Europe.
- Treat a password reset or device reimage as necessary but not sufficient; verify server-side mailbox permissions before closing the incident.
Source: Proofpoint
