Wprowadzenie do problemu / definicja luki
Na przełomie końcówki 2025 roku obserwujemy wyraźny wzrost kampanii wymierzonych w konta Microsoft 365, w których atakujący nie muszą kraść hasła ani „łamać” MFA. Zamiast tego wykorzystują legalny mechanizm OAuth 2.0 Device Authorization Grant (tzw. device code flow), aby skłonić ofiarę do wprowadzenia kodu na prawdziwej stronie logowania urządzeń Microsoftu i… samodzielnego przyznania dostępu aplikacji kontrolowanej przez napastnika.
W praktyce jest to odmiana „phishingu zgody” (consent phishing) / phishingu tokenów, gdzie celem nie jest hasło, tylko tokeny dostępu (access tokens) i często także tokeny odświeżania (refresh tokens), które zapewniają trwały dostęp do zasobów M365 zgodnie z nadanymi uprawnieniami.
W skrócie
- Ataki nadużywają mechanizmu OAuth device code: ofiara wpisuje kod na legalnym portalu logowania urządzeń Microsoftu, a napastnik przejmuje wynikowe tokeny.
- Skala kampanii ma rosnąć istotnie od września 2025, a w działaniach biorą udział zarówno grupy finansowe, jak i powiązane państwowo.
- W ekosystemie pojawiają się gotowe narzędzia/kity upraszczające atak (m.in. SquarePhish i Graphish).
- Obrona to głównie: blokada/ograniczenie device code flow, twardsze polityki zgód na aplikacje (app consent), oraz monitoring zdarzeń Entra ID / Enterprise Apps.
Kontekst / historia / powiązania
„Consent phishing” nie jest nowym zjawiskiem: to naturalna konsekwencja przeniesienia tożsamości i aplikacji do chmury, gdzie użytkownik może (świadomie lub nie) nadać aplikacji uprawnienia do poczty, plików czy profilu. Microsoft wprost opisuje ten wektor jako atak polegający na nakłonieniu użytkownika do przyznania uprawnień złośliwej aplikacji, po czym aplikacja uzyskuje dostęp do danych w usługach cloud.
Nowością w bieżącej fali jest nacisk na device code phishing w większej skali: Proofpoint wskazuje, iż obserwuje wiele klastrów używających tego schematu do przejęć kont M365, co przekłada się na przejęcia sesji i eksfiltrację danych.
BleepingComputer opisuje jednocześnie, iż wysoki wolumen takich kampanii jest „nietypowy”, a wzrost ma trwać od września 2025.
Analiza techniczna / szczegóły luki
1) Co to jest OAuth 2.0 device authorization grant?
Device code flow powstał z myślą o urządzeniach z ograniczonym interfejsem (np. TV, urządzenia IoT, terminale), gdzie logowanie „w urządzeniu” jest niewygodne. Użytkownik dostaje krótki kod, wchodzi na stronę logowania urządzeń i po zalogowaniu potwierdza powiązanie sesji z danym kodem.
2) Jak wygląda atak krok po kroku
Typowy łańcuch (z wariantami zależnie od kampanii) wygląda następująco:
- Wiadomość phishingowa (często z presją czasu): „ponowna autoryzacja tokenu”, „kod jednorazowy”, „powiadomienie kadrowe” itp.
- Ofiara dostaje instrukcję, by przejść na legalny portal device login Microsoftu (np. microsoft.com/devicelogin) i wkleić kod.
- Użytkownik loguje się prawidłowo (często także przechodzi MFA), ale w efekcie autoryzuje dostęp dla aplikacji/„urządzenia” kontrolowanego przez atakującego.
- Napastnik odbiera z procesu autoryzacji wynik (tokeny) i uzyskuje dostęp do zasobów M365 w granicach przyznanych scope’ów.
Kluczowy detal: to nie jest „bypass MFA” w sensie technicznym — MFA działa, ale zostaje użyte przeciwko użytkownikowi, bo to ofiara sama zatwierdza logowanie/autoryzację na legalnej stronie.
3) Narzędzia upraszczające phishing
W opisach kampanii pojawiają się m.in.:
- SquarePhish v1/v2 – publicznie dostępne narzędzie red-teamowe celujące w device grant flow (m.in. przez QR), imitujące „legitne” scenariusze MFA/TOTP.
- Graphish – kit phishingowy dystrybuowany w podziemiu, wspierający nadużycia OAuth, Azure App Registrations oraz techniki typu adversary-in-the-middle (AiTM).
To ważne operacyjnie: obniżenie bariery wejścia oznacza, iż tę technikę mogą replikować nie tylko zaawansowane grupy.
Praktyczne konsekwencje / ryzyko
Skuteczne przejęcie w tym modelu zwykle prowadzi do klasycznych scenariuszy po przejęciu tożsamości w chmurze:
- Account takeover w M365 (poczta, SharePoint/OneDrive, Teams – zależnie od scope’ów),
- eksfiltracja danych i dostęp do korespondencji,
- możliwość przygotowania kolejnych etapów (np. reguły skrzynki, utrzymanie dostępu),
- ryzyka BEC i nadużyć procesów biznesowych, jeżeli przejęte konto ma uprawnienia i relacje z partnerami.
Warto też zauważyć zmianę trendu: zamiast „kraść hasło”, atakujący coraz częściej nadużywają nowoczesnych przepływów uwierzytelniania i autoryzacji. To komplikuje detekcję, bo część zdarzeń wygląda jak „zwykłe logowanie użytkownika”.
Rekomendacje operacyjne / co zrobić teraz
Poniżej lista działań, które realnie ograniczają ten wektor (od najsilniejszych kontroli):
1) Zablokuj device code flow tam, gdzie to możliwe
Microsoft wprost zaleca blokowanie device code flow, a jeżeli jest wymagany — objęcie go politykami Conditional Access.
Praktyka: w wielu organizacjach device code flow nie jest potrzebny większości użytkowników. jeżeli nie masz jasnych use-case’ów — wyłącz.
2) jeżeli nie możesz zablokować — podejście allow-list w Conditional Access
Help Net Security (na bazie zaleceń Proofpoint) opisuje podejście „allow-list”: włączaj device code tylko dla zatwierdzonych użytkowników / systemów / zakresów IP (Named locations).
Dodatkowo, jeżeli używasz Intune lub rejestracji urządzeń, wymagaj aby logowania do M365 pochodziły z urządzeń zgodnych/compliant lub zarejestrowanych.
3) Utwardź polityki zgód na aplikacje (consent)
W „consent phishing” fundamentem obrony jest ograniczenie, kto i na jakie aplikacje może wyrażać zgodę:
- wymuś, by użytkownicy mogli wyrażać zgodę tylko na aplikacje o niskim ryzyku / zweryfikowanych wydawcach lub zarejestrowane w Twoim tenancie,
- wdroż app consent policies i governance wokół Enterprise Apps.
Microsoft opisuje też, iż aplikacje oznaczane jako podejrzane mogą zostać zablokowane przez Microsoft Entra ID, ale organizacja przez cały czas powinna prowadzić własną kontrolę i higienę zgód.
4) Monitoring i reakcja: co logować i co sprawdzać
Minimum operacyjne (blue team / SOC):
- alerty na nietypowe zgody (consent grants) i nowe/nieznane aplikacje w Enterprise Apps,
- korelacja: zgoda na aplikację → nietypowe logowanie → działania w Graph/Exchange,
- szybka ścieżka IR: unieważnienie sesji/tokenów, wycofanie zgód aplikacji, przegląd reguł skrzynki i delegacji.
(Źródła opisują mechanikę tokenów i ryzyko trwałego dostępu, co uzasadnia powyższą procedurę).
Różnice / porównania z innymi przypadkami (jeśli dotyczy)
Klasyczny phishing haseł
- Cel: hasło (czasem + kod MFA).
- Obrona: MFA, FIDO2, filtrowanie URL, DMARC itp.
AiTM / reverse proxy
- Cel: przechwycenie sesji i tokenów w trakcie logowania (MFA często „przechodzi” przez proxy).
- Obrona: phishing-resistant MFA, CA, detekcje anomalii, blokady „token replay”.
Device code phishing / consent phishing (ten przypadek)
- Cel: użytkownik sam autoryzuje dostęp (tokeny powstają „legalnie”), bez kradzieży hasła.
- Obrona: przede wszystkim blokada/ograniczenie device code flow oraz twardsze zasady zgód na aplikacje.
Najważniejsza różnica: w device code phishing duża część sygnałów jest „poprawna” z perspektywy dostawcy tożsamości (realny login, realna strona) — dlatego governance i CA są krytyczne.
Podsumowanie / najważniejsze wnioski
Fala ataków na Microsoft 365 z użyciem OAuth device code pokazuje, iż napastnicy coraz częściej omijają „wojnę na hasła” i przenoszą ciężar na nadużycie legalnych mechanizmów autoryzacji. W tej technice MFA nie musi zostać złamane — wystarczy, iż użytkownik da się poprowadzić do wykonania „właściwych kroków” na prawdziwej stronie Microsoftu.
Jeśli chcesz gwałtownie obniżyć ryzyko: zacznij od wyłączenia device code flow (albo bardzo ciasnego allow-list w Conditional Access), a następnie domknij temat politykami zgód na aplikacje i monitoringiem consent grants.
Źródła / bibliografia
- BleepingComputer – opis fali ataków, narzędzi (SquarePhish/Graphish) i wzrostu od września 2025. (BleepingComputer)
- Proofpoint – „Access granted: phishing with device code authorization for account takeover” (klastry, mechanika, skutki). (Proofpoint)
- Microsoft Security Blog – „Defending against evolving identity attack techniques” (device code phishing, zalecenia blokady, consent phishing). (Microsoft)
- Microsoft Learn (Entra ID) – „Protect against consent phishing” (definicja, mechanizmy, best practices). (Microsoft Learn)
- Help Net Security – podsumowanie trendu i wskazówki CA/allow-list dla device code. (Help Net Security)
