Microsoft rozbija EvilTokens: 12 tys. przejętych skrzynek i cios w device code phishing

Wprowadzenie do problemu / definicja

Microsoft przeprowadził skoordynowaną operację wymierzoną w EvilTokens, platformę phishing-as-a-service wyspecjalizowaną w atakach typu device code phishing na środowiska Microsoft 365. Usługa umożliwiała przejmowanie dostępu do skrzynek pocztowych bez klasycznej kradzieży hasła, wykorzystując legalny mechanizm autoryzacji urządzeń oraz przechwytywanie tokenów sesyjnych.

To szczególnie groźny model nadużycia, ponieważ ofiara nie wpisuje danych logowania na fałszywej stronie, lecz sama kończy proces uwierzytelniania w prawdziwym portalu dostawcy. W praktyce oznacza to, że nawet organizacje stosujące MFA mogą paść ofiarą skutecznego ataku, jeśli użytkownik zostanie nakłoniony do autoryzowania sesji kontrolowanej przez napastnika.

W skrócie

Według ujawnionych informacji operacja doprowadziła do przejęcia 50 witryn wykorzystywanych przez EvilTokens oraz wyłączenia ponad 150 dodatkowych domen wspierających zaplecze usługi. Z działalnością platformy powiązano ponad 12 tysięcy przejętych skrzynek pocztowych w więcej niż 10 tysiącach organizacji na świecie.

EvilTokens działał jako komercyjna platforma PhaaS.
Ataki opierały się na nadużywaniu OAuth 2.0 Device Authorization Flow.
Przejęte skrzynki były wykorzystywane m.in. do oszustw BEC.
Platforma zawierała funkcje automatyzacji i komponenty AI.
W działania przeciwko infrastrukturze zaangażowano partnerów prywatnych i organizacje branżowe.

Kontekst / historia

EvilTokens zwrócił uwagę badaczy na początku 2026 roku jako jedna z pierwszych szeroko dostępnych usług phishingowych skoncentrowanych na device code phishing. Model ten szybko zyskał popularność wśród cyberprzestępców, ponieważ pozwalał ominąć część tradycyjnych zabezpieczeń opartych na ochronie haseł i podstawowym MFA.

Platforma była oferowana w modelu subskrypcyjnym i zapewniała gotowe szablony kampanii, panel operatorski oraz narzędzia wspierające prowadzenie oszustw typu business email compromise. Według dostępnych informacji ekosystem rozwijano jak dojrzałą usługę cyberprzestępczą, z elementami automatyzacji, wsparciem operacyjnym i integracją z infrastrukturą ułatwiającą utrzymanie dostępu po skutecznym przejęciu konta.

Microsoft śledzi tę aktywność pod nazwą Storm-2992. Istotne jest również to, że operacja neutralizacji EvilTokens miała charakter wielopodmiotowy, co pokazuje rosnącą rolę współpracy między dostawcami chmury, firmami zajmującymi się analizą zagrożeń, operatorami infrastruktury oraz partnerami z sektora threat intelligence.

Analiza techniczna

Sednem działania EvilTokens był atak oparty na kodzie urządzenia. W odróżnieniu od klasycznego phishingu użytkownik nie był proszony o podanie loginu i hasła na podrobionej stronie. Zamiast tego otrzymywał instrukcję wpisania kodu na legalnej stronie logowania Microsoft, co znacząco podnosiło wiarygodność całego scenariusza.

Uproszczony przebieg ataku wyglądał następująco:

ofiara otrzymywała wiadomość phishingową dotyczącą np. faktury, pliku współdzielonego lub sprawy biznesowej,
link prowadził do strony pośredniczącej generującej aktywny kod urządzenia,
użytkownik był instruowany, aby skopiować kod i przejść do prawdziwego procesu logowania,
po wpisaniu kodu i ukończeniu MFA autoryzowany był klient kontrolowany przez przestępcę,
atakujący uzyskiwał tokeny dostępu i odświeżania działające w kontekście ofiary.

Właśnie ten mechanizm czyni atak wyjątkowo podstępnym. Ofiara nie oddaje hasła bezpośrednio napastnikowi, lecz sama nadaje mu autoryzację. Uzyskane tokeny mogły być następnie używane do odczytu poczty, analizy relacji biznesowych, tworzenia złośliwych reguł skrzynki, rejestrowania nowych urządzeń oraz utrzymywania dostępu nawet po zmianie hasła, jeśli organizacja nie unieważniła aktywnych sesji i tokenów.

EvilTokens wyróżniał się również warstwą automatyzacji. Platforma wykorzystywała funkcje AI do analizy zawartości przejętych skrzynek, identyfikowania wątków związanych z płatnościami, mapowania ról organizacyjnych i wskazywania najlepszych celów do dalszego podszywania się. W praktyce obniżało to próg wejścia dla mniej zaawansowanych operatorów BEC i skracało czas między przejęciem konta a próbą wyłudzenia środków.

Dodatkowo operatorzy stosowali wieloetapowe przekierowania, pliki PDF i HTML oraz elementy przypominające testy CAPTCHA, aby utrudnić wykrycie kampanii przez systemy bezpieczeństwa poczty i mechanizmy sandboxowe.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem device code phishingu jest przejęcie tożsamości w środowisku chmurowym bez łamania hasła. To oznacza, że organizacje koncentrujące ochronę wyłącznie na poświadczeniach mogą nie zauważyć incydentu na wczesnym etapie. Jeśli użytkownik poprawnie ukończy legalny proces logowania i MFA, klasyczne wskaźniki phishingu często nie występują.

Ryzyko biznesowe i operacyjne obejmuje przede wszystkim:

dostęp do poufnej korespondencji w Microsoft 365,
eskalację do fraudów BEC i oszustw fakturowych,
długotrwałe utrzymanie dostępu dzięki tokenom i rejestracji urządzeń,
ukrywanie aktywności przez złośliwe reguły skrzynki,
automatyczną analizę procesów płatniczych i relacji biznesowych,
skalowanie ataków dzięki komercjalizacji i automatyzacji usługi.

Z perspektywy zespołów SOC i IAM szczególnie ważne jest to, że sam reset hasła nie musi oznaczać pełnej remediacji. Jeżeli organizacja nie cofnie refresh tokenów, nie zakończy aktywnych sesji i nie sprawdzi zaufanych urządzeń, napastnik może zachować dostęp mimo pozornie wykonanych działań naprawczych.

Rekomendacje

Incydent związany z EvilTokens powinien skłonić organizacje korzystające z Microsoft 365 do przeglądu polityk tożsamości, monitoringu i procedur reagowania. Priorytetem jest nie tylko wzmacnianie MFA, ale też kontrola przepływów autoryzacji i widoczność cyklu życia tokenów.

ograniczyć lub wyłączyć device code flow tam, gdzie nie jest potrzebny biznesowo,
wdrożyć phishing-resistant MFA, w szczególności FIDO2,
monitorować logowania przez device code i nietypowe rejestracje urządzeń,
wykrywać złośliwe reguły skrzynki, przekierowania i ukrywanie wiadomości,
po incydencie unieważniać sesje, refresh tokeny i sprawdzać urządzenia powiązane z kontem,
analizować aktywność API, w tym masowy odczyt poczty i enumerację organizacji,
wzmacniać ochronę poczty przez SPF, DKIM i DMARC,
szkolić użytkowników, że wpisanie kodu na legalnej stronie także może być elementem ataku.

Dla zespołów reagowania istotne jest przygotowanie playbooków dedykowanych przejęciu tokenów, a nie wyłącznie kompromitacji haseł. W nowoczesnych środowiskach chmurowych telemetryka musi obejmować sesje, tokeny, rejestrację urządzeń i dostęp aplikacyjny.

Podsumowanie

Operacja przeciwko EvilTokens pokazuje, że device code phishing stał się dojrzałym, skomercjalizowanym segmentem cyberprzestępczości. Platforma łączyła legalne mechanizmy autoryzacji, automatyzację kampanii i funkcje AI wspierające dalsze oszustwa finansowe, a skala incydentu potwierdza realne zagrożenie dla organizacji opartych na usługach chmurowych.

Najważniejszy wniosek jest jednoznaczny: MFA nie zapewnia pełnej ochrony, jeśli użytkownik zostanie nakłoniony do autoryzowania sesji napastnika. Skuteczna obrona wymaga dziś kontroli przepływów uwierzytelniania, monitorowania tokenów, detekcji nadużyć w chmurze i szybkiego unieważniania dostępu po incydencie.