MFA nie kończy ataku: gdy celem phishingu jest sesja

Technicznie mechanizmy są różne. Tycoon2FA jest opisywany przede wszystkim jako adversary-in-the-middle (AiTM), czyli pośredniczenie między użytkownikiem a legalną usługą. ORAX według Abnormal wykorzystuje własny interfejs phishingowy synchronizowany z procesem uwierzytelniania i nie wymaga klasycznego reverse proxy.

Dla pracownika stabilna zasada pozostaje taka sama: jeśli wiadomość narzuca nieoczekiwaną ścieżkę logowania, lepiej ją przerwać i samodzielnie otworzyć oczekiwaną usługę. Po przejęciu sesji zagrożenie może przejść z phishingu w Business Email Compromise (BEC), ponieważ napastnik może działać z prawdziwego konta pocztowego.

MFA potwierdza krok, nie cały kontekst logowania

Problem nie polega na tym, że MFA przestaje działać. Użytkownik może wykonać prawidłowy krok uwierzytelnienia w ścieżce, którą wcześniej uruchomił napastnik. ORAX i Tycoon2FA pokazują różne techniczne drogi do podobnego rezultatu: uzyskania sesji po MFA. Stabilnym punktem obrony jest decyzja, czy w ogóle rozpoczynać logowanie z kontekstu narzuconego przez wiadomość.

Co właściwie oznaczają MFA, AiTM, reverse proxy i sesja

MFA: dodatkowy czynnik, nie potwierdzenie całej ścieżki

MFA (multi-factor authentication, czyli uwierzytelnianie wieloskładnikowe) wymaga co najmniej dwóch różnych rodzajów dowodu tożsamości, na przykład czegoś, co użytkownik zna, ma lub czym jest. W praktyce drugim krokiem może być kod jednorazowy, powiadomienie w aplikacji, klucz bezpieczeństwa albo mechanizm oparty na kryptografii klucza publicznego.

W scenariuszu takim jak Tycoon2FA napastnik nie musi „łamać” samego MFA. Microsoft opisuje przekazywanie danych logowania i kodów MFA do prawdziwej usługi w czasie rzeczywistym, a następnie przechwycenie ciasteczka sesyjnego powstającego po udanym uwierzytelnieniu. Użytkownik może więc zobaczyć autentyczne wyzwanie MFA i poprawnie je zatwierdzić, mimo że cały proces został wcześniej rozpoczęty z infrastruktury phishingowej.

AiTM i MitM: podobna idea, inny kontekst

Man-in-the-middle (MitM) to szeroka nazwa sytuacji, w której napastnik ustawia się pomiędzy dwiema komunikującymi się stronami. W phishingu tożsamościowym Microsoft używa określenia adversary-in-the-middle (AiTM) dla infrastruktury, która pośredniczy w procesie logowania między użytkownikiem a prawdziwym dostawcą tożsamości.

Dla użytkownika ważne jest to, że po drugiej stronie może rzeczywiście działać Microsoft, Google albo inny legalny dostawca, ale przeglądarka najpierw komunikuje się z warstwą kontrolowaną przez napastnika. Prawidłowa odpowiedź usługi i prawidłowe MFA nie wystarczają więc do oceny całej ścieżki.

Reverse proxy: pośrednik przekazujący logowanie

Reverse proxy to serwer pośredniczący, który odbiera żądanie od przeglądarki, przekazuje je dalej do właściwej usługi i zwraca jej odpowiedź. Sam reverse proxy jest zwykłym elementem architektury internetowej. W AiTM może jednak zostać wykorzystany tak, aby fałszywa domena przekazywała na bieżąco prawdziwy proces logowania.

Właśnie ten model jest charakterystyczny dla Tycoon2FA. Użytkownik przechodzi przez kolejne kroki logowania, a infrastruktura pośrednicząca może obserwować dane uwierzytelniające oraz artefakty sesji wygenerowane po pomyślnym MFA.

Ciasteczko sesyjne i token: dowód, że logowanie już się odbyło

Po udanym uwierzytelnieniu usługa nie prosi o hasło i MFA przy każdym kliknięciu. Przeglądarka otrzymuje artefakt sesji — na przykład ciasteczko sesyjne lub token — dzięki któremu serwer rozpoznaje już uwierzytelnioną sesję.

Jeżeli taki artefakt zostanie przejęty i może zostać ponownie użyty, napastnik może uzyskać dostęp bez ponownego przechodzenia pełnego logowania. To wyjaśnia, dlaczego sama zmiana hasła nie zawsze kończy incydent: aktywne sesje i tokeny mogą wymagać osobnego unieważnienia.

ORAX: podobny cel bez klasycznego reverse proxy

ORAX dochodzi do podobnego celu inną drogą. Według Abnormal pokazuje własny interfejs phishingowy i steruje przebiegiem sesji przez backend. GraphQL służy tam jako interfejs poleceń aplikacji, SignalR zarządza komunikacją w czasie rzeczywistym, a WebSocket utrzymuje stałe, dwukierunkowe połączenie między przeglądarką a backendem.

Te technologie same w sobie nie są złośliwe. Istotne jest ich użycie: ORAX synchronizuje własny ekran phishingowy z rzeczywistym procesem uwierzytelniania, zamiast po prostu przekazywać stronę dostawcy przez reverse proxy.

Dlaczego passkeys i WebAuthn zmieniają ten model

WebAuthn wykorzystuje poświadczenia klucza publicznego przypisane do konkretnej usługi (relying party) i jej dozwolonego originu. Przeglądarka i mechanizm uwierzytelniania nie powinny użyć takiego poświadczenia na przypadkowej domenie podszywającej się pod usługę.

Dlatego FIDO2/WebAuthn i passkeys są określane jako metody odporne na phishing: klasyczne przekazanie hasła, kodu TOTP lub powiadomienia push przez pośrednika nie daje napastnikowi równoważnego poświadczenia dla innej domeny. Nie oznacza to jednak, że każda kradzież sesji albo każdy scenariusz przejęcia urządzenia staje się niemożliwy — to odrębne klasy ryzyka.

Dwa odrębne przypadki, jeden problem obronny

ORAX

Abnormal Intelligence, zespół badający zagrożenia pocztowe i tożsamościowe, opublikował analizę ORAX 17 września 2026. Badacze podają, że infrastrukturę ORAX obserwowali mniej więcej od lutego do połowy sierpnia 2026, więc data publikacji nie jest datą jednego konkretnego ataku.

W opisanej kampanii przynętą było powiadomienie o wiadomości poczty głosowej. Abnormal zaobserwował około 12 846 wiadomości skierowanych do skrzynek pracowników w 675 organizacjach w USA. Te liczby opisują jedną obserwowaną kampanię; nie są liczbą potwierdzonych ofiar ani całkowitą skalą platformy.

Według Abnormal ORAX został zaprojektowany do uzyskiwania uwierzytelnionych sesji Google Workspace. Jego własny interfejs jest synchronizowany z procesem logowania przez SignalR i WebSockets, zamiast przekazywać legalną stronę dostawcy przez klasyczny reverse proxy.

Tycoon2FA

Microsoft opisał w marcu 2026 Tycoon2FA jako szeroko wykorzystywany zestaw phishingowy działający w modelu AiTM. W tym modelu infrastruktura napastnika pośredniczy między użytkownikiem a legalnym dostawcą tożsamości i może uzyskać dane potrzebne do dalszego użycia sesji po MFA.

Elastic Security Labs, zespół badawczy zajmujący się analizą zagrożeń, opisał obserwacje Tycoon2FA w środowiskach Entra ID i Google Workspace. Szczegółowy przebieg klasycznego AiTM omawiamy w materiale Jak wygląda atak krok po kroku na przykładzie Tycoon2FA.

Co łączy oba przypadki: celem jest sesja po MFA

W obu przypadkach hasło nie jest jedynym celem. Napastnik dąży do uzyskania możliwości działania po prawidłowym uwierzytelnieniu użytkownika.

To dlatego samo pojawienie się prawdziwego wyzwania MFA może dawać fałszywe poczucie bezpieczeństwa. MFA potwierdza konkretny krok uwierzytelnienia. Nie potwierdza, że użytkownik rozpoczął cały proces z właściwej strony i we właściwym celu.

Po uzyskaniu sesji ryzyko może wyjść poza etap logowania. Abnormal wskazuje BEC, nadużycie reguł skrzynki, phishing wewnętrzny i oszustwa finansowe jako możliwe działania po uzyskaniu sesji przez ORAX. Microsoft opisuje przy Tycoon2FA między innymi modyfikowanie reguł poczty i dalsze kampanie z przejętych kont.

Co je różni: reverse proxy nie jest jedyną drogą

Tycoon2FA jest dokumentowany przede wszystkim jako AiTM z reverse proxy. ORAX według Abnormal pokazuje własny interfejs i synchronizuje jego kolejne stany z równoległym procesem uwierzytelniania.

Ta różnica ma znaczenie dla detekcji i analizy technicznej, ale nie zmienia decyzji użytkownika. Nieoczekiwanej ścieżki logowania nie należy uznawać za bezpieczną tylko dlatego, że jeden z jej etapów wygląda prawidłowo.

Podobny cel nie oznacza wspólnej techniki

ORAX i Tycoon2FA są odrębnymi platformami i odrębnymi obserwacjami. Podobieństwo celu nie jest dowodem wspólnego kodu, operatora ani infrastruktury.

Nie należy też utożsamiać każdej techniki korzystającej z WebSocket z architekturą ORAX. Elastic opisuje WebSocket również w analizowanych wariantach Tycoon2FA, lecz w innym modelu działania.

Podobną granicę pokazuje nasza analiza Jak działa Browser-in-the-Middle w demonstracji: nadużycie uwierzytelnionej sesji nie oznacza złamania kryptografii passkey.

Decyzja pracownika zapada przed MFA

Najwcześniejszy stabilny punkt przerwania takiego ataku znajduje się przed wpisaniem hasła i zatwierdzeniem MFA. Pracownik powinien ustalić, czy sam zamierzał teraz logować się do danej usługi oraz czy proces został uruchomiony z miejsca, któremu ufa.

Realistyczny wygląd strony, CAPTCHA, poprawnie rozpoznany adres e-mail czy prawdziwe powiadomienie MFA mogą zwiększać wiarygodność całego ciągu, ale nie potwierdzają jego pochodzenia.

Bezpieczniejszym wzorcem jest samodzielne otwarcie Google Workspace lub Microsoft 365 ze znanego adresu, zakładki albo firmowego portalu i dopiero tam wykonanie zamierzonej czynności.

Co powinien zrobić pracownik

1. Jeżeli wiadomość prowadzi do nieoczekiwanego logowania, przerwij tę ścieżkę.
2. Otwórz usługę niezależnie ze znanego adresu, zakładki albo firmowego portalu.
3. Jeżeli pojawia się MFA, którego sam nie wywołałeś, nie zatwierdzaj go automatycznie.
4. Jeżeli hasło lub MFA zostały już użyte w podejrzanej ścieżce, zgłoś zdarzenie zgodnie z firmową procedurą.

Co powinna zrobić organizacja

Pierwszą warstwą jest uwierzytelnianie odporne na phishing. Abnormal zaleca FIDO2/WebAuthn lub passkeys, ponieważ mechanizm jest kryptograficznie związany z właściwą usługą.

Drugą warstwą jest telemetria tożsamości: obserwacja ryzykownych logowań, nowych sesji, zmian metod uwierzytelniania i nietypowego użycia tokenów.

Trzecią warstwą jest reakcja po podejrzeniu przejęcia. Reset hasła może nie wystarczyć, jeżeli aktywna sesja lub token nadal działa. Reakcja powinna obejmować unieważnienie sesji oraz sprawdzenie zmian w skrzynce i metodach uwierzytelniania.

Czwarta warstwa dotyczy procesów biznesowych. Business Email Compromise nie musi zaczynać się od sfałszowanego nadawcy. Nietypowa zmiana rachunku, pilny przelew albo prośba o poufny dokument nadal powinny wymagać niezależnego potwierdzenia znanym kanałem, nawet gdy wiadomość pochodzi z prawdziwego konta.

Jak przełożyć ten mechanizm na ćwiczenia pracowników

Z perspektywy security awareness najważniejszy jest moment przed logowaniem: czy pracownik rozpoznaje, że czynność została narzucona przez wiadomość, a nie rozpoczęta samodzielnie. Dlatego symulacja nie musi odtwarzać technicznego przejęcia sesji, aby sprawdzić właściwą decyzję użytkownika.

W symulacji warto odtworzyć decyzję widoczną dla pracownika, a nie ofensywny mechanizm przejęcia sesji. Scenariusz może prowadzić do kontrolowanej strony PHISHLY i kończyć się na syntetycznym etapie decyzji o logowaniu.

Symulacja nie powinna zbierać prawdziwych haseł, kodów MFA, ciasteczek ani uwierzytelnionych sesji. Mierzone mogą być wcześniejsze zachowania: przejście z przynęty, zatrzymanie przed symulowanym uwierzytelnieniem i zgłoszenie wiadomości.

Mini-lekcja po błędzie może utrwalać jedną regułę: jeżeli logowania nie rozpocząłeś samodzielnie w znanej usłudze, realistyczna strona i nawet prawdziwa interakcja MFA nie potwierdzają legalności całej ścieżki.

Takie zachowania można ćwiczyć w ramach testów phishingowych dla firm, bez przechwytywania prawdziwych danych uwierzytelniających.

Co z tego wynika dla ochrony kont i poczty

ORAX i Tycoon2FA nie są tym samym mechanizmem. Pokazują jednak wspólny problem obronny: prawidłowe MFA nie potwierdza automatycznie prawidłowego kontekstu całej ścieżki logowania.

Dlatego użytkownik powinien samodzielnie inicjować logowanie do oczekiwanej usługi, a organizacja po podejrzeniu przejęcia powinna sprawdzić również sesje i tokeny, nie tylko hasło. W przypadku poczty ta sama zasada łączy ochronę tożsamości z kontrolami BEC: prawdziwe konto nadawcy nie zwalnia z niezależnego potwierdzania nietypowych działań biznesowych.