BigBear 2.0 omija MFA w Microsoft 365 i przejmuje sesje po uwierzytelnieniu

Wprowadzenie do problemu / definicja

BigBear 2.0 to platforma phishing-as-a-service zaprojektowana do ataków na środowiska Microsoft 365 z użyciem techniki adversary-in-the-middle. Jej celem nie jest bezpośrednie łamanie mechanizmów wieloskładnikowego uwierzytelniania, lecz przechwytywanie już uwierzytelnionych sesji użytkowników, co pozwala napastnikom ominąć MFA i uzyskać dostęp do kont oraz zasobów chmurowych.

To istotna zmiana w krajobrazie zagrożeń, ponieważ skuteczna ochrona nie kończy się dziś na wdrożeniu drugiego składnika logowania. Coraz częściej atak przenosi się na poziom tokenów, ciasteczek sesyjnych i kontekstu dostępu po poprawnym zalogowaniu.

W skrócie

Badacze opisali operację BigBear 2.0, wykorzystywaną do kradzieży poświadczeń i sesji Microsoft 365 na szeroką skalę. Według ujawnionych ustaleń kampania objęła setki organizacji, a liczba przechwyconych rekordów uwierzytelnienia przekroczyła 5000.

atak bazował na modelu reverse proxy i frameworku Evilginx2,
przechwytywano tokeny oraz ciasteczka sesyjne po poprawnym przejściu MFA,
stosowano rezydencyjne proxy do ukrywania anomalii logowania,
użyto niestandardowego JavaScriptu do ograniczania FIDO2 i WebAuthn,
szczególnie atrakcyjnym celem były organizacje IT i dostawcy usług zarządzanych.

Kontekst / historia

Model phishing-as-a-service od lat obniża próg wejścia dla cyberprzestępców. Zamiast samodzielnie budować infrastrukturę, operatorzy i afilianci korzystają z gotowych paneli, szablonów kampanii, mechanizmów exfiltracji danych oraz zaplecza serwerowego, które można szybko uruchomić przeciw wybranym organizacjom.

BigBear 2.0 wpisuje się w ten trend, ale wyróżnia się silnym ukierunkowaniem na Microsoft 365 oraz praktycznym obejściem MFA przez przejęcie sesji. Taki model jest szczególnie groźny w firmach, gdzie jedno konto może zapewniać dostęp do poczty, plików, komunikacji, aplikacji biznesowych i administracji tożsamością.

Z ujawnionych analiz wynika, że badacze uzyskali wgląd w panel administracyjny usługi i zidentyfikowali infrastrukturę obsługującą wielu afiliantów. Dane wskazywały również na szeroki zasięg geograficzny kampanii oraz zainteresowanie podmiotami, których przejęcie mogło ułatwić dalszą kompromitację kolejnych środowisk.

Analiza techniczna

Rdzeń operacji opierał się na technice AiTM, w której ofiara trafia na fałszywą, ale wiarygodnie wyglądającą stronę logowania. Strona ta działa jako pośrednik między użytkownikiem a prawdziwą usługą Microsoft, przekazując ruch w obie strony i jednocześnie rejestrując wrażliwe dane uwierzytelniające.

Kluczowy moment następuje po poprawnym zalogowaniu i zatwierdzeniu MFA. Zamiast próbować przełamać drugi składnik, atakujący przechwytuje wystawione przez legalną usługę ciasteczko sesyjne lub powiązany token i wykorzystuje go do odtworzenia sesji po swojej stronie. Dzięki temu może uzyskać dostęp do konta bez ponownego wywoływania procesu MFA.

W przeanalizowanych danych miały znajdować się tysiące rekordów obejmujących hasła, artefakty sesyjne i przypadki pełnego przejęcia aktywnej sesji. Istotne jest jednak rozróżnienie między organizacjami obecnymi w danych kampanii a tymi, w których potwierdzono co najmniej jedno skuteczne obejście MFA i realny kompromis dostępu.

Dodatkową warstwą ukrywania aktywności były rezydencyjne serwery proxy. Pozwalały one dopasowywać geolokalizację adresu IP do regionu ofiary, co utrudniało wykrywanie nietypowych logowań wyłącznie na podstawie lokalizacji. Operatorzy zastosowali też niestandardowy kod JavaScript ograniczający lub zakłócający obsługę FIDO2 i WebAuthn, aby skłonić użytkowników do metod podatniejszych na przechwycenie w modelu proxy.

Z perspektywy obrony to ważna obserwacja: BigBear 2.0 nie atakuje samego algorytmu MFA. Uderza w warstwę sesji po uwierzytelnieniu, co oznacza, że nawet poprawnie wykonane MFA nie gwarantuje bezpieczeństwa, jeśli cały proces logowania przebiegł przez infrastrukturę kontrolowaną przez napastnika.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem takiego incydentu jest przejęcie aktywnej tożsamości użytkownika w Microsoft 365. W praktyce może to oznaczać dostęp do Exchange Online, OneDrive, SharePoint, Teams oraz aplikacji zintegrowanych przez mechanizmy jednokrotnego logowania.

Jeżeli przejęte konto należy do administratora, pracownika działu IT lub operatora MSP, incydent może szybko eskalować. Napastnik może nie tylko odczytywać dane, ale także utrwalać dostęp, rejestrować nowe metody MFA, tworzyć reguły przekierowań poczty, nadawać zgody OAuth złośliwym aplikacjom lub wykorzystywać przejętą tożsamość do dalszych oszustw BEC.

Kampania pokazuje też ograniczenia podejścia, w którym MFA traktowane jest jako ostateczna warstwa ochrony. W modelu przechwycenia sesji moment pomyślnego przejścia MFA może stać się chwilą, w której atakujący zdobywa najcenniejszy materiał uwierzytelniający.

Rekomendacje

Organizacje powinny traktować aktywność tego typu jako kompromitację sesji, a nie jedynie wyciek hasła. Reakcja powinna obejmować natychmiastowe unieważnienie aktywnych sesji, odwołanie tokenów odświeżania, wymuszenie ponownego uwierzytelnienia oraz reset ujawnionych haseł, zwłaszcza dla kont uprzywilejowanych.

Warto również przeprowadzić przegląd logów i aktywności w środowisku Microsoft 365 pod kątem:

nietypowych logowań następujących po poprawnym MFA,
tworzenia reguł skrzynkowych i przekierowań poczty,
nowych rejestracji metod uwierzytelniania,
zmian ról i uprawnień administracyjnych,
podejrzanych zgód OAuth,
dostępu do danych z nowych urządzeń lub klientów.

Strategicznie kluczowe jest wymuszanie metod phishing-resistant, a nie tylko ich udostępnianie. FIDO2, WebAuthn, passkeys, uwierzytelnianie certyfikatowe oraz uzależnienie dostępu od zarządzanego urządzenia mogą znacząco ograniczyć skuteczność kampanii AiTM.

Równie ważne jest odejście od polityk bazujących wyłącznie na geolokalizacji, ponieważ rezydencyjne proxy pozwalają skutecznie imitować lokalny ruch. W praktyce większą wartość dają mechanizmy ochrony tokenów, ciągła ocena dostępu, analiza ryzyka sesji oraz integracja sygnałów tożsamościowych z SOC i SIEM.

W obszarze świadomości użytkowników należy podkreślać, że poprawnie wyglądający ekran logowania i działające MFA nie są już wystarczającym dowodem bezpieczeństwa. Ochrona musi obejmować cały łańcuch uwierzytelnienia, od urządzenia i przeglądarki po kontrolę sesji po zalogowaniu.

Podsumowanie

BigBear 2.0 pokazuje, że nowoczesny phishing coraz częściej koncentruje się na przejęciu sesji, a nie wyłącznie na kradzieży haseł. Dla organizacji korzystających z Microsoft 365 oznacza to konieczność wzmocnienia ochrony tożsamości, lepszego monitorowania aktywności po logowaniu oraz wdrożenia metod uwierzytelniania odpornych na phishing.

Ataki tego typu przesuwają punkt ciężkości obrony z samego momentu logowania na bezpieczeństwo tokenów, ciasteczek sesyjnych i całego kontekstu dostępu. W praktyce tylko wielowarstwowe podejście do ochrony tożsamości chmurowej może ograniczyć ryzyko skutecznego obejścia MFA przez przejęcie sesji.