OAuth Device Code Flow: jak atakujący kradną tokeny M365 omijając MFA — i jak to zatrzymać

TL;DR: Atak device code flow pozwala przejąć konto M365 nawet gdy użytkownik ma MFA — ofiara loguje się na prawdziwej stronie Microsoftu, a tokeny trafiają do atakującego. Kampania Storm-2372 (powiązana z Rosją) aktywnie wykorzystuje tę technikę od sierpnia 2024. Zablokowanie w Conditional Access zajmuje 5 minut, ale uważaj na edge cases z Teams Rooms i narzędziami admina — bo zamiast atakującego możesz zablokować siebie.

Problem

Wyobraź sobie: dostajecie od użytkownika zgłoszenie, że ktoś logował się na jego konto z Azji o 3 w nocy. Sprawdzacie logi Entra ID — logowanie zakończone sukcesem, MFA przeszło. Jak to możliwe?

To właśnie device code flow phishing. Użytkownik dostał wiadomość (przez Teams, WhatsApp lub email) z prośbą o wpisanie krótkiego kodu na stronie microsoft.com/devicelogin — rzekomo żeby potwierdzić dostęp do dokumentu albo spotkania. Wszedł na prawdziwą stronę Microsoftu, wpisał kod, zalogował się swoim hasłem i zaakceptował MFA. Kompletnie legalna procedura. Tylko że kod wygenerował atakujący, a tokeny dostępowe trafiły prosto do jego serwera.

Od sierpnia 2024 Microsoft śledzi kampanię Storm-2372 — aktora powiązanego z Rosją — który aktywnie wykorzystuje tę technikę przeciwko rządom, NGO, firmom technologicznym, obronie i energetyce w Europie, Ameryce Północnej i na Bliskim Wschodzie. W lutym 2025 kampania wyewoluowała: atakujący zaczęli używać Microsoft Authentication Broker client ID do rejestrowania własnych urządzeń i przejmowania Primary Refresh Tokens (PRT) — co daje jeszcze trwalszy dostęp niż zwykły access token.

W 2026 pojawiły się gotowe zestawy PhaaS (Phishing-as-a-Service) jak EvilTokens, które automatyzują device code phishing w skali przemysłowej. Szablony podszywają się pod Adobe Acrobat Sign, DocuSign, OneDrive, SharePoint, powiadomienia o kwarantannie maili i zaproszenia na spotkania. Setki organizacji dziennie pada ofiarą tego ataku.

Dlaczego tak się dzieje

Device code flow (RFC 8628) powstał z konkretnego, uzasadnionego powodu: żeby pozwolić na logowanie do usług na urządzeniach bez klawiatury lub przeglądarki — drukarkach, telewizorach Smart TV, konsolach Xbox, urządzeniach IoT, salach konferencyjnych Teams Rooms.

Normalny flow wygląda tak:

1. Urządzenie (np. TV) wysyła request do Entra ID i otrzymuje device_code (ciąg 8-10 znaków) i user_code
2. TV wyświetla komunikat: "Idź na microsoft.com/devicelogin i wpisz kod XXXX-XXXX"
3. Użytkownik loguje się w przeglądarce — normalnie, z hasłem i MFA
4. TV odpytuje token endpoint co kilka sekund i po zalogowaniu użytkownika otrzymuje access_token i refresh_token

Problem: krok 1 może wykonać ktokolwiek, nie tylko legitymizowane urządzenie. Atakujący generuje device code, wysyła user_code do ofiary przez phishing, a sam czeka na tokeny. Ofiara widzi stronę login.microsoftonline.com — prawdziwą, z certyfikatem Microsoftu. Loguje się normalnie. Tokeny idą do atakującego.

Kluczowe szczegóły techniczne:

• Tokeny mają flagę amr: ["mfa"] — w logach Entra ID wygląda to jak normalne, MFA-chronione logowanie. Żaden alert się nie pojawi.
• Device code jest ważny 15 minut, ale atakujący generuje nowe kody do skutku.
• Refresh token po odebraniu jest ważny domyślnie 90 dni i pozwala odnawiać access token bez ponownego logowania użytkownika.
• Od lutego 2025 nowa odmiana ataku: Storm-2372 używa Microsoft Authentication Broker (client ID: 29d9ed98-a469-4536-ade2-f981bc1d605e) do rejestrowania urządzenia atakującego i uzyskania PRT — który daje dostęp SSO do wszystkich zasobów M365.

Rozwiązanie krok po kroku

Krok 1: Sprawdź czy Microsoft już wdrożył politykę zarządzaną

Od 2025 Microsoft w ramach Secure Future Initiative wdraża zarządzaną politykę "Block device code flow" do tenantów. Sprawdź jej status:

1. Entra ID Admin Center → Protection → Conditional Access → Policies
2. Poszukaj polityki "Block device code flow" — może być oznaczona jako "Microsoft-managed"
3. Sprawdź stan: Report-only czy On

Jeśli jest w Report-only — nie chroni cię. Zmień na On, ale dopiero po przeczytaniu sekcji o pułapkach.

Krok 2: Sprawdź logi — czy masz już problem

Przed wdrożeniem polityki sprawdź czy w Twoim tenancie już nie dochodzi do podejrzanych logowań przez device code. KQL w Microsoft Sentinel lub Log Analytics:

Normalne wyniki: logowania z Azure CLI, Az PowerShell, Connect-MgGraph — z IP admina i w godzinach roboczych. Podejrzane: logowania z egzotycznych IP, nieznanych aplikacji, w nocy.

Krok 3: Utwórz grupę wyjątków przed blokowaniem

Zidentyfikuj konta które legalnie używają device code flow:

• Konta zasobów Teams Rooms (resource accounts) na urządzeniach Android
• Konta Teams Phone, Teams Panels, Teams Displays
• Drukarki i urządzenia IoT logujące się przez M365

Stwórz dedykowaną grupę w Entra ID: SG-DeviceCodeFlow-Allowed i dodaj do niej wyłącznie te konta oraz konta break-glass. Bez tego możesz mieć niespodzianki w sali konferencyjnej.

Krok 4: Utwórz politykę blokującą przez portal

1. Entra ID → Conditional Access → New policy
2. Name: Block Device Code Flow — All Users
3. Users: All users
4. Exclude: SG-DeviceCodeFlow-Allowed + konta break-glass
5. Conditions → Authentication flows → Configure: Yes → Device code flow: Yes
6. Grant → Block access
7. State: Report-only na 7-14 dni

Po tygodniu obserwacji w Report-only sprawdź w Workbook CA: ile blokad by wystąpiło i dla których kont. Dopiero wtedy włącz na On.

Krok 5: Wdróż przez PowerShell dla powtarzalności

Po 14 dniach obserwacji, promocja do enforced:

Krok 6: Unieważnij podejrzane sesje

Jeśli znalazłeś podejrzane logowania w kroku 2:

Pamiętaj: odwołanie tokenów działa natychmiastowo na refresh tokeny, ale access tokeny (ważne domyślnie 1 godzinę) mogą być nadal używane przez atakującego do czasu ich naturalnego wygaśnięcia.

Typowe pułapki i edge cases

Pułapka 1: Teams Rooms i Teams Phones przestają działać

To najczęstszy problem po wdrożeniu. Teams Android devices — Teams Rooms on Android, Teams Phones, Teams Panels, Teams Displays — używają device code flow do logowania resource accounts. Gdy Microsoft wdrożył zarządzaną politykę w 2025, wiele firm dostało masowy problem — urządzenia konferencyjne przestały działać z dnia na dzień.

Jeśli tak się stało po Twoim wdrożeniu:

1. Identyfikuj resource accounts: Get-CsOnlineUser | Where-Object { $_.AccountType -eq "ResourceAccount" }
2. Dodaj je do grupy SG-DeviceCodeFlow-Allowed
3. Po propagacji polityki (do 10 minut) wykonaj reboot urządzenia 1-3 razy
4. Jeśli reboot nie pomaga — factory reset jest wymagany do wyczyszczenia nieprawidłowego stanu auth

Pułapka 2: Admini blokują siebie w Azure CLI i PowerShell

az login, Connect-AzAccount, Connect-MgGraph -UseDeviceCode, Connect-ExchangeOnline -UseDeviceCode — wszystkie te narzędzia domyślnie lub opcjonalnie używają device code flow. Admin wdraża politykę, a następnego dnia nie może uruchomić swoich skryptów. Błąd który zobaczy: AADSTS53003: Access has been blocked by Conditional Access policies.

Rozwiązanie długoterminowe: przestaw skrypty na Managed Identity lub Service Principal + certyfikat. Na własnym komputerze admin może używać interaktywnego logowania przez przeglądarkę (Connect-MgGraph bez -UseDeviceCode). Przejściowo: dodaj konta admina do SG-DeviceCodeFlow-Allowed podczas migracji skryptów.

Pułapka 3: Polityka zarządzana Microsoftu nie wystarczy jako jedyna ochrona

Microsoft-managed policy ma istotne ograniczenia:

• Raz zmodyfikowana przez admina nie jest już automatycznie aktualizowana przez Microsoft
• Domyślny stan przy pierwszym wdrożeniu to Report-only — Microsoft nie włącza jej za Ciebie
• Rollout jest stopniowy i nierównomierny między tenantami

Stwórz własną, niezależną politykę. Traktuj Microsoft-managed jako drugą linię obrony, nie jedyną.

Pułapka 4: Blokada nie cofnie historycznych przejęć przez PRT

Od lutego 2025 Storm-2372 używa Microsoft Authentication Broker do rejestrowania urządzenia atakującego podczas device code flow i uzyskania PRT. PRT daje dostęp SSO do wszystkich zasobów M365. Blokowanie device code flow od dziś nie pomoże jeśli atakujący już odebrał tokeny przed wdrożeniem polityki.

Sprawdź nieautoryzowane rejestracje urządzeń z ostatnich 30 dni:

Urządzenia zarejestrowane w ostatnim miesiącu których nie rozpoznajesz — usuń i zbadaj.

Podsumowanie

• Device code flow phishing omija MFA — ofiara wykonuje prawdziwe MFA, tokeny trafiają do atakującego; logi pokazują prawidłowe logowanie bez żadnej anomalii
• Storm-2372 (powiązana z Rosją) atakuje tą metodą od sierpnia 2024; skala rośnie przez gotowe zestawy PhaaS w 2026
• Blokada przez Conditional Access wymaga Entra ID P1 (zawartego w M365 Business Premium, E3, E5)
• Przed włączeniem polityki: przejrzyj logi KQL i stwórz grupę wyjątków dla Teams Rooms i IoT
• Politykę zarządzaną Microsoftu sprawdź aktywnie — domyślny stan Report-only nie chroni
• Po podejrzanym incydencie: odwołaj sesje + sprawdź rejestracje urządzeń z ostatnich 30 dni