Passkeys a przekaźnik phishingowy: dlaczego wiązanie z domeną wygrywa z kodami jednorazowymi
Zestawy phishingowe, które wchodzą między użytkownika a prawdziwą stronę logowania, stały się jednym z najpewniejszych sposobów obchodzenia uwierzytelniania wieloskładnikowego. Ofiara wpisuje kod jednorazowy, zestaw przekazuje go prawdziwej stronie w kilka sekund, a atakujący zatrzymuje wracającą sesję. Passkey zrywa ten przekaznik tak, jak nie potrafi to żadna metoda oparta na kodach: na ekranie po prostu nie ma czego kopiować.
Jak zestawy AiTM pochłaniają kody jednorazowe
Microsoft udokumentował mechanikę szczegółowo: śledził kampanię, która od września 2021 trafiła w ponad 10 000 organizacji. Atakujący uruchamia reverse proxy, który serwuje kopię prawdziwej strony logowania piksel w piksel we własnej domenie i utrzymuje dwie sesje TLS: z ofiarą i z prawdziwą stroną. Hasła i ciasteczka sesji płyną przez środek, a atakujący loguje się jako użytkownik. Microsoft podkreślił, że to nie jest podatność w MFA: kod jest prawdziwy, logowanie jest prawdziwe, a zestaw po prostu zatrzymuje to, co użytkownik sam oddaje (Microsoft). Technika nie zniknęła. W styczniu 2026 badacze Microsoftu opisali wieloetapową kampanię AiTM wymierzoną w organizacje sektora energetycznego, przychodzącą przez nadużyte linki SharePoint i kończącą się oszustwem finansowym (Microsoft). Rok telemetrii Kaspersky, opublikowany w sierpniu 2026, wykazał ponad 390 000 stron phishingowych na legalnych platformach chmurowych, wiele z otwartymi bibliotekami proxy i oknami browser-in-the-browser fałszującymi pasek adresu (Kaspersky). Nowoczesny zestaw przekazuje kod, zatwierdzenie push i wynikowe ciasteczko w czasie rzeczywistym. Wszystko oprócz adresu URL jest prawdziwe.Wiązanie z domeną: adres jest częścią poświadczenia
WebAuthn, standard stojący za passkeys, działa inaczej. Przy rejestracji strona i przeglądarka tworzą parę kluczy publiczny–prywatny ograniczoną do identyfikatora relying party, w praktyce domeny strony. Klucz prywatny nigdy nie opuszcza urządzenia, a przeglądarka oferuje poświadczenie tylko wtedy, gdy origin strony zgadza się z tym identyfikatorem. Dokumentacja Mozilli mówi to wprost: atakujący, który zbuduje fałszywą stronę logowania, nie zaloguje się jako użytkownik, bo podpis zmienia się wraz z origin serwisu (Mozilla). FIDO Alliance opisuje passkeys jako unikalne dla każdej strony czy aplikacji — dokładnie to odbiera credential stuffingowi paliwo (FIDO Alliance). Cisco Talos pokazał, co to oznacza dla zestawów proxy: ofiara, która wyląduje na fałszywej domenie podszywającej się pod jej bank, w ogóle nie ukończy ceremonii WebAuthn, bo przeglądarka nie zaoferuje poświadczenia związanego z prawdziwą domeną na fałszywej. Uwierzytelnianie zawodzi, zanim jakakolwiek tajemnica zostanie przesłana (Cisco Talos).Zestaw proxy może przekazać wszystko, co wpisuje użytkownik. Nie może przekazać poświadczenia, którego przeglądarka nigdy nie oferuje.Nawet tam, gdzie ceremonia się odbywa, nic nadającego się do ponownego użycia nie przechodzi przez łącze. Serwer wysyła duże losowe wyzwanie, uwierzytelniacz podpisuje je kluczem prywatnym, a podpis dowodzi posiadania bez ujawniania tajemnicy — jak odnotowuje specyfikacja Mozilli. Proxy może przesłać ten podpis dalej, ale prawdziwa strona zobaczy wtedy odpowiedź, która powołuje origin, którego nigdy nie serwowała, z poświadczeniem związanym z identyfikatorem, który sprawdza dokładnie pod tym kątem. Nie ma kodu ścigającego się z trzydziestosekundowym licznikiem ani ciasteczka wybitego po stronie atakującego.