Passkey odporny na phishing? Przestępcy atakują proces jego rejestracji

TL;DR

Passkey jest projektowany tak, aby klasyczny phishing nie mógł po prostu ukraść sekretu użytkownika i użyć go na innej stronie. To jednak nie oznacza, że przestępcy przestają atakować człowieka.

Okta Threat Intelligence opisuje kampanię prowadzoną od co najmniej kwietnia 2026 roku przez aktora śledzonego jako O-UNC-066, związanego z operacją wymuszeń określaną jako Pink. Napastnicy dzwonią do pracowników, podszywają się pod firmowy dział IT i przekonują ich, że muszą zarejestrować nowy passkey do Microsoft 365.

Najważniejsze jest jednak to, czego ten atak nie robi. Nie łamie kryptografii passkey. Nie pokazuje, że FIDO2 przestało być odporne na phishing. Atakujący obchodzą problem inaczej: wykorzystują telefon, fałszywą stronę i prowadzony na żywo proces logowania, aby uzyskać dostęp do prawdziwego konta, a potem samodzielnie dopisać do niego passkey kontrolowany przez napastnika.

To informacja dla firm przechodzących na phishing-resistant MFA: trzeba chronić nie tylko samo logowanie, lecz także enrollment, recovery i zmianę metod uwierzytelniania.

Co odkryła Okta

W analizie Vishing actors target Entra passkey enrollment Okta opisuje kampanię wymierzoną w użytkowników Microsoft 365 z wielu sektorów, między innymi technologii, ochrony zdrowia, motoryzacji, budownictwa, lotnictwa oraz branży spożywczej.

Schemat zaczyna się od vishingu, czyli phishingu głosowego. Atakujący telefonuje do pracownika i próbuje przekonać go, że kontaktuje się z nim firmowy dział IT. Pretekstem jest konieczność rejestracji nowego passkey.

To dobry pretekst, bo wiele osób dopiero uczy się, jak właściwie wygląda logowanie bez hasła i rejestracja nowych metod uwierzytelniania. Użytkownik może więc nie mieć utrwalonego wzorca, który pozwoliłby mu natychmiast rozpoznać nieprawidłową procedurę.

Atakujący przygotowują dla celu indywidualne subdomeny imitujące stronę Microsoft Entra. Według Okta strony mogą wykorzystywać prawdziwe elementy brandingu organizacji, co dodatkowo zwiększa ich wiarygodność.

Nie jest to zwykła statyczna strona wyłudzająca hasło. Operator phishing kitu może sterować tym, co ofiara widzi, i reagować na wymagania uwierzytelniania pojawiające się przy próbie wejścia do prawdziwego konta.

Jak wygląda atak krok po kroku

Pierwszy etap to telefon od rzekomego IT. Rozmówca buduje wiarygodny kontekst: zmiana zabezpieczeń, migracja, nowa metoda logowania albo konieczność skonfigurowania passkey.

Następnie pracownik trafia na przygotowaną dla jego organizacji fałszywą stronę. Podaje login i hasło. Dane trafiają do panelu operatora.

W tym samym czasie napastnik próbuje zalogować się na prawdziwe konto Microsoft. Jeżeli Microsoft wymaga dodatkowego składnika MFA, operator dostosowuje stronę widzianą przez ofiarę. Okta opisała obsługę między innymi kodów SMS, TOTP oraz powiadomień push z number matching.

Ofiara może więc dostać polecenie wpisania kodu albo zatwierdzenia czynności, która z jej perspektywy nadal wygląda jak część konfiguracji passkey. W rzeczywistości pomaga napastnikowi ukończyć logowanie do prawdziwego konta.

Dopiero potem pojawia się najbardziej charakterystyczna część kampanii: strony udające dalszą konfigurację passkey. Użytkownik może zobaczyć ekran z rzekomym kluczem odzyskiwania czy kolejnymi krokami konfiguracji.

Według Okta te elementy nie są prawdziwą rejestracją passkey użytkownika. Najprawdopodobniej mają zająć ofiarę i podtrzymać pretekst. W tym czasie napastnik, który ma już nieautoryzowany dostęp do konta, może zarejestrować własny passkey bezpośrednio w prawdziwym środowisku Microsoft.

To ważne rozróżnienie. Ofiara może potem otrzymać prawdziwe powiadomienie Microsoft o dodaniu passkey i uznać je za potwierdzenie czynności, którą sama przed chwilą wykonywała. Tymczasem to właśnie napastnik dopisał nowy mechanizm dostępu do jej konta.

Najważniejsze: passkey nie został złamany

Passkeys i mechanizmy FIDO2 są projektowane jako uwierzytelnianie odporne na phishing. Klucz prywatny nie jest przesyłany do strony w taki sposób jak hasło, a poświadczenie jest związane z właściwą usługą. Dzięki temu fałszywa domena nie może po prostu zebrać passkey i użyć go później przeciw prawdziwej stronie.

W tej kampanii atakujący nie próbują rozwiązać tego problemu kryptograficznie. Atakują wcześniejszy etap procesu.

Najpierw zdobywają hasło i pomagają sobie ofiarą przy przejściu aktualnego MFA. Po uzyskaniu dostępu do prawdziwego konta korzystają z legalnej funkcji zarządzania metodami uwierzytelniania i dopisują własny passkey.

CIS w sierpniowej analizie Vishing: An Evolving Threat to SLTT Organizations zwraca uwagę właśnie na tę zmianę. FIDO2 pozostaje bardzo silnym zabezpieczeniem, ale organizacje migrujące na tę technologię powinny traktować żądania związane z rejestracją passkey z taką samą ostrożnością jak reset hasła czy zmianę MFA.

Po co fałszywy ekran rejestracji passkey

Dobry phishing nie musi technicznie odwzorowywać prawdziwego procesu jeden do jednego. Ma przede wszystkim utrzymać człowieka w określonej historii.

W tym przypadku historia brzmi: „IT wdraża nowe zabezpieczenie i właśnie konfiguruję passkey”.

Jeżeli napastnik po zalogowaniu do konta dopisze własny passkey, Microsoft może wysłać prawdziwe powiadomienie o nowej metodzie uwierzytelniania. Bez kontekstu byłby to bardzo mocny sygnał alarmowy. Ale pracownik, który właśnie przez kilka minut „rejestrował passkey”, może uznać taką wiadomość za całkowicie normalne potwierdzenie.

To przykład manipulacji kontekstem. Techniczny system mówi prawdę: do konta dodano nowy passkey. Problem polega na tym, że ofiara została wcześniej przekonana, jak ma tę prawdziwą informację zinterpretować.

Dlaczego ten model jest groźny dla firm

Firmy coraz częściej słusznie odchodzą od haseł i słabszych metod MFA w stronę phishing-resistant authentication. Taka migracja zwiększa bezpieczeństwo, ale jednocześnie tworzy okres przejściowy, w którym użytkownicy uczą się nowych ekranów, komunikatów i procedur.

Dla przestępcy to okazja. Nie musi przekonywać ofiary do wykonania czegoś oczywiście podejrzanego. Może podszyć się pod rzeczywistą zmianę, którą organizacja właśnie komunikuje pracownikom.

Podobną zmianę ciężaru ataku widać już w innych kampaniach opisanych przez PHISHLY. W materiale Okta pod ostrzałem. Ten scenariusz może pojawić się także w Polsce pokazywaliśmy, że celem przestaje być pojedyncze hasło, a staje się nim cała warstwa tożsamości, resetów i MFA. Z kolei przypadek BlackFile pokazał, jak vishing i przejęta tożsamość mogą prowadzić dalej do kradzieży danych i wymuszenia.

Nowa kampania z passkeys idzie krok dalej: przestępcy wykorzystują samo wdrażanie silniejszych zabezpieczeń jako pretekst socjotechniczny.

Co powinno wzbudzić podejrzenie pracownika

Najważniejszym sygnałem ostrzegawczym jest nieoczekiwany kontakt, podczas którego ktoś próbuje przeprowadzić użytkownika przez zmianę sposobu logowania.

Szczególnej ostrożności wymagają rozmowy, w których rzekomy helpdesk lub IT:

• prosi o wejście na adres podany przez telefon, wiadomość albo czat;
• każe wpisać hasło w ramach „konfiguracji nowego MFA”;
• prosi o kod jednorazowy albo zatwierdzenie powiadomienia MFA;
• tłumaczy pojawienie się nietypowych komunikatów jako normalny element migracji;
• wywiera presję czasu i próbuje przeprowadzić całą zmianę podczas jednej rozmowy;
• prosi o zignorowanie lub specjalne zinterpretowanie powiadomienia o nowej metodzie uwierzytelniania.

Bezpieczna reakcja jest prosta: przerwać proces i zweryfikować żądanie niezależnym kanałem. Nie przez numer, adres ani link podany przez osobę inicjującą kontakt, lecz przez znany firmowy kanał wsparcia.

Co powinny zabezpieczyć IT i helpdesk

Ten przypadek pokazuje, że rejestracja nowej metody uwierzytelniania jest operacją bezpieczeństwa równie ważną jak samo logowanie.

Organizacja powinna przede wszystkim wiedzieć, kto, z jakiego urządzenia i w jakim kontekście może dodać nową metodę uwierzytelniania. Tam, gdzie to możliwe, warto ograniczać takie zmiany do urządzeń zarządzanych, zaufanych lokalizacji albo wcześniej zdefiniowanych procesów.

Drugim elementem jest natychmiastowa widoczność zmian. Użytkownik i zespół bezpieczeństwa powinni otrzymywać informację o dodaniu nowej metody uwierzytelnienia, a nietypowa rejestracja powinna być możliwa do szybkiego skorelowania z nowym logowaniem, nietypową lokalizacją lub zmianą urządzenia.

Trzeci element to procedura helpdesku. Reset hasła, zmiana MFA, dopisanie nowego urządzenia czy recovery nie mogą opierać się wyłącznie na tym, że rozmówca zna nazwisko, dział, adres e-mail albo inne informacje możliwe do zdobycia z publicznych źródeł lub wcześniejszych wycieków.

Jak ćwiczyć taki scenariusz w security awareness

Klasyczna symulacja phishingowa zwykle zaczyna się od wiadomości e-mail. Ten atak pokazuje, że to już za mało.

Program security awareness powinien uczyć także sytuacji, w których napastnik:

• dzwoni jako helpdesk;
• zna kontekst firmy i używane narzędzia;
• odwołuje się do prawdziwej zmiany technologicznej;
• wykorzystuje legalne powiadomienia MFA;
• próbuje doprowadzić użytkownika do zmiany sposobu uwierzytelniania.

W ćwiczeniu nie chodzi o sprawdzenie, czy pracownik zna definicję passkey. Chodzi o sprawdzenie, czy potrafi rozpoznać nieautoryzowaną zmianę procesu tożsamości i czy wie, jak zweryfikować ją niezależnym kanałem.

Dlatego testy phishingowe dla firm warto rozszerzać o scenariusze, w których decyzja użytkownika nie sprowadza się do „kliknąć czy nie kliknąć”. W nowoczesnych atakach równie ważne jest pytanie: czy powinienem w ogóle wykonywać tę zmianę i kto naprawdę o nią poprosił?

Wniosek

Przejście na passkeys jest dobrym kierunkiem. Ta kampania nie jest argumentem przeciwko phishing-resistant MFA. Wręcz przeciwnie: pokazuje, że silniejsze uwierzytelnianie zmusza napastników do szukania innej drogi.

Tą drogą staje się człowiek i proces wokół technologii.

Jeżeli organizacja zabezpieczy samo logowanie, ale pozostawi łatwy do zmanipulowania enrollment, recovery albo helpdesk, przestępca spróbuje wejść właśnie tam. Dlatego dojrzały model bezpieczeństwa to nie tylko „wdrożyliśmy passkeys”. To również odpowiedź na pytania: kto może je rejestrować, jak potwierdzamy taką zmianę, jak ją monitorujemy i czy pracownik wie, kiedy przerwać rozmowę z rzekomym IT.

Passkey może być odporny na phishing. Proces jego wdrażania nadal musi być odporny na socjotechnikę.