Nowy phishing przejmuje konta Microsoft 365. Uwierzytelnianie dwuskładnikowe już nie wystarcza

Pracownik dostaje wiadomość o fakturze, zaproszeniu na spotkanie albo dokumencie do podpisu. Link prowadzi go do strony, która prosi o podanie krótkiego kodu i przekierowuje na prawdziwy portal logowania Microsoftu.

Nie ma literówki w adresie, nie ma podrobionego formularza, nie ma wykradania hasła. Jest za to pułapka: kod należy do urządzenia cyberprzestępcy. Gdy użytkownik go zatwierdza, sam autoryzuje cudzą sesję i otwiera drogę do firmowej poczty, plików oraz Teams.

Taki schemat, określany jako device code phishing, wykorzystuje legalny mechanizm logowania Microsoft Entra ID. Mechanizm został stworzony z myślą o urządzeniach, które nie mają wygodnej klawiatury lub przeglądarki - na przykład sprzęcie konferencyjnym, ekranach informacyjnych, drukarkach czy telewizorach. Użytkownik ma zalogować się na drugim urządzeniu i wpisać wyświetlony kod. W ataku kod nie pochodzi jednak od zaufanego urządzenia należącego do firmy, lecz z sesji rozpoczętej przez przestępcę.[1]

To zmienia stary katalog ostrzeżeń przed phishingiem. Sprawdzanie domeny nadal ma sens, ale w tym przypadku nie wystarczy. Adres microsoft.com/devicelogin może być prawidłowy, a proces logowania - prawdziwy. Fałsz zaczyna się wcześniej: w wiadomości, która przekonuje odbiorcę, że ma pilnie zatwierdzić dostęp do dokumentu lub usługi.

Prawdziwa strona, cudza sesja

Microsoft opisuje ten mechanizm wprost. Atakujący rozpoczyna proces autoryzacji urządzenia i pobiera kod. Następnie przesyła go ofierze, zwykle wraz z profesjonalnie przygotowaną przynętą: rzekomą fakturą, dokumentem w SharePoincie, ostrzeżeniem o wygaśnięciu hasła, zaproszeniem do kalendarza albo prośbą o podpis. Ofiara wpisuje kod na prawdziwej stronie Microsoftu, loguje się i potwierdza MFA. W tym momencie nie uzyskuje dostępu do dokumentu. Zatwierdza sesję urządzenia napastnika.[2]

Po udanym logowaniu przestępca otrzymuje token dostępu, a w wielu scenariuszach także token odświeżania. To właśnie tokeny, a nie wykradzione hasło, są celem operacji. Mogą pozwolić na dostęp do Outlooka, OneDrive’a, SharePointa i Teams bez kolejnego pytania o hasło czy kod jednorazowy - aż do ich wygaśnięcia albo unieważnienia przez administratora.[2][3]

Microsoft zaobserwował w 2026 r. kampanię, w której przestępcy automatyzowali cały łańcuch ataku. Generatywna AI służyła im do tworzenia przekonujących, dopasowanych do roli ofiary wiadomości, a kody urządzeń były generowane dopiero po kliknięciu w link. To rozwiązywało problem krótkiej ważności kodu i zwiększało szansę, że pozostanie aktywny w chwili logowania.[2]

EvilTokens obniża próg wejścia

Jednym z narzędzi wykorzystywanych w tym modelu jest EvilTokens - zestaw phishingowy sprzedawany jako usługa. Analitycy Sekoia opisali go w marcu 2026 r. jako narzędzie dostępne przez boty na Telegramie, zawierające gotowe strony przynęt, automatyzację przejęcia tokenów oraz funkcje przydatne w oszustwach typu business email compromise, czyli wyłudzeniach prowadzonych z przejętej firmowej skrzynki.[4]

Według analizy Sekoia strony EvilTokens krążyły co najmniej od połowy lutego 2026 r. i podszywały się między innymi pod Adobe Acrobat, DocuSign, SharePoint, OneDrive, komunikaty o kwarantannie poczty czy zaproszenia do kalendarza. Ich konstrukcja jest prostsza niż w klasycznym phishingu typu adversary-in-the-middle, bo nie wymaga imitowania całej strony logowania Microsoftu. Wystarczy nakłonić użytkownika do zatwierdzenia kodu urządzenia na autentycznej stronie.[4]

Trzeba jednak rozdzielić dwie kwestie, które w komunikacji o zagrożeniu bywają łączone. Microsoft opisał w kwietniu 2026 r. konkretną, wspieraną przez AI kampanię device code phishing, ale w swoim materiale nie przypisał jej wprost EvilTokens. To podobna technika i podobny kierunek rozwoju przestępczych usług, nie zaś automatycznie ten sam operator lub ta sama infrastruktura.[2][4]

MFA nie zostało złamane

Nagłówek mówiący, że atak „omija MFA”, wymaga doprecyzowania. Uwierzytelnianie wieloskładnikowe nie zostaje tu przełamane metodą techniczną. Ofiara przechodzi je poprawnie, ale robi to w błędnym kontekście: potwierdza dostęp dla urządzenia, którego sama nie uruchomiła.

To istotna różnica. MFA nadal pozostaje konieczną ochroną przed masowym przejmowaniem kont za pomocą skradzionych haseł. Nie jest jednak wystarczającą odpowiedzią na phishing, w którym użytkownik zostaje namówiony do zatwierdzenia operacji przygotowanej przez napastnika. Microsoft wskazuje, że w device code flow sesja urządzenia inicjującego żądanie nie jest silnie związana z kontekstem, w którym użytkownik kończy uwierzytelnienie. Ta właściwość jest użyteczna dla legalnych urządzeń z ograniczonym interfejsem, ale stwarza pole do nadużycia.[2]

Federalne Biuro Śledcze Stanów Zjednoczonych ostrzegło w maju przed inną usługą phishing-as-a-service - Kali365 - wykorzystującą ten sam wektor. FBI podkreśliło, że atak może zapewnić przestępcy dostęp do kont Microsoft 365 bez przechwytywania danych logowania, a uzyskane tokeny dają dostęp do usług takich jak Outlook, Teams i OneDrive.[3]

Największe ryzyko: poczta firmowa i oszustwa BEC

Przejęta skrzynka pocztowa pozwala nie tylko czytać korespondencję. Przestępca może obserwować rozliczenia, relacje z kontrahentami i rytm pracy działu finansowego. Może też tworzyć reguły skrzynki, które przekierują wiadomości, ukryją odpowiedzi albo wyciszą ostrzeżenia. Microsoft zaobserwował w podobnych kampaniach zarówno eksfiltrację wiadomości, jak i tworzenie złośliwych reguł pocztowych zapewniających trwałość dostępu.[2]

W takiej sytuacji rośnie ryzyko BEC. To oszustwo wykorzystujące przejętą lub podszywającą się pod zaufaną firmową skrzynkę do zmiany numeru rachunku na fakturze, wymuszenia pilnego przelewu albo przekonania kontrahenta do ujawnienia danych. W przeciwieństwie do masowego spamu BEC jest wiarygodne, bo może wychodzić z prawdziwego konta, w prawdziwym wątku korespondencji.

Jak ograniczyć ryzyko w firmie

Pierwszym krokiem powinien być audyt użycia device code flow. Microsoft zaleca przeanalizowanie dzienników logowań i ustalenie, czy organizacja rzeczywiście potrzebuje tego trybu. Jeżeli nie, należy go zablokować polityką Conditional Access. Jeżeli jest potrzebny - dopuścić wyłącznie w jasno opisanych, ograniczonych scenariuszach, na przykład dla konkretnych urządzeń i kontrolowanej lokalizacji sieciowej.[5]

Takiej zmiany nie warto wprowadzać w ciemno. Microsoft rekomenduje rozpoczęcie od trybu Report-only, który pokazuje w dziennikach, jakie logowania zostałyby zablokowane, lecz nie przerywa pracy użytkowników. Dopiero po sprawdzeniu skutków można uruchomić blokadę. Z zakresu polityki trzeba rozważnie wyłączyć konta awaryjne, używane do odzyskiwania administracji w razie błędnej konfiguracji.[6]

Drugim działaniem jest kontrola logowań i urządzeń. Administratorzy powinni zwracać uwagę na zdarzenia device code flow, nieznane urządzenia, nietypowe adresy IP, niestandardowe lokalizacje oraz nagłe reguły przekierowania w skrzynkach. Warto także rozważyć blokowanie mechanizmu authentication transfer, jeśli firma nie potrzebuje przenoszenia potwierdzonego logowania między komputerem a telefonem. To osobny przepływ, ale również wymaga oceny ryzyka.[3][5]

Z perspektywy pracownika zasada jest prosta: nie wpisuje się kodu urządzenia, którego samemu się nie wygenerowało podczas świadomie rozpoczętej konfiguracji konkretnego sprzętu. Link do prawdziwej strony Microsoftu nie uwiarygadnia niespodziewanej prośby o taki kod. Podejrzaną wiadomość należy przekazać zespołowi IT lub bezpieczeństwa, a nie „sprawdzać”, wykonując krok wskazany przez nadawcę.

Co zrobić po podejrzeniu przejęcia

Samo zmienienie hasła może nie wystarczyć, gdy przestępca uzyskał już token odświeżania. Firma powinna traktować zdarzenie jak pełne przejęcie konta: zablokować nowe logowania do czasu analizy, unieważnić tokeny odświeżania i aktywne sesje, sprawdzić urządzenia zarejestrowane w Entra ID, reguły skrzynki, przekierowania, delegacje oraz ostatnią aktywność w poczcie i plikach.[2][7]

Microsoft udostępnia w Entra ID procedurę awaryjnego odebrania dostępu użytkownikowi, obejmującą blokadę logowań i unieważnienie tokenów odświeżania.[7] W praktyce reakcję powinien prowadzić administrator lub zespół bezpieczeństwa, z zachowaniem dowodów: oryginalnej wiadomości phishingowej wraz z nagłówkami, czasu zdarzenia, adresów IP, informacji o urządzeniach i historii aktywności.

W tym ataku najsłabszym punktem nie jest wadliwy adres internetowy ani samo hasło. Jest nim zgoda wyrwana w niewłaściwej chwili. Dlatego ochrona kont Microsoft 365 musi dziś łączyć MFA z kontrolą mechanizmów logowania, analizą tokenów i szkoleniem, które uczy nie tylko rozpoznawać fałszywe strony, lecz także nie zatwierdzać autentycznych żądań, których użytkownik sam nie rozpoczął.

 

 

Pobierz ebook "Wielki ranking agencji marketingowych 2026 roku i e-book o trendach w promocji w sieci"