Nowa platforma phishing-as-a-service o nazwie EvilTokens pokazuje, że atakujący odchodzą od tradycyjnej kradzieży haseł i przechodzą na bardziej niebezpieczną warstwę przejmowania tożsamości: nadużywanie zgód OAuth.
Uruchomiona w lutym 2026 r. platforma EvilTokens podobno w ciągu zaledwie pięciu tygodni przejęła dostęp do ponad 340 organizacji korzystających z Microsoft 365 w pięciu krajach. Szczególnie niepokojące w tej kampanii jest to, że nie polegała ona na kradzieży haseł ani na tradycyjnym omijaniu MFA.
Zamiast tego ofiary zostały nakłonione do przejścia legalnego procesu uwierzytelniania Microsoft.
Poproszono je o wpisanie krótkiego kodu na stronie microsoft.com/devicelogin, przejście zwykłej weryfikacji MFA i zatwierdzenie dostępu. Z perspektywy użytkownika wyglądało to na rutynowy proces weryfikacji.
W rzeczywistości przyznały atakującemu ważny token odświeżania OAuth z dostępem do skrzynki pocztowej, OneDrive, kalendarza i kontaktów.
Dlaczego ten atak jest inny
Tradycyjny phishing zazwyczaj polega na kradzieży nazwy użytkownika i hasła. Atakujący próbuje następnie użyć tych poświadczeń, a nowoczesne systemy tożsamości często zatrzymują taką próbę za pomocą MFA, dostępu warunkowego, wykrywania niemożliwej podróży lub kontroli zgodności urządzenia.
Phishing z wykorzystaniem zgód OAuth działa inaczej.
Ofiara uwierzytelnia się bezpośrednio u legalnego dostawcy tożsamości. MFA jest realizowane na prawdziwej domenie Microsoft. Nie jest potrzebna fałszywa strona logowania. Nie trzeba kraść hasła. Nie dochodzi do podejrzanego ponownego użycia logowania.
Atakujący po prostu przekonuje użytkownika do zatwierdzenia zgody OAuth.
Po zatwierdzeniu atakujący otrzymuje ważny token wystawiony przez samego dostawcę tożsamości. Taki token może pozostać użyteczny przez tygodnie lub miesiące, zależnie od polityki tenanta.
Dlatego nadużycie zgód OAuth jest tak niebezpieczne: złośliwy dostęp może wyglądać jak system działający dokładnie tak, jak został zaprojektowany.
MFA nie zatrzyma tego, co już zatwierdzono
MFA nadal jest ważne, ale samo w sobie nie rozwiązuje tego problemu.
W ataku phishingowym z wykorzystaniem zgód OAuth MFA zostało już zrealizowane, zanim dojdzie do niebezpiecznego działania. Użytkownik loguje się pomyślnie, przechodzi weryfikację, a następnie zatwierdza żądane uprawnienia.
Z perspektywy dostawcy tożsamości proces jest legalny.
Atakujący nie loguje się za pomocą wykradzionych poświadczeń. Używa tokenu, który użytkownik faktycznie autoryzował. Token ten może dawać dostęp do poczty, plików, kalendarzy, kontaktów lub innych danych SaaS, zależnie od zatwierdzonych zakresów uprawnień.
Resetowanie haseł również może być nieskuteczne. Jeśli zgoda OAuth pozostaje ważna, atakujący może nadal używać tokenu odświeżania nawet po zmianie hasła przez użytkownika.
Ścieżkę dostępu mogą zamknąć wyłącznie jawne unieważnienie tokenu, usunięcie zgody lub polityka dostępu warunkowego wymuszająca ponowne udzielenie zgody.
Problem ekranu zgody
Ekrany zgód OAuth stały się dla użytkowników normalnym tłem.
Pracownicy są stale proszeni o zatwierdzanie dostępu dla narzędzi zwiększających produktywność, rozszerzeń przeglądarki, asystentów AI, narzędzi do podsumowywania spotkań, integracji z CRM, pulpitów raportowych, automatyzacji przepływów pracy i wtyczek SaaS.
Z czasem użytkownicy przyzwyczajają się do klikania Akceptuj.
Tworzy to niebezpieczny nawyk. Ekran zgody staje się nowym celem phishingu.
Uprawnienie takie jak „Odczytywanie Twojej poczty” może brzmieć na ograniczone, ale w praktyce może ujawnić wszystkie wiadomości, załączniki, wspólne wątki, faktury, umowy, wewnętrzne dyskusje i wrażliwe dane biznesowe, do których użytkownik ma dostęp.
Uprawnienie takie jak „Dostęp do plików, gdy Cię nie ma” może brzmieć jak wygodna funkcja, ale operacyjnie może oznaczać długotrwały dostęp nawet wtedy, gdy użytkownik jest offline.
Atakujący wykorzystują rozdźwięk między tym, jak niegroźnie brzmią uprawnienia, a tym, jak potężne są w rzeczywistości.
Tokeny odświeżania zapewniają długotrwały dostęp
Najcenniejszym elementem ataku jest często token odświeżania.
Krótkotrwały token sesji może szybko wygasnąć, ale token odświeżania może umożliwiać dalszy dostęp przez znacznie dłuższy czas. W zależności od konfiguracji może pozostać ważny przez tygodnie lub miesiące.
Daje to atakującym czas na:
- czytanie e-maili
- monitorowanie kalendarzy
- dostęp do plików w OneDrive
- wyszukiwanie wrażliwych załączników
- zbieranie kontaktów
- identyfikowanie członków kadry zarządzającej i pracowników działów finansowych
- przygotowywanie ataków typu business email compromise
- wyszukiwanie haseł lub kluczy dostępu
- przemieszczanie się do innych aplikacji SaaS
Użytkownik może nigdy nie zauważyć niczego podejrzanego, ponieważ dostęp nie musi generować głośnego zdarzenia nieudanego logowania ani uruchamiać tradycyjnej weryfikacji MFA.
Toksyczne kombinacje: ukryte ryzyko w aplikacjach SaaS
Pojedyncza zgoda OAuth może być ryzykowna. Wiele zgód w różnych aplikacjach może być znacznie groźniejsze.
Nazywa się to toksyczną kombinacją.
Na przykład jeden pracownik może zatwierdzić:
- narzędzie do podsumowywania spotkań z dostępem do skrzynki pocztowej i kalendarza
- asystenta produktywności z dostępem do plików na dysku współdzielonym
- narzędzie do wzbogacania danych CRM z dostępem do rekordów klientów
- agenta AI z uprawnieniami do interakcji z systemami wewnętrznymi
Każda zgoda może wyglądać na akceptowalną w oderwaniu od pozostałych. Razem jednak tworzą połączoną ścieżkę dostępu, której żaden właściciel pojedynczej aplikacji nie przeglądał ani nie zatwierdzał.
Niebezpieczeństwo kryje się między systemami.
Jedna przejęta integracja może ujawnić e-maile, umowy, dane klientów, notatki ze spotkań i pliki wewnętrzne za pośrednictwem tej samej tożsamości człowieka.
Tradycyjne dzienniki aplikacji mogą nie pokazywać pełnego obrazu, ponieważ każda aplikacja widzi tylko własne uprawnienia. Rzeczywiste ryzyko istnieje w grafie tożsamości łączącym użytkowników, zgody OAuth, aplikacje SaaS, integracje i agentów AI.
Agenci AI i MCP zwiększają ryzyko
Ten sam model zaufania obejmuje obecnie także agentów AI i integracje Model Context Protocol.
Agenci AI często potrzebują dostępu do kalendarzy, poczty, plików, repozytoriów kodu, narzędzi projektowych, systemów zgłoszeń, baz danych i dokumentacji wewnętrznej. Aby go uzyskać, polegają na zgodach z określonym zakresem i przepływach udzielania zgody podobnych do OAuth.
Tworzy to nową wersję tego samego problemu.
Kliknięcie zgody OAuth, zatwierdzenie rozszerzenia przeglądarki lub instalacja serwera MCP może natychmiast utworzyć most między systemami. Taki most może pozwalać agentowi lub integracji na dostęp do danych na wielu platformach.
Jeśli atakujący przejmą jedno z takich połączeń, mogą odziedziczyć szeroki zasięg operacyjny w całej organizacji.
Dlatego zarządzanie zgodami staje się równie ważne jak zarządzanie uwierzytelnianiem.
Wnioski z wcześniejszych nadużyć OAuth
Incydent Salesloft-Drift z 2025 r. pokazał, jak tokeny OAuth mogą prowadzić do ekspozycji na dużą skalę w kolejnych systemach.
Klienci legalnie zatwierdzili integrację. Jednak gdy łącznik końcowy został przejęty, atakujący mógł nadużywać zatwierdzonych tokenów w wielu tenantach Salesforce.
Każdy z klientów autoryzował integrację. Żaden nie autoryzował wynikającej z niej kaskady dostępu.
EvilTokens potwierdza tę samą szerszą lekcję: obwód tożsamości to już nie tylko strona logowania. Obejmuje każdy zatwierdzony token, zgodę OAuth, łącznik, agenta i integrację zewnętrzną.
Co organizacje powinny przeglądać
Zespoły ds. bezpieczeństwa powinny zacząć traktować zgody OAuth jako krytyczną kontrolę tożsamości.
Kluczowe obszary do przeglądu to:
| Obszar | Co sprawdzić |
|---|---|
| Inwentarz aplikacji OAuth | Zidentyfikuj każdą aplikację firm trzecich posiadającą tokeny odświeżania w tenancie |
| Wiek zgody | Przejrzyj tokeny starsze niż 30 dni bez ponownej zgody |
| Zakresy wysokiego ryzyka | Szukaj uprawnień do poczty, plików, dostępu offline, kalendarza, kontaktów i katalogu |
| Dostęp między aplikacjami | Zidentyfikuj użytkowników ze zgodami w wielu platformach SaaS |
| Agenci AI i integracje | Przejrzyj agentów łączących systemy, które nigdy nie były zatwierdzane razem |
| Dostęp warunkowy | Zastosuj mechanizmy kontroli do zdarzeń zgody, a nie tylko do zdarzeń logowania |
| Unieważnianie tokenów | Przygotuj playbook umożliwiający unieważnienie konkretnej zgody OAuth bez wyłączania użytkownika |
| Workflow zgody administratora | Wymagaj przeglądu aplikacji i uprawnień wysokiego ryzyka |
| Edukacja użytkowników | Szkol użytkowników, że ukończenie MFA nie oznacza, iż następny ekran zgody jest bezpieczny |
Celem jest przejście od okazjonalnych przeglądów zgód do ciągłej widoczności.
Rekomendacje obronne
Aby ograniczyć ryzyko phishingu z wykorzystaniem zgód OAuth, organizacje powinny:
- wyłączyć zgodę użytkownika dla niezweryfikowanych lub wysokiego ryzyka aplikacji
- wymagać zatwierdzenia przez administratora dla wrażliwych zakresów uprawnień
- przejrzeć wszystkie aplikacje przedsiębiorstwa w Microsoft Entra ID
- usunąć nieużywane zgody OAuth
- unieważnić podejrzane tokeny odświeżania
- monitorować zdarzenia zgody w dziennikach audytu
- ustawić alerty dla nowych zgód z dostępem offline
- ustawić alerty dla uprawnień do poczty, plików, kalendarza i kontaktów
- wymagać ponownej zgody dla starych lub ryzykownych zgód
- egzekwować weryfikację wydawcy tam, gdzie to możliwe
- ograniczyć przepływ kodu urządzenia (device code flow) tam, gdzie nie jest wymagany
- przejrzeć polityki dostępu warunkowego pod kątem dostępu opartego na OAuth
- monitorować nietypowy dostęp do API po nowych zdarzeniach zgody
- uwzględnić nadużywanie zgód OAuth w symulacjach phishingu i szkoleniach użytkowników
W reagowaniu na incydenty samo zresetowanie hasła nie wystarcza. Zespoły muszą jawnie unieważnić tokeny i usunąć złośliwe zgody aplikacji.
Gdzie pomaga widoczność grafu tożsamości
Wyzwanie polega na tym, że zgody OAuth, agenci AI, rozszerzenia przeglądarki, łączniki SaaS i tożsamości niebędące ludźmi tworzą złożony graf dostępu.
Żaden pojedynczy właściciel aplikacji nie widzi łatwo pełnego obrazu.
Nowoczesne platformy bezpieczeństwa tożsamości zaczynają rozwiązywać ten problem, mapując:
- tożsamości ludzkie
- konta usługowe
- zgody OAuth
- aplikacje SaaS
- agentów AI
- integracje
- zakresy uprawnień
- wiek tokenów
- wzorce zachowań
- mosty między aplikacjami
Pomaga to zespołom ds. bezpieczeństwa wykrywać toksyczne kombinacje i unieważniać dostęp na poziomie tokenu zamiast podejmować szerokie działania, takie jak wyłączenie całego konta użytkownika.
Ważną zmianą jest przejście od statycznych list audytowych do ciągłej widoczności w czasie rzeczywistym.
Podsumowanie
EvilTokens pokazuje, że phishing ewoluował.
Najgroźniejszym kliknięciem nie zawsze jest już to, które przesyła hasło. Coraz częściej jest to kliknięcie zatwierdzające dostęp.
MFA pozostaje niezbędne, ale nie ochroni przed złośliwą zgodą OAuth, którą użytkownik zatwierdza po ukończeniu legalnego uwierzytelniania. Atakujący przesuwają się poniżej tradycyjnego obwodu tożsamości i atakują bezpośrednio warstwę zgód.
Organizacje muszą odpowiedzieć na to, traktując zgody OAuth, tokeny odświeżania, agentów AI i integracje SaaS jako pełnoprawne ryzyka dla tożsamości.
Przyszłość obrony przed phishingiem to nie tylko ochrona haseł. To kontrola zaufania po uwierzytelnieniu.
