EvilTokens: Microsoft zakłócił platformę device code phishing

Jednym z głównych mechanizmów EvilTokens był device code phishing. Ofiara mogła trafić na prawdziwy portal logowania Microsoft, wykonać normalne uwierzytelnienie i mimo to przekazać napastnikowi dostęp do konta. Atak nie opierał się więc na prostym skopiowaniu strony logowania. Wykorzystywał legalny przepływ OAuth przeznaczony między innymi dla urządzeń z ograniczonym interfejsem.

Microsoft opisał również wykorzystanie AI do przygotowywania przynęt i analizowania przejętych skrzynek pod kątem wartościowych celów. Zakłócenie EvilTokens ogranicza infrastrukturę konkretnej usługi, ale nie usuwa samego ryzyka device code phishing. Techniczne tło tego mechanizmu opisujemy szerzej w artykule Device code phishing w Microsoft 365.

Co wydarzyło się z EvilTokens

Microsoft poinformował 22 września o skoordynowanym zakłóceniu infrastruktury wykorzystywanej przez EvilTokens. W działaniach uczestniczyły zespoły Microsoft Digital Crimes Unit i Microsoft Threat Intelligence oraz partnerzy z sektora bezpieczeństwa i organy ścigania.

Według Microsoft EvilTokens pojawił się w lutym 2026 r. i szybko stał się szeroko używaną platformą PhaaS. Firma powiązała kampanie korzystające z tej infrastruktury z ponad 12 tys. przejętych skrzynek w przeszło 10 tys. organizacji. Aktywność obserwowano między innymi w Stanach Zjednoczonych, Kanadzie, Wielkiej Brytanii, Australii, Indiach i Francji.

Microsoft wskazał branże takie jak dystrybucja hurtowa, budownictwo, usługi finansowe, nieruchomości, szkolnictwo wyższe i ochrona zdrowia. Te dane opisują telemetrię i ustalenia Microsoft dotyczące EvilTokens; nie są statystyką wszystkich kampanii device code phishing.

Jak działał atak EvilTokens krok po kroku

Łańcuch zaczynał się od wiadomości lub załącznika, który miał skłonić użytkownika do wykonania kolejnych instrukcji. Microsoft opisał między innymi motywy związane z podpisywaniem dokumentów, usługami chmurowymi, plikami, płatnościami, pocztą głosową i wygasaniem hasła.

Po wejściu na stronę kontrolowaną przez napastnika skrypt generował aktualny kod urządzenia i wyświetlał go użytkownikowi. Następnie kierował ofiarę do oficjalnego portalu Microsoft do logowania urządzeń.

Użytkownik widział prawdziwą stronę Microsoft i mógł przejść normalne uwierzytelnienie, w tym wymagane MFA. Problem polegał na tym, że kod pochodził z procesu rozpoczętego przez napastnika. Po zatwierdzeniu logowania infrastruktura EvilTokens mogła odebrać token związany z tą sesją.

Microsoft opisał automatyczne sprawdzanie stanu logowania oraz dalsze działania po przejęciu konta. Obejmowały one dostęp do poczty, analizę skrzynki i tworzenie reguł mogących ukrywać część korespondencji.

Dlaczego prawdziwa strona Microsoft nie wystarcza

Device code phishing podważa prostą regułę „sprawdź, czy domena logowania jest prawdziwa”. W tym scenariuszu oficjalna domena może rzeczywiście pojawić się w środku ataku.

Znaczenie ma cały kontekst. Jeżeli kod urządzenia został przesłany w nieoczekiwanym e-mailu, pliku PDF, wiadomości lub na stronie, której użytkownik nie zna, wpisanie go na prawdziwym portalu może autoryzować cudzą sesję.

Użytkownik nie powinien więc oceniać bezpieczeństwa wyłącznie po wyglądzie ostatniego ekranu. Trzeba zadać prostsze pytanie: czy sam rozpocząłem ten proces i czy mam uzasadniony powód, aby łączyć urządzenie lub aplikację z kontem służbowym?

Gdzie EvilTokens wykorzystywał AI

Microsoft opisuje AI jako element kilku etapów działalności EvilTokens. Platforma pomagała przygotowywać wiadomości dopasowane do celu, a po przejęciu skrzynki mogła analizować korespondencję i wskazywać relacje, role oraz informacje przydatne w dalszym oszustwie.

To rozszerzało cel ataku poza samo zdobycie tokenu. Dostęp do skrzynki może być punktem wyjścia do Business Email Compromise, czyli oszustw wykorzystujących przejętą korespondencję służbową. Napastnik może obserwować rozmowy, szukać informacji o płatnościach i przygotowywać wiadomości osadzone w prawdziwym kontekście biznesowym.

Nie oznacza to, że AI jest niezbędne do device code phishing. Mechanizm działa bez niego. W EvilTokens automatyzacja i funkcje AI zwiększały skalę oraz ułatwiały dalsze wykorzystanie przejętego dostępu.

Co powinien zrobić użytkownik

Kod urządzenia należy traktować jak element procesu nadawania dostępu, a nie jak zwykły numer do przepisania. Jeżeli kod pojawia się w nieoczekiwanej wiadomości, załączniku lub na stronie otwartej z e-maila, nie należy go wpisywać tylko dlatego, że kolejny ekran znajduje się w domenie Microsoft.

Jeśli użytkownik już wpisał kod i zakończył logowanie, powinien od razu zgłosić zdarzenie przez znany firmowy kanał. Szybkie zgłoszenie pozwala zespołowi technicznemu unieważnić sesje i sprawdzić, czy konto zostało wykorzystane.

W szkoleniach warto ćwiczyć właśnie ten punkt decyzji: nie „czy strona wygląda profesjonalnie?”, ale „dlaczego ktoś prosi mnie o kod urządzenia i kto rozpoczął ten proces?”.

Takie scenariusze można ćwiczyć w kontrolowanych testach phishingowych dla firm, koncentrując się na rozpoznaniu nieoczekiwanego kodu i szybkim zgłoszeniu zdarzenia.

Co powinno sprawdzić IT i zespół bezpieczeństwa

Microsoft zaleca blokowanie device code flow tam, gdzie organizacja go nie potrzebuje. Jeżeli istnieją uzasadnione przypadki użycia, na przykład określone urządzenia Teams, wyjątki powinny być możliwie wąskie i kontrolowane przez polityki Conditional Access.

Po podejrzeniu przejęcia trzeba sprawdzić logowania związane z device code, aktywne sesje i tokeny, rejestrację urządzeń, aktywność Microsoft Graph oraz zmiany w skrzynce. Szczególną uwagę warto zwrócić na nietypowe reguły pocztowe, przekierowania i działania wykonywane krótko po podejrzanym uwierzytelnieniu.

Zakłócenie EvilTokens nie zastępuje tych kontroli. Dotyczy konkretnej infrastruktury przestępczej, podczas gdy legalny device code flow nadal może być celem nadużyć.

Co zmienia zakłócenie EvilTokens

Nowe dane Microsoft pokazują skalę komercjalizacji tej techniki. Device code phishing nie był wyłącznie pojedynczym scenariuszem laboratoryjnym lub niszową sztuczką. EvilTokens oferował go jako usługę wraz z gotowymi przynętami, automatyzacją i funkcjami wspierającymi działania po przejęciu konta.

Dla zespołów bezpieczeństwa to powód, aby rozdzielić dwa zadania. Pierwsze to ograniczenie niepotrzebnego device code flow i monitorowanie tożsamości. Drugie to przygotowanie użytkowników na sytuację, w której prawdziwa strona logowania pojawia się w złośliwym procesie.

Szczegółowy mechanizm, warianty ataku i zasady reakcji opisuje nasz wcześniejszy materiał Device code phishing w Microsoft 365. Ten artykuł pozostaje technicznym tłem; EvilTokens jest aktualizacją o konkretnej platformie i operacji z września 2026 r. Uzupełnieniem jest także materiał o phishingu OAuth i zgodach aplikacji w Microsoft 365, który pokazuje pokrewny sposób nadużywania legalnych mechanizmów autoryzacji.

Wniosek

EvilTokens łączył device code phishing, automatyzację i analizę przejętych skrzynek w usługę dla cyberprzestępców. Microsoft i partnerzy zakłócili infrastrukturę tej platformy, ale mechanizm wykorzystywany w atakach pozostaje częścią legalnych przepływów uwierzytelniania.

Dla użytkownika najbezpieczniejsza zasada jest konkretna: nie wpisuj kodu urządzenia otrzymanego z nieoczekiwanej wiadomości i nie traktuj prawdziwej domeny Microsoft jako potwierdzenia, że cały wcześniejszy proces był bezpieczny.

Dla organizacji priorytetem jest ograniczenie device code flow do rzeczywistych potrzeb, monitorowanie nietypowych uwierzytelnień i szybka reakcja na zgłoszenia użytkowników.