Kampania wykorzystująca kradzież i powtórne użycie tokenów uwierzytelniających doprowadziła do przejęcia 97 kont w 79 organizacjach. Cyberprzestępcy nie musieli łamać haseł ani ponownie przechodzić uwierzytelniania wieloskładnikowego. Po uzyskaniu dostępu rejestrowali własne urządzenia, podmieniali metody MFA i ukrywali wiadomości e-mail, przygotowując grunt pod kolejne ataki.

Ponad 200 tysięcy prób logowania

Analitycy z firmy Huntress opisali kampanię wymierzoną w środowiska Microsoft 365, prowadzoną od 14 lipca do 22 września 2026 roku. W analizowanych obszarach odnotowano 497 skutecznych logowań powiązanych z kampanią oraz ponad 200 tysięcy nieudanych prób. Ostatecznie atakujący uzyskali dostęp do 97 kont w 79 organizacjach i zarejestrowali co najmniej 48 nieautoryzowanych urządzeń w katalogach Microsoft Entra ID.

Kluczowym elementem operacji była technika token replay, czyli ponowne wykorzystanie skradzionego tokenu uwierzytelniającego. W odróżnieniu od klasycznego ataku brute force czy password spray napastnik nie musi odgadywać hasła. Wystarczy, że przechwyci artefakt potwierdzający poprawne uwierzytelnienie użytkownika, a następnie użyje go w celu uzyskania dostępu do usług chmurowych.

To szczególnie istotne w środowiskach, w których organizacje traktują MFA jako główną barierę przed przejęciem kont. Uwierzytelnianie wieloskładnikowe nadal znacząco ogranicza ryzyko, ale nie chroni automatycznie przed kradzieżą już uwierzytelnionej sesji.

Jak działał atak typu AiTM?

Jednym ze sposobów pozyskania tokenów był atak typu Adversary-in-the-Middle (AiTM). Ofiara trafiała na fałszywą stronę logowania, która pośredniczyła w komunikacji z prawdziwą infrastrukturą Microsoft. Dzięki temu użytkownik widział autentyczny proces logowania i mógł wpisać hasło oraz kod MFA, nie zdając sobie sprawy, że jego sesja jest przechwytywana.

Po zakończeniu uwierzytelniania Microsoft wydawał token sesyjny. Atakujący przejmował go i wykorzystywał na własnym urządzeniu. Ponieważ uwierzytelnienie zostało już przeprowadzone, skradziony artefakt mógł umożliwić dostęp bez ponownego wpisywania hasła i przechodzenia tego samego wyzwania MFA.

Analitycy Huntress zaobserwowali również inne sposoby pozyskiwania tokenów, w tym phishing wykorzystujący przepływ logowania za pomocą kodu urządzenia oraz socjotechnikę podczas prawidłowego procesu logowania. W kampanii nie stosowano więc jednego, niezmiennego scenariusza – atakujący korzystali z różnych dróg pozyskania sesji, a następnie odtwarzali je z własnej infrastruktury.

Badacze określili tę metodę mianem token spraying. Nazwa nawiązuje do password sprayingu, ale zamiast testowania popularnych haseł wobec wielu kont przestępcy na dużą skalę wykorzystywali przechwycone tokeny. W części przypadków od momentu przechwycenia sesji do jej użycia przez atakującego mijało zaledwie kilka minut.

Fałszywe urządzenia i podmiana metod MFA

Uzyskanie dostępu do konta było dla napastników dopiero początkiem. Aby utrzymać kontrolę również po wygaśnięciu skradzionej sesji, rejestrowali oni własne urządzenia w katalogach Microsoft Entra ID. Huntress zidentyfikowało co najmniej 48 takich wpisów. Nazwy przypominały standardowe nazwy komputerów z systemem Windows, ale zawierały prefiks DESKTOP- i osiem znaków szesnastkowych, co stanowiło użyteczny punkt wyjścia do wyszukiwania anomalii.

Jeszcze poważniejszym działaniem była manipulacja metodami uwierzytelniania. W co najmniej 19 organizacjach istniejące metody MFA ofiar usuwano, a następnie rejestrowano nowe, i to w ciągu trzech godzin od pierwszego logowania związanego z kampanią. W jednym z przypadków aplikacja uwierzytelniająca oznaczona jako „iPhone 13” została dodana mniej niż 51 minut po przejęciu sesji.

Taka zmiana może zapewnić napastnikowi trwalszy dostęp do konta. Nawet jeśli pierwotny token przestanie działać, nowo zarejestrowana metoda MFA może pozwolić na przechodzenie kolejnych wyzwań uwierzytelniających. Z tego powodu samo zresetowanie hasła nie jest wystarczającym działaniem naprawczym.

Ukrywanie korespondencji i przygotowanie do oszustw

Po przejęciu skrzynek pocztowych atakujący tworzyli reguły, których zadaniem było ukrywanie wybranych wiadomości. Te zawierające słowa związane z listą płac, przelewami, premiami czy wpłatami były usuwane albo przenoszone do mniej oczywistych folderów, takich jak RSS Feeds lub Conversation History. Część reguł oznaczała przychodzącą korespondencję jako przeczytaną, a następnie ją usuwała.

W jednym z incydentów przejęta skrzynka została wykorzystana do wysyłania spamu setkom zewnętrznych odbiorców. W innym atakujący przygotowywał wiadomości związane z płatnościami i manipulował regułami tak, aby ukrywać odpowiedzi od zewnętrznego kontaktu księgowego.

Takie zachowanie jest charakterystyczne dla ataków typu Business Email Compromise (BEC). Celem nie musi być wyłącznie kradzież danych – przejęta skrzynka może posłużyć do wyłudzania pieniędzy, podszywania się pod pracowników i partnerów biznesowych oraz przechwytywania korespondencji dotyczącej transakcji.

Jak wykrywać i ograniczać ryzyko?

W tego typu kampanii tradycyjne alerty dotyczące błędnych haseł mogą nie wystarczyć. Zespoły SOC powinny analizować logowania do Microsoft Entra ID w kontekście źródłowych adresów IP, aplikacji klienckich, zasobów, identyfikatorów urządzeń oraz nietypowych zmian metod MFA. Szczególną uwagę należy zwrócić na logowania następujące krótko po podejrzanej aktywności, rejestrację nowych urządzeń i modyfikacje reguł skrzynki pocztowej.

W analizowanej kampanii ruch związany z ponownym użyciem tokenów pochodził m.in. z zakresu 193.26.115[.]0/24. Jest to wskaźnik powiązany z opisaną operacją, a nie samodzielny dowód włamania. Wskaźniki infrastrukturalne mogą się zmieniać, dlatego nie powinny zastępować analizy zachowania użytkownika i sesji. Warto również wyszukiwać nietypowe nazwy urządzeń, takie jak DESKTOP- zakończone ośmioma znakami szesnastkowymi, oraz podejrzane reguły pocztowe o nazwach takich jak sss, ss, iT czy d.

Microsoft zaleca wielowarstwową ochronę tokenów: ograniczanie ryzyka ich kradzieży na urządzeniach, stosowanie polityk Conditional Access, wykrywanie ryzykownych logowań oraz wykorzystanie mechanizmów ochrony sesji tam, gdzie są dostępne i obsługiwane. Polityki Conditional Access powinny wymagać MFA lub blokować dostęp zgodnie z ryzykiem i kontekstem logowania, a operacje wrażliwe mogą wymagać ponownego, odpornego na phishing uwierzytelnienia. Dostęp do możliwości takich jak Token Protection jest zależny od rodzaju urządzenia, aplikacji i licencji.

Jeżeli organizacja podejrzewa przejęcie konta, powinna unieważnić aktywne sesje, zresetować hasło i sprawdzić wszystkie metody MFA oraz zarejestrowane urządzenia. Należy usunąć nieautoryzowane wpisy, przejrzeć reguły skrzynki, aplikacje przedsiębiorstwa i uprawnienia, a także sprawdzić, czy z konta nie wysyłano podejrzanych wiadomości. Sam reset hasła bez unieważnienia sesji i kontroli utrwalonych metod dostępu może pozostawić napastnikowi możliwość powrotu.

MFA to nie koniec ochrony tożsamości

Kampania Huntress pokazuje, że skuteczna ochrona Microsoft 365 wymaga spojrzenia na cały cykl uwierzytelniania – od momentu wpisania danych przez użytkownika po ochronę wydanych tokenów i monitorowanie działań po zalogowaniu. MFA pozostaje ważnym zabezpieczeniem, ale nie należy utożsamiać poprawnego przejścia tego procesu z gwarancją, że sesja pozostanie bezpieczna.

W praktyce najważniejsze jest połączenie polityk dostępu warunkowego, ochrony urządzeń, analizy ryzyka logowania i monitorowania zmian w Entra ID oraz Exchange Online. Dopiero taki zestaw kontroli utrudnia zarówno kradzież tokenu, jak i wykorzystanie go do długotrwałego przejęcia konta.