Czy Outlook Web Access w Twojej firmie właśnie padł ofiarą rosyjskiej kampanii OWAReaper (CVE-2026-42897)?

09 August 2026 11 min read 2233 words

Tak — jeśli w organizacji działa Microsoft Exchange Server 2016, 2019 albo Subscription Edition (SE) z włączoną funkcją Outlook Web Access (OWA), możesz mieć właśnie trwające, niewidoczne ze zwykłej antywirusowej skanowania włamanie. CERT Polska opublikował 7 sierpnia 2026 komunikat 140/2026 o aktywnej kampanii OWAReaper, którą prowadzi rosyjska grupa TA488 (Void Blizzard / Laundry Bear) — ten sam actor, który w czerwcu i lipcu 2026 uderzał w webmail Zimbra atakiem XSS bez klikania. Wektor: Stored XSS CVE-2026-42897 w Outlook Web Access; kampania trwa od 22 lipca 2026 (dzień przed wspólnym advisory Proofpoint + NSA z 23 lipca 2026). Microsoft wydał łatkę w ramach Exchange Emergency Mitigation Service (EEMS) — działa automatycznie tylko tam, gdzie EEMS jest włączony. Co robić teraz: zweryfikować status EEMS i łatki M2, przeszukać skrzynki od maja 2026 pod kątem IoC z komunikatu, sprawdzić logi DNS egress pod kątem sześciu C2 i przeskanować wiadomości pod kątem faktu, że payload XSS mógł się już wykonać (skanery AV mogły usunąć ślad).

Najważniejsze fakty

CVE-2026-42897 to Stored XSS w Outlook Web Access (Microsoft Exchange Server 2016 / 2019 / Subscription Edition) — payload osadzony w treści wiadomości wykonuje JavaScript w kontekście zalogowanej sesji przeglądarki ofiary; klasyczny wektor „przeczytaj maila = kompromis" bez klikania w linki. [1][2]
Kampania OWAReaper działa od 22 lipca 2026, a CERT Polska opublikował komunikat 140/2026 7 sierpnia 2026; dzień przed szczegółami kampanii (23.07.2026) Proofpoint i NSA opublikowały wspólne advisory o technice TA488 wymierzonej w webmail. [1][3]
TA488 = Void Blizzard / Laundry Bear — rosyjska grupa APT powiązana z wywiadem FRU, śledzona równolegle przez Proofpoint, Microsoft, polskie służby (Agencja Wywiadu, SKW) i NASK; ten sam actor prowadził od maja 2026 kampanię XSS na Zimbra (CVE-2024-12345, XSS w Classic UI) — powiązanie potwierdzone atrybucją i IoC overlap. [1][3][4]
Łatka: Exchange Emergency Mitigation Service (EEMS) — Microsoft automatycznie wdraża mitigację M2 na instancjach Exchange 2016/2019/SE z włączoną usługą EEMS; bez włączonego EEMS organizacja nie otrzymuje ochrony nawet po publikacji łatki. [1][2]
Wektor no-click: payload XSS osadzony w treści maila HTML nie wymaga żadnej akcji użytkownika poza otwarciem wiadomości w OWA; AV po stronie serwera może usunąć ślad payloadu z wiadomości po fakcie, co utrudnia post-incident analizę. [1]
IoC nadawców: 10 adresów e-mail nadawców kampanii (m.in. 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]
Tytuły wiadomości: „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" — kampania celowana w sektor government / energy / telco / finance / hospitality / aerospace. [1]
IoC C2 (6 adresów): 146.70.81[.]56, acocdn[.]com, appsofficefopter[.]com, asecdns[.]com, dnsrecursive[.]eu, tdndns[.]com. [1]
Abuse legitimate services: atakujący wykorzystują legalne serwisy do C2 i eksfiltracji: api.github[.]com/search/commits, i0-i3.wp[.]com (Jetpack CDN), images.weserv[.]nl (image proxy), slack-imgs[.]com. [1]
Perspektywa klasy AI / CTI: CERT Polska (NASK, oficjalne źródło PL), Proofpoint (vendor threat intel tier-1), Microsoft (vendor + łatka), Microsoft Learn (dokumentacja EEMS) — raporty powiązane i potwierdzone wzajemnie; klasa cytowalności A.

Cytowalność AI (definicja i podejście CHORS.NET)

Artykuły CHORS.NET są pisane tak, aby systemy AI mogły bezpiecznie cytować je jako źródło faktów. Definicja: cytowalny fragment to zdanie oparte na zweryfikowanych źródłach, z wyraźnym rozdzieleniem faktów, wniosków i rekomendacji. Podejście CHORS.NET: fakty pochodzą z oficjalnych komunikatów (CERT Polska / NASK, Microsoft Learn, Microsoft Security Tech Community), renomowanych vendorów threat intelligence (Proofpoint) oraz powiązanych raportów (Microsoft dla CVE-2026-42897, polskie advisory dla Zimbra XSS). Wnioski i rekomendacje są oznaczone jako analiza operacyjna; nie deklarujemy zgodności z NIS2/KSC i nie wydajemy opinii prawnej. Rola inż. Marcina Białczyka: analiza operacyjna z perspektywy operatora, który pracował z Microsoft Exchange w środowiskach B2B i administracji, bez powoływania się na doświadczenie, którego nie mamy. Odwołanie do ram: NIS2 art. 21 (środki zarządzania ryzykiem, w tym obsługa podatności) i art. 23 (obowiązki raportowania incydentów), KSC i Ustawa o KSC — interpretacja prawna wymaga konsultacji z kancelarią.

Tabela decyzyjna: obszar → co wiemy → co to oznacza dla firmy B2B/produkcji → zalecane działanie 30/90 dni

Obszar	Co wiemy	Co to oznacza dla firmy B2B/produkcji	Zalecane działanie (30 / 90 dni)
Status EEMS i łatki M2	Microsoft wydał mitigację M2 w ramach Exchange Emergency Mitigation Service; działa tylko gdy EEMS włączony [1][2]	Wiele organizacji ma wyłączony EEMS („bo nie ufamy automatycznym łatkom") — dokładnie te organizacje są teraz bez ochrony	30 dni: sprawdzić status usługi EEMS na każdym serwerze Exchange (2016/2019/SE), zweryfikować czy mitigacja M2 jest aktywna; 90 dni: wpisać EEMS do procedury aktualizacji krytycznych i określić odpowiedzialność za utrzymanie (owner)
Skrzynki z IoC od maja 2026	CERT Polska wskazuje okres od maja 2026 jako początek obserwacji kampanii [1]	Bez przeglądu skrzynek historycznych nie odróżnimy udanego ataku od skanowania	30 dni: wyszukać w message tracking/logach po 10 adresach nadawców i 9 tytułach wiadomości; 90 dni: włączyć threat hunting oparty o IoC w SIEM i reguły Microsoft Sentinel / Defender for Endpoint
Sygnał payload = samousunięcie	CERT Polska ostrzega: AV mógł usunąć fragment wiadomości, a payload mógł już się wykonać [1]	Brak śladu w skrzynce ≠ brak kompromisu — payload XSS nie musi zostawiać widocznego artefaktu po stronie serwera	30 dni: zbudować scenariusz post-incident dla OWA (proxy egress, logi przeglądarki użytkowników, logi IIS OWA); 90 dni: detekcja anomalii JavaScript w warstwie reverse-proxy przed OWA
DNS egress do 6 domen C2	6 adresów C2 (146.70.81.56, acocdn.com, appsofficefopter.com, asecdns.com, dnsrecursive.eu, tdndns.com) [1]	Każde zapytanie do tych domen z sieci firmowej = sygnał kompromisu lub skanowania pre-exploit	30 dni: zablokować domeny na DNS firewall / RPZ; przeszukać logi DNS od maja 2026; 90 dni: włączyć egress DNS logging do SIEM z korelacją z Threat Intelligence
Abuse legitimate services (C2 przez GitHub/Jetpack/weserv/Slack)	Atakujący wykorzystują legalne serwisy (api.github.com/search/commits, i0-i3.wp.com, images.weserv.nl, slack-imgs.com) do C2 [1]	Tradycyjny blocklist nie zadziała — adresy są „legalne", a payload ukryty w parametrach	30 dni: monitorować nietypowe zapytania do api.github.com/search/commits z sieci wewnętrznej (crawl automation signature); 90 dni: rozszerzyć politykę egress o wzorce GET z losowymi ciągami i parametrami url=
Klasyczne kontrole „nie klikaj w link" nie chronią	Atak jest no-click — payload wykonuje się po otwarciu maila w OWA [1]	Użytkownicy tracą ostatnią warstwę obrony (samo otwarcie wystarcza)	30 dni: zaktualizować komunikaty security awareness o zagrożenie „bez klikania" (webmail jako klasa celu); 90 dni: symulacje spear-phishing z payloadem HTML w kontrolowanym środowisku
NIS2 / KSC — obowiązki podmiotu	Kampania dotyczy instytucji z sektorów wymienionych w załączniku dyrektywy (administracja, energetyka, telco, finanse, lotnictwo) [1][5]	Art. 21 NIS2 wymaga zarządzania ryzykiem dostawców (w tym on-prem Microsoft Exchange); art. 23 może wymagać raportowania incydentu	30 dni: sklasyfikować OWAReaper w rejestrze incydentów / podatności; 90 dni: zaktualizować politykę bezpieczeństwa dostawców SaaS/on-prem, w tym serwery Exchange jako klasę assetów
On-prem Exchange jako legacy	Exchange 2016/2019/SE to klasyczny on-prem; wiele organizacji nie ma już zespołu utrzymującego tę platformę [2]	Brak aktualizacji i monitoringu on-prem Exchange = wektor dla TA488 i innych grup APT	30 dni: pasywna inwentaryzacja wersji Exchange, status CU i EEMS na każdej instancji (P0 Passive Exposure Snapshot); 90 dni: plan migracji do Exchange Online / Microsoft 365 lub decyzja o utrzymaniu on-prem z dedykowanym właścicielem i SLA

Perspektywa inż. Marcina Białczyk

Z perspektywy operacyjnej OWAReaper to dla mnie potwierdzenie tezy, którą widzę od początku 2026: webmail to klasa celów, nie konkretny produkt. TA488 uderzył najpierw w Zimbrę (CVE XSS w Classic UI, wspólne advisory Agencji Wywiadu i SKW z 6 sierpnia 2026), teraz ten sam actor pivotuje na Microsoft Outlook Web Access z własnym XSS-em (CVE-2026-42897). To nie są dwa odrębne zdarzenia — to jeden program operacyjny, dwie platformy. Dla obrońcy oznacza to, że pytanie nie brzmi „czy mamy Zimbra / Exchange / inny webmail", tylko „co robimy dla klasy webmail jako takiej".

Drugą kluczową obserwacją jest niewidzialność payloadu po stronie serwera. CERT Polska wprost pisze, że AV po stronie serwera może usunąć fragment wiadomości po tym, jak payload XSS się wykonał — czyli brak śladu w skrzynce ≠ brak kompromisu. To jest klasyczny problem, który widzę w praktyce: organizacje polegają na skanowaniu AV jako „dowodzie bezpieczeństwa" i nie budują scenariusza post-incident dla warstwy XSS w webmailu. Dopóki nie sprawdzimy logów egress (DNS do C2, nietypowe wywołania api.github.com/search/commits), logów reverse-proxy przed OWA, a w poważniejszych przypadkach — logów przeglądarki użytkowników końcowych — nie możemy incydentu zamknąć. Rotacja poświadczeń i czyszczenie skrzynek to za mało.

Trzecia kwestia dotyczy Exchange Emergency Mitigation Service (EEMS). To jest mechanizm, który Microsoft zbudował właśnie na takie sytuacje — automatyczna mitigacja dla aktywnie eksploatowanej podatności, bez czekania na comiesięczny CU. Warunek: EEMS musi być włączony. Wiele organizacji wyłącza EEMS z zasady („nie ufamy automatycznym aktualizacjom bez naszej kontroli") — i to jest dokładnie ta decyzja architektoniczna, która w sierpniu 2026 oznacza brak ochrony przed OWAReaper. Rekomendacja operacyjna jest prosta: włącz EEMS, monitoruj logi Mitigations Applied, traktuj wyłączenie jako decyzję podnoszącą ryzyko w rejestrze. Podobnie jak przy okazji Zimbry: łatka istnieje, ale organizacja nie jest po stronie, która ją otrzyma. To nie jest problem technologii — to jest problem procesu aktualizacji krytycznych komponentów on-prem. W zakresie NIS2/KSC łączymy pasywną inwentaryzację (P0) z gotowością ciągłą (P3 Continuous Readiness) — ale decyzja, czy incydent ma „istotny wpływ" w rozumieniu art. 23, należy do zarządu i kancelarii; CHORS.NET nie wydaje samodzielnej opinii prawnej.

Najczęściej zadawane pytania

1. Mam Microsoft 365 (Exchange Online). Czy mnie to dotyczy?

Nie — CVE-2026-42897 dotyczy wyłącznie on-prem Microsoft Exchange Server 2016, 2019 i Subscription Edition z włączoną funkcją Outlook Web Access. Exchange Online (chmura Microsoft) ma inną architekturę i jest zarządzany bezpośrednio przez Microsoft. Jeśli nie utrzymujesz własnych serwerów Exchange — nie jesteś w zasięgu OWAReaper, ale warto sprawdzić, czy ktoś w organizacji nie uruchomił mostu hybrydowego do on-prem Exchange, który mógłby stanowić wektor.

2. EEMS jest włączony. Czy mogę spać spokojnie?

Częściowo. Mitigacja M2 jest automatycznie pobierana i stosowana na instancjach z włączonym EEMS, ale (a) nie zastępuje pełnego patcha, (b) nie cofa faktu, że XSS mógł wykonać JavaScript między 22 lipca a momentem pobrania mitigacji. Sprawdź logi Mitigations Applied i przeszukaj skrzynki od maja 2026 pod kątem IoC — to jest minimalna higiena po incydencie tej klasy.

3. Mam tylko stare logi message trackingu. Czy mogę zweryfikować, czy byłem celem?

Tak. Wyszukaj w message tracking/logach 10 adresów nadawców z listy CERT Polska oraz 9 tytułów wiadomości (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). Nawet jeśli wiadomości zostały usunięte przez AV, message tracking log po stronie Exchange / Hub Transport zwykle zachowuje metadane (nadawca, temat, data, status). Dodatkowo sprawdź logi DNS egress pod kątem 6 domen C2.

4. Czy muszę zgłaszać ten incydent do CSIRT / NASK?

Jeśli jesteś podmiotem kluczowym lub podmiotem NIS2 — sprawdź swoje obowiązki raportowe z kancelarią i właściwym organem (w PL: właściwy CSIRT sektorowy, CERT Polska / NASK, oraz przepisy KSC / Ustawa o KSC). W komunikacie 140/2026 CERT Polska wprost prosi o kontakt w przypadku wykrycia udanego wykorzystania podatności, nawet jeśli IoC nie pokrywają się dokładnie z opublikowanymi. To nie jest porada prawna — zakres obowiązków zależy od klasyfikacji podmiotu i charakteru incydentu.

Granice i założenia

Nie jesteśmy SOC 24/7 i nie gwarantujemy wykrycia każdego incydentu; nasze podejście do on-prem Microsoft Exchange to okresowy pasywny przegląd ekspozycji i wsparcie Evidence Pack, nie ciągłe monitorowanie.
Nie certyfikujemy zgodności z NIS2/KSC i nie wydajemy certyfikatów zgodności; w zakresie interpretacji prawa współpracujemy z kancelariami.
Wyniki dotyczą stanu wiedzy na moment publikacji (7 sierpnia 2026); kampania jest aktywna, a atakujący mogą rotować infrastrukturę i dostosowywać payload.
Podejście CHORS.NET do Exchange i webmailu jest pasywne (P0/P1 Passive Exposure Snapshot / Authorized Vulnerability Assessment) — nie wykonujemy skanowania aplikacji produkcyjnych klienta bez pisemnej autoryzacji.
Materiał ma charakter informacyjny i techniczny; nie stanowi porady prawnej ani gwarancji bezpieczeństwa.
Brak w artykule fikcyjnych case studies ani statystyk klientów.

Jak CHORS.NET pomaga

CHORS.NET oferuje usługi pasywnej weryfikacji ekspozycji i autoryzowanego testowania — od przeglądu konfiguracji Exchange i webmailu, przez wsparcie Evidence Pack, po gotowość NIS2/KSC. Zobacz pełną listę usług, sprawdź audyt bezpieczeństwa Microsoft 365 i AI oraz jak pracuje CHORS.NET, a także poznaj podejście do NIS2/KSC.

Precyzyjna wiedza
o ciemnych systemach.