MFA odporne na phishing: dlaczego MFA nie wystarcza i co dalej

Skoro mamy MFA, dlaczego konta wciąż są przejmowane

Zacznijmy od tego, co MFA faktycznie robi. Dodaje drugi dowód tożsamości w momencie logowania, więc samo skradzione hasło już nie wystarcza. Ta jedna zmiana jest ogromnie skuteczna przeciwko najczęstszym atakom. Microsoft podaje, że MFA blokuje ponad 99,2% ataków polegających na przejęciu konta, a raport Digital Defense Report 2025 opisuje zdecydowaną większość ataków na tożsamość jako zwykły password spray i próby brute-force, czyli typ ataku, który drugi składnik zatrzymuje od razu. Nic z tego, co dalej, nie jest argumentem przeciwko MFA. Rzecz jest węższa: ataki, które przechodzą przez konta chronione MFA, nie próbują odgadnąć twojego drugiego składnika.

Słabość ma charakter strukturalny i tkwi w tym, jak działają sesje internetowe, a nie w konkretnym produkcie. Gdy logowanie się powiedzie, dostawca tożsamości wystawia token sesji: cyfrowy artefakt mówiący „ta osoba już się uwierzytelniła, i oto jak". Przeglądarka przedstawia ten token przy każdym kolejnym żądaniu, więc nie jesteś pytany o dane logowania przy każdym kliknięciu. Token niesie twój uwierzytelniony stan, co czyni go łupem. Atakujący, który zdobędzie ważny token sesji, nie potrzebuje ani twojego hasła, ani drugiego składnika, bo token już reprezentuje sesję, która przeszła przez oba. Zespół tożsamości Microsoftu opisuje skradziony token sesji jako odpowiednik przepustki dającej dostęp wszędzie, którą atakujący może skopiować i użyć ponownie.

Współczesny atak nie próbuje więc pokonać MFA na ekranie logowania. Pozwala ci dokończyć MFA, a potem przejmuje wynik. Dominują dwie techniki: phishing typu adversary-in-the-middle, który przechwytuje sesję w momencie jej powstania, oraz kradzież tokenu, która wykrada artefakt sesji po fakcie. Obie kończą się tym samym: atakujący trzyma w ręku żywą sesję zwalidowaną przez MFA, i żadna z nich nie wymaga złamania drugiego składnika.

Phishing adversary-in-the-middle po ludzku

W tradycyjnym ataku phishingowym fałszywa strona logowania wyłudza nazwę użytkownika i hasło, a atakujący używa ich później. MFA łamie ten model, bo samo skradzione hasło nie wystarczy, żeby się dostać. Phishing adversary-in-the-middle (AiTM) to odpowiedź, jaką atakujący opracowali, gdy MFA stało się powszechne.

W ataku AiTM strona phishingowa nie jest statyczną podróbką. To działający na żywo reverse proxy, który siedzi między tobą a prawdziwym dostawcą tożsamości. Klikasz link, trafiasz na coś, co wygląda jak twoja zwykła strona logowania, i faktycznie to jest twoja zwykła strona logowania, bo proxy przekazuje prawdziwe strony w obie strony w czasie rzeczywistym. Wpisujesz hasło i zostaje ono przekazane do prawdziwej usługi. Prawdziwa usługa prosi o drugi składnik, a ta prośba jest przekazywana do ciebie. Zatwierdzasz push, wpisujesz kod albo robisz to, czego wymaga twoje MFA. Wszystko działa, bo naprawdę właśnie uwierzytelniłeś się w prawdziwej usłudze. Różnica polega na tym, że proxy pośrodku obserwowało cały proces, i gdy dostawca tożsamości wystawił twój token sesji, atakujący go przechwycił. Ma teraz kopię twojej uwierzytelnionej sesji.

Microsoft nazywa phishing poświadczeń AiTM najbardziej rozpowszechnioną współczesną techniką phishingową i wiąże jej wzrost bezpośrednio z upowszechnianiem się MFA: im więcej kont wymaga drugiego składnika, tym częściej atakujący sięgają po metodę, która go omija. Ta zdolność nie jest już czymś, co atakujący musi zbudować sam. Zestawy phishing-as-a-service, w tym otwartoźródłowy framework Evilginx i komercyjne oferty jak Tycoon 2FA, pakują AiTM w produkt, który mogą wynająć nawet mniej zaawansowani sprawcy. Microsoft namierzył zestaw Evilginx w użyciu u operatorów od zwykłych grup przestępczych po aktora szpiegowskiego powiązanego z państwem. Przynęty są zwyczajne: udostępniony dokument, powiadomienie o płatności, fałszywa prośba o weryfikację konta, coraz częściej dopracowane przez generatywne AI, przez co znikają dawne sygnały ostrzegawcze jak błędy gramatyczne.

AiTM działa skutecznie, bo ofiara przeżywa zupełnie normalne logowanie. Nie ma dodatkowego okna, żadnego oczywistego błędu, niczego, czego szkolenia nauczyły ludzi nie ufać. Jedyną anomalią jest domena w pasku adresu, a przekonujący zestaw stara się ukryć nawet to.

Kradzież tokenu i przejęcie sesji

AiTM przechwytuje sesję w momencie logowania. Kradzież tokenu zabiera ją później. Gdy token sesji istnieje na twoim urządzeniu albo jest w tranzycie, atakujący, który ma do niego dostęp, może go skopiować i użyć ponownie z własnej maszyny.

Typowe drogi to malware na endpoincie, które odczytuje token z przeglądarki, przechwycenie tokenu, gdy przechodzi przez sieć kontrolowaną przez atakującego, oraz wyciąganie tokenów pozostawionych w niezabezpieczonych logach. Przykład Microsoftu jest przyziemny: użytkownik klika link phishingowy, instaluje infostealera, a malware kopiuje token sesji i wysyła go do atakującego, który używa go ponownie, żeby dostać się do firmowego magazynu w chmurze. Token użytkownika nadal działa, więc z jego strony nic nie wygląda na podejrzane, dlatego kradzież tokenu może przez jakiś czas pozostać niewykryta.

Jeśli chodzi o skalę, uczciwy obraz jest taki, że kradzież tokenu jest realna i rośnie, ale wciąż stanowi mniejszość przejęć. Microsoft podał, że kradzież tokenu to mniej niż 5% przejęć tożsamości, jednocześnie raportując 147 000 ataków typu token replay w ciągu jednego roku, czyli wzrost o 111% rok do roku (Microsoft Entra Blog, czerwiec 2024). Raport Digital Defense Report 2025 wskazał kradzież tokenu przez malware na poziomie około 2,4% prób przejęcia tożsamości. Liczby się różnią, bo mierzą nieco inne rzeczy, ale kierunek jest spójny: niewielki udział w ogólnej liczbie ataków, gwałtownie rosnący i o dużym wpływie, gdy się uda, bo token użyty ponownie omija zarówno hasło, jak i MFA.

Z perspektywy obrony liczy się to, że skradziony token całkowicie pokonuje siłę uwierzytelniania, bo powstał już po udanym uwierzytelnieniu. Pomagają kontrole, które ograniczają sesję, a nie logowanie: powiązanie tokenu z urządzeniem, dla którego został wystawiony, tak żeby nie dało się go użyć gdzie indziej, ciągła ocena, która może odwołać sesję w trakcie, gdy zmienia się ryzyko, oraz reguły dostępu warunkowego odrzucające sesje pochodzące z nieoczekiwanych lokalizacji albo z niezgodnych urządzeń. To ogranicza użyteczność skradzionego tokenu. Nie zmienia to jednak faktu, że zwykłe MFA samo w sobie nie powstrzymuje kradzieży.

Dlaczego nie każde MFA jest sobie równe

„MFA" to jedna etykieta na metody, które bardzo się różnią tym, jak dobrze opierają się realnej próbie phishingu. Raport o pokryciu MFA, który liczy każdą metodę tak samo, zaciera tę różnicę, a to właśnie ją wykorzystuje atak AiTM.

Kluczowe jest zrozumienie, że większość metod MFA wysyła przez sieć współdzielony sekret, który atakujący pośrodku może przechwycić i od razu użyć ponownie. Sześciocyfrowy kod SMS albo z aplikacji uwierzytelniającej to sekret, który wpisujesz, więc proxy go odczytuje i powtarza w krótkim oknie ważności. Push do zatwierdzenia to po prostu tak albo nie, więc proxy zwyczajnie czeka na twoje tak. Żadna z tych metod nie potrafi rozpoznać, że żądanie przyszło z fałszywej strony, a nie z prawdziwej, bo żadna nie sprawdza, skąd żądanie faktycznie pochodzi. Właśnie to sprawdzenie dodaje odporność na phishing.

• Kod jednorazowy SMS / głosowy · Odporność na ataki tylko-hasłowe: Tak · Odporność na phishing AiTM w czasie rzeczywistym: Nie · Uwagi: Najsłabszy składnik. Podatny też na SIM-swap i przechwycenie w sieci. CISA i NIST traktują SMS jako najmniej bezpieczną opcję.
• Kod TOTP z aplikacji uwierzytelniającej · Odporność na ataki tylko-hasłowe: Tak · Odporność na phishing AiTM w czasie rzeczywistym: Nie · Uwagi: Lepszy od SMS wobec SIM-swap, ale wpisany kod jest przechwytywany i powtarzany przez proxy.
• Push w aplikacji (zwykły) · Odporność na ataki tylko-hasłowe: Tak · Odporność na phishing AiTM w czasie rzeczywistym: Nie · Uwagi: Podatny na zmęczenie zatwierdzaniem i na proxy, które przekazuje prośbę.
• Push w aplikacji z dopasowaniem liczb · Odporność na ataki tylko-hasłowe: Tak · Odporność na phishing AiTM w czasie rzeczywistym: Częściowo · Uwagi: Zatrzymuje ślepe zatwierdzanie i zmęczenie push. Wciąż da się go przepuścić przez niektóre schematy AiTM. Nieklasyfikowany jako odporny na phishing.
• Klucz bezpieczeństwa FIDO2 / passkey · Odporność na ataki tylko-hasłowe: Tak · Odporność na phishing AiTM w czasie rzeczywistym: Tak · Uwagi: Odporny na phishing. Poświadczenie jest związane z prawdziwą domeną i nie da się go użyć wobec fałszywej.
• PKI / karta inteligentna · Odporność na ataki tylko-hasłowe: Tak · Odporność na phishing AiTM w czasie rzeczywistym: Tak · Uwagi: Odporny na phishing. Częsty w administracji i sektorach regulowanych, cięższy w obsłudze.

Praktyczny wniosek nie jest taki, że zwykłe MFA jest bezwartościowe. Każde MFA to duża poprawa względem samego hasła, a dla przeciętnego użytkownika SMS wciąż zatrzymuje podstawowe ataki, które stanowią większość wolumenu. Wniosek jest taki, że różnica między górą a dołem tej tabeli jest realna i liczy się najbardziej dla kont, na których atakującemu zależy najbardziej: administratorów, osób zatwierdzających płatności, kadry zarządzającej, każdego, kto może autoryzować płatność albo dostać się do wrażliwych systemów. Dla tych kont kod z aplikacji albo push nie wystarczą, bo atakujący, którzy w nie celują, używają technik, które pokonują dokładnie te metody.

Co FIDO2 i passkeys naprawdę zmieniają

FIDO2 i passkeys to nie tylko wygodniejszy sposób uwierzytelniania. Zmieniają mechanizm w sposób, który usuwa coś, na czym opiera się AiTM. CISA określa MFA odporne na phishing jako złoty standard i wskazuje tylko dwie formy, które się kwalifikują: uwierzytelnianie FIDO/WebAuthn i uwierzytelnianie oparte na PKI (CISA factsheet, 31 października 2022). FIDO2, rodzina obejmująca klucze bezpieczeństwa i passkeys, to ta szeroko dostępna.

Mechanizm to kryptografia klucza publicznego powiązana z domeną. Gdy rejestrujesz passkey albo klucz bezpieczeństwa w usłudze, twoje urządzenie generuje parę kluczy. Klucz prywatny nigdy nie opuszcza urządzenia. Klucz publiczny przechowuje usługa. Przy logowaniu usługa wysyła wyzwanie, a urządzenie podpisuje je kluczem prywatnym, uwalniając podpis dopiero po lokalnym geście, jak odcisk palca, twarz albo PIN. Co kluczowe, ten podpis jest związany z konkretną domeną strony, dla której poświadczenie zostało utworzone. Egzekwuje to przeglądarka: poświadczenie odpowie tylko na prawowite źródło.

To właśnie pokonuje AiTM. Gdy ofiara trafia na domenę proxy atakującego, passkey po prostu nie wygeneruje ważnej odpowiedzi, bo domena nie zgadza się z tą, do której poświadczenie jest przypisane. Nie ma współdzielonego kodu do wpisania, żadnego push do zatwierdzenia, niczego, co proxy mogłoby przekazać dalej. Logowanie nie zawodzi w jakiś subtelny sposób, który użytkownik mógłby przeklikać; na złej domenie po prostu w ogóle się nie kończy. Ochroną jest to, że poświadczenie odmawia odpowiedzi na cokolwiek poza prawdziwą stroną.

Dwa zastrzeżenia, bo się pojawiają. Po pierwsze, MFA odporne na phishing pokonuje AiTM, ale nie jest lekarstwem na wszystko w przypadku kradzieży tokenu: jeśli na urządzeniu już działa malware, może ono odczytać token sesji po prawowitym logowaniu, niezależnie od tego, jak mocne było to logowanie, dlatego higiena endpointów i kontrole wiążące token z urządzeniem wciąż mają znaczenie obok passkeys. Po drugie, passkeys występują w dwóch odmianach. Passkeys związane z urządzeniem, w tym sprzętowe klucze bezpieczeństwa, trzymają klucz prywatny na urządzeniu uwierzytelniającym i dają najsilniejszą gwarancję, naturalny wybór dla kont najwyższego ryzyka. Passkeys synchronizowane synchronizują się między urządzeniami użytkownika przez konto platformy i łatwiej je wdrożyć na dużą skalę dla szerszej populacji.

Realistyczna ścieżka: najpierw konta najwyższego ryzyka

Nie przenosi się całej firmy na uwierzytelnianie odporne na phishing z dnia na dzień i nie warto nawet próbować. Realistyczne podejście to ustawienie kolejności według ryzyka: najpierw konta, na których zależy najbardziej, dostają metody odporne na phishing, a reszta populacji zostaje na MFA, które już macie. Sama wskazówka Microsoftu brzmi: priorytetowo potraktuj MFA odporne na phishing dla kont uprzywilejowanych i od tego zacznij planować szerszy rollout passkeys.

Sensowna kolejność wygląda tak.

Zidentyfikuj konta, w które celowałby atakujący. To konta uprzywilejowane i o wysokiej wartości: administratorzy globalni i domenowi, admini tożsamości i bezpieczeństwa, role finansowe mogące przesuwać pieniądze, kadra zarządzająca oraz każde konto ze stałym dostępem do wrażliwych danych albo systemów krytycznych. To niewielki ułamek użytkowników i duży ułamek ryzyka. Dokładna wiedza, które to konta i które wciąż korzystają ze słabszych składników, jest warunkiem wszystkiego, co dalej.

Przenieś te konta na metodę odporną na phishing. Dla administratorów mocnym domyślnym wyborem są klucze bezpieczeństwa związane z urządzeniem albo passkeys, a wiele platform pozwala teraz wymagać siły uwierzytelniania odpornej na phishing konkretnie dla logowań uprzywilejowanych przez dostęp warunkowy. Wydaj klucze, zarejestruj je i wymagaj ich. Zaplanuj mechanizm zapasowy przy rejestracji, który sam jest odporny na phishing, zamiast spadać z powrotem do SMS, bo inaczej to on stanie się furtką.

Zamknij ścieżki obejścia. Wymóg odporności na phishing jest tak silny, jak najsłabsza dopuszczona alternatywa. Jeśli admin wciąż może spełnić MFA kodem SMS, atakujący go tam skieruje. Usuń albo mocno ogranicz słabsze metody dla kont wysokiego ryzyka i zablokuj przestarzałe protokoły uwierzytelniania, które całkowicie omijają nowoczesną politykę MFA.

Dodaj kontrole na poziomie sesji za logowaniem. Ponieważ samo logowanie odporne na phishing nie zatrzymuje kradzieży tokenu, połącz je z kontrolami ograniczającymi sesję: dostępem warunkowym opartym na ryzyku, który wyzwala dodatkowe pytanie albo blokuje nietypowe logowania, ciągłą oceną dostępu mogącą odwołać token, gdy zmienia się ryzyko, oraz tam, gdzie to wspierane, powiązaniem tokenu z urządzeniem, dla którego został wystawiony. To ogranicza resztkowe ryzyko kradzieży tokenu.

Potem poszerz krąg. Gdy konta uprzywilejowane są już chronione, rozszerz passkeys na szerszą populację w tempie, jakie udźwignie twój support. Passkeys synchronizowane ułatwiają to dla zwykłych użytkowników. Celem jest, żeby uwierzytelnianie odporne na phishing stało się normalnym sposobem logowania, a słabsze składniki były z czasem wycofywane, a nie zostawały jako stała furtka.

Taka kolejność koncentruje wysiłek tam, gdzie koncentrują się ataki. Konta, w które najprawdopodobniej uderzy kampania AiTM, to też te, w których szkody są największe, a jest ich na tyle mało, że da się je szybko ochronić. Pełne pokrycie jest celem docelowym, ale ochrona kont wysokiego ryzyka w pierwszej kolejności daje realną redukcję ryzyka w tygodnie, zamiast czekać na pełny rollout.

Źródła

• Plan for mandatory Microsoft Entra multifactor authentication (MFA), Microsoft Learn · https://learn.microsoft.com/en-us/entra/identity/authentication/concept-mandatory-multifactor-authentication (MFA blokuje ponad 99,2% ataków polegających na przejęciu konta)
• How to break the token theft cyber-attack chain, Microsoft Entra Blog, Alex Weinert, 20 June 2024 · https://techcommunity.microsoft.com/blog/microsoft-entra-blog/how-to-break-the-token-theft-cyber-attack-chain/4062700 (jak działają tokeny sesji; 147 000 ataków token replay, wzrost o 111% rok do roku; kradzież tokenu poniżej 5% przejęć tożsamości; powiązanie tokenu z urządzeniem)
• Defending against evolving identity attack techniques, Microsoft Security Blog, Igor Sakhnov, 29 May 2025 · https://www.microsoft.com/en-us/security/blog/2025/05/29/defending-against-evolving-identity-attack-techniques/ (AiTM jako najbardziej rozpowszechniona współczesna technika phishingowa; Evilginx i phishing-as-a-service; priorytet dla MFA odpornego na phishing w kontach uprzywilejowanych; przynęty dopracowane przez AI)
• Microsoft Digital Defense Report 2025, Microsoft · https://www.microsoft.com/en-us/security/security-insider/threat-landscape/microsoft-digital-defense-report-2025 (większość ataków na tożsamość to password spray i brute force; kradzież tokenu przez malware na poziomie około 2,4% prób przejęcia tożsamości)
• Implementing Phishing-Resistant MFA, CISA factsheet, 31 October 2022 · https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf (MFA odporne na phishing jako złoty standard; FIDO/WebAuthn i PKI jako dwie formy odporne na phishing; SMS traktowany jako najsłabszy)
• CISA Releases Guidance on Phishing-Resistant and Numbers Matching Multifactor Authentication, CISA, 31 October 2022 · https://www.cisa.gov/news-events/alerts/2022/10/31/cisa-releases-guidance-phishing-resistant-and-numbers-matching-multifactor-authentication (data publikacji i zakres wytycznych CISA dotyczących MFA)