Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Phishing typu device code to technika przejęcia dostępu, która wykorzystuje legalny mechanizm OAuth 2.0 Device Authorization Grant. Został on zaprojektowany z myślą o urządzeniach z ograniczonym interfejsem, takich jak telewizory smart, kioski czy urządzenia IoT, jednak w praktyce coraz częściej staje się narzędziem nadużyć w środowiskach chmurowych.
W tym scenariuszu atakujący nie musi kraść hasła w tradycyjny sposób. Zamiast tego nakłania ofiarę do wpisania specjalnego kodu urządzenia na prawdziwej stronie logowania Microsoft. Jeśli użytkownik zakończy proces powodzeniem, napastnik może uzyskać tokeny dostępu i odświeżania, które pozwalają na dalsze działanie w koncie ofiary.
W skrócie
W marcu 2026 roku opisano kampanię wymierzoną w ponad 340 organizacji korzystających z Microsoft 365 w kilku krajach, w tym w Stanach Zjednoczonych, Kanadzie, Australii, Nowej Zelandii i Niemczech. Atak wykorzystywał legalny przepływ device code w ekosystemie Microsoft 365 i Microsoft Entra ID.
Mechanizm ataku polegał na generowaniu prawidłowego kodu urządzenia, a następnie przekazywaniu go ofierze za pośrednictwem spreparowanych wiadomości e-mail i stron pośrednich. Po wpisaniu kodu przez użytkownika na autentycznej stronie Microsoft dochodziło do wystawienia tokenów OAuth, co mogło zapewnić napastnikowi trwały dostęp do danych i usług organizacji.
- Atak bazuje na legalnym procesie logowania Microsoft.
- Może działać mimo poprawnie wdrożonego MFA.
- Umożliwia przejęcie tokenów bez kradzieży hasła.
- Stanowi rosnące zagrożenie dla środowisk Microsoft 365.
Kontekst / historia
Device code flow jest częścią standardu OAuth 2.0 i służy do uwierzytelniania urządzeń, które nie mają pełnej przeglądarki lub wygodnej klawiatury. Użytkownik rozpoczyna logowanie na jednym urządzeniu, a kończy je na innym, wpisując kod na stronie logowania. Z perspektywy użyteczności jest to rozwiązanie wygodne, ale z perspektywy bezpieczeństwa tworzy nietypową powierzchnię ataku.
Już wcześniej badacze oraz dostawcy zabezpieczeń ostrzegali, że phishing wykorzystujący device code może być używany zarówno w operacjach ukierunkowanych, jak i w bardziej masowych kampaniach. Obecna fala ataków pokazuje jednak wyraźną ewolucję tej techniki: od pojedynczych incydentów do szerzej zakrojonych, częściowo zautomatyzowanych operacji wspieranych zewnętrzną infrastrukturą phishingową.
Rosnące znaczenie tej techniki wynika również z faktu, że organizacje przez długi czas traktowały device code flow jako niszowy wyjątek. Dziś staje się jasne, że legalny przepływ uwierzytelniania może zostać skutecznie wykorzystany do przejęcia tożsamości bez klasycznego podszywania się pod stronę logowania.
Analiza techniczna
Schemat ataku jest stosunkowo prosty. Napastnik najpierw uzyskuje legalny kod urządzenia z interfejsu device code. Następnie przygotowuje wiadomość phishingową opartą na wiarygodnym pretekście biznesowym, na przykład dotyczącym dokumentu, wiadomości głosowej, podpisu elektronicznego lub postępowania przetargowego.
Ofiara trafia na stronę pośrednią, która wyświetla wygenerowany kod oraz instruuje, aby przejść do prawdziwej strony logowania Microsoft i go wpisać. Po uwierzytelnieniu i zatwierdzeniu MFA system wydaje tokeny powiązane z sesją. Ponieważ atakujący kontroluje początkowy proces, może następnie odebrać te tokeny z odpowiedniego punktu końcowego OAuth.
W analizowanej kampanii wykorzystano wieloetapowe łańcuchy przekierowań oraz infrastrukturę pośredniczącą, w tym usługi chmurowe i komponenty PaaS. Końcowe strony phishingowe dynamicznie prezentowały kod urządzenia, co sugeruje częściową automatyzację procesu. Badacze opisali także powiązania z usługami phishing-as-a-service oraz z technikami utrudniającymi analizę, takimi jak blokowanie narzędzi deweloperskich czy inspekcji strony.
Najważniejsza różnica względem klasycznego phishingu polega na tym, że użytkownik nie wpisuje danych na fałszywej stronie. Loguje się do autentycznej usługi Microsoft, co znacząco obniża czujność i utrudnia rozpoznanie oszustwa.
Konsekwencje / ryzyko
Największe zagrożenie wynika z tego, że legalny interfejs logowania budzi zaufanie użytkownika. W efekcie tradycyjne porady, takie jak sprawdzanie domeny, przestają być wystarczające. Atak nie bazuje na podróbce formularza, lecz na socjotechnice i nadużyciu poprawnego przepływu uwierzytelniania.
Drugim poważnym ryzykiem jest trwałość dostępu. Jeśli napastnik uzyska token odświeżania, może utrzymać dostęp nawet po zmianie hasła, o ile organizacja nie unieważni aktywnych sesji i tokenów. To oznacza, że samo zresetowanie poświadczeń może nie zakończyć incydentu.
Skutki mogą obejmować przejęcie skrzynki pocztowej, dostęp do dokumentów w SharePoint i OneDrive, nadużycia aplikacji OAuth, a także dalszy ruch boczny w środowisku SaaS. W praktyce taka kompromitacja może prowadzić do ataków BEC, wewnętrznego phishingu oraz wycieku danych biznesowych.
Rekomendacje
Najważniejszym krokiem obronnym jest wyłączenie lub ścisłe ograniczenie device code flow wszędzie tam, gdzie nie jest on rzeczywiście potrzebny operacyjnie. Organizacje korzystające z Microsoft Entra Conditional Access powinny jawnie kontrolować ten przepływ i blokować go dla większości użytkowników, lokalizacji oraz scenariuszy dostępu.
Drugim filarem ochrony pozostaje monitoring logów logowania. Zespoły bezpieczeństwa powinny analizować wykorzystanie device code flow, nietypowe adresy IP, logowania pochodzące z infrastruktury chmurowej niewykorzystywanej w działalności operacyjnej oraz wszelkie anomalie pojawiające się po interakcji użytkownika z podejrzaną wiadomością.
- Wyłączyć device code flow tam, gdzie nie jest niezbędny.
- Monitorować logi Microsoft Entra pod kątem użycia tego przepływu.
- Unieważniać aktywne sesje i refresh tokeny po incydencie.
- Przeglądać zgody aplikacyjne oraz uprawnienia OAuth.
- Rozszerzyć szkolenia awareness o scenariusze wpisywania kodu na legalnej stronie Microsoft.
W przypadku podejrzenia kompromitacji nie należy ograniczać się do zmiany hasła. Konieczne jest unieważnienie sesji, cofnięcie tokenów, analiza aktywności w poczcie i plikach, a także sprawdzenie, czy konto nie zostało wykorzystane do dalszych działań wewnętrznych. Warto również ograniczyć możliwość samodzielnego nadawania zgód aplikacjom przez użytkowników.
Podsumowanie
Kampania phishingu typu device code pokazuje, że współczesne ataki na tożsamość coraz częściej koncentrują się nie na kradzieży haseł, lecz na przejmowaniu tokenów i nadużywaniu legalnych przepływów OAuth. To przesuwa punkt ciężkości z klasycznego phishingu domenowego w stronę bardziej wyrafinowanych nadużyć zaufanej infrastruktury.
Dla organizacji korzystających z Microsoft 365 najważniejszy wniosek jest prosty: legalny proces logowania nie zawsze oznacza legalną intencję. Device code flow powinien być traktowany jako funkcja podwyższonego ryzyka, objęta ścisłą kontrolą, monitoringiem i procedurami reagowania uwzględniającymi unieważnianie tokenów, a nie tylko reset haseł.
Źródła
- The Hacker News — Device Code Phishing Hits 340+ Microsoft 365 Orgs Across Five Countries via OAuth Abuse — https://thehackernews.com/2026/03/device-code-phishing-hits-340-microsoft.html
- Huntress — Oh, Auth 2.0! Device Code Phishing in Google Cloud and Azure — https://www.huntress.com/blog/oh-auth-2-0-device-code-phishing-in-google-cloud-and-azure
- Microsoft Learn — Authentication flows as a condition in Conditional Access policy – Microsoft Entra ID — https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-authentication-flows
- Microsoft Learn — OAuth 2.0 device authorization grant – Microsoft identity platform — https://learn.microsoft.com/en-ie/entra/identity-platform/v2-oauth2-device-code
- Microsoft Learn — Protect against consent phishing – Microsoft Entra ID — https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/protect-against-consent-phishing