Logujesz się na prawdziwej stronie Microsoftu. Dostęp dostaje ktoś inny
6 kwietnia 2026 Microsoft opisał kampanię phishingową, w której ofiara mogła zalogować się na prawdziwej stronie firmy i mimo to przekazać dostęp napastnikowi. Badacze powiązali ją z narzędziem EvilTokens. Przynętami były między innymi faktury, zapytania ofertowe i udostępnione dokumenty. Ten tekst wraca do opisanego wtedy mechanizmu, nie donosi o nowym październikowym ataku.
Najbardziej niewygodny szczegół: sprawdzenie domeny może tu wypaść poprawnie. Hasło trafia tam, gdzie powinno. Problemem jest to, czyją prośbę o dostęp właśnie zatwierdzasz.
Archiwalny szyld Microsoftu w Redmond, 2005. Fot. Derrick Coetzee / Wikimedia Commons, domena publiczna. Zdjęcie ilustracyjne, pomniejszone i dopasowane do ramki.
Po co w ogóle logowanie kodem urządzenia
Logowanie do konta na telewizorze przy użyciu pilota jest uciążliwe. Podobny problem mają drukarki i inne urządzenia bez wygodnej przeglądarki. OAuth przewiduje dla nich mechanizm nazywany device authorization grant, a w dokumentacji Microsoftu także device code flow.
Urządzenie wyświetla krótki kod. Użytkownik otwiera stronę dostawcy tożsamości na telefonie albo komputerze, wpisuje go i przechodzi uwierzytelnienie. Kod pozwala powiązać tę czynność z oczekującą aplikacją. Po zatwierdzeniu to ona dostaje tokeny umożliwiające dostęp w przyznanym zakresie.
Takie rozdzielenie jest zamierzone: ekran, na którym podajesz hasło, nie musi być urządzeniem otrzymującym dostęp. Cała wygoda opiera się jednak na założeniu, że wiesz, skąd pochodzi prośba.
W device code phishing napastnik nakłania cię do zatwierdzenia sesji, którą sam rozpoczął. Kod przysłany razem z obietnicą otwarcia dokumentu ma zastąpić kod z twojego własnego urządzenia. To nie jest kod jednorazowy wygenerowany przez twój Authenticator. Podobny wygląd krótkich ciągów znaków nie oznacza tej samej funkcji.
Co zawodzi w radzie „sprawdź adres”
Przy fałszywej stronie e-Urzędu Skarbowego rozpoznanie obcej domeny pozwalało zauważyć podmianę. Tutaj prawidłowy adres potwierdza dostawcę logowania, ale nie zamiar osoby, która przysłała kod.
Microsoft opisuje przekazanie tokenów do sesji kontrolowanej przez atakującego po tym, jak użytkownik ukończył prawidłowe uwierzytelnienie. W badanej kampanii dostęp wykorzystywano do pobierania poczty, tworzenia reguł skrzynki i rozpoznawania organizacji. To ustalenia autorów raportu dotyczące obserwowanej przez nich aktywności.
Nie wyciągałbym stąd wniosku, że MFA jest bezużyteczne. Dodatkowy składnik potwierdza tożsamość osoby wykonującej logowanie. Sam nie rozstrzyga, czy ta osoba właściwie rozpoznała cel operacji. Możliwość skorzystania z danego przepływu zależy też od polityk organizacji. Opisany atak nie dowodzi przełamania każdego rodzaju uwierzytelniania ani każdej konfiguracji Microsoft 365.
Zwykłe szkolenie o literówkach w domenie zostawia więc lukę. Trzeba jeszcze wyjaśnić, co użytkownik zatwierdza na stronie, której ufa.
Dokument nie tłumaczy każdej prośby o kod
Przed wpisaniem kodu warto wrócić do początku czynności. Czy właśnie uruchomiłeś logowanie na swoim urządzeniu albo w znanej aplikacji? Czy potrafisz wskazać, komu ten dostęp ma służyć? Sam fakt, że wiadomość obiecuje fakturę, nie daje odpowiedzi.
Jeśli niespodziewany mail każe przepisać kod, żeby zobaczyć plik, przerwij tę ścieżkę. Sprawdź sprawę u nadawcy znanym wcześniej kanałem, choćby pod zapisanym numerem telefonu. Odpowiedź w tym samym wątku może wrócić do osoby kontrolującej przejętą skrzynkę. Znane nazwisko nadawcy nie zastępuje weryfikacji prośby.
Nie proponuję zakazu każdego logowania kodem. Administratorzy i użytkownicy części aplikacji mają ku temu normalne powody. Chodzi o rozpoznanie własnej czynności, zanim wiadomość od kogoś innego nada jej pozorny sens.
Kod już wpisany. Co teraz
Jeśli chodzi o konto służbowe, zgłoś zdarzenie zespołowi IT lub osobie odpowiedzialnej za Microsoft 365. Podaj przybliżoną godzinę i przekaż podejrzaną wiadomość ustalonym w firmie sposobem. Nie przesyłaj przy tym hasła ani kolejnych kodów uwierzytelnienia. Zamknięcie karty przeglądarki nie cofa dostępu przyznanego innej aplikacji.
Procedura Microsoftu dla przejętej skrzynki obejmuje zabezpieczenie konta, unieważnienie sesji i zmianę hasła, a następnie sprawdzenie śladów oraz ustawień pozostawionych przez intruza. Administrator powinien zajrzeć do metod MFA, zgód aplikacji, przekazywania poczty i reguł skrzynki, również ukrytych. Logi logowań i audytu pomagają ustalić, co wydarzyło się po zatwierdzeniu kodu. Przy potwierdzonym przejęciu dokumentacja zaleca wyłączenie konta na czas zabezpieczania.
Samo nowe hasło nie jest dowodem odzyskania kontroli. W tym przypadku interesują nas także wydane wcześniej tokeny i sesje. Microsoft zaznacza, że cofnięcie dostępu zależy od ich rodzaju oraz zachowania aplikacji. Sesja utrzymywana przez samą aplikację może wymagać osobnego zakończenia; efekt administracyjnego unieważnienia nie musi być wszędzie natychmiastowy.
To procedura dla organizacji zarządzającej kontem, nie zestaw ustawień dostępny każdemu posiadaczowi prywatnego Outlooka.
Administrator może ograniczyć ten przepływ
Microsoft zaleca blokowanie device code flow tam, gdzie nie jest potrzebny. W Entra Conditional Access istnieje warunek dotyczący przepływów uwierzytelniania, który pozwala objąć go taką polityką.
Najpierw trzeba jednak sprawdzić użycie. W przeciwnym razie zabezpieczenie może przerwać pracę legalnej aplikacji. Dokumentacja zaleca przetestowanie polityki w trybie report-only, ocenę wyników i dopiero potem włączenie blokady. Report-only pozwala zobaczyć skutki planowanej reguły, ale jeszcze nie zatrzymuje logowań. Potrzebne wyjątki powinny być wąskie i udokumentowane, z uwzględnieniem procedur dostępu awaryjnego.
Dla użytkownika zostaje prostsza zmiana nawyku: przy niespodziewanej prośbie o kod sprawdzić również, dla jakiego urządzenia albo aplikacji ma on zatwierdzić dostęp. Prawdziwa domena Microsoftu nie odpowie na to pytanie za nadawcę wiadomości.
Źródła
- Microsoft Security: kampania device code phishing powiązana z EvilTokens, 6 kwietnia 2026
- Microsoft Learn: Microsoft identity platform i OAuth 2.0 device authorization grant
- Microsoft Learn: reagowanie na przejęcie konta pocztowego Microsoft 365
- Microsoft Learn: unieważnianie dostępu, tokenów i sesji użytkownika
- Microsoft Learn: blokowanie przepływów uwierzytelniania przez Conditional Access
Jak pracuję ze źródłami i poprawiam błędy. Znalazłeś błąd? Podaj fragment i źródło.