Phishing na 2FA przez WhatsApp i passkey

TL;DR

Phishing coraz częściej nie udaje tylko problemu z płatnością. Coraz częściej udaje procedurę bezpieczeństwa. W niemieckich ostrzeżeniach Verbraucherzentrale pojawiły się warianty podszywające się pod PayPal: jeden sugerował obowiązkową aktywację dwuskładnikowego uwierzytelniania przez WhatsApp, drugi powoływał się na PSD2, EBA RTS i rzekomą niezgodność metody passkey z aktualnymi wymaganiami bezpieczeństwa.

To ważny mechanizm dla firm, bo użytkownik przyzwyczaja się, że 2FA, MFA, passkey, PSD2 i weryfikacja to słowa związane z ochroną konta. Atakujący wykorzystuje właśnie to skojarzenie. Wiadomość nie mówi: podaj hasło, bo chcemy je ukraść. Mówi: potwierdź bezpieczeństwo, inaczej konto zostanie ograniczone.

Najważniejsza zasada jest prosta: komunikat o MFA, 2FA, passkey albo PSD2 nie powinien prowadzić do logowania przez link z e-maila. Jeżeli zmiana dotyczy konta, płatności lub uwierzytelniania, trzeba wejść do usługi ręcznie, przez aplikację, zapisany adres albo firmowy portal.

Jak działa ten mechanizm

Wariant z WhatsApp używał motywu obowiązkowej aktywacji dwuskładnikowego uwierzytelniania. Użytkownik miał potwierdzić tożsamość w ciągu 24 godzin, aby uniknąć rzekomych ograniczeń konta. Wariant z passkey powoływał się na wymogi PSD2 i EBA RTS oraz sugerował, że obecna metoda uwierzytelnienia nie spełnia nowych standardów.

W obu scenariuszach przynętą nie jest nagroda, faktura ani paczka. Przynętą jest bezpieczeństwo. Użytkownik ma uwierzyć, że działa odpowiedzialnie, bo wykonuje polecenie związane z ochroną konta.

To szczególnie skuteczne, ponieważ wiele prawdziwych usług rzeczywiście promuje passkeys, wieloskładnikowe uwierzytelnianie i silniejsze zabezpieczenia. Gdy oszust używa tych samych słów, granica między realną zmianą a phishingiem staje się mniej oczywista.

W praktyce taki link może prowadzić do fałszywej strony logowania, formularza weryfikacji, bramki płatniczej albo strony, która próbuje przechwycić dane sesji. Użytkownik widzi język bezpieczeństwa, ale wykonuje działanie korzystne dla atakującego.

Dlaczego to działa na użytkownika

Klasyczny phishing często można było rozpoznać po obietnicy zysku albo groźbie straty. Tutaj dochodzi trzeci motyw: obowiązek ochrony konta. Użytkownik nie ma poczuć chciwości ani paniki. Ma poczuć, że powinien wykonać procedurę.

Słowa takie jak PSD2, passkey, 2FA, MFA, EBA RTS, silne uwierzytelnianie i weryfikacja brzmią formalnie. Dla osoby nietechnicznej mogą być trudne do oceny, więc łatwo przyjąć, że wiadomość jest prawdziwa. Tym bardziej, jeśli pojawia się termin 24 godzin, groźba ograniczeń lub informacja o niezgodności zabezpieczeń.

W firmie ten sam mechanizm może dotyczyć Microsoft 365, Google Workspace, bankowości firmowej, systemu HR, CRM, panelu dostawcy, platformy e-commerce albo aplikacji księgowej. Przestępca nie musi wiedzieć wszystkiego o organizacji. Wystarczy, że wybierze usługę, z której prawdopodobnie korzysta wielu pracowników.

Polski kontekst

W Polsce podobny scenariusz może podszywać się pod bank, BLIK, operatora płatności, Microsoft 365, Google Workspace, system kadrowy, e-Doręczenia albo platformę księgową. Wiadomość może mówić o nowej metodzie logowania, wymogu PSD2, reaktywacji urządzenia zaufanego, aktualizacji aplikacji mobilnej albo zmianie w MFA.

Ryzyko rośnie tam, gdzie pracownik samodzielnie zarządza kontami i subskrypcjami. Jeżeli firma nie ma jasnych zasad dotyczących MFA, passkeys i zmian w dostępie, użytkownik może uznać, że każda wiadomość o zabezpieczeniach jest czymś, co trzeba szybko obsłużyć.

Dlatego organizacja powinna jasno komunikować, skąd przychodzą prawdziwe informacje o zmianach w uwierzytelnianiu. Jeśli użytkownik nie wie, czy zmiana MFA jest inicjowana przez IT, bank, dostawcę SaaS czy dział finansów, atakujący zyskuje przestrzeń do manipulacji.

Co powinien zrobić użytkownik

Użytkownik nie powinien zmieniać MFA, 2FA, passkey ani danych płatniczych po kliknięciu w link z wiadomości. To dotyczy zarówno e-maila, SMS-a, komunikatora, jak i reklamy.

Najbezpieczniejsza ścieżka to samodzielne otwarcie usługi. W przypadku konta prywatnego można użyć aplikacji lub zapisanego adresu. W przypadku konta firmowego warto użyć firmowego portalu aplikacji, menedżera haseł albo Single Sign-On, czyli jednokrotnego logowania.

Jeżeli wiadomość dotyczy konta służbowego, płatności, karty firmowej albo zmian bezpieczeństwa, należy ją zgłosić do IT, Security albo osoby odpowiedzialnej za dany proces. Prawdziwa procedura bezpieczeństwa nie powinna wymagać pośpiechu i logowania przez przypadkowy link.

Co powinny zrobić IT, Security i SOC

Zespoły bezpieczeństwa powinny traktować słowa MFA, 2FA, passkey, PSD2 i weryfikacja jako możliwe elementy przynęty. Reguły filtrów i playbooki SOC nie mogą zakładać, że wiadomość o bezpieczeństwie jest automatycznie mniej podejrzana.

Warto przygotować użytkownikom jasny komunikat: firma nie będzie prosić o aktywację MFA przez link z e-maila ani przez prywatny komunikator. Wszelkie zmiany uwierzytelniania powinny mieć potwierdzony kanał, właściciela procesu i instrukcję dostępną poza wiadomością.

W testach phishingowych można sprawdzić, czy pracownicy rozpoznają fałszywy komunikat o zabezpieczeniach. To ważne, bo wiele osób odruchowo ignoruje fałszywe wygrane, ale reaguje na wiadomości brzmiące jak obowiązkowa procedura bezpieczeństwa. Taki scenariusz dobrze uzupełnia testy opisane w artykule o testach phishingowych dla firm.

Co zrobić, jeśli to już się stało

Jeżeli użytkownik kliknął link, ale nie podał danych, powinien zgłosić wiadomość i adres strony. Zespół bezpieczeństwa może zablokować domenę, sprawdzić podobne wiadomości i ostrzec innych pracowników.

Jeżeli użytkownik podał login i hasło, trzeba zmienić hasło, unieważnić aktywne sesje i sprawdzić metody MFA. Jeśli fałszywa strona przechwyciła kod jednorazowy albo token sesji, reset samego hasła może nie wystarczyć.

Jeżeli użytkownik zatwierdził zmianę MFA, dodał nowe urządzenie, zaakceptował passkey lub potwierdził logowanie, trzeba sprawdzić historię logowań, urządzenia zaufane, metody odzyskiwania i aktywne sesje. W systemach firmowych konieczna jest analiza logów i ocena, czy konto nie zostało użyte do dalszych działań.

Jeżeli podano dane karty, należy skontaktować się z bankiem, zastrzec kartę lub ograniczyć jej użycie i sprawdzić transakcje. W firmie trzeba równolegle powiadomić finanse i właściciela konta lub subskrypcji.

Jak ćwiczyć ten scenariusz w awareness

Scenariusz z fałszywą 2FA lub passkey jest dobrym testem dojrzałości organizacji. Nie sprawdza tylko tego, czy użytkownik rozpozna literówkę w domenie. Sprawdza, czy rozumie, że atak może udawać procedurę bezpieczeństwa.

W symulacji można użyć spokojnego komunikatu o migracji do passkey, konieczności odnowienia MFA albo aktualizacji metody uwierzytelniania. Ważne jest, aby po teście omówić konkretny moment decyzji: użytkownik powinien przerwać proces przy linku prowadzącym do logowania i potwierdzić zmianę niezależnym kanałem.

Najlepszy wniosek dla pracownika brzmi: jeśli wiadomość dotyczy zabezpieczeń konta, nie oznacza to, że sama jest bezpieczna.

Bezpieczeństwo też może być przynętą

Atakujący coraz częściej używają języka ochrony konta. To sprawia, że użytkownik może wykonywać polecenie oszusta z poczuciem, że właśnie dba o bezpieczeństwo.

Zasada na koniec jest konkretna: zmiany MFA, passkey, metod płatności i urządzeń zaufanych wykonuj tylko po wejściu do usługi znanym kanałem. Link z wiadomości nie jest właściwą ścieżką do ochrony konta.