OWAReaper: phishing, który uruchamia się po otwarciu wiadomości w OWA

TL;DR

OWAReaper pokazuje niewygodną granicę zasady „nie klikaj w podejrzane linki”. W kampanii opisanej przez Proofpoint wiadomości nie musiały zawierać linku, załącznika ani wyraźnej prośby o działanie. Jeżeli odbiorca otworzył spreparowaną wiadomość w podatnym Outlook Web Access, czyli przeglądarkowym interfejsie lokalnego Microsoft Exchange, kod JavaScript mógł uruchomić się w kontekście jego zalogowanej sesji.

Atak wykorzystywał CVE-2026-42897, podatność typu cross-site scripting, w skrócie XSS, związaną z niewłaściwym oczyszczaniem treści HTML renderowanej przez OWA. Nie należy przedstawiać jej jako klasycznego zdalnego wykonania kodu na serwerze Exchange. Problem polegał na tym, że przygotowana treść wiadomości mogła wykonać kod w przeglądarce użytkownika, która była już uwierzytelniona w firmowej poczcie.

Najważniejszy wniosek dotyczy reakcji. Proofpoint opisał mechanizmy utrzymania dostępu w danych przeglądarki, cache wiadomości, tokenach dodatków i uprawnieniach folderów skrzynki. Sama zmiana hasła, wyczyszczenie komputera albo jego ponowna instalacja nie muszą więc usunąć napastnika. Firma musi sprawdzić jednocześnie endpoint, przeglądarkę, konto, skrzynkę i serwer Exchange.

Wiadomość bez linku i załącznika też może być niebezpieczna

Większość porad dotyczących rozpoznawania phishingu skupia się na widocznej decyzji użytkownika: kliknięciu linku, otwarciu załącznika, podaniu hasła albo zatwierdzeniu MFA. To nadal przydatne reguły, ale OWAReaper wykorzystał inną granicę. Decyzją uruchamiającą atak mogło być samo otwarcie wiadomości w webmailu.

Według Proofpoint obserwowane wiadomości były celowo zwyczajne. Dotyczyły między innymi łańcuchów dostaw, turystyki, rynku gazu, zdrowia publicznego czy wskaźników hydrologicznych. Nie zawierały typowego wezwania do działania. Miały wyglądać jak materiał, który odbiorca szybko otworzy, przejrzy i uzna za mało istotny — bez zgłoszenia go zespołowi bezpieczeństwa.

Proofpoint określa ten model jako „half-click”, czyli atak wymagający mniej interakcji niż klasyczne kliknięcie w link. Nazwa nie jest nową odmianą phishingu dla użytkowników, lecz opisem technicznego progu uruchomienia łańcucha. Wiadomość nadal musi zostać dostarczona do właściwego środowiska, odbiorca musi korzystać z podatnego OWA, a treść musi być specjalnie przygotowana.

Jak działał atak half-click w OWA

W opisanym łańcuchu serwer Exchange nie oczyszczał prawidłowo określonej treści HTML wiadomości. Po wyświetleniu jej w Outlook Web Access kod uruchamiał się wewnątrz zalogowanej sesji przeglądarki. Payload był ukryty w elementach wyglądających jak zwyczajne części wiadomości, między innymi w danych związanych z obrazami ikon społecznościowych.

Atak przebiegał w pięciu logicznych etapach:

1. Napastnik wysyłał niepozorną, specjalnie przygotowaną wiadomość z przejętego konta.
2. Wiadomość trafiała do skrzynki obsługiwanej przez podatny lokalny Exchange Server.
3. Odbiorca otwierał ją albo wyświetlał w panelu odczytu Outlook Web Access.
4. Błąd sanitizacji pozwalał uruchomić JavaScript w kontekście uwierzytelnionej sesji OWA.
5. Implant OWAReaper ustanawiał mechanizmy utrzymania dostępu, zbierał informacje i przygotowywał kanały sterowania oraz wyprowadzania danych.

Momentem krytycznym jest renderowanie spreparowanej wiadomości w podatnym OWA. Dowody trzeba zabezpieczyć przed usuwaniem artefaktów i mechanizmów utrzymania dostępu.

Ten scenariusz różni się od kampanii, w których dokument dopiero prowadzi użytkownika do kolejnego etapu. Przykładowo FrostyNeighbor wykorzystywał PDF, link, walidację celu i dalsze pobranie. W OWAReaper moment wykonania znajdował się już wewnątrz interfejsu poczty. Dlatego brak adresu URL i załącznika nie był dowodem bezpieczeństwa.

Co robił OWAReaper

OWAReaper był implantem JavaScript działającym wewnątrz OWA, a nie typowym plikiem wykonywalnym pozostawionym na dysku. Po uruchomieniu przepisywał oryginalną wiadomość na serwerze, aby usunąć z niej treść odpowiedzialną za wykorzystanie podatności. Zbierał też adres e-mail, nazwę użytkownika i ustawienia Outlooka. Proofpoint opisał próbę pozyskania danych logowania z mechanizmu automatycznego uzupełniania przeglądarki za pomocą niewidocznych pól formularza.

Implant zapisywał zaszyfrowaną kopię siebie oraz kod odtwarzający w localStorage, czyli lokalnym magazynie danych przeglądarki używanym przez stronę OWA. Wykorzystywał legalny proces odtwarzania ustawień, dzięki czemu mógł uruchamiać się ponownie przy otwarciu kolejnej karty OWA.

Kolejna warstwa dotyczyła dodatków Outlooka i skrzynki. Jeśli dostępny dodatek miał uprawnienie ReadWriteMailbox, OWAReaper próbował uzyskać token dostępu. Następnie mógł nadać aliasowi „Default” poziom właściciela dla folderów pocztowych. W praktyce otwierało to dostęp do skrzynki innemu uwierzytelnionemu kontu w tej samej organizacji. Taka zmiana znajdowała się po stronie Exchange i nie znikała po zmianie hasła użytkownika.

Proofpoint opisał również modyfikację wiadomości przechowywanych w lokalnym cache IndexedDB OWA. Zatruta kopia mogła ponownie uruchomić infekcję po otwarciu wiadomości, nawet po odtworzeniu urządzenia. Komendy mogły docierać przez publiczne komunikaty commitów GitHub albo przez kolejne wiadomości, a dane mogły być wysyłane przez HTTPS lub zapytania DNS. Te szczegóły są ważne dla SOC, ale nie zmieniają podstawowego priorytetu: najpierw trzeba usunąć podatność i ustalić, czy doszło do wykonania kodu.

Dlaczego zmiana hasła i reinstalacja komputera nie wystarczą

W zwykłym credential phishingu szybka zmiana hasła, unieważnienie sesji i sprawdzenie aktywności konta są naturalnym początkiem reakcji. W tym przypadku pozostają potrzebne, ale nie zamykają incydentu.

| Warstwa | Co mogło pozostać | Dlaczego standardowa reakcja jest niewystarczająca | | --- | --- | --- | | Przeglądarka | Dane OWAReaper w localStorage | Zmiana hasła nie usuwa magazynu strony w profilu przeglądarki | | Cache OWA | Zmodyfikowana wiadomość w IndexedDB | Ponowne otwarcie zatrutej kopii może odtworzyć implant | | Tokeny | Tokeny uzyskane przez dodatki Outlooka | Hasło nie unieważnia automatycznie każdego tokenu i uprawnienia | | Skrzynka | Nietypowe uprawnienia folderów dla „Default” | Zmiana znajduje się po stronie Exchange, a nie na komputerze użytkownika | | Serwer | Podatny OWA i złośliwe wiadomości | Odtworzenie endpointa nie usuwa wiadomości ani nie aktualizuje Exchange |

To praktyczny przykład, dlaczego ryzyka po phishingu nie można mierzyć samym kliknięciem. W tym scenariuszu trzeba ustalić nie tylko, kto otworzył wiadomość, ale również w jakiej wersji OWA, o której godzinie, na jakim profilu przeglądarki i z jakimi skutkami dla skrzynki oraz serwera.

Kogo dotyczy CVE-2026-42897

CERT Polska wskazał Exchange Server 2016, Exchange Server 2019 i Exchange Server Subscription Edition. Microsoft zaznacza, że Exchange Online nie jest dotknięty tą podatnością. Organizacja korzystająca wyłącznie z chmurowej usługi nie powinna więc automatycznie traktować tego komunikatu jako potwierdzenia własnej ekspozycji.

Większej uwagi wymagają środowiska lokalne i hybrydowe. Firma może uważać, że „poczta jest już w Microsoft 365”, a nadal utrzymywać lokalny Exchange do zarządzania odbiorcami, integracji, obsługi części skrzynek albo starszych procesów. Pierwszym krokiem powinien być rzeczywisty spis serwerów, wersji, poprawek, dostępności OWA z internetu i stanu Exchange Emergency Mitigation Service.

CVE-2026-42897 zostało publicznie opisane przez Microsoft 14 maja 2026 roku, a dzień później CISA dodała je do katalogu Known Exploited Vulnerabilities. Proofpoint podał, że obserwowana przez firmę fala TA488 rozpoczęła się 22 lipca. Infrastruktura powiązana z kampanią była jednak tworzona wcześniej, dlatego badacze uznali użycie podatności jako zero-day za możliwe. To ocena oparta na osi czasu, a nie samodzielny dowód, że każdy wcześniejszy incydent wykorzystywał tę samą lukę.

Co powinien zrobić pracownik

Użytkownik nie jest w stanie samodzielnie ocenić, czy serwer Exchange ma właściwą poprawkę. Nie powinien też analizować podejrzanej wiadomości przez wielokrotne otwieranie jej w OWA. Przy nietypowej, nieoczekiwanej wiadomości — również takiej bez linku i załącznika — bezpieczna procedura powinna być krótka:

1. Nie otwieraj wiadomości ponownie i nie przesyłaj jej dalej jako zwykłego forwardu.
2. Przerwij pracę w karcie OWA, jeśli komunikat bezpieczeństwa firmy nakazuje takie działanie.
3. Zapisz temat, nadawcę, przybliżony czas otwarcia oraz używaną przeglądarkę i urządzenie.
4. Zgłoś zdarzenie pilnym kanałem do IT lub security, bez kopiowania podejrzanej treści do kolejnych osób.
5. Wykonuj dalsze czynności dopiero według instrukcji zespołu reagowania.

Ważny jest język komunikatu. Nie można oczekiwać, że pracownik rozpozna ukryty XSS po wyglądzie wiadomości. Jego zadaniem jest zgłoszenie nietypowego kontaktu i dokładnego momentu interakcji. Obowiązkiem organizacji jest zapewnienie aktualnego środowiska oraz procesu, który szybko łączy zgłoszenie z logami poczty, przeglądarki, tożsamości i sieci.

Co administrator i SOC powinni sprawdzić

Reakcję należy podzielić na ograniczenie ekspozycji, ocenę kompromitacji i usunięcie mechanizmów utrzymania dostępu. Szczegółowe polecenia i wskaźniki powinny pochodzić z aktualnych komunikatów Microsoftu, CERT Polska i Proofpoint, ponieważ zalecenia producenta zmieniały się wraz z publikacją kolejnych aktualizacji.

1. Ustal ekspozycję i zastosuj aktualne zabezpieczenie

Zidentyfikuj wszystkie lokalne serwery Exchange, w tym elementy pozostawione w środowisku hybrydowym. Sprawdź wersję, poziom Security Update, dostępność OWA oraz status EEMS. Zainstaluj najnowszą poprawkę właściwą dla danej wersji i potwierdź stan narzędziem Exchange Server Health Checker. Jeżeli poprawka nie może zostać wdrożona natychmiast, zastosuj aktualną mitigację wskazaną przez Microsoft zamiast zakładać, że została aktywowana automatycznie.

2. Wyszukaj wiadomości i wskaźniki kampanii

Przeszukaj skrzynki oraz logi za okres wskazany w aktualnych komunikatach. Uwzględnij hash złośliwego body wiadomości, domeny i wzorce opisane przez CERT Polska oraz Proofpoint. Nie ograniczaj się do tematów opublikowanych w raporcie — były celowo banalne, a napastnik może je zmienić.

3. Usuń cache OWA

Na potencjalnie dotkniętych profilach usuń wskazany przez Proofpoint wpis PageDataPayload.OwaUserDefaultSettings z localStorage oraz bazę owa_offline_db w IndexedDB. Czynność powinna być wykonana kontrolowanie, z zachowaniem artefaktów potrzebnych do analizy. Samo wyczyszczenie historii przeglądarki bez potwierdzenia zakresu nie jest wystarczającym dowodem usunięcia zagrożenia.

4. Sprawdź tokeny i uprawnienia skrzynki

Przeprowadź audyt tokenów Exchange Web Services używanych przez dodatki z uprawnieniem ReadWriteMailbox. Unieważnij podejrzane tokeny i sprawdź, czy alias „Default” nie otrzymał nieoczekiwanie uprawnień Owner do folderów. Usuń nieautoryzowane wpisy na wszystkich dotkniętych skrzynkach, a nie tylko na skrzynce osoby, która pierwsza zgłosiła wiadomość.

5. Oceń komunikację i możliwe wyprowadzenie danych

Sprawdź ruch HTTPS oraz DNS względem aktualnych IoC. Proofpoint opisał oba kanały jako możliwe drogi komunikacji i eksfiltracji. Analiza powinna objąć serwer, urządzenie użytkownika, proxy, DNS, EDR, logi tożsamości i zdarzenia skrzynki. Jest to dobry przykład sytuacji, w której SOC musi przeanalizować phishing przepuszczony przez filtr jako pełny łańcuch, a nie pojedynczy plik lub adres URL.

6. Dopiero potem zamknij działania kontowe i odtworzeniowe

Unieważnienie sesji, rotacja poświadczeń i odtworzenie endpointa mają sens po usunięciu mechanizmów utrzymania dostępu z OWA i Exchange. W przeciwnym razie organizacja może przywrócić użytkownikowi czysty komputer, który ponownie zetknie się z zatrutą wiadomością albo nadal dostępną skrzynką.

Jak ćwiczyć taki scenariusz bez używania podatności

OWAReaper nie powinien być odtwarzany w kampanii awareness. Bezpieczna symulacja może natomiast sprawdzić zachowanie, które zespół chce uzyskać: zgłoszenie nieoczekiwanej, neutralnie wyglądającej wiadomości i przekazanie informacji potrzebnych do szybkiego triage. Wiadomość testowa nie powinna zawierać exploita, złośliwego JavaScriptu ani aktywnego mechanizmu utrzymania dostępu.

Scenariusz może zakończyć się po otwarciu bezpiecznej strony edukacyjnej lub po użyciu przycisku zgłoszenia. Warto mierzyć:

• liczbę prawidłowych zgłoszeń bez ponownego otwierania lub rozsyłania wiadomości;
• czas do pierwszego zgłoszenia i czas eskalacji do zespołu technicznego;
• kompletność danych: temat, nadawca, czas, kanał, urządzenie i sposób otwarcia;
• zdolność helpdesku do rozpoznania, że samo „nie kliknąłem” nie kończy analizy;
• czas wyszukania i usunięcia podobnych wiadomości z innych skrzynek.

Tak rozumiany security awareness program nie próbuje nauczyć pracowników analizy CVE. Ćwiczy raportowanie i współpracę z IT. Testy phishingowe dla firm mają największą wartość wtedy, gdy sprawdzają cały proces: zauważenie sygnału, zgłoszenie, korelację danych, decyzję o eskalacji i techniczne ograniczenie skutków.

Wniosek dla firmy

OWAReaper nie unieważnia wszystkich dotychczasowych zasad bezpieczeństwa poczty. Pokazuje jednak, że hasło „nie klikaj” jest tylko fragmentem ochrony. Użytkownik korzysta z aplikacji, aplikacja renderuje treść, a przeglądarka działa w zalogowanej sesji. Jeżeli któryś z tych elementów jest podatny, niepozorna wiadomość może stać się technicznym nośnikiem ataku bez klasycznego linku czy załącznika.

Dlatego ochrona przed phishingiem musi wykraczać poza filtr poczty. Potrzebne są aktualizacje, kontrola dostępu do OWA, monitoring tożsamości i skrzynek, widoczność ruchu DNS/HTTPS, szybkie zgłaszanie oraz procedura, która obejmuje serwer, konto i endpoint.

Najkrótsza instrukcja po podejrzeniu tego scenariusza brzmi: nie otwieraj wiadomości ponownie, zgłoś dokładny czas zdarzenia, sprawdź podatność Exchange i usuń mechanizmy utrzymania dostępu ze wszystkich warstw. Dopiero po takim sprawdzeniu można uznać, że zmiana hasła i odtworzenie komputera rzeczywiście kończą incydent.