Most Exchange incident response follows the same playbook: patch the flaw, rotate the compromised credentials, re-image the endpoint if needed, confirm the account is clean. Against the campaign that security researchers disclosed on July 30, 2026, every step in that playbook can succeed and the attacker keeps their access anyway, because the access was never on the endpoint or the credential in the first place.
A half-click flaw with government targets
The campaign runs through CVE-2026-42897, a cross-site scripting vulnerability in Outlook Web Access that Microsoft patched with an out-of-band fix in June 2026 after warning about active exploitation the previous month. The threat actor behind it, tracked as TA488, Void Blizzard, or Laundry Bear depending on the vendor, sends specially crafted emails through already-compromised accounts. OWA’s improper HTML sanitisation executes attacker-controlled JavaScript the moment a target opens the message in the webmail interface, no click on a link required. Infrastructure tied to the campaign dates back to March 2026, two months before Microsoft’s temporary mitigation, meaning this was very likely run as a genuine zero-day against government entities and organisations in telecommunications, financial services, hospitality, and aerospace across the US and Europe.
Why the standard response does not work here
What makes this campaign worth a specific write-up rather than a routine patch-now advisory is the implant it deploys. OWAReaper does not primarily rely on a foothold on the victim’s machine. Its core mechanism is a server-side call to Exchange’s UpdateFolder API that grants the attacker’s infrastructure owner-level access to the compromised mailbox through Exchange’s Default user alias. That permission grant lives on the Exchange server itself, not on the endpoint and not in any credential store, so none of the usual remediation steps touch it. Patching the OWA vulnerability stops new infections. Rotating the user’s password does not revoke a permission the attacker granted at the mailbox level. Re-imaging the device does not help either, because the implant also plants a hidden iframe inside messages cached in OWA’s offline IndexedDB store, which re-triggers the exploit chain the moment the rebuilt endpoint syncs the mailbox again.
What actually closes the door
Closing this access requires a deliberate audit of Exchange mailbox permissions for exactly this kind of anomalous Owner-level grant on the Default alias, something that sits outside almost every organisation’s routine incident response checklist because it was never designed to catch a persistence mechanism that lives entirely server-side. For any organisation running on-premises Exchange or hybrid OWA access, and particularly for government bodies, critical infrastructure operators, and regulated sectors across Europe that NIS2 and sector-specific rules already hold to a higher incident response standard, this is a strong argument for extending mailbox permission reviews beyond the account level and treating “we patched and rotated credentials” as an incomplete answer until the server-side grants have been checked too.
If your organisation runs Exchange or OWA and needs a mailbox permission audit, help closing out this specific persistence technique, or a broader review of your incident response process for attacks that survive the usual remediation steps, contact Excello Digital. We help European organisations respond to threats that do not stop at patch and rotate.