Kali365 i device code phishing w Microsoft 365

TL;DR

Device code phishing wykorzystuje legalny przepływ logowania przeznaczony między innymi dla telewizorów, drukarek i innych urządzeń z ograniczonym interfejsem. Napastnik inicjuje sesję, pobiera krótki kod, a następnie przekonuje pracownika, aby wpisał go na prawdziwej stronie Microsoft. Użytkownik może poprawnie podać hasło i przejść wieloskładnikowe uwierzytelnianie, lecz w praktyce zatwierdza dostęp dla sesji kontrolowanej przez przestępcę.

Kaspersky opisał kampanię prowadzoną od początku kwietnia do połowy maja 2026 roku. Wiadomości udawały korespondencję kancelarii prawnej lub potwierdzenie zamówienia. Atak prowadził przez zabezpieczony hasłem plik PDF, przekierowania i strony z CAPTCHA, a kończył się wpisaniem kodu na oficjalnym portalu Microsoft. Po udanej autoryzacji atakujący mógł uzyskać tokeny pozwalające na dostęp do poczty, OneDrive i Teams.

Dla użytkownika reguła jest konkretna: kod urządzenia wpisuje się tylko wtedy, gdy samemu rozpoczęło się logowanie na znanym urządzeniu, które jest widoczne i pozostaje pod kontrolą. Kod otrzymany w wiadomości, dokumencie, komunikatorze lub rozmowie z rzekomym wsparciem należy potraktować jako możliwy phishing.

Czym jest device code flow i dlaczego istnieje

Device code flow, czyli przepływ autoryzacji kodem urządzenia, jest częścią OAuth 2.0. Powstał dla urządzeń, na których trudno wpisać login, hasło i drugi składnik uwierzytelniania. Dotyczy to na przykład telewizorów, drukarek, terminali konferencyjnych lub urządzeń Internetu Rzeczy.

W prawidłowym scenariuszu urządzenie wyświetla krótki kod i adres strony. Użytkownik otwiera tę stronę na telefonie lub komputerze, wpisuje kod i potwierdza dostęp. Po udanej autoryzacji urządzenie otrzymuje token dostępu. Może także otrzymać token odświeżania, który pozwala odnawiać dostęp bez ponownego przechodzenia pełnego logowania.

Problem nie wynika z błędu samego protokołu. Powstaje wtedy, gdy to napastnik inicjuje żądanie i przekazuje kod ofierze. Użytkownik widzi prawdziwy portal Microsoft, ale nie autoryzuje własnego telewizora, drukarki ani aplikacji. Zatwierdza sesję przygotowaną poza swoim urządzeniem.

To rozwinięcie klasycznego phishingu. Przestępca nadal manipuluje decyzją człowieka, lecz nie musi kopiować strony logowania ani przechwytywać hasła na własnym serwerze.

Jak wygląda atak krok po kroku

Pierwszy etap przypomina zwykłą wiadomość biznesową. Pretekstem może być umowa, pozew, faktura, zamówienie, dokument z SharePoint, plik do podpisu albo powiadomienie głosowe. W kampanii opisanej przez Kaspersky wiadomość udawała zawiadomienie kancelarii prawnej i zawierała chroniony hasłem plik PDF. W późniejszym wariancie wykorzystano link prowadzący przez legalną platformę do tworzenia diagramów.

Po otwarciu dokumentu użytkownik trafiał do strony udającej portal prawny lub panel dokumentów. Kilka ekranów i CAPTCHA miało utrudnić analizę automatyczną oraz nadać procesowi pozory formalności. Dopiero na końcu pojawiał się krótki kod przedstawiony jako jednorazowa wartość potrzebna do otwarcia pliku.

Kod nie był hasłem użytkownika. Napastnik pobrał go wcześniej z usługi Microsoft dla własnej sesji. Kliknięcie mogło skopiować kod do schowka i otworzyć prawdziwy portal Microsoft. Gdy ofiara wklejała kod, logowała się i przechodziła MFA, serwer Microsoft prawidłowo kończył autoryzację. Tokeny trafiały jednak do aplikacji lub procesu kontrolowanego przez atakującego.

Dlaczego prawdziwa domena Microsoft nie rozstrzyga sprawy

Sprawdzanie domeny nadal ma sens. Chroni przed wieloma fałszywymi stronami i literówkami w adresach. W tym scenariuszu nie wystarcza, ponieważ końcowe logowanie rzeczywiście może odbywać się w domenie Microsoft.

Domena odpowiada na pytanie, kto obsługuje stronę. Nie odpowiada na pytanie, kto rozpoczął proces i do jakiej sesji należy kod. Jeżeli instrukcję, kod oraz pretekst dostarczył nadawca nieoczekiwanej wiadomości, prawdziwy ekran logowania nie naprawia błędnego kontekstu.

Podobny problem występuje w innych kampaniach wykorzystujących legalne usługi chmurowe i przejęcie sesji. Opisujemy go także w analizie phishingu Microsoft 365 z użyciem platformy Railway oraz w materiale o phishingu omijającym MFA w modelu AiTM. Mechanizmy techniczne są różne, ale decyzja użytkownika często zapada w pozornie wiarygodnym procesie.

Gdzie w tym ataku znajduje się MFA

Device code phishing nie dowodzi, że MFA jest zbędne. Wieloskładnikowe uwierzytelnianie nadal blokuje wiele prób przejęcia kont. W tym wariancie przestępca nie musi jednak kraść drugiego składnika. Przekonuje użytkownika, aby ten sam wykonał poprawne uwierzytelnienie dla cudzej sesji.

Z perspektywy platformy użytkownik podał prawidłowe dane i spełnił wymagane warunki. Jeżeli polityki dostępu dopuszczają device code flow, proces może zakończyć się wydaniem tokenów. Dlatego samo stwierdzenie „mamy MFA” nie zamyka ryzyka związanego z tożsamością w chmurze.

Obrona wymaga połączenia kilku warstw: ograniczenia ryzykownych przepływów, kontroli urządzeń, monitoringu logowań, szybkiego unieważniania sesji oraz przygotowania użytkowników do rozpoznania nietypowej prośby o kod.

Kali365 i upowszechnianie gotowych zestawów phishingowych

Kali365 jest opisywany jako phishing-as-a-service, czyli PhaaS. Operator udostępnia gotową infrastrukturę, strony, automatyzację, panele i mechanizmy śledzenia statusu ofiary. Taki model obniża próg wejścia dla osób, które nie potrafią samodzielnie przygotować całego łańcucha ataku.

Arctic Wolf opisał Kali365 jako zestaw nadużywający OAuth Device Authorization Grant do przejmowania tokenów Microsoft 365. Badacze wskazali też rozwój infrastruktury na kolejne marki i usługi, w tym Okta SSO, Xerox DocuShare oraz inne platformy pocztowe i chmurowe.

Kampania opisana przez Kaspersky nie musi być tym samym przedsięwzięciem. Ma jednak ten sam rdzeń: kod dostarczony przez napastnika, oficjalny portal tożsamości i tokeny wydane po prawidłowym uwierzytelnieniu. To ważniejsze niż nazwa konkretnego zestawu, ponieważ podobny schemat może zostać wdrożony przez wielu operatorów.

Proofpoint obserwował w 2026 roku wzrost liczby odmian device code phishingu oraz przechodzenie części operatorów z zestawów adversary-in-the-middle do nadużywania kodów urządzenia. Dla organizacji oznacza to, że nie należy traktować tej techniki jako jednorazowej kampanii.

Sygnały, które powinien rozpoznać użytkownik

Najbardziej charakterystyczny sygnał to prośba o skopiowanie lub wklejenie kodu urządzenia w celu otwarcia dokumentu, odsłuchania wiadomości albo potwierdzenia dostępu. Szczególnie podejrzany jest proces, którego użytkownik sam nie rozpoczął na konkretnym urządzeniu.

Ryzyko rośnie, gdy wiadomość:

• prowadzi przez kilka przekierowań lub ekranów weryfikacyjnych,
• zawiera plik PDF zabezpieczony hasłem przekazanym w tej samej wiadomości,
• używa presji związanej z terminem, umową, płatnością lub blokadą dostępu,
• każe skopiować kod do schowka i przejść do strony Microsoft,
• przedstawia kod urządzenia jako jednorazowe hasło do dokumentu,
• wymaga zalogowania się na konto, na które przyszła wiadomość,
• kończy się prawidłowym MFA, mimo że użytkownik nie konfiguruje żadnego urządzenia.

Nie należy analizować takiego procesu przez wykonywanie kolejnych poleceń. Bezpieczniejszą reakcją jest przerwanie działania i zgłoszenie wiadomości do IT lub Security wraz z linkiem, załącznikiem i opisem wykonanych kroków.

Co powinny zrobić IT, Security i SOC

Pierwszym zadaniem jest ustalenie, czy organizacja rzeczywiście potrzebuje device code flow. Microsoft zaleca dążyć do możliwie szerokiej blokady tego przepływu. Przed włączeniem polityki warto przeanalizować dotychczasowe użycie i uruchomić Conditional Access w trybie report-only. Pozwala to wykryć legalne zależności, zanim polityka zacznie blokować pracę.

Jeżeli przepływ jest potrzebny, wyjątki powinny być wąskie, udokumentowane i regularnie przeglądane. Mogą dotyczyć określonych kont zasobowych, starszych narzędzi lub zatwierdzonych urządzeń. Ogólne dopuszczenie dla wszystkich użytkowników zwiększa powierzchnię ataku.

Drugim zadaniem jest monitoring. Zespół powinien umieć filtrować logowania związane z device code flow i analizować je według prostego modelu: kto się logował, jaką aplikacją i do jakiego zasobu. Szczególnej uwagi wymagają:

• logowania z nietypowych adresów IP lub lokalizacji,
• użycie przepływu przez osobę, która zwykle z niego nie korzysta,
• dostęp do nowej aplikacji albo zasobu bez uzasadnienia biznesowego,
• szybkie działania w Outlooku, OneDrive, SharePoint, Teams lub Microsoft Graph,
• rejestracja nowego urządzenia lub metody uwierzytelniania,
• tworzenie reguł skrzynki, przekierowań i masowe odczyty wiadomości,
• pobieranie wielu plików krótko po pierwszym logowaniu.

Trzecim zadaniem jest połączenie detekcji tożsamości z procedurą reakcji. Alert nie może kończyć się na sprawdzeniu, że hasło nie zostało wpisane na fałszywej stronie. W tym modelu właśnie brak klasycznej kradzieży hasła jest częścią mechanizmu.

Czwartym elementem jest przygotowanie pracowników i helpdesku. Program security awareness powinien wyjaśniać różnicę między prawdziwą stroną a prawidłowym kontekstem autoryzacji. Helpdesk nie powinien prowadzić użytkownika przez nieoczekiwany proces tylko dlatego, że ekran wygląda poprawnie.

W testach phishingowych dla firm warto mierzyć nie tylko kliknięcie. Istotne są przerwanie procesu przed wpisaniem kodu, zgłoszenie incydentu oraz przekazanie informacji, które umożliwiają szybką analizę kampanii.

Co zrobić, jeśli to już się stało

Jeżeli użytkownik wpisał kod urządzenia i zakończył logowanie, należy traktować konto jako potencjalnie przejęte. Reakcja powinna rozpocząć się od kontaktu z IT lub Security znanym kanałem. Nie należy czekać na widoczne skutki w poczcie.

Zespół reagujący powinien:

1. Zablokować możliwość nowych logowań dla konta, jeżeli wymaga tego ocena ryzyka.
2. Unieważnić aktywne sesje i odwołać tokeny odświeżania w Microsoft Entra ID.
3. Sprawdzić logi interaktywne i nieinteraktywne, aplikację, zasób, adresy IP, urządzenia oraz wynik Conditional Access.
4. Zweryfikować zarejestrowane urządzenia, metody MFA, dane odzyskiwania i nowe poświadczenia.
5. Przejrzeć zgody OAuth i aplikacje, które uzyskały dostęp do danych użytkownika.
6. Sprawdzić reguły skrzynki, przekierowania, wiadomości wysłane, usunięte i oznaczone jako przeczytane.
7. Zbadać aktywność w OneDrive, SharePoint, Teams oraz innych aplikacjach powiązanych z tożsamością.
8. Ustalić, czy z przejętej skrzynki wysłano kolejne wiadomości do pracowników, klientów lub dostawców.
9. Zmienić hasło, jeżeli mogło zostać ujawnione, pamiętając, że sama zmiana hasła nie zastępuje odwołania sesji i tokenów.
10. Zachować wiadomość, plik, adresy, kod, czas zdarzenia i opis działań użytkownika jako materiał do analizy.

Przy koncie uprzywilejowanym, finansowym, zarządczym lub administracyjnym zakres dochodzenia powinien objąć także zmiany konfiguracji, dostęp do danych wrażliwych i działania wykonane w innych usługach SaaS.

Jak przełożyć ten scenariusz na prostą zasadę firmową

Instrukcja dla pracownika nie powinna sprowadzać się do rozpoznawania złej domeny. Powinna opisywać moment decyzji:

Kod urządzenia wpisuj tylko wtedy, gdy sam rozpocząłeś logowanie na znanym urządzeniu, które masz przed sobą. Nie używaj kodu przesłanego w e-mailu, dokumencie, komunikatorze ani rozmowie telefonicznej.

Ta zasada obejmuje kampanie Kali365, wariant opisany przez Kaspersky i kolejne zestawy wykorzystujące ten sam przepływ. Prawdziwy portal Microsoft może być bezpiecznym elementem infrastruktury, ale nadal uczestniczyć w procesie rozpoczętym przez przestępcę.

Organizacja, która chce sprawdzić ustawienia Entra ID, scenariusze testowe i procedurę reakcji na przejęcie sesji, może skontaktować się z PHISHLY.