Phishing OAuth w Microsoft 365

TL;DR

Phishing OAuth w Microsoft 365 pokazuje, że ataki na MFA nie muszą wyglądać jak fałszywa strona logowania. W device code phishingu użytkownik może zostać poproszony o wejście na prawdziwą stronę Microsoft, wpisanie krótkiego kodu i przejście normalnego uwierzytelnienia. Problem polega na tym, że kod został wygenerowany przez infrastrukturę atakującego, a po zakończeniu procesu token dostępu trafia do napastnika.

Microsoft opisał w 2026 roku kampanię nadużywającą device code authentication flow do kompromitacji kont organizacyjnych na dużą skalę. Sekoia i Abnormal AI opisały EvilTokens jako Phishing-as-a-Service, który produktowo wykorzystuje ten model, a następnie wspiera dalsze działania BEC, czyli business email compromise.

Dla firm najważniejszy wniosek jest praktyczny: MFA nie zwalnia z edukacji. Użytkownik musi rozumieć, że prawdziwa strona logowania nie zawsze oznacza bezpieczny proces. Jeśli kod, QR, link albo prośba o zgodę pojawia się w wiadomości, czacie lub połączeniu, trzeba przerwać proces i zgłosić sprawę.

Nowy klik nie wygląda jak stary phishing

Klasyczny phishing opierał się na fałszywej stronie logowania. Użytkownik wpisywał login i hasło, a atakujący je przejmował. W device code phishingu mechanizm jest bardziej podstępny. Użytkownik może naprawdę wejść na domenę Microsoftu, zobaczyć prawdziwe logowanie i przejść poprawne MFA, czyli wieloskładnikowe uwierzytelnianie.

Atakujący nie potrzebuje wtedy podrabiać całego procesu logowania. Nakłania ofiarę, aby zatwierdziła dostęp wygenerowany przez napastnika. Dla użytkownika wygląda to jak weryfikacja dokumentu, dostępu do pliku, udziału w spotkaniu, potwierdzenia tożsamości albo dokończenia procesu. W rzeczywistości jest to autoryzacja dostępu do konta.

To dlatego ten mechanizm jest trudny w edukacji. Użytkownik może zapamiętać, że ma sprawdzać domenę, a mimo to popełnić błąd, bo domena będzie prawdziwa. Potrzebna jest inna zasada: nie wpisuję kodów urządzenia i nie zatwierdzam zgód po instrukcji z niezweryfikowanej wiadomości.

Jak działa device code phishing

Device code flow jest legalnym mechanizmem OAuth, przydatnym między innymi na urządzeniach, które nie mają wygodnej klawiatury lub przeglądarki. Użytkownik dostaje kod i wpisuje go na stronie logowania, aby połączyć urządzenie lub aplikację z kontem.

W ataku napastnik generuje kod po swojej stronie i przekazuje go ofierze jako część wiadomości phishingowej. Ofiara wchodzi na prawdziwą stronę Microsoft, wpisuje kod i przechodzi MFA. System wydaje token dostępu, ale trafia on do atakującego, który wcześniej zainicjował proces.

To nie jest obejście MFA w prostym sensie. To wykorzystanie zaufanego przepływu uwierzytelniania przeciw użytkownikowi. Ofiara nie przekazuje hasła wprost. Zatwierdza dostęp, którego znaczenia nie rozumie.

Microsoft wskazywał, że nowsze kampanie używały automatyzacji i dynamicznego generowania kodów w momencie interakcji użytkownika, co pomagało ominąć ograniczenia czasu ważności kodów. Abnormal opisywał również dalsze wykorzystanie tokenów do automatyzacji działań BEC, analizy poczty i prowadzenia korespondencji z przejętego konta.

Dlaczego to groźne dla firm

Microsoft 365 jest centrum pracy wielu organizacji. Poczta, Teams, SharePoint, OneDrive, kalendarze, pliki, zgody aplikacji i tożsamość użytkownika tworzą środowisko, które po przejęciu daje atakującemu duży potencjał do dalszych działań.

Przejęcie tokenu może pozwolić na czytanie korespondencji, wyszukiwanie faktur, analizę rozmów z kontrahentami, przygotowanie BEC, rozsyłanie kolejnych wiadomości phishingowych i omijanie części klasycznych sygnałów. Jeśli wiadomość wychodzi z prawdziwej skrzynki, kolejna ofiara ma mniej powodów do podejrzeń.

W polskich firmach taki scenariusz może dotyczyć fałszywego dokumentu z Microsoft 365, zaproszenia do Teams, dostępu do faktury, podpisu elektronicznego, pliku z przetargu, udostępnienia w SharePoint albo zgody na aplikację. Treść może być prosta: wpisz kod, aby zobaczyć dokument. Problem w tym, że użytkownik nie zawsze widzi, komu daje dostęp.

Co powinien zrobić użytkownik

Jeżeli wiadomość prosi o wpisanie kodu urządzenia, wejście na stronę logowania, zatwierdzenie MFA, zeskanowanie QR albo nadanie zgody aplikacji, użytkownik powinien zatrzymać proces. Zwłaszcza jeśli prośba przyszła z e-maila, czatu, komunikatora, SMS-a albo od osoby, której nie może potwierdzić innym kanałem.

Nie należy zakładać, że prawdziwa domena Microsoftu wystarczy. W tym scenariuszu problemem jest nie fałszywa strona, lecz fałszywy kontekst. Prawdziwe logowanie może zostać użyte do autoryzacji dostępu dla atakującego.

Użytkownik powinien zgłosić wiadomość do IT lub SOC, nie kontynuować procesu i nie wpisywać kodu. Jeśli już to zrobił, trzeba jak najszybciej powiadomić zespół bezpieczeństwa, bo reakcja powinna objąć tokeny, sesje, aplikacje i logi, a nie tylko zmianę hasła.

Co powinien zrobić IT i SOC

W takim incydencie samo wymuszenie zmiany hasła może być niewystarczające. Trzeba sprawdzić aktywne sesje, tokeny, logowania przez device code flow, nietypowe aplikacje, zgody OAuth, reguły pocztowe, przekierowania, nowe urządzenia i działania w skrzynce.

Warto rozważyć ograniczenie lub kontrolę device code flow tam, gdzie organizacja nie ma uzasadnionych przypadków użycia. Pomocne są polityki Conditional Access, alerty na nietypowy device code authentication, ryzykowne logowania, anomalie tokenów i wykrywanie logowania po kliknięciu w link od rzadkiego nadawcy.

W reakcji SOC na phishing po filtrze poczty kluczowa jest korelacja: wiadomość, kliknięcie, logowanie, wydanie tokenu, dostęp do skrzynki, późniejsze działania. Jeśli SOC patrzy tylko na hasło, przegapi istotę ataku.

Jak ćwiczyć ten scenariusz w awareness

Ten typ phishingu powinien wejść do testów phishingowych dla firm, ponieważ dobrze sprawdza zachowanie użytkownika w sytuacji, w której klasyczne rady są niewystarczające. Nie chodzi tylko o domenę. Chodzi o rozumienie procesu autoryzacji.

Bezpieczna symulacja może pokazywać wiadomość z prośbą o wpisanie kodu urządzenia, otwarcie dokumentu, potwierdzenie aplikacji albo zeskanowanie QR. Metryki powinny obejmować kliknięcie, próbę wpisania kodu, zgłoszenie, czas reakcji i to, czy użytkownik rozpoznał nietypowy kontekst logowania.

Mikrolekcja po błędzie powinna wyjaśniać krótko: prawdziwa strona logowania nie zawsze oznacza prawdziwą sprawę. Kod urządzenia i zgoda OAuth są decyzją o dostępie. Jeśli nie rozumiesz, komu dajesz dostęp, przerwij proces.

Wniosek

Phishing OAuth przesuwa ciężar z kradzieży hasła na przejęcie decyzji użytkownika. Atakujący nie musi fałszować całego Microsoft 365, jeśli potrafi sprawić, że użytkownik sam wykona prawdziwe logowanie w złym kontekście.

Praktyczna zasada dla firm jest konkretna: MFA musi być połączone z edukacją o tokenach, zgodach OAuth, kodach urządzenia i nietypowych przepływach logowania. Bez tego pracownik może przejść prawidłowe uwierzytelnienie i jednocześnie autoryzować dostęp dla napastnika.