Device code phishing w Microsoft 365

TL;DR

Device code phishing to atak na tożsamość Microsoft 365, w którym użytkownik nie musi wpisywać hasła na fałszywej stronie. Zamiast tego dostaje instrukcję, aby wejść na prawdziwy portal Microsoft do logowania urządzeń i wpisać podany kod. Z perspektywy użytkownika proces wygląda wiarygodnie, bo logowanie rzeczywiście odbywa się w domenie Microsoft. Z perspektywy atakującego kod pozwala uzyskać tokeny dostępu do konta i usług chmurowych.

Proofpoint opisał szybki wzrost takich kampanii, a eSentire pokazał wariant Tycoon 2FA, w którym przynęta prowadziła przez Trustifi i Cloudflare Workers do przepływu OAuth Device Authorization Grant. Celem nie jest już tylko hasło. Celem są tokeny, sesje, dostęp do poczty, plików i dalsze działania po przejęciu konta.

Dla firm to ważny sygnał: szkolenie o sprawdzaniu adresu strony logowania nie wystarczy. Pracownik musi rozumieć, że kod urządzenia, QR, PDF z instrukcją, komunikat o poczcie głosowej albo prośba o potwierdzenie logowania mogą być elementem ataku, nawet jeśli część procesu odbywa się na prawdziwej stronie Microsoft.

Dlaczego ten atak jest trudniejszy od klasycznego phishingu

W klasycznym phishingu użytkownik widzi fałszywą stronę logowania i wpisuje hasło. W device code phishingu napastnik nadużywa legalnego mechanizmu, który Microsoft przewidział dla urządzeń z ograniczonym interfejsem, na przykład telewizorów, narzędzi konsolowych albo urządzeń, na których trudno wygodnie wpisać hasło.

Mechanizm sam w sobie nie jest złośliwy. Problem zaczyna się wtedy, gdy kod wygenerowany przez atakującego trafia do ofiary. Użytkownik dostaje wiadomość, PDF, QR albo link i jest proszony o wpisanie kodu na stronie Microsoft. Po poprawnym logowaniu i spełnieniu MFA, czyli wieloskładnikowego uwierzytelniania, tokeny mogą zostać powiązane z urządzeniem lub sesją kontrolowaną przez napastnika.

To łamie prostą intuicję użytkownika. Prawdziwa strona logowania przestaje być wystarczającym dowodem bezpieczeństwa. Jeżeli proces rozpoczął się od nieoczekiwanej wiadomości, pliku PDF, QR, linku z poczty lub instrukcji od niezweryfikowanego nadawcy, prawdziwa domena Microsoft w jednym kroku nie oznacza, że cały proces jest prawidłowy.

Jak wygląda scenariusz Microsoft 365

W obserwowanych kampaniach użytkownik może otrzymać wiadomość o poczcie głosowej, płatności, dokumencie, fakturze, wynagrodzeniu, pliku SharePoint, DocuSign albo wiadomości HR. W środku znajduje się link, załącznik PDF albo kod QR. Po przejściu dalej ofiara trafia do instrukcji, która sugeruje wpisanie kodu na stronie Microsoft.

Atakujący nie musi przekonywać użytkownika do instalacji złośliwego pliku. Wystarczy, że poprowadzi go przez kilka kroków i utrzyma w przekonaniu, że to procedura dostępu do dokumentu lub usługi. Po wpisaniu kodu i zalogowaniu tokeny mogą umożliwić dostęp do Microsoft 365, poczty, kalendarza, OneDrive, SharePoint, Teams albo danych dostępnych przez Microsoft Graph.

eSentire opisał wariant Tycoon 2FA, w którym przynęta zaczynała się od linku śledzącego w usłudze Trustifi, a później prowadziła przez kolejne warstwy do strony z motywem poczty głosowej Microsoft 365. To pokazuje, że pierwsza domena w łańcuchu może wyglądać czysto i mieć dobrą reputację. Złośliwy sens pojawia się dopiero po przekierowaniach, walidacji ofiary i wyświetleniu właściwej instrukcji.

Dlaczego to jest problem dla awareness

Device code phishing wymaga zmiany języka edukacji. Hasło nadal jest ważne, ale pracownik musi wiedzieć, że wrażliwe są także kody urządzenia, QR, adresy URL z procesu logowania, zgody OAuth, powiadomienia MFA i nietypowe instrukcje techniczne. Komunikat nie podawaj hasła jest za wąski.

W programie security awareness taki scenariusz warto ćwiczyć jako decyzję pod presją. Użytkownik dostaje maila z PDF-em, rzekomą wiadomością głosową albo dokumentem HR. Następnie widzi kod i instrukcję logowania. Celem testu nie jest złapanie kogoś na błędzie, ale sprawdzenie, czy pracownik potrafi zatrzymać proces, zgłosić wiadomość i nie wprowadzać kodu z nieoczekiwanego źródła.

Dojrzała kampania powinna mierzyć nie tylko kliknięcie. Ważne jest, czy użytkownik zeskanował QR, otworzył PDF, przepisał kod, zalogował się, zgłosił wiadomość i jak szybko organizacja zareagowała. W tym scenariuszu kliknięcie jest tylko początkiem łańcucha.

Co zrobić, jeśli kod został wpisany

Jeżeli użytkownik wpisał kod urządzenia, zatwierdził logowanie albo podejrzewa, że wykonał nietypową instrukcję Microsoft 365, zdarzenie trzeba traktować jako możliwe przejęcie tokenów. Sama zmiana hasła może być niewystarczająca, jeśli aktywne sesje i refresh tokeny nadal działają.

Zespół IT lub SOC powinien unieważnić sesje użytkownika, wymusić ponowne logowanie, sprawdzić logi Microsoft Entra ID, sign-in logs, non-interactive sign-ins, użycie device code flow, aplikacje OAuth, Microsoft Authentication Broker, dostęp do Microsoft Graph i nietypowe działania w poczcie. Należy sprawdzić reguły skrzynki, przekierowania, pobrania plików, dostęp do SharePoint i OneDrive oraz możliwość wysyłania dalszego phishingu z przejętego konta.

Jeżeli ofiarą była osoba z dostępem administracyjnym, finansowym, HR albo zarządowym, zakres analizy powinien być szerszy. Przejęcie tokenu takiego konta może prowadzić do BEC, czyli business email compromise, dostępu do dokumentów, obserwowania korespondencji i przygotowania bardziej precyzyjnych ataków na kolejne osoby.

Co powinna zmienić organizacja

Organizacja powinna ograniczyć lub zablokować device code flow tam, gdzie nie jest potrzebny. W wielu firmach użytkownicy końcowi nie mają uzasadnionej potrzeby korzystania z takiego przepływu. Microsoft Conditional Access pozwala kontrolować wybrane przepływy uwierzytelniania, a w środowiskach Microsoft 365 warto rozważyć polityki ograniczające ten mechanizm do zatwierdzonych przypadków.

Drugim elementem jest kontrola zgód OAuth i aplikacji. Użytkownicy nie powinni swobodnie nadawać szerokich uprawnień aplikacjom, a po incydencie trzeba sprawdzać nie tylko hasła, ale też tokeny, sesje, zgody, reguły pocztowe i nowe urządzenia.

Trzecim elementem jest ćwiczenie. W testach phishingowych dla firm device code phishing powinien być osobnym scenariuszem dla organizacji korzystających z Microsoft 365. Można go odtworzyć w kontrolowany sposób bez przejmowania kont, ucząc użytkowników, że prawdziwy portal logowania nie kończy analizy, jeśli proces zaczął się od nieoczekiwanej wiadomości.

Wniosek

Device code phishing pokazuje, że phishing tożsamościowy przesuwa się z haseł na tokeny, kody i legalne przepływy uwierzytelniania. Dla użytkownika najważniejsza zasada jest konkretna: nie wpisuj kodu urządzenia, nie skanuj QR i nie potwierdzaj logowania, jeżeli instrukcja przyszła z nieoczekiwanego maila, PDF-a, wiadomości głosowej albo linku.

Dla firmy to test dojrzałości ochrony tożsamości. Skuteczna obrona wymaga kontroli Entra ID, ograniczenia niepotrzebnych przepływów OAuth, monitorowania sesji i regularnego ćwiczenia scenariuszy, w których użytkownik nie podaje hasła, ale mimo to może oddać dostęp do konta.