Contribution
This post adds a detection method that joins TA488's Zimbra and Outlook Web Access campaigns. The source reports each document the persistence artefacts on their own platform: CISA records the Zimbra application passcode and IMAP enablement, and Proofpoint records the Exchange folder grant and browser storage. The contribution here is the cross-product correlation: one hunt joining message-rendered script execution, external browser traffic and server-side mailbox state drift across both products, with repeatable permission and passcode checks for the persistence that survives a rebuilt endpoint and a password reset.
The pattern
A malicious message does not need a link or attachment when the webmail reader itself is the exploit surface. TA488, also tracked as Void Blizzard and Laundry Bear, has now used this idea against two mail platforms. The user's risky action is opening or previewing an ordinary-looking message. The server renders attacker-controlled HTML in a trusted mailbox session, and the browser runs the payload with access to the webmail application's data and APIs.
Unit 42's Zimbra investigation describes CVE-2025-66376, a view-based flaw used against government, defence, transport and financial organisations. The message carried an obfuscated division containing a Base64-encoded script. Loading an invisible SVG decoded and injected the JavaScript. Unit 42 saw the payload collect CSRF tokens, the email address and password, two-factor authentication scratch codes, system details, search history and the previous 90 days of email. The script sent that material to hard-coded command-and-control infrastructure.
The joint CISA advisory AA26-204A matters because it moves the Zimbra activity beyond a single vendor report. The advisory says the campaign had targeted Western government and commercial organisations since at least July 2025. It also records the change in tradecraft: earlier Laundry Bear access included password spraying, phishing and pass-the-cookie activity; the newer chain needed only the victim to view a malicious message in a vulnerable Zimbra client. Patching CVE-2025-66376 blocks that entry path, but CISA's account also makes clear that exposed mail, directory data and credentials need their own incident response.
Proofpoint's Outlook Web Access follow-up shows the same actor turning the idea into persistence. On 22 July, TA488 sent vague informational messages that abused CVE-2026-42897. OWA failed to sanitise HTML in the message body. An onload handler assembled JavaScript from Base64 fragments hidden after hash characters in social-media image data, then ran OWAReaper in the reading pane. There was no suspicious link for the user to click.
OWAReaper removed the exploit content from the message after execution. It then stored an encrypted copy of itself in the browser's PageDataPayload.OwaUserDefaultSettings local-storage key, where the normal OWA synchronisation flow would execute it when another OWA tab opened. It also poisoned messages in the offline IndexedDB cache with a hidden iframe. Those two mechanisms explain why clearing a single message or rebuilding the device may not finish the job.
The more serious persistence sat on Exchange. Proofpoint found OWAReaper looking for Outlook add-ins with ReadWriteMailbox permission, calling GetClientAccessToken to steal OAuth tokens, then using UpdateFolder to grant the built-in Default user Owner rights on every mail folder. Any authenticated user in the organisation could then reach the victim's mailbox. A password reset for the victim does not remove that access-control change.
The implant took commands from specially formed GitHub commit messages or from inbound emails. It sent data over HTTPS, sometimes through legitimate image CDN services, and fell back to DNS tunnelling. This mixture is awkward for a SOC because each component can look ordinary on its own: a GitHub API query, an image request, an inbound message, or a mailbox permission change. The chain is much less ordinary when those events follow the rendering of one bland message.
Why it matters to cloud defenders
These reports concern self-managed Zimbra and Exchange infrastructure, but the detection problem crosses into cloud operations. Hybrid Exchange organisations synchronise identities and mail settings with Microsoft 365. Security teams often send reverse-proxy, DNS and identity records to cloud SIEMs while Exchange administration remains with a separate messaging team. The attacker benefits when nobody joins those records.
Mailboxes also contain the reset links, incident updates and business data that unlock later SaaS access. ZimReaper sought credentials and 2FA scratch codes. OWAReaper could steal EWS tokens and open mail folders to other authenticated users. Once an attacker can read a mailbox, they can observe password resets, study internal service names and follow conversations about the incident. The data payoff is bigger than the mail server itself.
This changes the closure test for a webmail vulnerability. A patched server answers, 'Can the same message exploit us again?' It does not answer, 'Did the earlier exploit alter mailbox access, leave a token behind or seed browser storage that will run again?' Cloud defenders need both answers before they close the case.
ATT&CK mapping
The entry maps to T1189 Drive-by Compromise. ATT&CK includes cross-site scripting in built-in web interfaces as a form of drive-by compromise. Here, the trusted site is webmail and the user reaches attacker-controlled code by opening a message in the normal reading pane. A separate exploit-public-facing-application label would miss the important part: the payload executes in the user's browser session, not as direct server-side code execution from an unauthenticated scanner.
The credential theft needs a cautious label. OWAReaper does not capture a login in progress; it plants invisible input elements and lets the browser's autofill disclose a credential the user saved earlier. The closest ATT&CK home for that saved-credential theft is T1555.003, Credentials from Password Stores: Credentials from Web Browsers, and even that is a behavioural fit rather than an exact one, because the implant coaxes the credential out of autofill instead of reading browser credential files. ZimReaper's scratch-code retrieval is a different path again: the script requests the codes from the server through GetScratchCodesRequest, authentication material the joint advisory maps to T1556.006 alongside the application passcode. The collection payoff maps to T1114 Email Collection. ZimReaper took 90 days of mail and search history, while OWAReaper created continuing access to Exchange folders. The exfiltration legs have their own homes: the encrypted HTTPS channel maps to T1048.002 and the DNS-label fallback to T1048.003, the labels the joint advisory applies to the Zimbra campaign's Flowerbed exfiltration.
The server-side persistence moves deserve their own labels, because they are what the closure test misses. OWAReaper's use of add-ins holding ReadWriteMailbox permission to call GetClientAccessToken maps to T1528 Steal Application Access Token: the stolen EWS token keeps working after the victim's password changes, so token revocation is a separate remediation step. The UpdateFolder call that grants the built-in Default user Owner rights maps to T1098 Account Manipulation; ATT&CK's sub-technique T1098.002, Additional Email Delegate Permissions, describes exactly this grant of mailbox rights to another principal. Both changes live on Exchange, not the endpoint, which is why they survive a rebuilt laptop and a cleared browser profile.
Zimbra's durable change is authentication state rather than folder rights. The joint advisory maps the ZimbraWeb application passcode to T1556.006, Modify Authentication Process: Multi-Factor Authentication, because the passcode and the stolen scratch codes both bypass the account's 2FA flow, and the passcode arrives beside a zimbraPrefImapEnabled preference change that opens a protocol where that flow does not apply. A password reset revokes neither.
The end-to-end chain is therefore: message preview as T1189, saved-credential theft as T1555.003, token theft as T1528, then mailbox access and data collection as T1114 with exfiltration over T1048.002 and T1048.003, while the T1098 folder grant and the T1556.006 passcode hold the door open. Persistence is implemented through browser storage, stolen tokens, authentication material and mailbox ACL changes rather than a normal endpoint autostart. That last distinction should shape the hunt.
Detection guidance
Start at delivery, but do not stop there. Search mail-gateway or message-sanitisation telemetry for HTML bodies containing an event handler such as onload, Base64 fragments split across image or SVG data, and no conventional link or attachment. This is a triage filter, not a stand-alone verdict. HTML newsletters use event handlers and embedded images, so the signal becomes useful when the message was opened in OWA or Zimbra and the same browser session soon contacted an unusual external destination.
At the reverse proxy, retain the mailbox account, session identifier, request URI, source address and user agent. A vulnerable message-view request followed by requests from the same browser to an unfamiliar host is the first product-neutral join. For the OWAReaper activity reported by Proofpoint, alert on paths beginning /assets/v1_ sent through images.weserv.nl, i3.wp.com or slack-imgs.com, especially when the image service is being asked to fetch a newly seen domain. Also look for direct POST requests carrying files named msanalytics.json, ews_extensions_debug.json or poison_wizard_error_dom.html. Those names are campaign-specific, so keep a second behaviour-based detector for long encoded URL paths after an OWA session.
DNS is the fallback channel. Proofpoint describes encrypted data encoded with the alphabet 0-9a-v, split into two to four labels beneath an attacker-controlled domain. A practical DNS analytic groups queries by client and parent domain over five minutes, then alerts when it sees repeated long labels restricted to that alphabet, high label uniqueness and few successful answers. Exclude known security scanners and sanctioned DNS-testing tools. Raise the score when the client recently accessed OWA or when the queried domain is new to the organisation.
The decisive Exchange check is permission drift. Proofpoint says OWAReaper granted Owner to the built-in Default user on every mail folder. The campaign hit self-managed Exchange, so use Get-MailboxFolderPermission, which Microsoft documents for on-premises Exchange Server (2010 through Subscription Edition) as well as Exchange Online. For a suspected mailbox, run it against high-value folders first:
Get-MailboxFolderPermission `
-Identity 'victim@example.org:\Inbox' `
-User Default |
Where-Object { $_.AccessRights -contains 'Owner' }
Repeat the check for Sent Items, Deleted Items, Drafts and any custom folders. In a larger response, enumerate mailbox folders, collect the output as a point-in-time ACL inventory, then compare it with the previous approved snapshot. Alert when Default gains Owner, PublishingEditor or another write-capable role outside a recorded change. The useful baseline is not 'Default exists', because that principal is normal. The useful baseline is the rights assigned to it.
Use Microsoft's Get-MailboxFolderPermission documentation as the command reference; for a tenant in Exchange Online, that page recommends the optimised Get-EXOMailboxFolderPermission variant, which takes the same identity and user arguments. Where a malicious right is present, reset it with the approved local value rather than guessing. For an organisation whose baseline is None, the corresponding remediation is:
Set-MailboxFolderPermission `
-Identity 'victim@example.org:\Inbox' `
-User Default `
-AccessRights None
The Microsoft command reference documents the update path. Capture the before and after output in the case record. If the organisation deliberately grants Default access on shared folders, compare against the approved entitlement rather than forcing None everywhere.
Review Outlook add-ins on affected accounts and focus on add-ins with ReadWriteMailbox. Proofpoint found OWAReaper using that permission to request EWS client-access tokens. Revoke affected tokens, remove unknown add-ins and look for token use from addresses or clients that do not match the user's normal pattern. Do not treat a password change as token revocation.
On Zimbra, the equivalent drift check is the account-change pair. Search application telemetry for CreateAppSpecificPasswordRequest naming the application ZimbraWeb and ModifyPrefsRequest setting zimbraPrefImapEnabled to TRUE, then inventory application passcodes across affected accounts and compare creation times with the suspect message views. An unexplained passcode or a newly enabled IMAP path is live access, not residue: revoke the passcode, reset the preference and end active sessions before treating a credential rotation as meaningful, because the passcode authenticates on a path where the account's normal 2FA flow does not run.
Endpoint evidence still matters even though the implant is browser-resident. On affected profiles, preserve and inspect the PageDataPayload.OwaUserDefaultSettings local-storage key and the owa_offline_db IndexedDB database before clearing them. Search cached messages for hidden iframes and compare the stored settings with a clean profile. A clean EDR process tree does not clear this incident; Proofpoint's implant ran inside the normal OWA browser context and left no separate host process.
The strongest alert is a sequence, not one IOC: a user previews a suspicious HTML message; the browser starts encoded HTTPS or DNS traffic; Exchange folder permissions for Default gain Owner; then another account reads the mailbox. Any one event can be noisy. The sequence is narrow enough to justify immediate containment.
What to do now
Patch affected Zimbra and Exchange releases using the vendor guidance for CVE-2025-66376 and CVE-2026-42897. Confirm that every public webmail node and standby node is covered.
Search historical mail for the reported message shapes and indicators. Include bland informational subjects because TA488 deliberately avoided urgent lures and obvious calls to action. Preserve suspect messages before remediation so responders can recover the original HTML.
Treat every opened suspect message as possible code execution in the webmail session. Pull reverse-proxy, DNS, mail-gateway and browser evidence for the same account and time window. Check for image-CDN relays, encoded asset paths and DNS-label tunnelling.
Audit mailbox folder permissions, EWS tokens and Outlook add-ins. Reset malicious rights, revoke tokens and remove unapproved add-ins. Widen the permission review to other accounts because OWAReaper's
Defaultgrant was designed to let a second compromised account read the target mailbox. On Zimbra, revoke unexplained application passcodes (the campaign names its passcodeZimbraWeb) and reverse unexpected IMAP preference changes.Clear the documented local-storage and IndexedDB persistence only after preserving evidence. Force fresh webmail sessions, then verify that the settings do not return when OWA starts again.
Rotate credentials and recovery material after the access paths above have been removed. ZimReaper collected passwords and 2FA scratch codes, so replace both. Review mail for exposed reset links and incident correspondence that could support follow-on access.
Keep a scheduled mailbox ACL snapshot. The cheap long-term control is a diff that flags unexpected write-capable rights for
Defaultor other broad principals. That catches the server-side residue which a rebuilt laptop and a green EDR console will miss.