Kategoria: Security News

Wprowadzenie do problemu / definicja luki

Microsoft opisał trwające kampanie phishingowe, w których napastnicy nie „łamą” OAuth, tylko nadużywają poprawnego (standardowego) zachowania mechanizmu przekierowań w OAuth — szczególnie w scenariuszach błędów (tzw. error flows). Efekt: link wygląda na prowadzący do zaufanej domeny dostawcy tożsamości (np. Entra ID), po czym ofiara zostaje przekierowana na infrastrukturę atakującego i trafia na stronę phishingową lub automatyczny download złośliwego pliku.

W praktyce to kolejny przykład „identity-first”: łańcuch ataku startuje od tożsamości i protokołów logowania, a dopiero później przechodzi w kompromitację endpointu (malware) lub przejęcie sesji (AiTM).

W skrócie

• Atakujący rejestruje złośliwą aplikację OAuth w kontrolowanym tenantcie i ustawia w niej redirect URI na własną domenę (np. pod dystrybucję malware).
• Phishing zawiera link do prawdziwego endpointu autoryzacji, ale z parametrami celowo wywołującymi błąd (m.in. prompt=none + nieprawidłowy scope).
• Dostawca tożsamości (IdP) zwraca błąd i — zgodnie ze specyfikacją — przekierowuje przeglądarkę na zarejestrowany redirect URI aplikacji, czyli… domenę atakującego.
• Celem nie musi być kradzież tokenów OAuth — często chodzi o dostarczenie payloadu (ZIP/LNK/HTML smuggling) albo AiTM (np. EvilProxy) do przejęcia cookies/sesji.

Kontekst / historia / powiązania

OAuth od lat jest atrakcyjny dla przestępców, bo stoi „na ścieżce zaufania” użytkownika: logowanie przez znaną domenę i spodziewane przekierowania obniżają czujność. Nowość w opisywanej fali nie polega na nowej luce w implementacji, tylko na tym, że mechanika przekierowań w warunkach błędu stała się praktycznie operacyjna i masowo wykorzystywana do obejścia klasycznych filtrów linków w poczcie i przeglądarkach.

Microsoft wskazuje też, że kampanie celowały m.in. w sektor publiczny/rządowy, a wiadomości miały „klasyczne” przynęty: e-podpisy, HR, finanse, tematy społeczne/polityczne, zaproszenia/„nagrania” z Teams, reset hasła.

Analiza techniczna / szczegóły luki

1) Złośliwa aplikacja i redirect URI

Atak zaczyna się od utworzenia aplikacji OAuth w tenantcie kontrolowanym przez napastnika. Kluczowe jest ustawienie redirect URI na domenę/ścieżkę, gdzie atakujący kontroluje dalszy krok (phishing lub malware download).

2) Link, który wygląda „normalnie”, ale jest celowo popsuty

Użytkownik dostaje URL do legalnego endpointu autoryzacji (np. login.microsoftonline.com/.../authorize). Parametry są jednak ustawione tak, by wywołać błąd bez interaktywnego logowania:

• prompt=none wymusza próbę „cichej” autoryzacji,
• scope bywa niepoprawny/nieobsługiwany (albo w inny sposób gwarantuje błąd),
• a state bywa nadużywany do przeniesienia danych (np. zakodowanego adresu e-mail ofiary), co potem umożliwia autopodstawienie e-maila na stronie docelowej i podbicie wiarygodności.

3) Error flow → przekierowanie na domenę napastnika

Gdy IdP nie może dokończyć autoryzacji „po cichu”, generuje błąd (np. wymaganie interakcji/zgody) i — zgodnie z zachowaniem protokołu — odsyła przeglądarkę na redirect URI przypisany do aplikacji, dołączając parametry błędu oraz state. To właśnie ten „legalny” redirect jest nadużywany jako trampolina z zaufanej domeny do złośliwej.

4) Co dalej: AiTM albo malware delivery (ZIP → LNK → PowerShell → DLL sideloading)

Microsoft i media branżowe opisują dwa główne warianty:

• AiTM / phishing-as-a-service (np. EvilProxy): przejęcie sesji poprzez wyłudzanie poświadczeń i cookies, potencjalnie z obejściem MFA dzięki kradzieży tokenów sesyjnych/cookies.
• Malware delivery: przekierowanie na ścieżkę typu /download, automatyczne pobranie ZIP zawierającego m.in. LNK oraz elementy HTML smuggling. Otwarcie LNK uruchamia PowerShell (rekonesans + staging), a następnie dochodzi do DLL side-loading: legalny binarny plik ładuje złośliwą bibliotekę (w opisach pojawiają się m.in. stream_monitor.exe i crashhandler.dll), która odszyfrowuje i ładuje payload w pamięci (np. crashlog.dat) i zestawia komunikację z C2.

Warto podkreślić: w tych kampaniach celem często nie jest kradzież tokenów OAuth, bo użytkownik nie udziela poprawnej autoryzacji — błąd jest celowy. Chodzi o wiarygodne „podprowadzenie” użytkownika i systemów filtrujących do kontrolowanej destynacji.

Praktyczne konsekwencje / ryzyko

1. „Hover to check link” przestaje działać: użytkownik widzi zaufaną domenę dostawcy tożsamości, a realne ryzyko siedzi w parametrach i późniejszym przekierowaniu.
2. Obejście części zabezpieczeń poczty i przeglądarki: filtry URL mogą przepuszczać linki do legalnych domen, a dopiero później następuje redirect na domenę atakującego.
3. Ryzyko kompromitacji endpointu (malware, pre-ransom, hands-on-keyboard) oraz ryzyko przejęcia sesji (AiTM) nawet przy włączonym MFA.
4. Szybka rotacja domen docelowych: payload hostowany „za redirectem” pozwala napastnikom dynamicznie zmieniać infrastrukturę, gdy kolejne domeny trafiają na blocklisty.

Rekomendacje operacyjne / co zrobić teraz

Poniżej praktyczny zestaw działań, które bezpośrednio wynikają z opisu Microsoftu (i są spójne z dobrymi praktykami IAM/Entra):

Kontrola aplikacji OAuth i zgód

• Ogranicz user consent (wiele organizacji powinno przejść na model, gdzie zgody na aplikacje wymagają akceptacji admina).
• Regularnie przeglądaj Enterprise Applications / App registrations pod kątem nowych, nieużywanych lub nadmiernie uprzywilejowanych aplikacji; usuwaj zbędne.
• Monitoruj i alertuj zmiany w redirect URI (to pole jest w tym scenariuszu kluczowe).

Polityki dostępu i sygnały tożsamości

• Wzmocnij Conditional Access (w tym wymagania urządzenia zgodnego/compliant, ryzyko logowania, lokalizacje, itp.). Microsoft wskazuje na konieczność korelowania sygnałów z email/identity/endpoint.
• Traktuj nietypowe żądania OAuth (np. wzorce z prompt=none + podejrzany scope) jako sygnał detekcyjny w telemetryce.

Twarde zabezpieczenia endpointu i poczty

• Blokuj/ogranicz ryzykowne typy (ZIP z LNK, HTML smuggling), wzmacniaj reguły ASR / polityki uruchamiania skryptów, kontroluj PowerShell (Constrained Language Mode tam, gdzie możliwe) i detekcje DLL side-loading.
• W email security nie polegaj wyłącznie na reputacji domeny w linku — wdrażaj analizę łańcucha przekierowań i sandbox/URL detonation (o ile środowisko na to pozwala). Uzasadnienie jest wprost w obserwacjach o „benign-looking URLs”.

Edukacja (ale „nowa”: parametry i przekierowania)

• Uaktualnij szkolenia: „zaufana domena w linku” nie wystarcza, bo zagrożenie może siedzieć w parametrach i późniejszym redirect.

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

• To nie jest klasyczne „consent phishing”, gdzie użytkownik faktycznie nadaje uprawnienia i atakujący dostaje tokeny do zasobów. Tutaj błąd jest intencjonalny, a mechanizm redirectu służy jako wiarygodna przesiadka do kolejnego etapu (phish/malware).
• W porównaniu do „zwykłego” phishingu na podrabianą domenę: przewaga atakującego polega na tym, że pierwszy hop jest na domenie zaufanej (IdP), co osłabia wiele heurystyk użytkownika i części narzędzi.

Podsumowanie / kluczowe wnioski

Nadużycie OAuth error flows to sprytny, a zarazem prosty w operacjonalizacji wzorzec: „legalny” endpoint autoryzacji + celowo wywołany błąd + standards-compliant redirect = wiarygodny łańcuch prowadzący do phishingu lub malware. Najważniejsze w obronie jest przesunięcie ciężaru z „czy domena wygląda legitnie” na zarządzanie aplikacjami OAuth, kontrolę zgód, monitoring redirect URI oraz korelację sygnałów identity + email + endpoint.

Źródła / bibliografia

1. Microsoft Security Blog — OAuth redirection abuse enables phishing and malware delivery (02.03.2026). (Microsoft)
2. BleepingComputer — Microsoft: Hackers abuse OAuth error flows to spread malware (04.03.2026). (BleepingComputer)
3. Malwarebytes — Attackers abuse OAuth’s built-in redirects to launch phishing and malware attacks (04.03.2026). (Malwarebytes)
4. CSO Online — OAuth phishers make ‘check where the link points’ advice ineffective (03.03.2026). (CSO Online)
5. The Register — Microsoft OAuth scams abuse redirects for malware delivery (03.03.2026). (theregister.com)