Phishing adversary-in-the-middle: jak EvilGinx pokonuje MFA

Uwierzytelnianie wieloskładnikowe miało uczynić skradzione hasła bezwartościowymi. Phishing adversary-in-the-middle (AiTM) — spopularyzowany przez otwartoźródłowe frameworki takie jak EvilGinx — po cichu złamał to założenie, kradnąc sesję, a nie hasło. Zrozumienie, jak działa, to pierwszy krok do obrony.

Czym jest phishing adversary-in-the-middle

Klasyczny phishing pokazuje ofierze statyczny klon strony logowania i po prostu zapisuje to, co wpisze. Nie poradzi sobie z jednorazowym kodem na żywo ani nie przejdzie prawdziwego wyzwania MFA.

Phishing AiTM usuwa to ograniczenie, wstawiając odwrotne proxy między ofiarę a prawdziwą witrynę. Serwer napastnika wcale nie hostuje fałszywej strony — przekazuje prawdziwą:

Ofiara → login.micros0ft-verify.example (proxy napastnika) → login.microsoftonline.com

Każde żądanie ofiary jest przekazywane do legalnej usługi, a każda odpowiedź odsyłana z powrotem. Ofiara widzi autentyczny przepływ logowania — prawdziwy branding, prawdziwe komunikaty błędów, prawdziwe monity MFA — bo w istocie rozmawia z prawdziwą usługą, tyle że przez przekaźnik, który czyta wszystko w tranzycie.

Dlaczego pokonuje OTP i push

Kluczowe spostrzeżenie: napastnik nie próbuje poznać Twojego hasła ani kodu. Próbuje przechwycić to, co produkuje udane logowanie: uwierzytelniony plik cookie sesji.

• Ofiara wpisuje nazwę użytkownika i hasło → przekazane do prawdziwej witryny.
• Prawdziwa witryna wystawia wyzwanie MFA → odesłane do ofiary.
• Ofiara zatwierdza push albo wpisuje OTP → przekazane do prawdziwej witryny.
• Prawdziwa witryna wszystko weryfikuje i zwraca token sesji → proxy go przechwytuje.

W tym momencie OTP już spełnił swoje zadanie i jego powtórzenie jest bezwartościowe. Napastnik importuje skradziony plik cookie do własnej przeglądarki i jest zalogowany jako użytkownik — bez hasła, bez kodu, bez drugiego monitu. Dlatego kody SMS, aplikacje TOTP i zatwierdzenia push padają wszystkie wobec sprawnego zestawu AiTM: każdy z nich to wspólny sekret, do którego przekazania w czasie rzeczywistym można nakłonić człowieka.

Monit MFA, który ofiara zatwierdziła, był prawdziwy. To właśnie czyni AiTM tak skutecznym — nic nie wygląda źle dla użytkownika i nic nie wygląda źle dla dostawcy tożsamości.

Dlaczego istniejące zabezpieczenia kuleją

• Domena jest często zupełnie nowa. Świeżo zarejestrowane podobne domeny nie mają historii reputacji do oznaczenia.
• TLS wygląda legalnie. Proxy podaje ważny certyfikat; kłódka jest obecna.
• Treść jest prawdziwa. Skanowanie oparte na sygnaturach nie znajduje nic fałszywego do dopasowania, bo strona jest prawdziwą, przekazaną.
• Okna wykrywania są krótkie. Zestawy używają filtrowania antyanaliza, linków jednorazowych i geofencingu, więc adres URL żywy dla ofiary zwraca nieszkodliwą stronę badającemu SOC.

Prawdziwe rozwiązanie: MFA odporne na phishing

AiTM działa, bo drugi składnik przechodzi przez napastnika. Usuń tę możliwość, a atak się załamie. FIDO2 / WebAuthn i passkeye wiążą dane logowania kryptograficznie z dokładnym pochodzeniem WWW, dla którego je zarejestrowano:

Dane logowania zarejestrowane dla : https://login.microsoftonline.com
Przeglądarka widzi pochodzenie     : https://login.micros0ft-verify.example
→ niezgodność pochodzenia → authenticator odmawia podpisu → logowanie zawodzi

Nie ma kodu do przekazania ani pliku cookie do zebrania, bo uwierzytelnienie nigdy nie powiedzie się wobec złego pochodzenia. Wymusza to przeglądarka — nie użytkownik. Uzupełniające mechanizmy wzmacniają resztę:

• Dostęp warunkowy wiążący sesje ze zgodnością urządzenia i zarządzanymi sieciami.
• Ochrona tokenów / ciągła ocena dostępu dla obniżenia wartości skradzionego pliku cookie.
• Szybkie wykrywanie świeżo zarejestrowanych podobnych domen przez monitorowanie certificate transparency.

Celem jest MFA odporne na phishing jako wymagane, a nie tylko dostępne — każdy podatny na phishing wariant zapasowy to ścieżka, do której napastnicy pokierują użytkowników.

Jak GottaPhish automatyzuje symulacje AiTM

Ataki AiTM pokonują MFA oparte na OTP i push, przekazując sesję w czasie rzeczywistym, i żadne proxy ani filtr z osobna nie zamyka tej luki niezawodnie. GottaPhish i jego zespół ekspertów odtwarzają scenariusze adversary-in-the-middle automatycznie i bezpiecznie w ramach autoryzowanych symulacji — nie ma infrastruktury napastnika, którą Twój zespół musiałby postawić, hostować czy zdemontować. Pokazujemy, z pełnym audytem, jak MFA oparte na OTP i push pada wobec prawdziwego proxy, podczas gdy dane logowania odporne na phishing się bronią, dając mierzalne dane o ekspozycji na użytkownika, dział i rolę; nasi eksperci pomagają projektować scenariusze, konfigurować kampanie i interpretować wyniki. Ten dowód uczynia uzasadnienie biznesowe dla FIDO2/passkeyów konkretnym, a nasze raporty śledzą adopcję obok współczynników kliknięć i zgłoszeń, abyś mógł udowodnić, że podatna luka rzeczywiście się zamyka — a nie tylko że polityka istnieje na papierze.