#in-browser malware

A week ago, Proofpoint released a report on a Russian-aligned threat actor using a phishing campaign that abused Zimbra Collaboration Suite. The report was written and scheduled for publishing right before another campaign began, which means it therefore missed this critical aspect of the scheme. However, they’ve now released an update. This one focuses on a campaign targeting Outlook users.

TA488 (aka Void Blizzard, Laundry Bear) has been abusing the known vulnerability CVE-2026-4289, a cross-site scripting vulnerability in Outlook Web Access (OWA). This phishing campaign is considered ‘half-click’, meaning that the act of simply opening the malicious email is enough to execute the embedded malware. Its targets are US and European government entities, as well as the telecommunications, financial, hospitality, and aerospace sectors, all prime sources for harvesting data on critical infrastructure. The point of compromise is a JavaScript browser-based implant they’re calling OWAReaper, built specifically to run in the application. The subjects of the phishing emails are typically generic in nature, enough to get the user to open the message and skim it, but disregard it as anything obviously malicious so they don’t report it.

If the email is opened in Outlook Webmail, the Outlook Exchange server mishandles the HTML from the message and runs arbitrary JavaScript. This executes the payload in the message body, and by its nature bypasses credential rotation, browser rebooting, and full re-imaging of the compromised device since it doesn’t require any action on the part of the victim to execute. OWAReaper runs in the OWA reading pane, using the app’s own API’s to rewrite itself on the Exchange server and delete indications of its presence. It then creates a unique session key for each victim, to gather the target's email address, username and settings. After that it simply waits for the user to login themselves and harvests their credentials. It retains persistence in the browser’s local storage, under an otherwise legitimate key in the setting field. Each time the victim opens Outlook in their browser, OWAReaper runs. It also scans for read/write permissions and, if it finds any, uses those to steal 0Auth tokens, elevating its own privilege to owner level on every email folder. This grants full access to the mailbox to any authenticated user in the same organization, which allows it to spread laterally throughout a network. Because its persistence is on the server side, only removal from the Exchange network will get rid of it.

There are two forms of command-and-control communications involved with OWAReaper, they are either fetched from public GitHub commit messages or read via inbound emails sent by the attacker. One of three commands is then sent: a code command replaces OWAReaper’s entire toolkit code, a domn command to rotate the C2’s that OWAReaper uses or a cmnd command for one-time execution of arbitrary code via eval(). Additionally, there are two ways data is exfiltrated. The primary method occurs over HTTPS with AES-CTR encrypted URI paths, either proxied through a set of defined image content delivery network (CDN) domains or directly to the actor-controlled server specified in the function initializing outbound network sessions. If the HTTPS method fails, OWAReaper will use DNS label tunneling to exfiltrate data inside the subdomains of standard DNS queries of an actor-controlled domain. This sets it apart from previous versions of similar attacks, since the whole point of HTTPS is that it’s secure. By remaining in-browser, it bypasses this security feature.

Proofpoint calls this the most sophisticated backdoor they’ve seen to date, and I have to agree. They’re confident in the attribution to this campaign as the same threat actor as the Zimbra campaign based on behavioral overlaps with ZimReaper, the use of encoded DNS exfiltration, and the focus on email and credential theft. CVE-2026-42897 does have a patch; Proofpoint presumes this campaign was initially written to exploit it as a zero-day. They recommend revoking and auditing Exchange Web Services (EWS) tokens for affected add-ins, auditing and removing Exchange folder permission grants to the Default user, clearing OWA's IndexedDB (owa_offline_db) and the PageDataPayload.OwaUserDefaultSettings localStorage key on affected endpoints, and blocking or alerting on outbound connections to the known C2 servers.