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, iż 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ż, iż 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. najważniejsze 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
- „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.
- 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.
- Ryzyko kompromitacji endpointu (malware, pre-ransom, hands-on-keyboard) oraz ryzyko przejęcia sesji (AiTM) choćby przy włączonym MFA.
- 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, iż pierwszy hop jest na domenie zaufanej (IdP), co osłabia wiele heurystyk użytkownika i części narzędzi.
Podsumowanie / najważniejsze 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
- Microsoft Security Blog — OAuth redirection abuse enables phishing and malware delivery (02.03.2026). (Microsoft)
- BleepingComputer — Microsoft: Hackers abuse OAuth error flows to spread malware (04.03.2026). (BleepingComputer)
- Malwarebytes — Attackers abuse OAuth’s built-in redirects to launch phishing and malware attacks (04.03.2026). (Malwarebytes)
- CSO Online — OAuth phishers make ‘check where the link points’ advice ineffective (03.03.2026). (CSO Online)
- The Register — Microsoft OAuth scams abuse redirects for malware delivery (03.03.2026). (theregister.com)
