BigBear 2.0 przejmuje sesje Microsoft 365 po MFA

Skala jest istotna, ale liczby trzeba czytać precyzyjnie. CloudSEK znalazł w panelu 5 137 rekordów, w tym 4 148 plików cookie sesji, 1 032 przechwycone hasła i 474 ukończone uwierzytelnienia z przejęciem sesji po MFA. Dane obejmowały 461 organizacji w szerszym zbiorze targetowania. Według doprecyzowania przekazanego BleepingComputer 258 odrębnych organizacji miało co najmniej jedno ukończone przejęcie sesji po MFA.

Dla użytkownika szczególnie istotny jest inny element: CloudSEK opisał własny JavaScript BigBear 2.0, który próbował wyłączyć FIDO2/WebAuthn i skłonić ofiarę do przejścia na słabszą metodę logowania. Jeżeli znany proces uwierzytelniania nagle nie pozwala użyć klucza bezpieczeństwa lub innej metody odpornej na phishing i proponuje „awaryjny” powrót do kodu, to jest moment na przerwanie procesu.

Co CloudSEK znalazł w panelu BigBear 2.0

CloudSEK to firma zajmująca się analizą zagrożeń. Jej zespół TRIAD podał, że w czerwcu 2026 roku uzyskał dostęp administracyjny do panelu BigBear 2.0 i mógł obserwować sposób zarządzania infrastrukturą oraz danymi przechwytywanymi przez operatorów.

Według raportu BigBear 2.0 jest oparty na Evilginx2, czyli narzędziu pozwalającym budować strony pośredniczące w logowaniu. Panel był skonfigurowany wyłącznie pod Microsoft 365. W całym cyklu kampanii badacze zaobserwowali 42 węzły VPS, a co najmniej pięciu operatorów afiliacyjnych otrzymywało przechwycone dane w czasie rzeczywistym przez osobne boty Telegram.

Najbardziej użyteczny obraz skali daje zestaw danych w panelu:

• 5 137 rekordów związanych z kampanią,
• 4 148 plików cookie sesji,
• 1 032 przechwycone hasła,
• 474 ukończone uwierzytelnienia z przejęciem sesji po MFA,
• 3 331 unikalnych adresów IP ofiar w ponad 40 krajach,
• 461 organizacji obecnych w danych o targetowaniu.

Te kategorie częściowo się nakładają, więc nie należy ich sumować ani traktować jako liczby unikalnych kont. Równie ważne jest rozróżnienie między organizacją, która pojawiła się w danych o targetowaniu, a organizacją, w której zarejestrowano ukończone przejęcie po MFA.

461 targetowanych organizacji to nie 461 potwierdzonych kompromitacji

To rozróżnienie jest kluczowe dla rzetelnego opisu tej kampanii. Sam raport CloudSEK pokazuje 461 organizacji w danych związanych z targetowaniem. BleepingComputer podał jednak dodatkowe wyjaśnienie CloudSEK: 258 odrębnych organizacji miało co najmniej jedno ukończone przejęcie sesji po MFA.

Dlatego stwierdzenie „BigBear skompromitował 461 organizacji” byłoby zbyt daleko idące. Bezpieczniej mówić o 461 organizacjach w szerszym zbiorze targetowania oraz 258 organizacjach z co najmniej jednym ukończonym przejęciem po MFA.

Podobnie 5 137 rekordów nie oznacza 5 137 różnych użytkowników. W panelu występują różne rodzaje danych dotyczących logowania i sesji, a część z nich dotyczy tego samego zdarzenia lub konta.

Jak BigBear przejmuje sesję po MFA

Mechanizm należy do klasy AiTM, czyli adversary-in-the-middle — ataku z pośrednikiem w procesie logowania. W praktyce infrastruktura napastnika znajduje się pomiędzy przeglądarką użytkownika a prawdziwym serwisem logowania Microsoft.

Schemat wygląda tak:

1. użytkownik trafia na link do strony phishingowej, najczęściej z wiadomości,
2. strona pośrednicząca przekazuje żądania do prawdziwego logowania Microsoft 365,
3. użytkownik wpisuje login i hasło,
4. Microsoft uruchamia zwykły drugi składnik uwierzytelniania,
5. użytkownik poprawnie kończy MFA,
6. Microsoft wystawia uwierzytelnioną sesję,
7. pośrednik przechwytuje plik cookie sesji i może go odtworzyć po stronie napastnika.

To nie jest atak polegający na odszyfrowaniu jednorazowego kodu ani złamaniu matematyki MFA. Napastnik wykorzystuje fakt, że ofiara sama kończy prawidłowy proces logowania, ale robi to przez domenę kontrolowaną przez atakującego.

Szerszy mechanizm opisujemy w evergreenie Phishing omijający MFA AiTM. BigBear 2.0 jest świeżym przykładem tego samego problemu opakowanego w usługę z panelem, afiliantami, automatyzacją i skalą operacyjną.

Dlaczego BigBear próbuje wyłączyć FIDO2 i WebAuthn

FIDO2 i WebAuthn to standardy uwierzytelniania odpornego na phishing, w których poświadczenie jest powiązane z właściwą domeną. Klucz bezpieczeństwa albo zgodna metoda platformowa nie powinna po prostu zaakceptować żądania z domeny phishingowej tylko dlatego, że ekran wygląda jak Microsoft.

CloudSEK znalazł w BigBear 2.0 własne wstrzyknięcia JavaScript, które modyfikowały dostęp do PublicKeyCredential oraz funkcji navigator.credentials. Cel nie polegał na przełamaniu FIDO2. Strona phishingowa próbowała sprawić, aby taka metoda przestała być dostępna i aby użytkownik przeszedł na słabszy wariant, który da się przechwycić przez pośrednika.

To tworzy bardzo konkretny sygnał dla użytkownika. Jeżeli organizacja normalnie używa klucza bezpieczeństwa, klucza dostępu lub innej metody odpornej na phishing, a strona otwarta z linku nagle twierdzi, że ta metoda nie działa i proponuje SMS, kod jednorazowy albo inny „zapasowy” sposób, nie należy automatycznie wybierać alternatywy.

Najpierw trzeba przerwać logowanie, wejść do usługi znanym adresem lub przez firmowy portal i w razie potrzeby potwierdzić problem z zespołem wsparcia przez wcześniej ustalony kanał.

Proxy z adresami mieszkalnymi utrudnia ocenę logowania po samej lokalizacji

BigBear 2.0 korzystał również z puli proxy z adresami mieszkalnymi (residential proxy). Są to serwery pośredniczące wykorzystujące adresy IP wyglądające jak zwykłe łącza użytkowników, a nie typowe centra danych. CloudSEK opisał pule dla 69 krajów i automatyczny dobór kraju do lokalizacji ofiary.

Taki mechanizm może sprawić, że logowanie widoczne po stronie usługi będzie geograficznie bardziej podobne do normalnej aktywności użytkownika. Ogranicza to wartość prostych reguł opartych wyłącznie na kraju lub nietypowej lokalizacji.

Nie oznacza to jednak, że BigBear automatycznie omija każdą politykę dostępu warunkowego (Conditional Access). Kontrole wymagające zgodnego urządzenia, odpowiedniej siły uwierzytelnienia, oceny ryzyka i dodatkowych sygnałów nadal mogą przerwać atak. Wniosek jest bardziej praktyczny: sama zgodność kraju logowania nie powinna być traktowana jako dowód, że sesja jest bezpieczna.

Co widzi użytkownik i gdzie powinien przerwać proces

Problem z AiTM polega na tym, że ekran może wyglądać poprawnie, bo pośrednik przekazuje prawdziwą zawartość usługi logowania. Użytkownik może zobaczyć znane logo, prawidłowy formularz, prośbę o MFA i typową sekwencję ekranów.

Dlatego szkolenie oparte wyłącznie na wyglądzie fałszywej strony jest za wąskie. W scenariuszu BigBear bardziej użyteczne są cztery pytania:

• Czy logowanie zaczęło się z linku w wiadomości, czy ze znanego portalu?
• Czy domena w przeglądarce rzeczywiście należy do usługi, do której użytkownik chce się zalogować?
• Czy system nagle odrzuca zwykle używaną metodę odporną na phishing i namawia do słabszej alternatywy?
• Czy prośba o logowanie pasuje do rzeczywistej czynności, którą użytkownik przed chwilą wykonywał?

W PHISHLY ten rodzaj ryzyka łączy się z szerszym problemem uprzemysłowienia ataków. Artykuł Industrializacja phishingu. Jak PhaaS zamienia oszustwa w powtarzalny proces wyjaśnia, dlaczego panel, infrastruktura i afilianci obniżają próg wejścia dla kolejnych operatorów. Z kolei BlueKit pokazuje, dokąd zmierza Phishing-as-a-Service pokazuje inny wariant usługowego podejścia do przejęcia procesu logowania.

Co zrobić po podejrzeniu przejęcia sesji

Jeżeli użytkownik wpisał dane na stronie AiTM i ukończył MFA, reakcja nie powinna kończyć się na zmianie hasła. Trzeba założyć, że napastnik mógł przejąć aktywną sesję.

W praktyce zespół odpowiedzialny za bezpieczeństwo powinien:

1. zablokować lub ograniczyć dostęp do podejrzanego konta,
2. zmienić hasło,
3. unieważnić aktywne sesje i tokeny odświeżania,
4. wymusić ponowne logowanie,
5. sprawdzić zarejestrowane metody MFA i nowe urządzenia,
6. przejrzeć reguły skrzynki, przekierowania i nietypową wysyłkę,
7. sprawdzić aktywność w SharePoint, OneDrive i innych usługach dostępnych przez Microsoft 365,
8. zweryfikować nowe zgody aplikacji oraz nietypowe zmiany uprawnień.

Dokumentacja Microsoft dotycząca przejętego konta chmurowego również podkreśla, że analiza musi obejmować więcej niż reset hasła. Jeżeli napastnik zdążył użyć sesji albo zmodyfikować konfigurację konta, samo nowe hasło nie usuwa wszystkich skutków zdarzenia.

Co BigBear zmienia w security awareness

Mechanizm techniczny jest złożony, ale decyzja użytkownika może być bardzo konkretna. Nie chodzi o zapamiętanie nazwy Evilginx2 ani analizę kodu JavaScript. Pracownik powinien umieć rozpoznać sytuację, w której proces logowania zmienia się w sposób niezgodny z normalnym doświadczeniem firmy.

Kontrolowany scenariusz szkoleniowy może sprawdzać między innymi:

• czy użytkownik loguje się do Microsoft 365 przez znany portal zamiast przez link z wiadomości,
• czy zwraca uwagę na domenę, nawet gdy ekran wygląda poprawnie,
• czy zatrzyma się, gdy metoda odporna na phishing nagle „przestaje działać”,
• czy zgłosi nietypowy przebieg logowania,
• czy po podejrzeniu wpisania danych wie, że trzeba zgłosić zdarzenie natychmiast, a nie tylko samodzielnie zmienić hasło.

Program security awareness powinien łączyć takie decyzje użytkownika z techniczną ochroną tożsamości i gotową ścieżką reakcji. Z kolei testy phishingowe dla firm mogą mierzyć nie tylko kliknięcie, ale też moment przerwania logowania, zgłoszenie podejrzanej zmiany metody MFA i szybkość reakcji po błędzie.

BigBear 2.0 pokazuje, dlaczego mierzenie samego współczynnika kliknięć nie wystarcza. W nowoczesnym phishingu najcenniejsza decyzja może nastąpić dopiero po kliknięciu: przed wpisaniem danych, przy zmianie metody logowania albo natychmiast po rozpoznaniu, że sesja mogła zostać przejęta.

Podsumowanie

BigBear 2.0 nie wnosi nowej zasady kryptograficznej. Pokazuje natomiast, jak dojrzała usługa PhaaS może połączyć znany mechanizm AiTM z panelem dla wielu operatorów, automatycznym przechwytywaniem sesji, proxy z adresami mieszkalnymi i próbą zepchnięcia użytkownika z FIDO2/WebAuthn na słabszą metodę.

Dla organizacji liczą się trzy rzeczy. Po pierwsze, MFA musi być rozumiane szerzej niż jako dowolny drugi składnik — metody odporne na phishing mają znaczenie. Po drugie, przejęcie sesji wymaga reakcji na sesje i tokeny, a nie tylko zmiany hasła. Po trzecie, pracownik musi wiedzieć, kiedy przerwać nawet bardzo wiarygodnie wyglądający proces logowania.

Właśnie ten ostatni element można ćwiczyć: nie rozpoznawanie konkretnego zestawu phishingowego z nazwy, lecz decyzję użytkownika w momencie, gdy normalny proces Microsoft 365 zaczyna zachowywać się inaczej niż powinien.