Russian OWAReaper implant exploits an Outlook Web Access flaw, and a password reset won't evict it

The standard response to a compromised mailbox is muscle memory: reset the password, force a sign-out, reimage the laptop, move on. Against the backdoor Russian operators are planting in on-premises Exchange right now, that runbook accomplishes nothing. The implant, tracked as OWAReaper, does not live on the victim device or depend on their credentials. It grants itself permissions on the Exchange server, so it keeps reading mail after every step of the usual cleanup. If you run Outlook Web Access on your own tin, the detection you need is on the server, not the endpoint.

Proofpoint attributes the campaign to Laundry Bear, the Russian state-aligned group also tracked as Void Blizzard and TA488. The current wave started on July 22, 2026, and weaponizes CVE-2026-42897, a cross-site scripting flaw in Outlook Web Access that Microsoft rated CVSS 8.1. Microsoft published its advisory on May 14, 2026, but Proofpoint says the attacker built the OWAReaper infrastructure back in March, roughly two months earlier, which points to a period of zero-day exploitation before anyone had a patch to apply.

The targets are a familiar espionage spread: government bodies in the United States and Europe, plus companies across telecommunications, financial services, hospitality, and aerospace. The delivery is a booby-trapped email. A loader script rides in on an onload= event handler, reassembles a Base64 fragment hidden in the message body, and runs it as JavaScript the moment the victim opens the mail in the reading pane. There is no attachment to detonate and barely a click to make.

Why a password reset changes nothing

OWAReaper builds two forms of persistence, and both sit on the server. First, it hunts for Outlook add-ins that carry ReadWriteMailbox permission and rides them to lift OAuth tokens with a GetClientAccessToken request. It then calls UpdateFolder to give the Default user Owner-level rights on every folder in the mailbox. That is a server-side access-control change. Rotating the account password or wiping the workstation leaves it untouched, because the grant was never tied to the password in the first place.

Second, it turns the mailbox against itself. The implant enables offline caching and injects a hidden iframe into messages stored in the OWA browser cache, the local IndexedDB store. Every time the victim opens one of those poisoned messages from the cache, the iframe fires again and re-establishes the foothold. We have seen this pattern of reset-proof persistence before, from session-stealing malware that survives a password change to a SharePoint bug where patching alone does not clean the box. The lesson repeats: once an attacker converts a login into a durable server-side artifact, credential hygiene stops being remediation.

The same actor, a second webmail platform in a week

This is not a novelty. One week ago the same group ran the same play on a different product. We covered Void Blizzard exploiting a Zimbra webmail zero-day with a payload called ZimReaper, which minted app passwords that skipped multi-factor authentication and survived resets. ZimReaper on Zimbra, OWAReaper on Exchange: two webmail platforms, one operator, one method. The naming is a taunt, but the repetition is the real signal. Laundry Bear has industrialized near-zero-click webmail espionage, and any browser-based mail interface is a candidate for the next Reaper.

The browser-resident design is the sharpest part. OWAReaper runs entirely inside the OWA tab and leaves no file on disk, no process, no host footprint. Endpoint detection and response tooling, which watches for exactly those artifacts, has nothing to catch. That is a deliberate choice: it pushes the entire detection burden off the endpoint and onto the mail server and the identity layer, which is precisely where most shops are watching least.

A command channel hiding in GitHub traffic

For command and control, OWAReaper uses two channels. It reads instructions from attacker-sent emails, and it queries GitHub every 24 hours through the public Commit Search API, hunting for commit messages that contain the target's email address. Both are chosen to blend in. Outbound requests to github.com from a corporate network are so routine that they almost never draw a second look, and they are commonly on the allowlist. Building a covert channel out of trusted, allowlisted traffic is the same instinct behind actors who turn Microsoft 365 itself into a C2 channel. The traffic is not anomalous, so signature-based egress filtering waves it through.

Hunt on the Exchange server, not the laptop

Patch CVE-2026-42897 first; that closes the door for new infections. But patching is step one, not remediation, because it does nothing about a mailbox that is already owned. For on-premises Exchange operators, treat any mailbox that opened a suspect message during the exposure window as compromised and work the server side:

• Audit mailbox folder permissions for Owner-level grants to the Default or anonymous user. That grant is the core persistence artifact and it should not be there.

• Review Outlook add-ins that hold ReadWriteMailbox permission and revoke any you cannot account for; those are the tokens OWAReaper steals.

• Inspect the OWA offline cache for injected iframes in stored messages, and clear it for affected users.

• Watch for OWA or Exchange hosts making outbound calls to GitHub Commit Search, which a mail server has no legitimate reason to do.

• Remove access at the server, then rotate credentials. Doing it in the other order just hands the attacker the new session.

The through-line across ZimReaper, OWAReaper, and the identity-theft campaigns before them is that the endpoint is no longer where mail-account persistence lives. It lives in tokens, mailbox permissions, and app grants on the server. If your incident playbook for a phished mailbox still ends at a password reset, this campaign is the reason to rewrite it.