Every security awareness program on the planet teaches the same core lessons…don't click the link and don't open the attachment. Make sure that you hover over the URL, and did you check the sender. Think before you click! We've spent years drilling this into people, we've built an entire industry around it. Phishing simulations, mandatory training modules, shame-adjacent leaderboards, little pop-up warnings that say "This email came from outside your organization." We have turned "don't click" into the closest thing cybersecurity has to a universal commandment.
On July 22, 2026, a Russian threat group called TA488 launched a campaign that made all of it irrelevant (more hyperbole than anything, but all that training has a new weakness). Their new weapon is called OWAReaper, it targets users using Outlook Web Access (OWA), the browser-based email client that millions of people use to check their work email every day. The attack exploits CVE-2026-42897, a cross-site scripting vulnerability in Microsoft Exchange Server. The vulnerability exists in how the Exchange server processes HTML content inside email messages. When a user opens a specially crafted email in OWA, malicious JavaScript executes automatically inside their browser session. No link to click, no attachment to open, no macro to enable…just reading the email. The thing your users do hundreds of times a day without thought…the thing you trained them to do as part of triaging their inbox.
Proofpoint, who discovered and named OWAReaper, calls this a "half-click" exploit. I'm not sure how I feel about "half-click", but I guess it counts as the user's only action is opening an email to see what it says.
I want to unpack this one carefully, because the technical details matter and because the implications go further than most of the coverage I've seen so far. Let's start with how the emails look, because this is where social engineering gets interesting by being aggressively boring. TA488 (AKA: Void Blizzard and Laundry Bear, because threat actor naming conventions remains an industry-wide embarrassment) sent these emails from compromised accounts, not spoofed ones. Real accounts, real organizations, real sender addresses that pass every authentication check your email gateway runs. The subject lines were intentionally mundane: semiconductor supply chain metrics, energy market updates, tourism indicators, public health data. The kind of email that lands in your inbox and you open it, glance at it, decide it's not relevant, and move on. That three-second interaction is all OWAReaper needs.
Proofpoint noted that the boring-on-purpose lure strategy is a deliberate evolution from TA488's earlier campaigns. They're not trying to trick you into clicking something exciting. They're counting on you doing exactly what a responsible employee does with a mildly relevant email: open it, skim it, close it. Your diligence is their attack vector, which is a scary thought.
The targeting was broad: U.S. and European government entities, plus telecommunications, financial services, hospitality, and aerospace. Proofpoint flagged the volume and breadth as unusual for TA488, suggesting the campaign may have been intentionally noisy to blend in with normal email traffic. Think about that for a second. They sent so many emails that the campaign itself looked like spam (volume as camouflage…genius). That's not something most threat intel dashboards are optimized to catch. That should make every security awareness program manager deeply uncomfortable.
Now let's talk about what happens after you open that email, because this is where OWAReaper gets genuinely impressive (in the worst possible way). The moment the email renders in OWA, the Exchange server fails to properly sanitize the HTML in the message body. A small JavaScript loader fires via an onload event handler, parses the rest of the email body, reassembles a Base64-encoded payload that's been hidden inside what looks like social media icon URLs (after the # character, where nobody's looking), and executes it. All of this happens inside the OWA reading pane. There is no file dropped to disk, no process spawned on the endpoint, so your EDR sees nothing because there is nothing for it to see. The malware lives entirely inside the browser.
The first thing OWAReaper does after executing is cover its tracks. It uses Outlook's own APIs to rewrite the triggering email directly on the Exchange server, stripping out all the exploit artifacts. The email that compromised you now looks like a normal email. If your incident response team goes looking for the initial access vector, the evidence has already been cleaned up by the malware itself. It also temporarily disables right-click functionality and OWA pop-ups while it operates, a small but telling detail that shows how carefully this thing was built.
Then it starts harvesting. OWAReaper creates invisible input elements on the page and waits for the browser's autofill to populate them, capturing the user's saved OWA username and password without any visible prompt. It collects the account's email address, username, and Outlook configuration settings. It generates a unique session key for the victim. All of this happens silently, inside a browser tab that looks completely normal.
But the persistence mechanism is the part that should keep you up at night. OWAReaper writes an encrypted copy of itself and a decryption wrapper into the browser's localStorage under a field called PageDataPayload.OwaUserDefaultSettings. That's not a random key the attackers invented. That's a legitimate key that OWA itself uses during page rendering. Every time the user opens a new OWA tab, Exchange's native frontend sync process reads that key and automatically re-executes OWAReaper as part of normal page loading. The malware has grafted itself onto OWA's own startup routine. It runs every time email runs.
That alone would be bad enough, but OWAReaper has a second persistence layer that's worse. It checks whether the victim has any Outlook add-ins installed with ReadWriteMailbox permissions. If it finds one (and in most enterprise environments, it will), it abuses that add-in's capabilities to call GetClientAccessToken and steal OAuth tokens. Then it calls UpdateFolder to grant Exchange's built-in "Default" user Owner-level permissions on every mail folder in the victim's mailbox.
I need to explain why that matters, because it's the detail that breaks standard incident response.
In Exchange, the "Default" user isn't a person. It's a low-privilege preset alias that exists in every Exchange tenant. It represents any authenticated user in the organization who doesn't have an explicit permission entry. By granting "Default" Owner-level access to every folder, OWAReaper has effectively opened the victim's entire mailbox to anyone else in the organization who has valid credentials. If TA488 has compromised even one other account in your environment (and given that they're sending these emails from compromised accounts, they almost certainly have), they now have persistent access to the victim's mailbox that survives everything you'd normally do to remediate. Password reset? Doesn't matter. The access isn't tied to the victim's password. Session revocation? Doesn't matter. The OAuth tokens operate independently. Full device reimage? Doesn't matter. The persistence lives on the Exchange server, not the endpoint. The mailbox permission change is server-side. It will survive until someone specifically audits Exchange folder permissions and removes the Owner-level grant from the Default user.
How many organizations do that as part of their standard incident response playbook? I'm guessing very few. Most IR teams would reset the password, reimage the laptop, rotate credentials, and call it done. Against OWAReaper, that checklist leaves the attacker fully operational.
There's even a third persistence layer. OWAReaper plants a hidden iframe in messages stored in OWA's offline IndexedDB cache. If the device gets reimaged and the user logs back into OWA, the cached messages can re-trigger the infection cycle.
For command and control, OWAReaper uses GitHub commit messages. It searches public GitHub repositories for commits containing encoded instructions, which means C2 traffic looks like normal developer activity and blends into the kind of outbound traffic that most organizations allow without inspection. For data exfiltration, it prefers encrypted HTTPS traffic disguised as image requests routed through legitimate CDNs. If HTTPS fails, it falls back to DNS tunneling, AES-CTR encrypting the data, Base32-encoding it, and splitting it across subdomain labels of an attacker-controlled domain.
Every design decision in this thing is optimized for one goal: look normal. Uses legitimate keys. Uses legitimate APIs. Uses legitimate CDNs. Uses legitimate sync processes. It hides inside the tools the organization already trusts. It's the digital equivalent of breaking into a building by putting on a maintenance uniform and walking through the front door.
What makes this worse is the evolution it represents. OWAReaper is the successor to ZimReaper, a tool TA488 deployed earlier against Zimbra webmail servers using the same half-click XSS approach (that campaign exploited CVE-2025-66376). ZimReaper worked, but it was loud. It mass-exfiltrated entire mailboxes, which generated traffic patterns that attentive defenders could spot. OWAReaper learned from that. It dropped the mass exfiltration in favor of targeted, selective data theft. It improved the persistence. It added the Exchange permission manipulation that ZimReaper never had. It refined the C2 channels. This is an adversary iterating on their own tooling the way a product team would. They shipped version one, collected feedback (in the form of detection and attribution), and built version two to address the gaps. They have a development cycle. That alone should tell you something about the maturity of the operation.
I've been working in technology for over twenty years and I've seen a lot of clever malware. OWAReaper is one of the most thoughtfully engineered pieces I've read about. Not because any single technique is revolutionary, but because every piece fits together into something that is genuinely difficult to detect, difficult to attribute, and difficult to remove even after you know it's there.
So what do we do about it?
The immediate technical answer is straightforward. Patch CVE-2026-42897. Microsoft shipped emergency mitigations during active exploitation, and if you're running on-premises Exchange with OWA exposed, this should already be done. But patching only prevents new infections. It does nothing about access that OWAReaper has already established.
For organizations that may have been exposed, Proofpoint's remediation guidance is specific and worth following. Audit Exchange Web Services token grants for all installed Outlook add-ins, with particular attention to anything holding ReadWriteMailbox permissions. Revoke those tokens. Review Exchange folder permissions across the entire tenant and remove any Owner-level grants to the Default user that you didn't explicitly create. On affected endpoints, clear OWA's IndexedDB message cache and delete the PageDataPayload.OwaUserDefaultSettings localStorage key. Reset passwords and invalidate sessions, but understand that this alone is not sufficient.
The infrastructure associated with this campaign dates back to March 2026, roughly two months before Microsoft's out-of-band patch. TA488 launched the current wave on July 22, one day before Proofpoint and the NSA published a joint advisory about the group's earlier Zimbra activity. That timing doesn't feel accidental. It feels like an actor who knew disclosure was coming and decided to run the new campaign before defenders had the full picture. Organizations were potentially exposed for months before a patch existed, and the campaign went live at the exact moment the security community's attention was pointed somewhere else.
The window for existing compromises could be substantial. If your organization runs on-premises OWA and received any emails with those mundane subject lines between March and July 2026, you should be investigating. Not as a theoretical exercise…an active hunt.
But the bigger question isn't about this specific vulnerability. It's about the assumptions we've been operating under. Most security programs are built on a set of implicit beliefs about how email attacks work. The user has to do something they weren't supposed to do. There will be an indicator on the endpoint. Password rotation limits the blast radius. Reimaging restores the machine to a known-good state. OWAReaper violates every one of those assumptions. The user didn't do anything wrong. There's no endpoint indicator. Password rotation doesn't help. Reimaging doesn't evict the attacker. If your incident response playbook is built on those assumptions (and most are), you have a gap you probably haven't tested for.
I'll be honest, I'm not sure how I would talk to executives about this one. "Someone read an email and now a Russian intelligence service has persistent access to our mailboxes that survives every remediation step we'd normally take" is not a sentence that inspires confidence. (But it's accurate.) The challenge for security leaders is figuring out how to communicate that the threat has evolved past the defenses we've been presenting as adequate for the last decade without making it sound like those defenses were worthless. They weren't worthless…they were built for a different attack model and now that attack model has changed.
The awareness training question is the most uncomfortable one. I still believe security awareness training has value. Teaching people to recognize social engineering, to report suspicious messages, to think critically about what lands in their inbox…those are good things. I'm not ready to throw the whole program out. But we have to stop pretending that user behavior is the primary control against email-based compromise. When the attack fires on open, not on click, the user is no longer the control point. The infrastructure is. Server-side sanitization, the Exchange permissions model, the email platform itself. Those are the things that failed here, and those are the things we need to invest in protecting.
I think about all the budget conversations I've sat in where awareness training was the first line item approved and infrastructure hardening was the one that got pushed to next quarter. Awareness training is cheap, easy to measure (or at least easy to produce numbers that look like measurement), and it makes leadership feel like they're doing something visible. Infrastructure hardening is expensive, invisible when it works, and impossible to attribute ROI to until something goes wrong. OWAReaper is the "something going wrong" that exposes which of those investments actually mattered.
We've also built a culture where the user gets blamed for the breach. "Someone clicked a phishing link" is the explanation that launches a thousand retraining campaigns. What's the retraining campaign for "someone opened an email"? There isn't one. There can't be one. You can't train people not to read their email. Which means the failure has to be absorbed somewhere else in the stack, and we need to be honest about whether we've invested in that somewhere else or just assumed the user would save us.
There's also a detection conversation we need to have, because most of the tools we rely on were not designed for this threat model. Your EDR is watching the endpoint. OWAReaper doesn't touch the endpoint. Your SIEM is ingesting logs from your email gateway and your firewall. OWAReaper's C2 looks like GitHub browsing and CDN image requests. Your DLP is scanning for sensitive data leaving the network in recognizable patterns. OWAReaper encrypts everything and fragments it across DNS subdomains. I'm not saying these tools are useless. I'm saying they were built to watch the doors and windows, and this attacker came in through the plumbing.
The organizations that will catch this are the ones doing the unglamorous work: auditing Exchange permissions regularly, monitoring OAuth token grants, reviewing add-in installations, and treating browser-resident threats as a real category rather than a theoretical one.
If you're still running on-premises Exchange with OWA exposed to the internet, this should be the story that makes you seriously reconsider that architecture. Not because cloud email is invulnerable (it is not), but because the attack surface of a self-managed Exchange server with browser-based access is enormous, and the resources required to defend it properly exceed what most organizations are willing to commit. That's not a criticism. It's math.
TA488 didn't invent a new concept. They perfected an existing one. They took the "half-click" technique they'd already used against Zimbra, improved the loading mechanism, improved the persistence, improved the exfiltration, and pointed it at a much bigger target. They'll do it again…maybe not against OWA next time, but against whatever webmail platform you migrated to after reading this article. The underlying class of vulnerability (webmail clients that render attacker-controlled HTML with insufficient sanitization) is not unique to Exchange. Any web-based email client that processes message content in the context of an authenticated session is a potential target.
The lesson isn't "patch this CVE." The lesson is that our mental model of email security has a hole in it, and the Russians just drove a truck through it. We built our defenses around the click. The click is no longer the moment that matters. The open is. We need to catch up.
The next time you sit through a phishing simulation debrief where everyone celebrates a 3% click rate, ask yourself: what's the open rate?
Because that's the number that matters now.