OWAReaper survived password resets through OWA persistence

On 30 July 2026, technical reporting detailed a Russian TA488 campaign exploiting CVE-2026-42897 in on-premises Outlook Web Access. Opening a crafted message in affected OWA was enough to run JavaScript inside the reading pane. The OWAReaper implant established persistence across several layers: browser storage, offline message cache, add-in tokens and mailbox permissions.

The operational conclusion is uncomfortable: a password reset, ordinary session revocation and even complete endpoint reimaging might not remove every persistence mechanism. Some changes lived on Exchange and required deliberate reversal.

What happened from 22 July

Proofpoint documented activity observed from 22 July 2026. Reporting published on 30 July collected the technical scope:

• the operation exploited CVE-2026-42897, scored 8.1;
• targets included US and European government entities plus telecommunications, finance, hospitality and aerospace;
• mail came from attacker-controlled and previously compromised accounts;
• the recipient did not need to click a link or open an attachment;
• rendering the message in vulnerable OWA triggered execution;
• the implant operated inside the browser context;
• the operator used two C2 channels and two exfiltration paths;
• not every persistence method disappeared after credentials changed or a host was rebuilt.

Microsoft previously marked the flaw as exploited as early as May 2026. Proofpoint found infrastructure created in March, but registration time alone does not prove zero-day exploitation from March. It supports a preparation hypothesis, not a definitive first-compromise date.

Half-click mail with no link or attachment

Proofpoint calls this a half-click exploit. A recipient has to open the message in webmail but does not click a URL, launch a file or approve a macro. That defeats awareness programmes focused solely on “do not click.”

The messages were intentionally unremarkable, covering supply-chain analysis, research updates, tourism or gas-market metrics. A lack of links and attachments could reduce user suspicion and lower some filter scores.

The exploit used an onload handler. Trigger material and payload blobs were stored in social-media icons embedded in message HTML. Further fragments followed # symbols that the normal image parser stopped processing. The loader assembled Base64 data and executed the result as JavaScript.

We do not reproduce the message structure or payload. Defensively, the important point is that an innocuous-looking icon and valid HTML can carry executable data.

OWAReaper inside the reading pane

Once running, the implant inherited APIs available to the OWA session. It first rewrote the message on Exchange to remove exploit content, reducing visibility and complicating analysis of the exact email that fired the chain.

OWAReaper also disabled pop-ups and right-click while active, created a target-specific session key and collected the user’s address, username and Outlook settings.

It inserted two invisible input elements into the DOM to encourage browser autofill to enter saved credentials. Not every browser stores a password and not every manager fills invisible fields, but the feature expanded credential-theft potential in environments that allowed it.

localStorage persistence

The implant wrote an encrypted copy of itself and a decryption wrapper to localStorage. Opening another OWA tab could start the code again.

This mechanism belongs to the browser profile. Reimaging the endpoint should remove that store, but only that layer. Server-side persistence or a malicious cached message could reintroduce execution.

Preserve:

• OWA-domain localStorage;
• IndexedDB;
• application and offline message cache;
• browser extensions and Outlook add-ins;
• browser-process memory;
• Exchange message-modification history;
• mailbox access and permission-change logs.

IndexedDB as a second carrier

OWAReaper placed a hidden iframe into messages stored in OWA’s offline IndexedDB cache and enabled caching. Opening the malicious message from local storage could reinfect the profile.

That explains why removing localStorage alone may be incomplete. Browser profiles contain several independent stores. Clean them under a controlled procedure, after preserving evidence.

Outlook add-ins and OAuth tokens

The implant checked for Outlook add-ins holding ReadWriteMailbox. Where present, it attempted to obtain OAuth tokens.

Tokens have their own lifecycle and can remain useful independently of a password. Response must cover:

• session and refresh-token revocation;
• enterprise application and consent review;
• add-ins with ReadWriteMailbox;
• unusual post-infection token use;
• new or changed application permissions;
• client logins inconsistent with normal activity.

A password reset is one step, not a complete OAuth response.

The most dangerous persistence: Default as Owner

OWAReaper granted the Default identity Owner permission on every mailbox folder. In Exchange, Default is not one user; it represents authenticated users in the organisation who have no explicit permission entry.

If the attacker controlled another account in the environment, they could preserve access to the victim’s mailbox after the victim changed their password. This was an Exchange-side modification, so reinstalling a laptop did not undo it.

Administrators need to review folder permissions across affected mailboxes, particularly Default and Anonymous. Removing a single suspicious account is insufficient when the implant changed a collective role.

Two command-and-control channels

OWAReaper accepted commands through two mechanisms. The first used GitHub’s Commit Search API. Every 24 hours, the implant searched commit messages for the target email address. Matching data was decrypted with a hard-coded value and a session key.

Three command headers were described:

• code — replace the implant;
• domn — rotate C2 servers;
• cmnd — execute JavaScript.

The second channel used operator-sent emails. OWAReaper searched IndexedDB for a target-address and encoded-content structure.

Using legitimate GitHub infrastructure does not make activity invisible. OWA sessions querying Commit Search at a regular interval with a corporate email address are valuable signals.

Two exfiltration paths

The primary method sent data over HTTPS, placing AES-CTR-encrypted information in URI paths. A fallback encoded data inside DNS query labels to an actor-controlled domain.

DNS was a backup rather than the first route. An organisation monitoring only web proxy traffic can miss it. Resolver logs, label length and entropy, query frequency and source-process correlation are required.

Our DNS tunnelling detection guide covers the technique in greater detail.

Who is affected

CVE-2026-42897 affects on-premises Exchange OWA, not Exchange Online as a service. Hybrid organisations may still run local servers and management tooling. “We use Microsoft 365” does not complete inventory.

Scope should include:

• Exchange Server 2016 and 2019 under the applicable update support;
• Exchange Server Subscription Edition;
• internet-facing OWA deployments;
• servers kept only for hybrid or management purposes;
• browser profiles of users who accessed mail through OWA.

Our separate guide to CVE-2026-42897 in Exchange OWA covers patch and mitigation details.

Step-by-step response

1. Apply Microsoft’s fixes across every scoped local server and management tool.
2. Identify OWA users and messages opened during the possible exposure window.
3. Preserve browser evidence, including localStorage and IndexedDB.
4. Review message modifications, because the implant removed exploit content from Exchange.
5. Audit folder permissions, especially Default and Anonymous.
6. Revoke OAuth tokens, sessions and add-in consent.
7. Remove unauthorised server-side permissions and validate them again.
8. Hunt GitHub API, HTTPS and DNS patterns from Proofpoint’s research.
9. Search neighbouring identities, because the operator could use another account.
10. Rebuild the profile or host, but only after Exchange persistence is removed.

Reset passwords after access paths are contained. Otherwise an actor may capture new credentials or continue using a token or folder role.

Detection across mail, IAM and SOC

OWAReaper crosses three teams. Mail administrators see folders and add-ins, IAM sees tokens and sessions, while SOC sees browser and network telemetry. Correlate:

• a linkless message causes unusual OWA JavaScript;
• message content changes shortly after reading;
• Default receives Owner on many folders;
• an add-in with ReadWriteMailbox generates an unusual token;
• OWA queries GitHub Commit Search;
• new localStorage and IndexedDB values appear;
• long, high-entropy DNS labels are observed;
• users receive similar informational mail from compromised accounts.

Build these correlations through a Sigma and SIEM detection-engineering process and manage campaign context through the Cyber Threat Intelligence lifecycle.

Evidence required for closure

Containment is complete only after every persistence layer is reviewed again. Evidence should show clean folder permissions, no unauthorised add-in or token, removed localStorage and IndexedDB entries, patched Exchange servers and no continuing C2 signal. Record results for each user, mailbox, browser profile and server. A generic “password reset completed” entry does not represent OWAReaper’s scope.

Perform a controlled permission test as well: unauthenticated and standard accounts must not read folders through the Default role, and a new add-in token must require an approved application. Restore normal access only after these checks pass. Maintain heightened monitoring of DNS, GitHub API and mailbox events for a period aligned with log retention and the earliest confirmed activity.

Source findings versus Breachroad conclusions

Proofpoint confirms the targeting, half-click loader, OWAReaper functions, localStorage, IndexedDB, add-in tokens, folder-permission changes, C2 channels and exfiltration. Microsoft confirms the vulnerability and fixes. The zero-day timeline remains an inference from infrastructure chronology, not conclusive proof of first use.

Our response ordering, cross-team correlation and closure metrics are Breachroad conclusions. An IT security audit can validate Exchange, IAM and telemetry.

The campaign also changes user education: a message is not safe merely because it has no link. Cybersecurity and phishing training must accompany OWA patching and technical readiness, because users could not identify the exploit from an ordinary-looking message.