Kali365 i phishing kodem urządzenia w Microsoft 365

TL;DR

Kali365 pokazuje, że phishing Microsoft 365 nie musi kraść hasła ani kodu MFA. Atak może wykorzystać legalny przepływ OAuth dla urządzeń, które nie obsługują klasycznego logowania. Użytkownik wpisuje kod na prawdziwej stronie Microsoft, a atakujący otrzymuje tokeny dostępu do konta.

To szczególnie groźne, bo część procesu wygląda wiarygodnie. Strona logowania może być prawdziwa, MFA może zostać poprawnie wykonane, a mimo to użytkownik autoryzuje sesję kontrolowaną przez napastnika. Arctic Wolf opisał, że Kali365 rozwinął się z kampanii Microsoft 365 w szerszy model phishing-as-a-service, obejmujący między innymi Okta SSO, Xerox DocuShare, LiveDrive, GMX, wzorce nazw AWS oraz MAX Messenger.

Dla firm korzystających z Microsoft 365, Entra ID, Okta i wielu aplikacji SaaS to ważny sygnał. Awareness powinien obejmować nie tylko fałszywe strony logowania, ale też prośby o wpisanie kodu urządzenia, nietypowe instrukcje autoryzacji, udostępnianie dokumentów i procesy, w których prawdziwa domena dostawcy nie oznacza bezpiecznego całego łańcucha.

Kod urządzenia jako przynęta

Device code flow, czyli przepływ autoryzacji kodem urządzenia, został zaprojektowany dla urządzeń, na których trudno wygodnie wpisać login i hasło. Typowym przykładem są telewizory, drukarki, urządzenia IoT albo inne systemy bez pełnej przeglądarki i klawiatury.

W prawidłowym scenariuszu urządzenie pokazuje krótki kod. Użytkownik otwiera stronę dostawcy tożsamości na innym urządzeniu, wpisuje kod i autoryzuje dostęp. Problem zaczyna się wtedy, gdy kod nie pochodzi z urządzenia użytkownika, tylko z sesji zainicjowanej przez atakującego.

W takim ataku przestępca przygotowuje stronę lub wiadomość, która wygląda jak udostępniony dokument, OneDrive, SharePoint albo inny proces firmowy. Ofiara widzi instrukcję, aby wejść na prawdziwą stronę Microsoft i wpisać podany kod. Po wykonaniu tej czynności użytkownik nie przekazuje hasła atakującemu, ale autoryzuje jego sesję.

To dlatego zwykłe szkolenie o fałszywych domenach nie wystarczy. Użytkownik może wejść na prawdziwą domenę Microsoft i nadal uczestniczyć w ataku.

Dlaczego MFA nie zamyka problemu

Wieloskładnikowe uwierzytelnianie, czyli MFA, jest nadal potrzebne. Kali365 nie jest argumentem przeciw MFA. Jest argumentem przeciw traktowaniu MFA jako jedynej odpowiedzi na phishing tożsamościowy.

W device code phishingu ofiara przechodzi prawidłową autoryzację. Z perspektywy dostawcy tożsamości wygląda to jak użytkownik, który poprawnie potwierdził dostęp. Atakujący otrzymuje access token i refresh token, czyli token dostępu oraz token pozwalający odnawiać dostęp bez ponownego logowania, dopóki pozwalają na to polityki środowiska.

To przesuwa problem z hasła na sesję. Jeśli SOC monitoruje tylko nieudane logowania albo klasyczne wpisanie hasła na fałszywej stronie, może przeoczyć moment, w którym użytkownik sam zatwierdził dostęp. Po przejęciu tokenów atakujący może czytać pocztę, przeglądać pliki, tworzyć reguły skrzynki, sprawdzać Teams lub OneDrive i przygotowywać kolejne działania.

Właśnie dlatego temat dobrze łączy się z phishingiem OAuth opisywanym przy ConsentFix v3. W obu przypadkach nie chodzi o proste wpisanie hasła w złym miejscu, lecz o nadużycie legalnego procesu autoryzacji.

Kali365 jako usługa phishingowa

Kali365 jest opisywany jako phishing-as-a-service, czyli PhaaS. To model, w którym mniej techniczni atakujący mogą korzystać z gotowej infrastruktury, paneli, szablonów i automatyzacji. Nie muszą samodzielnie budować całego łańcucha ataku.

FBI ostrzegało, że Kali365 daje dostęp do AI-generowanych przynęt, automatycznych szablonów kampanii, paneli śledzenia ofiar w czasie rzeczywistym i możliwości przejmowania tokenów OAuth. Arctic Wolf opisał także wielodzierżawczy charakter takiej infrastruktury, panel C2 oraz rozszerzenie działań na wiele marek i usług.

To ważne dla obrony, bo PhaaS skraca drogę od pomysłu do kampanii. Jeżeli gotowy zestaw pozwala podszyć się pod dokument, przygotować kod, śledzić status ofiary i przejąć token, liczba osób zdolnych do uruchomienia takiego ataku rośnie.

Z perspektywy użytkownika nazwa Kali365 nie ma większego znaczenia. Ma znaczenie to, że ktoś może poprosić o wpisanie kodu do prawdziwego logowania, a całość będzie wyglądała jak zwykły dostęp do dokumentu.

Ekspansja poza Microsoft 365

Najciekawszy element najnowszych ustaleń Arctic Wolf to rozszerzenie infrastruktury Kali365 na wiele marek i usług. Badacze opisali klaster 126 hostów, które obsługiwały ten sam wzorzec zestawu phishingowego i podszywały się między innymi pod Microsoft Outlook, Microsoft Live, Okta SSO, Xerox DocuShare, LiveDrive, GMX, Mail.ru, Yandex Disk, Odnoklassniki oraz wzorce nazw kojarzące się z AWS.

To pokazuje, że przestępcy nie myślą już wyłącznie kategorią jednej kampanii i jednej marki. Myślą kategorią infrastruktury, którą można przepinać między usługami. Gdy jedna przynęta traci skuteczność, można użyć innej. Gdy jedna grupa użytkowników jest odporna na OneDrive, można spróbować komunikatora, SSO albo systemu dokumentów.

W przypadku MAX Messenger Arctic Wolf opisał także przejmowanie kont przez fałszywy proces odbioru nagrody. Ofiara podawała numer telefonu, jednorazowy kod i ewentualne hasło 2FA, a dane trafiały do atakującego przez bota Telegram. Ten wariant jest konsumencki, ale pokazuje ten sam wzorzec: prawdziwy kod z prawdziwej usługi zostaje użyty w fałszywym procesie.

Dla polskich firm wniosek jest praktyczny. Dziś przynętą może być Microsoft 365. Jutro Okta, Google Workspace, CRM, system HR, elektroniczny obieg dokumentów, portal dostawcy albo komunikator używany w projekcie.

Polski kontekst dla Entra ID, Okta i SaaS

Wiele polskich organizacji używa Microsoft 365 i Entra ID jako podstawy pracy biurowej. Część używa Okta, Google Workspace albo innych dostawców tożsamości. Dla użytkownika te różnice techniczne są często niewidoczne. Widzi powiadomienie o dokumencie, prośbę o weryfikację, kod, ekran logowania i komunikat, że dostęp zostanie przyznany po potwierdzeniu.

Ten scenariusz może uderzyć w działy finansowe, HR, sprzedaż, zarząd, IT i administrację. Wystarczy wiarygodny pretekst: nowy dokument, umowa, faktura, plik z audytu, zaproszenie do projektu, formularz dostawcy albo pilne udostępnienie zasobu.

Problem jest szczególnie ważny w organizacjach objętych wymaganiami NIS2, DORA, ISO 27001 albo wewnętrznymi regulacjami bezpieczeństwa. Przejęcie tokenu nie wygląda jak klasyczne włamanie do hasła. To może być legalnie wyglądająca sesja, która uzyskuje dostęp do poczty, plików i aplikacji SaaS.

Dlatego polityki tożsamości i program awareness muszą mówić jednym językiem. Użytkownik powinien wiedzieć, że nie wpisuje kodu urządzenia, jeśli nie inicjował procesu na własnym, znanym urządzeniu. Administrator powinien wiedzieć, gdzie taki proces widać w logach.

Co powinien zrobić użytkownik

Najważniejsza zasada dla użytkownika brzmi: nie wpisuj kodu logowania tylko dlatego, że instrukcja wygląda technicznie i prowadzi do prawdziwej strony Microsoft. Kod urządzenia ma sens wtedy, gdy sam inicjujesz logowanie na konkretnym urządzeniu, które widzisz i rozumiesz.

Jeżeli wiadomość z dokumentem, linkiem albo załącznikiem prosi o wejście na stronę logowania i wpisanie kodu, proces trzeba przerwać. To samo dotyczy rozmowy telefonicznej z rzekomym helpdeskiem, który tłumaczy, że kod jest potrzebny do naprawy konta, wdrożenia MFA albo potwierdzenia dostępu.

Warto też zwracać uwagę na nietypowe sformułowania: skopiuj kod, wklej kod, otwórz stronę w nowym oknie, kliknij allow, zatwierdź urządzenie, przejdź przez weryfikację, aby zobaczyć dokument. Te instrukcje mogą być częścią normalnego procesu, ale w nieoczekiwanym kontekście są sygnałem ostrzegawczym.

Zgłoszenie takiej wiadomości jest równie ważne jak zgłoszenie klasycznego phishingu. Jeden kod może ujawnić kampanię wymierzoną w wiele osób w firmie.

Co powinny zrobić IT, Security i SOC

Pierwszym krokiem jest audyt użycia device code flow. Jeżeli organizacja nie potrzebuje tego mechanizmu, warto rozważyć jego blokadę lub silne ograniczenie przez Conditional Access. Jeśli jest potrzebny, trzeba określić wyjątki i monitorować ich użycie.

Drugim krokiem jest widoczność w logach tożsamości. SOC powinien umieć rozpoznać nietypowe użycie OAuth device authorization flow, nowe sesje, tokeny, logowania z nietypowych lokalizacji, dostęp do Microsoft Graph, szybkie przejścia do SharePoint, OneDrive, Outlook i Teams oraz tworzenie reguł skrzynki po udanym dostępie.

Trzecim krokiem jest reakcja po przejęciu tokenu. Sama zmiana hasła może nie wystarczyć. Trzeba unieważnić sesje, odwołać refresh tokeny, sprawdzić metody MFA, nowe urządzenia, zgody aplikacji OAuth i reguły pocztowe.

Czwarty element to ćwiczenie helpdesku. Jeżeli użytkownik dzwoni z pytaniem o kod lub helpdesk otrzymuje prośbę o pomoc przy logowaniu, procedura powinna prowadzić do weryfikacji kanałem niezależnym, a nie do szybkiego przeprowadzenia użytkownika przez podejrzany proces.

W testach phishingowych dla firm taki scenariusz dobrze sprawdza, czy pracownicy rozumieją różnicę między prawdziwą stroną logowania a fałszywym procesem, który tę stronę wykorzystuje.

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

Jeżeli użytkownik wpisał kod urządzenia i przeszedł logowanie, należy traktować sprawę jak możliwe przejęcie sesji. Nie wystarczy odpowiedź: hasło nie zostało wpisane na fałszywej stronie. W tym modelu właśnie o to chodzi, że hasło mogło nie zostać skradzione.

Zespół bezpieczeństwa powinien unieważnić aktywne sesje, odwołać refresh tokeny, sprawdzić logowania, urządzenia, aplikacje, zgody OAuth, reguły pocztowe i dostęp do plików. W Microsoft 365 szczególnie ważne są Outlook, SharePoint, OneDrive i Teams.

Jeżeli konto ma dostęp uprzywilejowany albo należy do osoby z finansów, HR, zarządu, IT lub administracji systemami, zakres analizy powinien objąć działania wykonane po autoryzacji. Trzeba sprawdzić pobrania plików, wysyłkę wiadomości, masowe odczyty, eksporty, zmiany w skrzynce i dostęp do aplikacji SaaS.

Użytkownik powinien zachować wiadomość, link, załącznik, kod i kontekst rozmowy. Dla SOC te elementy pomagają ustalić, czy kampania dotyczyła jednej osoby, czy całej grupy.

Najważniejsza zasada

Kali365 pokazuje, że prawdziwa domena logowania nie gwarantuje bezpiecznego procesu. Jeśli to atakujący podaje kod, instrukcję i pretekst, użytkownik może autoryzować cudzą sesję, nawet przechodząc przez prawidłowe MFA.

Dlatego zasada powinna być konkretna: kod urządzenia wpisuj tylko wtedy, gdy sam uruchomiłeś logowanie na własnym, znanym urządzeniu. Każdy kod przysłany w wiadomości, dokumencie, rozmowie lub przez nieoczekiwany portal traktuj jak phishing tożsamościowy.