LAUNDRY BEAR

The May entry tracked CVE-2026-42897 as an Exchange OWA flaw whose interim protection depended on the EM Service auto-mitigation. Two things changed. Proofpoint has now attributed in-the-wild exploitation to a named Russian state-supported actor and published the implant's full mechanics (Proofpoint, 2026-07-29), and the mitigation is no longer the remediation; the July 2026 Security Update is, with the mitigation now something that must be actively torn down (Microsoft Exchange Team Blog, 2026-07-14). NCSC-CH appended the Proofpoint reporting to its own advisory on 2026-07-30 (NCSC Switzerland, 2026-07-30).

The actor is TA488, which Microsoft tracks as Void Blizzard and which this pipeline registers as LAUNDRY BEAR, the same Russian state-supported email-espionage actor a 16-nation joint advisory exposed on 2026-07-23 for its Zimbra campaign. Proofpoint assesses OWAReaper as an evolution of that campaign's ZimReaper payload, citing shared code including an identical invisible-element sizing and error-handling pattern (Proofpoint, 2026-07-29). Campaign activity began 2026-07-22 against government, telecommunications, finance, hospitality and aerospace targets across the US and Europe, using deliberately banal lure subjects with no call to action, Proofpoint reads the unusual breadth as intentional blending with bulk mail. Its stated infrastructure-creation date of March 2026 precedes Microsoft's May disclosure by two months, which is the basis for its assessment that zero-day use is feasible; that is an inference from infrastructure dating, not a confirmed finding.

Execution. The flaw is a failure to sanitise HTML in the message body, so a loader script in an onload= handler reassembles a Base64 fragment from the rest of the message and evaluates it, no link click and no attachment open, only viewing the message in OWA. The exploit and payload fragments are hidden inside the message's social-media icon elements, with next-stage data placed after # fragment markers where the browser's Base64 image parser stops reading, so the payload is not visible to casual inspection of the HTML. On execution OWAReaper first rewrites the delivered message server-side to strip the exploit content and suppresses OWA pop-ups and right-click, then enumerates the victim's address, username and settings.

Credential and token theft. It creates two invisible input elements and waits for the browser's own autofill to populate them with the saved OWA username and password. Separately it enumerates installed Outlook add-ins holding ReadWriteMailbox permission and, where one exists, abuses it to call GetClientAccessToken and obtain OAuth tokens.

Persistence, in three independent layers. Client-side, the implant writes an AES-encrypted copy of itself and a decryption wrapper into browser localStorage under a settings field of the legitimate PageDataPayload.OwaUserDefaultSettings key, which OWA itself evaluates during its own sync-restore flow, so every ordinary OWA tab-open re-launches it with no separate loader. A second client-side layer adds a hidden iframe to messages cached in OWA's offline IndexedDB store, so opening the cached message re-infects an endpoint even after a full re-image. The third is server-side and is the one that matters most: the implant calls UpdateFolder to grant Owner-level permission on every mail folder to the low-privilege "Default" preset alias that exists in every Exchange organisation. Proofpoint is explicit that this "requires deliberate removal from the Exchange server" and that credential rotation and re-imaging will not evict it.

Command and control. Two channels, both over infrastructure defenders generally trust. The implant polls GitHub's public Commit Search API every 24 hours for crafted commit messages containing the target's own email address, decrypting matches to a four-character command header that selects toolkit replacement, C2-domain rotation, or one-off code execution; in parallel it re-parses cached inbound messages every five minutes for the same command structure. Exfiltration runs primarily over HTTPS with encrypted URI paths, either relayed through a set of legitimate image-CDN domains or sent directly to the actor-controlled server when those proxies fail; if the HTTPS method fails altogether, the implant switches to DNS label tunnelling, packing the data into the subdomain labels of ordinary DNS queries for an actor-controlled domain. Notably, Proofpoint states there is no mass mailbox exfiltration here, unlike the Zimbra campaign, which is why this entry maps browser-session and credential-access behaviour rather than bulk email collection.

Patching. The permanent fix is the July 2026 Security Update, available as Exchange SE RTM publicly and for Exchange 2019 CU14/CU15 and Exchange 2016 CU23 only through the Period 2 Extended Security Update programme; organisations that were enrolled only in Period 1, which ended in April 2026, do not receive it (Microsoft Exchange Team Blog, 2026-07-14). Microsoft's own vulnerability record scores the flaw 8.1 and marks it exploited (Microsoft Security Response Center, 2026-07-14). Installing the update does not remove a previously applied mitigation: administrators who used the EM Service must remove the M2.1.0 IIS rules through the documented rollback, and those who ran the downloadable mitigation script must run its rollback. The known operational side effects of the mitigation era (broken OWA calendar printing, inline-image rendering problems, OWA-light failing, and false-unhealthy calendar-proxy health alerts) only clear once both steps are done, so a server left on mitigation-only status keeps them indefinitely (Microsoft Exchange Team Blog, 2026-05-14).

Detection. The highest-value signal is in mailbox audit and Exchange Web Services telemetry: a folder-permission change granting Owner rights to the "Default" alias, applied across many folders of one mailbox in quick succession. Client-side, monitor for writes to the OWA user-default-settings localStorage key outside the browser's own sync flow, and for OWA sessions in which invisible form inputs are created and immediately populated. On the network side, two egress patterns stand out from a mail client's normal behaviour: repeated polling of a public source-code hosting search API on a roughly daily cadence, and DNS queries with the label-length and entropy profile of tunnelled data.

Triage: OWA legitimately reads and writes its own settings keys constantly, so the presence of localStorage activity is not the signal; the discriminator is the specific settings-field path carrying an encrypted blob, and its correlation with a message open. For the server-side artifact the discrimination is cleaner: administrators do grant folder permissions, but they grant them to named users or groups for a specific folder, not Owner rights to the built-in "Default" alias across an entire mailbox. Treat any such grant as compromise until proven otherwise.

The prior entry covered the 16-nation joint advisory (AA26-204A) on LAUNDRY BEAR's (TA488 / Void Blizzard) zero-click Zimbra campaign exploiting CVE-2025-66376. Proofpoint's own two-part writeup adds mechanics the advisory did not detail (Proofpoint, 2026-07-23).

The exploit defeats Zimbra's client-side HTML sanitizer by tag-splitting: a fake CSS @import directive is fragmented across HTML tags so that the sanitizer strips each @import sequence individually, but "the browser successfully reconstructs <svg onload="eval(atob('…'))"> and executes it", a sanitizer-bypass-by-reassembly, where the surviving characters rejoin into valid executing script (Proofpoint, 2026-07-23). The resulting payload (which Proofpoint attributes to LAUNDRY BEAR's post-exploitation tooling and names ZimReaper) steals CSRF tokens, browser-autofill credentials, 2FA scratch codes and the Zimbra version/URL, exfiltrating tokens via DNS tunneling (Base32-encoded subdomains carrying a session id and a plaintext token-type label) and mail archives via HTTP POST.

The operationally important delta is persistence: after exploitation ZimReaper issues a CreateAppSpecificPasswordRequest to mint a Zimbra application-specific password labelled "ZimbraWeb" that bypasses 2FA and grants IMAP/POP3/SMTP access, then exfiltrates it via DNS for direct mailbox access (Proofpoint, 2026-07-23). Because that credential is independent of the primary account password, it survives a password reset and the CVE-2025-66376 patch alike.