Wprowadzenie do problemu / definicja
Nowa fala ataków wymierzonych w środowiska Microsoft 365 pokazuje, że polityka BYOD może stać się skutecznym wektorem wejścia do zasobów firmowych nawet przy wdrożonych zabezpieczeniach poczty, tożsamości i punktów końcowych. W tym scenariuszu cyberprzestępcy wykorzystują połączenia głosowe oraz wiadomości SMS kierowane na prywatne telefony pracowników, podszywając się pod firmowe wsparcie IT.
Celem ataku nie jest samo przejęcie urządzenia, lecz nakłonienie ofiary do wykonania działań uwierzytelniających, które otwierają dostęp do konta Microsoft 365. Po uzyskaniu dostępu napastnicy mogą prowadzić rekonesans, utrwalać obecność w środowisku i stopniowo wyprowadzać dane z usług chmurowych.
W skrócie
- Ataki obserwowane od maja 2026 roku wykorzystują vishing i SMS-y na prywatne telefony pracowników.
- Ofiary są nakłaniane do rzekomej aktualizacji passkey, MFA lub konfiguracji SSO.
- Napastnicy stosują fałszywe strony logowania oraz scenariusze device code phishing.
- Po przejęciu konta rejestrują własne metody MFA i budują trwałość dostępu.
- Do rekonesansu i pobierania danych wykorzystywany jest Microsoft Graph API oraz usługi SharePoint, OneDrive i Exchange.
- Duża część łańcucha ataku omija klasyczną telemetrię urządzeń zarządzanych.
Kontekst / historia
W ostatnich latach ataki na organizacje coraz wyraźniej przesuwają się z obszaru malware do warstwy tożsamości, użytkownika i usług chmurowych. Zamiast uruchamiania złośliwego kodu napastnicy chętniej nadużywają legalnych mechanizmów logowania, tokenów sesyjnych i autoryzowanych interfejsów API.
W opisywanej kampanii wykorzystano naturalne zachowania pracowników: odbieranie połączeń na prywatnych telefonach, reagowanie na pilne prośby rzekomego helpdesku oraz korzystanie z własnych urządzeń do dostępu do zasobów służbowych. To sprawia, że atak jest wiarygodny i trudniejszy do odróżnienia od prawdziwych działań administracyjnych.
Aktywność była obserwowana co najmniej od maja 2026 roku. Kampania jest wiązana z grupami określanymi jako Storm-3032 i Storm-3121, a uzyskany dostęp może być wykorzystywany dalej w działaniach ekstorsyjnych lub przekazywany innym podmiotom z cyberprzestępczego ekosystemu.
Analiza techniczna
Łańcuch ataku zwykle zaczyna się od telefonu lub wiadomości SMS na prywatny numer pracownika. Osoba kontaktująca się z ofiarą podaje się za przedstawiciela działu IT i buduje presję czasu, informując o konieczności pilnej aktualizacji passkey, MFA albo logowania jednokrotnego. Tego rodzaju komunikat odwołuje się do znanych procedur bezpieczeństwa, dzięki czemu wzmacnia wiarygodność oszustwa.
Następnie ofiara otrzymuje odnośnik do strony przypominającej prawdziwy portal logowania Microsoft lub zostaje poprowadzona przez legalnie wyglądający proces autoryzacji. W praktyce obserwowane są dwa główne warianty: atak adversary-in-the-middle, w którym przechwytywane są poświadczenia i tokeny sesyjne, oraz device code phishing, gdzie użytkownik sam autoryzuje dostęp dla napastnika poprzez prawidłowo wyglądający mechanizm uwierzytelniania.
Po przejęciu tożsamości atakujący przechodzą do ustanowienia trwałości. Rejestrują własne metody MFA lub dodatkowe urządzenia uwierzytelniające, co pozwala utrzymać dostęp także po wygaśnięciu pierwotnej sesji. To kluczowy moment, ponieważ incydent przestaje być jednorazowym przechwyceniem logowania i staje się trwałą kompromitacją konta.
Kolejnym etapem jest rekonesans z użyciem Microsoft Graph API. Z perspektywy napastnika to bardzo atrakcyjne narzędzie, ponieważ umożliwia przegląd użytkowników, grup, ról, uprawnień, witryn i zasobów w tenantach Microsoft 365 przy użyciu legalnych wywołań API. Pojedyncze zapytania nie muszą wyglądać podejrzanie, ale ich korelacja może ujawnić schemat rozpoznania środowiska.
Po zmapowaniu zasobów rozpoczyna się etap dostępu do danych. Napastnicy pobierają dokumenty, wiadomości i załączniki z usług takich jak SharePoint, OneDrive i Exchange. Zamiast jednorazowego, dużego transferu często stosowane są mniejsze i rozłożone w czasie pobrania, co utrudnia wykrycie na podstawie prostych progów anomalii.
Dodatkowym problemem dla zespołów bezpieczeństwa jest ograniczona widoczność początku incydentu. Jeżeli użytkownik wykonał działania na prywatnym telefonie nieobjętym EDR ani MDM, organizacja może nie dysponować żadną telemetrią z tego etapu. Rekonstrukcja ataku opiera się wtedy głównie na logach tożsamości, rejestracji metod MFA, aktywności tokenów i operacjach wykonywanych przez Graph API.
Konsekwencje / ryzyko
Skuteczny atak tego typu może zapewnić bezpośredni dostęp do dokumentów firmowych, poczty, danych projektowych, informacji finansowych oraz materiałów objętych tajemnicą przedsiębiorstwa. Oznacza to realne ryzyko wycieku danych, utraty przewagi konkurencyjnej i naruszenia obowiązków regulacyjnych.
Przejęte konto może zostać wykorzystane również do dalszego phishingu wewnętrznego. Dzięki temu napastnicy mogą zwiększać zasięg operacji, próbować przejąć konta uprzywilejowane i rozszerzać kompromitację na kolejne obszary tenanta Microsoft 365.
Szczególnie istotne jest to, że nadużywane są legalne funkcje chmurowe, a nie złośliwe pliki czy procesy. W efekcie tradycyjne mechanizmy obronne oparte na sygnaturach, IOC i detekcji malware mogą okazać się niewystarczające. Ciężar wykrywania przesuwa się więc na analizę behawioralną tożsamości oraz telemetrykę SaaS.
W modelu BYOD problem nie sprowadza się wyłącznie do samego prywatnego urządzenia. Kluczowe znaczenie ma brak zaufanej ścieżki komunikacji, ograniczona kontrola nad kontekstem logowania oraz możliwość zmanipulowania użytkownika do samodzielnego nadania dostępu atakującemu.
Rekomendacje
Podstawą obrony powinno być wdrożenie phishing-resistant MFA wszędzie tam, gdzie jest to możliwe. Dotyczy to w szczególności FIDO2, passkeys oraz rozwiązań takich jak Windows Hello for Business. Równolegle warto silnie ograniczyć możliwość rejestracji nowych metod uwierzytelniania i dopuścić ją tylko w kontrolowanych scenariuszach.
Istotną rolę odgrywa także polityka Conditional Access. Dostęp do Exchange Online, SharePoint Online, OneDrive oraz aplikacji wykorzystujących Graph powinien być ograniczony do urządzeń zarządzanych i zgodnych z polityką bezpieczeństwa. Jeżeli organizacja dopuszcza urządzenia niezarządzane, warto rozważyć sesje wyłącznie webowe bez możliwości pobierania i synchronizacji plików.
W wielu środowiskach zasadne będzie wyłączenie przepływu device code oraz authentication transfer tam, gdzie nie ma uzasadnionej potrzeby biznesowej. Dodatkowo należy ograniczyć user consent dla aplikacji, wymagać akceptacji administracyjnej dla uprawnień wysokiego ryzyka oraz regularnie przeglądać service principals i delegowane uprawnienia do Graph.
Od strony detekcji organizacje powinny monitorować przede wszystkim ciągi zdarzeń, a nie pojedyncze alerty. Szczególną uwagę warto zwracać na:
- nietypowe logowania poprzedzające rejestrację nowych metod MFA,
- nagły wzrost zapytań Graph związanych z enumeracją użytkowników, grup, ról i witryn,
- nietypowe pobrania z SharePoint i OneDrive,
- wzorce dostępu do skrzynek pocztowych przez API,
- zmiany w regułach skrzynek i ustawieniach tożsamości po podejrzanych logowaniach.
Nie mniej ważne są procedury organizacyjne. Pracownicy powinni wiedzieć, że dział IT nie inicjuje spontanicznie przez prywatny telefon resetów MFA ani nie wysyła linków do pilnej aktualizacji passkey bez wcześniej potwierdzonego zgłoszenia. Konieczne jest też wdrożenie jednego oficjalnego kanału raportowania podejrzanych połączeń i próśb o uwierzytelnienie.
Jeżeli kompromitacja zostanie wykryta, należy natychmiast unieważnić aktywne sesje i tokeny odświeżania, zresetować poświadczenia, usunąć nieautoryzowane metody MFA, przeanalizować zgody OAuth i ustalić zakres dostępu do danych w SharePoint, OneDrive oraz Exchange. Sam reset hasła może nie wystarczyć, jeśli napastnik utrwalił dostęp przez dodatkowe metody uwierzytelniania lub aktywne tokeny.
Podsumowanie
Opisywana kampania potwierdza, że nowoczesne ataki na Microsoft 365 coraz częściej opierają się nie na luce technicznej, lecz na przejęciu zaufania użytkownika i nadużyciu legalnych funkcji chmurowych. Połączenie vishingu, BYOD, fałszywych scenariuszy aktualizacji passkey oraz rekonesansu przez Microsoft Graph API tworzy trudny do wykrycia łańcuch ataku mogący zakończyć się wyciekiem danych bez użycia klasycznego malware.
Dla obrońców kluczowe staje się przesunięcie nacisku z ochrony pojedynczego urządzenia na ochronę tożsamości, kontekstu logowania i zachowań w usługach SaaS. To właśnie kontrola dostępu, odporne na phishing mechanizmy MFA, monitoring aktywności Graph i dojrzałe procedury helpdeskowe powinny dziś stanowić fundament obrony.