Is your Exchange Outlook Web Access already compromised by the Russian OWAReaper campaign (CVE-2026-42897)?

09 August 2026 10 min read 2105 words

Yes — if your organisation runs Microsoft Exchange Server 2016, 2019 or Subscription Edition (SE) with Outlook Web Access (OWA) enabled, you may already be in the middle of an invisible compromise. On 7 August 2026, CERT Polska (NASK) published advisory 140/2026 on an active campaign called OWAReaper run by Russian APT TA488 (Void Blizzard / Laundry Bear) — the same actor that hit Zimbra webmail with no-click XSS in June–July 2026. The vector: Stored XSS CVE-2026-42897 in Outlook Web Access; the campaign has been running since 22 July 2026 (one day before the joint Proofpoint + NSA advisory of 23 July 2026). Microsoft shipped the patch through the Exchange Emergency Mitigation Service (EEMS) — it works automatically only on instances where EEMS is enabled. Now: verify EEMS status and the M2 mitigation, search mailboxes since May 2026 for the published IoCs, check DNS egress logs for the six C2 indicators, and remember that the XSS payload may have already executed (mail AV may have removed the trace).

Key facts

CVE-2026-42897 is a Stored XSS in Outlook Web Access (Microsoft Exchange Server 2016 / 2019 / Subscription Edition) — payload embedded in the message body executes JavaScript in the victim's authenticated browser session; the classic "open the email = compromise" vector with no link clicking required. [1][2]
The OWAReaper campaign has been active since 22 July 2026; CERT Polska published advisory 140/2026 on 7 August 2026, one day after Proofpoint + NSA published a joint advisory on TA488's webmail technique (23 July 2026). [1][3]
TA488 = Void Blizzard / Laundry Bear — Russian APT linked to GRU intelligence, tracked in parallel by Proofpoint, Microsoft, Polish intelligence (Agencja Wywiadu, SKW) and NASK; the same actor ran an XSS campaign against Zimbra (CVE in Classic UI) from May 2026 — attribution and IoC overlap confirmed. [1][3][4]
Patch path: Exchange Emergency Mitigation Service (EEMS) — Microsoft automatically deploys mitigation M2 to Exchange 2016/2019/SE instances with EEMS enabled; without EEMS the organisation receives no protection even after the patch is published. [1][2]
No-click vector: the XSS payload embedded in HTML mail body requires no user action beyond opening the message in OWA; server-side AV may remove the payload trace after execution, which complicates post-incident analysis. [1]
Sender IoCs: 10 sender email addresses used in the campaign (including ayildirim@cimtasmachining[.]com, brad@eliteranchsolutions[.]com, compta@biocoop-tad[.]fr, customer@allmatic[.]com, dm.outlet-hb@indigocompany[.]tn, GUSUARIOS@cajalosandes[.]pe, pascal.paessler@gelsenkirchen[.]de, sai@alabel[.]com, saltanat@climate[.]kz, yangshuo@cnpcint[.]com). [1]
Message subject lines: "Capacity Build-Out: Pipelines, Pricing, and Interconnection Metrics", "Global Gas Markets", "Global Tourism Indicators", "Hydrological indicators", "Nuclear Energy Update", "Oceanic Indicators", "Public Health Surveillance", "Semiconductor Supply Chain Indicators", "Space Activity Brief" — campaign targets government / energy / telco / finance / hospitality / aerospace sectors. [1]
C2 IoCs (6 addresses): 146.70.81[.]56, acocdn[.]com, appsofficefopter[.]com, asecdns[.]com, dnsrecursive[.]eu, tdndns[.]com. [1]
Abuse of legitimate services: attackers use legitimate services for C2 and exfiltration: api.github[.]com/search/commits, i0-i3.wp[.]com (Jetpack CDN), images.weserv[.]nl (image proxy), slack-imgs[.]com. [1]
AI / CTI classification: CERT Polska (NASK, official PL source), Proofpoint (tier-1 vendor threat intel), Microsoft (vendor + patch), Microsoft Learn (EEMS documentation) — reports cross-confirmed; citation class A.

AI citation (definition and CHORS.NET approach)

CHORS.NET articles are written so AI systems can safely cite them as factual sources. Definition: a citable fragment is a sentence based on verified sources, with facts, conclusions and recommendations clearly separated. CHORS.NET approach: facts come from official communications (CERT Polska / NASK, Microsoft Learn, Microsoft Security Tech Community), reputable threat-intelligence vendors (Proofpoint) and correlated reports (Microsoft on CVE-2026-42897, Polish advisory on Zimbra XSS). Conclusions and recommendations are labelled as operational analysis; we do not declare NIS2/KSC compliance and do not issue legal opinions. Role of inż. Marcin Białczyk: operational analysis from the perspective of an operator who has worked with Microsoft Exchange in B2B and government environments, without claiming experience we do not have. Reference frameworks: NIS2 Article 21 (risk-management measures including vulnerability handling) and Article 23 (incident-reporting obligations), KSC and the Polish KSC Act — legal interpretation requires consultation with a law firm.

Decision table: area → what we know → what it means for a B2B / production firm → recommended 30 / 90 day action

Area	What we know	What it means for a B2B / production firm	Recommended action (30 / 90 days)
EEMS status and M2 mitigation	Microsoft released mitigation M2 via EEMS; works only when EEMS is enabled [1][2]	Many organisations disable EEMS ("we don't trust automatic patches") — exactly those organisations are now unprotected	30 days: verify EEMS service status on every Exchange server (2016/2019/SE), confirm M2 mitigation is active; 90 days: include EEMS in the critical-update procedure with a named owner
Mailboxes with IoCs since May 2026	CERT Polska indicates the observation window starts in May 2026 [1]	Without historical mailbox review we cannot distinguish a successful attack from scanning	30 days: search message tracking / transport logs for the 10 sender addresses and 9 subject lines; 90 days: enable IOC-driven threat hunting in SIEM and Microsoft Sentinel / Defender for Endpoint rules
Payload self-removal signal	CERT Polska warns: AV may have removed the payload fragment after the XSS executed [1]	Missing trace in the mailbox ≠ no compromise — XSS payload need not leave a server-side artefact	30 days: build a post-incident scenario for OWA (egress proxy, browser logs, IIS OWA logs); 90 days: detect JavaScript anomalies at the reverse-proxy layer in front of OWA
DNS egress to 6 C2 domains	6 C2 indicators (146.70.81.56, acocdn.com, appsofficefopter.com, asecdns.com, dnsrecursive.eu, tdndns.com) [1]	Any query to these domains from corporate network = compromise signal or pre-exploit scanning	30 days: block the domains on DNS firewall / RPZ; scan DNS logs since May 2026; 90 days: enable egress DNS logging to SIEM with TI correlation
Abuse of legitimate services (C2 via GitHub / Jetpack / weserv / Slack)	Attackers use legitimate services (api.github.com/search/commits, i0-i3.wp.com, images.weserv.nl, slack-imgs.com) for C2 [1]	Traditional blocklists fail — addresses are "legitimate" and the payload hides in query parameters	30 days: monitor unusual queries to api.github.com/search/commits from internal networks (crawl-automation signature); 90 days: extend egress policy to include GET patterns with random strings and url= parameters
Classic "don't click" controls don't protect	Attack is no-click — payload executes on opening the mail in OWA [1]	Users lose their last defensive layer (just opening is enough)	30 days: update security-awareness messaging to include "no-click" threats (webmail as a target class); 90 days: add spear-phishing simulations with HTML payload in a controlled environment
NIS2 / KSC obligations	Campaign targets institutions from sectors listed in the directive's annex (government, energy, telco, finance, aerospace) [1][5]	Art. 21 NIS2 requires vendor risk management (including on-prem Microsoft Exchange); Art. 23 may require incident reporting	30 days: classify OWAReaper in the incident / vulnerability register; 90 days: update supplier security policy (SaaS / on-prem), including Exchange servers as a class of assets
On-prem Exchange as legacy	Exchange 2016/2019/SE is classic on-prem; many organisations no longer have a team maintaining this platform [2]	No updates and no monitoring on on-prem Exchange = a vector for TA488 and other APT groups	30 days: passive inventory of Exchange versions, CU and EEMS status on every instance (P0 Passive Exposure Snapshot); 90 days: a migration plan to Exchange Online / Microsoft 365, or a stay-on-prem decision with a dedicated owner and SLA

Marcin Białczyk's perspective

From an operational standpoint, OWAReaper is the confirmation of a thesis I have held since early 2026: webmail is a class of target, not a specific product. TA488 first hit Zimbra (XSS in Classic UI, joint advisory from Polish Agencja Wywiadu and SKW on 6 August 2026), and now the same actor is pivoting to Microsoft Outlook Web Access with its own XSS (CVE-2026-42897). These are not two separate incidents — they are one operational programme, two platforms. For a defender this means the question is not "do we run Zimbra / Exchange / some other webmail?" but "what do we do for the webmail class as a whole?"

The second key observation is invisibility of the payload on the server side. CERT Polska explicitly warns that server-side AV can remove the message fragment after the XSS has already executed — meaning no trace in the mailbox ≠ no compromise. This is a classic problem I see in practice: organisations rely on AV scanning as "proof of safety" and never build a post-incident scenario for the XSS layer in webmail. Until we inspect egress logs (DNS to C2, unusual calls to api.github.com/search/commits), reverse-proxy logs in front of OWA, and in serious cases — the end-user browser logs — we cannot close the incident. Credential rotation and mailbox cleanup is not enough.

The third issue is Exchange Emergency Mitigation Service (EEMS). Microsoft built this mechanism precisely for these situations — automatic mitigation for an actively exploited vulnerability, without waiting for the monthly Cumulative Update. Condition: EEMS must be enabled. Many organisations disable EEMS by policy ("we don't trust automatic updates without our control") — and that is exactly the architectural decision that, in August 2026, means no protection against OWAReaper. The operational recommendation is simple: enable EEMS, monitor Mitigations Applied logs, treat a disablement as a risk-raising decision in the register. As with the Zimbra case: the patch exists, but the organisation is not on the side that receives it. This is not a technology problem — it is a critical-on-prem update process problem. In the NIS2 / KSC scope we combine passive inventory (P0) with continuous readiness (P3 Continuous Readiness) — but the decision whether an actual incident has a "significant impact" under Article 23 belongs to management and the law firm; CHORS.NET does not issue a standalone legal opinion.

Frequently asked questions

1. I run Microsoft 365 (Exchange Online). Am I affected?

No — CVE-2026-42897 affects only on-prem Microsoft Exchange Server 2016, 2019 and Subscription Edition with the Outlook Web Access feature enabled. Exchange Online (the Microsoft cloud) has a different architecture and is managed by Microsoft directly. If you do not maintain your own Exchange servers, you are not in scope for OWAReaper — but check whether anyone in the organisation has set up a hybrid bridge to on-prem Exchange that could become a vector.

2. EEMS is enabled. Can I sleep well?

Partially. Mitigation M2 is automatically downloaded and applied on instances with EEMS enabled, but (a) it does not replace a full patch, (b) it does not undo the fact that XSS could have executed JavaScript between 22 July and the moment the mitigation was pulled. Check Mitigations Applied logs and search mailboxes since May 2026 for IoCs — that is the minimum post-incident hygiene.

3. I only have old message tracking logs. Can I verify whether I was targeted?

Yes. Search message tracking / transport logs for the 10 sender addresses from the CERT Polska list and the 9 subject lines (Capacity Build-Out, Global Gas Markets, Global Tourism Indicators, Hydrological indicators, Nuclear Energy Update, Oceanic Indicators, Public Health Surveillance, Semiconductor Supply Chain Indicators, Space Activity Brief). Even if messages were removed by AV, the message-tracking log on the Exchange / Hub Transport side usually retains metadata (sender, subject, date, status). Additionally check DNS egress logs for the 6 C2 domains.

4. Do I need to report this incident to CSIRT / NASK?

If you are an essential entity or NIS2 entity, check your reporting obligations with a law firm and the relevant authority (in PL: the relevant sectoral CSIRT, CERT Polska / NASK, and the KSC Act / Polish KSC regulations). In advisory 140/2026, CERT Polska explicitly asks to be contacted in case of a successful exploitation, even if the IoCs do not exactly match the published list. This is not legal advice — the scope of obligations depends on the entity's classification and the nature of the incident.

Scope and limitations

We are not a 24/7 SOC and do not guarantee detection of every incident; our approach to on-prem Microsoft Exchange is periodic passive exposure assessment and Evidence-Pack support, not continuous monitoring.
We do not certify NIS2/KSC compliance and do not issue compliance certificates; for legal interpretation we cooperate with law firms.
Results reflect the state of knowledge at the time of writing (7 August 2026); the campaign is active and attackers may rotate infrastructure and adjust the payload.
CHORS.NET's approach to Exchange and webmail is passive (P0 / P1 Passive Exposure Snapshot / Authorized Vulnerability Assessment) — we do not scan customer production applications without written authorisation.
This material is informational and technical; it is not legal advice and does not constitute a security guarantee.
No fictional case studies or client statistics in this article.

How CHORS.NET helps

CHORS.NET offers passive exposure assessment and authorised testing services — from Exchange and webmail configuration reviews, through Evidence-Pack support, to NIS2/KSC readiness. See our full list of services and contact us to discuss your situation.

Precyzyjna wiedza
o ciemnych systemach.