OWAReaper: CVE-2026-42897 przetrwał zmianę hasła

30 lipca 2026 roku opublikowano techniczne szczegóły kampanii rosyjskiego aktora TA488, który wykorzystuje CVE-2026-42897 w lokalnym Outlook Web Access. Otwarcie spreparowanej wiadomości w podatnym OWA wystarczało do uruchomienia JavaScript w panelu odczytu. Implant nazwany OWAReaper utrzymywał dostęp w kilku warstwach: pamięci przeglądarki, cache wiadomości, tokenach dodatków i uprawnieniach skrzynki.

Najważniejszy wniosek operacyjny jest niewygodny: sama zmiana hasła, odwołanie zwykłej sesji, a nawet pełne odtworzenie komputera użytkownika mogły nie usunąć wszystkich mechanizmów trwałości. Część zmian znajdowała się po stronie Exchange i wymagała świadomego cofnięcia.

Co wydarzyło się 22 lipca

Proofpoint opisał kampanię, której nową falę zaobserwowano od 22 lipca 2026 roku. Publikacja z 30 lipca zebrała szczegóły techniczne i zakres:

wykorzystywano CVE-2026-42897 o CVSS 8.1;
celem były instytucje rządowe w USA i Europie oraz telekomunikacja, finanse, hotelarstwo i lotnictwo;
wiadomości przychodziły z kont kontrolowanych przez napastnika i wcześniej przejętych skrzynek;
użytkownik nie musiał klikać linku ani otwierać załącznika;
uruchomienie następowało po wyświetleniu wiadomości w podatnym OWA;
implant działał wewnątrz kontekstu przeglądarki;
operator używał dwóch kanałów C2 i dwóch metod eksfiltracji;
nie wszystkie mechanizmy trwałości znikały po zmianie poświadczeń lub reinstalacji hosta.

Microsoft wcześniej oznaczył podatność jako wykorzystywaną od maja 2026 roku. Proofpoint znalazł infrastrukturę utworzoną w marcu, ale sam czas rejestracji nie dowodzi eksploatacji zero-day od marca. Uzasadnia hipotezę wcześniejszego przygotowania, nie twardą datę pierwszego włamania.

Half-click: wiadomość bez linku i załącznika

Proofpoint używa określenia half-click exploit. Odbiorca musi otworzyć wiadomość w webmailu, ale nie musi klikać linku, uruchamiać pliku ani akceptować makra. To utrudnia tradycyjną edukację phishingową, która koncentruje się na „nie klikaj”.

Wiadomości były celowo niepozorne. Dotyczyły analiz łańcucha dostaw, aktualizacji badań, turystyki albo rynku gazu. Brak linków i załączników mógł obniżyć podejrzliwość użytkownika oraz wynik części filtrów.

Kod wykorzystywał zdarzenie onload. Fragment uruchamiający i dane payloadu znajdowały się w ikonach mediów społecznościowych osadzonych w HTML wiadomości. Kolejne fragmenty zapisano po znakach #, których parser obrazów nie uwzględniał w zwykłym odczycie źródła. Loader składał elementy Base64 i wykonywał wynik jako JavaScript.

Nie publikujemy konstrukcji wiadomości ani payloadu. Dla obrony ważne jest to, że „pusta” ikona i poprawnie wyglądający HTML mogą pełnić rolę kontenera danych.

OWAReaper działał w panelu odczytu

Po wykonaniu implant otrzymywał dostęp do interfejsów dostępnych w sesji OWA. Najpierw przepisywał wiadomość na serwerze Exchange, usuwając zawartość exploita. To ograniczało widoczność i utrudniało późniejszą analizę dokładnie tego e-maila, który uruchomił łańcuch.

OWAReaper wyłączał także wyskakujące okna i prawy przycisk myszy na czas działania, tworzył unikalny klucz sesji oraz zbierał adres e-mail, nazwę użytkownika i ustawienia Outlooka.

Następnie dodawał do DOM dwa niewidoczne pola formularza. Celem było skłonienie mechanizmu autouzupełniania przeglądarki do wpisania zapisanych danych uwierzytelniających. Nie każda konfiguracja przeglądarki przechowuje hasło i nie każdy menedżer uzupełni niewidoczne pole. Funkcja zwiększała jednak zakres możliwej kradzieży w środowiskach, które to dopuszczały.

Trwałość w localStorage

Implant zapisywał zaszyfrowaną kopię własnego kodu i wrapper deszyfrujący w localStorage. Gdy użytkownik otwierał kolejną kartę OWA, kod mógł uruchomić się ponownie.

To mechanizm po stronie profilu przeglądarki. Odtworzenie komputera powinno usunąć lokalny magazyn, ale tylko ten wariant. Jeżeli inne mechanizmy pozostały na serwerze lub wiadomość była nadal w cache, reinfekcja mogła nastąpić ponownie.

W analizie nie należy ograniczać się do historii URL. Warto zabezpieczyć:

localStorage dla domeny OWA;
IndexedDB;
cache aplikacji i wiadomości offline;
rozszerzenia oraz dodatki;
pamięć procesu przeglądarki;
historię modyfikacji wiadomości na Exchange;
logi dostępu i zmian uprawnień skrzynki.

IndexedDB jako drugi nośnik

OWAReaper dodawał ukryty iframe do wiadomości przechowywanych w offline cache OWA i włączał cache’owanie. Po otwarciu złośliwej wiadomości z lokalnej bazy IndexedDB kod mógł wykonać się ponownie.

Ten mechanizm tłumaczy, dlaczego samo usunięcie localStorage nie musi wystarczyć. Profil przeglądarki zawiera kilka oddzielnych magazynów. Zespół reagowania powinien czyścić je zgodnie z procedurą producenta, ale dopiero po zabezpieczeniu dowodów.

Dodatki Outlooka i tokeny OAuth

Implant sprawdzał zainstalowane dodatki Outlooka posiadające uprawnienie ReadWriteMailbox. Jeśli taki dodatek był dostępny, OWAReaper próbował pozyskać token OAuth.

Token ma własny cykl życia i może pozostać użyteczny niezależnie od hasła użytkownika. Reakcja powinna więc obejmować:

odwołanie sesji i refresh tokenów;
przegląd enterprise applications i consentów;
listę dodatków mających ReadWriteMailbox;
nietypowe użycie tokenów po czasie infekcji;
nowe lub zmienione uprawnienia aplikacji;
logowania klienta niewynikające z normalnej aktywności.

Rotacja hasła jest jednym krokiem, nie pełną odpowiedzią na nadużycie OAuth.

Najgroźniejsza trwałość: Default jako Owner

OWAReaper nadawał użytkownikowi Default uprawnienie Owner do każdego folderu skrzynki. W Exchange Default nie oznacza jednej konkretnej osoby. Jest to wpis obejmujący uwierzytelnionych użytkowników organizacji, którzy nie mają osobnego wpisu uprawnień.

Jeżeli napastnik kontrolował inne konto w tym samym środowisku, mógł utrzymać dostęp do skrzynki ofiary nawet po zmianie jej hasła. Ta zmiana znajdowała się po stronie serwera Exchange. Reinstalacja laptopa jej nie cofała.

Administrator powinien sprawdzić uprawnienia folderów w całym zakresie dotkniętych skrzynek, szczególnie wartości Default i Anonymous. Nie wolno jedynie odebrać prawa pojedynczemu podejrzanemu kontu, jeśli implant zmienił rolę zbiorczą.

Dwa kanały C2

OWAReaper pobierał polecenia na dwa sposoby. Pierwszy wykorzystywał GitHub Commit Search API. Raz na 24 godziny implant szukał komunikatów commitów zawierających adres e-mail celu. Po odnalezieniu pasującego wpisu odszyfrowywał dane z użyciem klucza zaszytego w kodzie i klucza sesji.

Opisano trzy nagłówki poleceń:

code — zastąpienie kodu implantu;
domn — zmiana serwerów C2;
cmnd — wykonanie JavaScript.

Druga metoda używała wiadomości przysłanych przez operatora. Implant przeszukiwał IndexedDB pod kątem określonej struktury adresu celu i zakodowanej treści.

Zastosowanie legalnego GitHuba nie czyni komunikacji niewidoczną. Nietypowe użycie Commit Search API przez sesję OWA, regularny interwał oraz zapytania zawierające firmowy adres e-mail są potencjalnymi sygnałami.

Dwie ścieżki eksfiltracji

Podstawowa metoda wysyłała dane przez HTTPS, kodując je w ścieżkach URI i szyfrując AES-CTR. Wariant zapasowy przenosił fragmenty w etykietach zapytań DNS do domeny operatora.

DNS nie był tu pierwszym kanałem, lecz planem awaryjnym. Organizacja, która widzi wyłącznie ruch proxy, może przeoczyć fallback. Potrzebne są logi resolvera, długość i entropia etykiet, częstotliwość zapytań oraz powiązanie z procesem źródłowym.

Techniki wykrywania omawiamy szerzej w przewodniku DNS tunneling i jego detekcja.

Kogo dotyczy podatność

CVE-2026-42897 dotyczy lokalnych instalacji Exchange OWA, nie Exchange Online jako usługi. Organizacje hybrydowe nadal mogą mieć lokalne serwery i narzędzia zarządzające. Samo „mamy Microsoft 365” nie kończy inwentaryzacji.

Praktyczny zakres obejmuje:

Exchange Server 2016 i 2019 z odpowiednim wsparciem aktualizacji;
Exchange Server Subscription Edition;
instancje publikujące OWA na zewnątrz;
serwery używane tylko do celów hybrydowych lub zarządzania;
profile przeglądarek użytkowników, którzy otwierali pocztę przez OWA.

Dokładny plan aktualizacji i mitygacji opisujemy w osobnym przewodniku CVE-2026-42897: XSS w Exchange OWA.

Plan reakcji krok po kroku

Zastosuj poprawki Microsoftu na wszystkich lokalnych serwerach i narzędziach objętych zakresem.
Zidentyfikuj użytkowników OWA oraz wiadomości otwierane od początku możliwej ekspozycji.
Zachowaj dowody przeglądarki, w tym localStorage i IndexedDB.
Sprawdź modyfikacje wiadomości, bo implant usuwał kod exploita z serwera.
Przejrzyj uprawnienia folderów, zwłaszcza role Default i Anonymous.
Odwołaj tokeny OAuth, sesje i zgody dodatków.
Usuń nieautoryzowane uprawnienia serwerowe i zweryfikuj je ponownie.
Sprawdź GitHub API, HTTPS i DNS pod kątem wzorców opisanych przez Proofpoint.
Przeszukaj inne konta, ponieważ operator mógł wykorzystać sąsiednią tożsamość.
Odtwórz profil lub host, ale dopiero po usunięciu trwałości po stronie Exchange.

Zmiana hasła powinna wystąpić po odcięciu ścieżek trwałości. W przeciwnym razie napastnik może ponownie uzyskać dane albo nadal korzystać z tokena czy roli folderu.

Detekcja dla poczty, IAM i SOC

OWAReaper przecina trzy zespoły. Administrator poczty widzi foldery i dodatki, IAM tokeny oraz sesje, a SOC ruch i przeglądarkę. Sygnały warto korelować:

wiadomość bez linku uruchamia nietypowy JavaScript w OWA;
treść e-maila zmienia się krótko po odczycie;
Default otrzymuje Owner na wielu folderach;
dodatek z ReadWriteMailbox generuje nietypowy token;
OWA odpytuje GitHub Commit Search;
profil ma nowe wartości localStorage i IndexedDB;
pojawiają się długie, nietypowe etykiety DNS;
użytkownik otrzymuje podobne „informacyjne” wiadomości z przejętych kont.

Budowę korelacji można prowadzić zgodnie z detection engineering w Sigma i SIEM, a całą kampanię osadzić w cyklu Cyber Threat Intelligence.

Dowody, które potwierdzają zamknięcie

Incydent można uznać za opanowany dopiero po ponownym przeglądzie każdej warstwy trwałości. Potrzebne są czyste uprawnienia folderów, brak nieautoryzowanych dodatków i tokenów, usunięte wpisy localStorage oraz IndexedDB, aktualny Exchange i brak dalszych sygnałów C2. Wyniki trzeba zapisać dla konkretnego użytkownika, skrzynki, profilu przeglądarki i serwera — ogólne stwierdzenie „hasło zmienione” nie pokrywa zakresu OWAReaper.

Warto też wykonać kontrolowany test uprawnień: konto nieuwierzytelnione i zwykły użytkownik nie mogą odczytać folderów przez rolę Default, a nowy token dodatku wymaga zatwierdzonej aplikacji. Dopiero po takim teście można przywracać pełny dostęp. Monitoring DNS, GitHub API i zdarzeń skrzynki powinien pozostać podwyższony przez okres wynikający z retencji i najwcześniejszej potwierdzonej aktywności.

Źródła a wnioski Breachroad

Proofpoint potwierdza zakres celów, half-click, konstrukcję loadera, funkcje OWAReaper, localStorage, IndexedDB, tokeny dodatków, zmianę uprawnień folderów, kanały C2 i eksfiltrację. Microsoft potwierdza podatność i poprawki. Hipoteza eksploatacji zero-day przed publicznym ujawnieniem wynika z chronologii infrastruktury, ale nie jest ostatecznym dowodem daty użycia.

Kolejność reakcji, korelacja zespołów i mierniki zamknięcia są wnioskami Breachroad. Organizacje mogą zweryfikować Exchange, IAM i logowanie podczas audytu bezpieczeństwa IT.

Ta kampania zmienia też szkolenie użytkowników: bezpieczna wiadomość to nie tylko „brak linku”. Szkolenia cyberbezpieczeństwa i phishingu muszą iść w parze z aktualizacją OWA oraz gotowością techniczną, bo użytkownik nie mógł rozpoznać exploita po zwykłym wyglądzie wiadomości.