Microsoft rozbija EvilTokens – phishing oparty na device code uderzył w tysiące skrzynek Microsoft 365

Wprowadzenie do problemu / definicja

EvilTokens to usługa typu phishing-as-a-service, która wykorzystywała mechanizm OAuth 2.0 Device Authorization Flow do przejmowania dostępu do kont Microsoft 365. W odróżnieniu od klasycznych kampanii wyłudzających hasła, ten model nie wymagał bezpośredniego pozyskania poświadczeń od ofiary. Użytkownik logował się bowiem na legalnej stronie Microsoft, a atakujący uzyskiwał tokeny pozwalające na dalszy dostęp do skrzynki pocztowej i danych organizacyjnych.

Z perspektywy bezpieczeństwa to szczególnie niebezpieczny wariant ataku na tożsamość. Ofiara może nie zauważyć nic podejrzanego, ponieważ proces uwierzytelnienia przebiega z użyciem prawdziwego portalu logowania oraz często także z poprawnym użyciem MFA. Problem polega na tym, że zatwierdzany jest dostęp dla klienta kontrolowanego przez przestępcę.

W skrócie

Microsoft poinformował o rozbiciu infrastruktury EvilTokens, platformy powiązanej z przejęciem ponad 12 tysięcy skrzynek pocztowych w przeszło 10 tysiącach organizacji. Operacja została przeprowadzona przy wsparciu partnerów prywatnych i w oparciu o działania prawne w Stanach Zjednoczonych, a brytyjskie służby zatrzymały dwóch podejrzanych związanych ze sprawą.

EvilTokens wykorzystywał phishing oparty na device code przeciwko kontom Microsoft 365.
Ataki prowadziły do przejęcia tokenów sesyjnych zamiast haseł.
Platforma oferowała funkcje automatyzujące analizę skrzynek i przygotowanie oszustw BEC.
Skala kampanii wskazuje na uprzemysłowienie ataków na tożsamość w chmurze.

Kontekst / historia

Platforma została opisana publicznie w 2026 roku jako komercyjna usługa PhaaS nastawiona na kompromitację środowisk Microsoft 365. Jej model biznesowy znacząco obniżał próg wejścia dla cyberprzestępców zainteresowanych przejęciem skrzynek, oszustwami fakturowymi oraz kampaniami business email compromise.

Zamiast budować własne zaplecze techniczne, afilianci mogli korzystać z gotowych paneli administracyjnych, szablonów kampanii, infrastruktury wysyłkowej oraz narzędzi wspierających utrzymanie dostępu po skutecznym ataku. EvilTokens działał więc nie tylko jako pojedyncze narzędzie phishingowe, ale jako pełna usługa umożliwiająca przejście od initial access do finansowego nadużycia.

Istotnym wyróżnikiem platformy było połączenie klasycznego phishingu z funkcjami opartymi na sztucznej inteligencji. Taki model zwiększał skuteczność dalszego wykorzystania przejętej skrzynki, zwłaszcza w scenariuszach podszywania się pod pracowników, dostawców i partnerów biznesowych.

Analiza techniczna

Rdzeniem operacji był legalny mechanizm device code flow, przeznaczony pierwotnie dla urządzeń i aplikacji z ograniczonym interfejsem wejściowym. W prawidłowym zastosowaniu użytkownik otrzymuje kod, przechodzi do oficjalnego portalu logowania i autoryzuje urządzenie lub aplikację.

W kampaniach EvilTokens proces był nadużywany. Ofiara otrzymywała wiadomość phishingową z biznesowym pretekstem, takim jak faktura, dokument do akceptacji, zapytanie ofertowe lub współdzielony plik. Po kliknięciu następowało przekierowanie do strony pośredniej, która generowała aktywny kod urządzenia i instruowała użytkownika, aby zatwierdził go na prawdziwej stronie Microsoft.

Jeżeli ofiara nie miała aktywnej sesji, logowała się standardowo i przechodziła także przez MFA. Z perspektywy użytkownika cały proces mógł wyglądać wiarygodnie, ponieważ nie dochodziło do wpisania hasła na fałszywej stronie. W rzeczywistości autoryzowana była jednak sesja klienta kontrolowanego przez atakującego.

Po zatwierdzeniu procesu napastnik uzyskiwał tokeny dostępu i odświeżania. To dawało możliwość:

odczytu i przeszukiwania poczty,
eksfiltracji danych ze skrzynki,
tworzenia reguł ukrywających wiadomości,
utrzymania dostępu mimo zmiany hasła, jeśli tokeny nie zostały unieważnione,
prowadzenia dalszej komunikacji w imieniu ofiary.

EvilTokens rozszerzał ten scenariusz o warstwę automatyzacji. Według ujawnionych informacji platforma analizowała skrzynki w wielu językach, identyfikowała relacje biznesowe, wątki związane z płatnościami oraz osoby odpowiedzialne za finanse. Następnie mogła wspierać przygotowanie wiadomości wykorzystywanych w oszustwach BEC, co znacząco skracało czas między przejęciem konta a próbą wyłudzenia środków.

Operatorzy wykorzystywali również techniki utrudniające detekcję, w tym wieloetapowe przekierowania, fałszywe testy CAPTCHA oraz infrastrukturę chmurową i serverless. Dzięki temu ruch mógł wyglądać jak legalna aktywność związana z popularnymi usługami internetowymi.

Konsekwencje / ryzyko

Skala operacji pokazuje, że phishing device code wyrósł na dojrzały i masowy model ataku przeciwko tożsamościom w chmurze. Przejęcie ponad 12 tysięcy skrzynek w ponad 10 tysiącach organizacji oznacza, że nie był to incydent ograniczony do wąskiej grupy ofiar, lecz szeroko zakrojona kampania o globalnym zasięgu.

Najpoważniejsze ryzyko wynika z faktu, że samo zresetowanie hasła nie zawsze kończy incydent. Jeśli organizacja nie unieważni aktywnych sesji i tokenów, napastnik może zachować dostęp nawet po zmianie poświadczeń. To odróżnia device code phishing od wielu tradycyjnych kampanii credential phishingu.

Dodatkowym zagrożeniem jest wykorzystanie AI do automatycznej analizy treści skrzynki. Oznacza to szybszy rekonesans, lepsze dopasowanie fałszywych wiadomości do kontekstu biznesowego oraz wyższą skuteczność oszustw finansowych. W praktyce przestępcy mogą szybciej identyfikować osoby decyzyjne, rozmowy o płatnościach i relacje z kontrahentami, które warto wykorzystać w dalszym ataku.

Rekomendacje

Organizacje powinny traktować device code phishing jako pełnoprawny scenariusz przejęcia tożsamości, a nie jedynie odmianę klasycznego wyłudzania haseł. Ochrona przed tym zagrożeniem wymaga kontroli tokenów, sesji i aplikacji, a nie wyłącznie silnych haseł oraz MFA.

W pierwszej kolejności warto ocenić, czy device code flow jest rzeczywiście potrzebny w środowisku. Jeżeli nie istnieje uzasadnienie biznesowe, należy ograniczyć lub wyłączyć jego użycie tam, gdzie to możliwe.

Z perspektywy monitoringu i reagowania warto:

analizować logi Entra ID oraz Microsoft 365 pod kątem nietypowych autoryzacji urządzeń,
wykrywać anomalie geograficzne i nietypowe przyznania tokenów aplikacjom,
monitorować tworzenie reguł skrzynkowych ukrywających lub przekierowujących wiadomości,
weryfikować nowo zarejestrowane aplikacje i urządzenia powiązane z kontem,
wdrażać polityki Conditional Access dla ryzykownych przepływów uwierzytelnienia.

W przypadku podejrzenia kompromitacji należy natychmiast unieważnić aktywne sesje i tokeny, wymusić ponowne logowanie użytkownika, sprawdzić reguły skrzynki, delegacje oraz historię aktywności pocztowej, a także ustalić, czy z konta nie prowadzono dalszych prób oszustwa BEC.

Nie mniej ważne są szkolenia użytkowników. Personel powinien rozumieć, że nawet legalna strona logowania może zostać wykorzystana jako element ataku socjotechnicznego, jeśli użytkownik zostanie nakłoniony do autoryzacji dostępu dla nieuprawnionego klienta.

Podsumowanie

Rozbicie EvilTokens to ważny sygnał dla rynku bezpieczeństwa: phishing oparty na device code stał się skalowalnym i komercyjnie dojrzałym narzędziem ataku na środowiska chmurowe. Szczególnie niepokoi połączenie przejęcia tożsamości z automatyczną analizą treści skrzynki i wsparciem AI dla dalszych oszustw finansowych.

Dla zespołów bezpieczeństwa oznacza to konieczność szerszego spojrzenia na ochronę tożsamości. Widoczność tokenów, kontrola sesji, detekcja nietypowych autoryzacji i szybkie unieważnianie dostępu powinny dziś być równie istotne jak ochrona haseł czy stacji roboczych.