Wprowadzenie do problemu / definicja
EvilTokens to nowy zestaw phishingowy rozwijany w modelu phishing-as-a-service, którego celem są przede wszystkim konta Microsoft 365. Jego operatorzy nie skupiają się na klasycznej kradzieży loginu i hasła przez fałszywy formularz, lecz nadużywają legalnego mechanizmu OAuth 2.0 Device Authorization Grant, znanego jako device code flow.
W praktyce oznacza to, że ofiara zostaje nakłoniona do wpisania prawidłowego kodu urządzenia na autentycznej stronie Microsoft. Po zakończeniu procesu atakujący może uzyskać tokeny dostępu i odświeżania, co otwiera drogę do przejęcia sesji, dostępu do danych oraz utrzymania obecności w środowisku ofiary.
W skrócie
EvilTokens został zaobserwowany jako rozwijana usługa cyberprzestępcza oferowana operatorom kampanii phishingowych. Narzędzie koncentruje się na atakach wymierzonych w użytkowników Microsoft 365 i wykorzystuje legalny proces logowania dla urządzeń o ograniczonych możliwościach wprowadzania danych.
- Atak opiera się na phishingu typu device code.
- Ofiara loguje się na legalnej stronie Microsoft, co zwiększa wiarygodność kampanii.
- Przestępcy przejmują tokeny zamiast hasła.
- Celem mogą być poczta, pliki, Teams oraz dalsze oszustwa typu business email compromise.
- Mechanizm utrudnia wykrycie, ponieważ nie wymaga klasycznej fałszywej strony logowania.
Kontekst / historia
Mechanizm device code został zaprojektowany z myślą o urządzeniach takich jak telewizory, drukarki, terminale i systemy IoT, które nie są przystosowane do pełnego, interaktywnego logowania. Użytkownik otrzymuje krótki kod, przechodzi na inną stronę na wygodniejszym urządzeniu i zatwierdza uwierzytelnienie.
W ostatnich latach cyberprzestępcy coraz częściej nadużywają tego rozwiązania, ponieważ omija ono część tradycyjnych zabezpieczeń antyphishingowych. EvilTokens wpisuje się w ten trend, ale wyróżnia się automatyzacją, gotowymi szablonami kampanii oraz zapleczem ułatwiającym przechwytywanie i dalsze wykorzystanie tokenów w atakach na organizacje biznesowe.
Szczególnie istotne jest to, że ofiara widzi prawdziwą domenę Microsoft, co osłabia skuteczność klasycznych porad bezpieczeństwa opartych wyłącznie na rozpoznawaniu fałszywych adresów URL i podrobionych formularzy logowania.
Analiza techniczna
Atak rozpoczyna się od wiadomości phishingowej zawierającej link lub załącznik. Przynęty naśladują typowe procesy biznesowe, takie jak podpis dokumentu, współdzielenie pliku, wiadomość głosowa, zaproszenie kalendarzowe, komunikat o kwarantannie wiadomości czy informacja o wygaśnięciu hasła.
Po kliknięciu ofiara trafia na stronę podszywającą się pod zaufaną usługę. Następnie widzi instrukcje weryfikacji, krótki kod oraz przycisk kierujący do prawdziwej strony Microsoft przeznaczonej do autoryzacji urządzeń. To kluczowy moment całej kampanii: ofiara nie przekazuje danych logowania bezpośrednio przestępcom, lecz sama autoryzuje sesję zainicjowaną wcześniej przez atakującego.
Od strony technicznej przeciwnik inicjuje żądanie do endpointu device code i uzyskuje zestaw danych obejmujący identyfikator urządzenia, kod użytkownika, adres weryfikacyjny oraz czas ważności. Następnie przekazuje ofierze kod użytkownika. Po jego wpisaniu na legalnej stronie Microsoft backend przestępcy odpytuje endpoint tokenowy i oczekuje na zakończenie autoryzacji.
- Atakujący inicjuje proces device code.
- Microsoft generuje kod użytkownika i dane sesji.
- Ofiara wpisuje kod na legalnej stronie Microsoft.
- Backend przestępcy pobiera token dostępu.
- W zależności od zakresów może zostać uzyskany także token odświeżania.
Zaletą tego modelu z perspektywy atakującego jest brak konieczności przechwytywania hasła lub kodu MFA w tradycyjny sposób. To użytkownik sam zatwierdza proces, ufając legalnemu adresowi. Dodatkowo opisywana infrastruktura ma wspierać automatyzację kampanii, przechowywanie tokenów, powiadomienia operatorskie oraz dalsze uzbrajanie uzyskanego dostępu.
Według analiz technicznych zestaw ma również wykorzystywać samohostowane szablony phishingowe oraz zaciemnianie kodu po stronie klienta, co utrudnia analizę i wykrywanie metodami statycznymi.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem skutecznego ataku jest przejęcie aktywnej sesji użytkownika bez potrzeby znajomości jego hasła. Uzyskany token dostępu może pozwolić na natychmiastowy wgląd w pocztę Exchange Online, dokumenty w OneDrive i SharePoint oraz dane z Microsoft Teams.
Jeszcze większe ryzyko pojawia się wtedy, gdy przestępca zdobywa również token odświeżania. Taki token może umożliwić utrzymanie dostępu przez dłuższy czas i ograniczyć skuteczność prostych działań naprawczych, takich jak sama zmiana hasła.
- Przejęcie skrzynki pocztowej i monitorowanie komunikacji.
- Kradzież dokumentów finansowych, handlowych i operacyjnych.
- Realizacja oszustw BEC i modyfikacja instrukcji płatniczych.
- Rozszerzenie dostępu do kolejnych usług dzięki integracji tożsamości.
- Trudniejsze wykrycie incydentu z powodu użycia legalnego procesu logowania.
Dla organizacji oznacza to wzrost ryzyka incydentów tożsamościowych w chmurze, szczególnie tam, gdzie monitorowanie tokenów, sesji oraz nietypowych zgód aplikacyjnych nie jest wystarczająco rozwinięte.
Rekomendacje
Firmy korzystające z Microsoft 365 powinny traktować phishing device code jako osobną kategorię zagrożeń. Obrona nie może opierać się wyłącznie na edukacji dotyczącej fałszywych domen, ponieważ w tym scenariuszu użytkownik rzeczywiście widzi legalną stronę dostawcy.
- Ograniczyć lub wyłączyć niepotrzebne użycie device code flow tam, gdzie jest to możliwe.
- Wdrożyć i dostroić polityki Conditional Access oraz kontrole zgodności urządzeń.
- Monitorować logi Entra ID pod kątem nietypowych zdarzeń związanych z device code i tokenami.
- Wykrywać nowe sesje, lokalizacje, adresy IP i nietypowych klientów aplikacyjnych.
- Szybko unieważniać tokeny i aktywne sesje po podejrzeniu przejęcia konta.
- Korelować zdarzenia z poczty, logowań i dostępu do zasobów w celu wykrywania BEC.
- Aktualizować szkolenia użytkowników o scenariusze nadużycia legalnych stron logowania.
- Filtrować kampanie wykorzystujące biznesowe przynęty związane z dokumentami, finansami, HR i logistyką.
W działaniach reagowania incydentowego należy przyjąć, że sama zmiana hasła może być niewystarczająca. Konieczne może być unieważnienie aktywnych sesji, cofnięcie tokenów, przegląd powiązanych aplikacji i urządzeń oraz analiza możliwych działań następczych w poczcie i usługach chmurowych.
Podsumowanie
EvilTokens pokazuje, że współczesny phishing coraz częściej koncentruje się na nadużywaniu legalnych mechanizmów uwierzytelniania zamiast wyłącznie na imitowaniu stron logowania. To podejście zwiększa wiarygodność kampanii, utrudnia jej wykrycie i pozwala przejmować sesje oraz tokeny bez tradycyjnej kradzieży poświadczeń.
Dla zespołów bezpieczeństwa to sygnał, że ochrona tożsamości w chmurze musi obejmować cały cykl życia sesji, tokenów i przepływów autoryzacyjnych. Organizacje, które nie monitorują nadużyć device code i nie mają procedur szybkiej revokacji tokenów, pozostają szczególnie narażone na przejęcia kont Microsoft 365 oraz incydenty business email compromise.
Źródła
- New EvilTokens service fuels Microsoft device code phishing attacks — https://www.bleepingcomputer.com/news/security/new-eviltokens-service-fuels-microsoft-device-code-phishing-attacks/
- New widespread EvilTokens kit: device code phishing as-a-service – Part 1 — https://blog.sekoia.io/new-widespread-eviltokens-kit-device-code-phishing-as-a-service-part-1/
- Microsoft identity platform and the OAuth 2.0 device authorization grant flow — https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-device-code