iAuthFlow v2: passkey po phishingu może przetrwać reset hasła

iAuthFlow v2: co dokładnie opisał Abnormal

20 sierpnia 2026 roku firma Abnormal AI opublikowała analizę zestawu phishingowego iAuthFlow v2, reklamowanego na rosyjskojęzycznym forum cyberprzestępczym. W materiałach sprzedawcy cena bazowa wynosi 10 000 USD, a dodatkowe moduły są oferowane osobno.

Najciekawszy element nie dotyczy jednak samej ceny ani kolejnej kopii strony logowania Google. W demonstracji analizowanej przez Abnormal po udanym uwierzytelnieniu operator wykorzystuje aktywną sesję do przejścia do ustawień bezpieczeństwa konta i dodania nowego passkey kontrolowanego przez siebie. Następnie demonstracja pokazuje zmianę hasła, utratę wcześniejszej sesji i ponowne wejście do skrzynki z użyciem wcześniej dodanej metody logowania.

Ta informacja wymaga mocnej granicy faktów. Abnormal nie kupił zestawu i nie odtworzył pełnego ataku na własnym koncie. Badacze analizowali posty sprzedawcy, kanał Telegram, nagrania demonstracyjne, dokumentację Google oraz udostępnioną instancję testową, ale nie wprowadzali do niej danych logowania i nie wykonywali rzeczywistego procesu uwierzytelnienia.

Nie ma więc podstaw, aby na tej podstawie podawać liczbę ofiar, mówić o potwierdzonej masowej kampanii albo przedstawiać wszystkie deklarowane funkcje iAuthFlow v2 jako niezależnie zweryfikowane. To dobrze udokumentowana analiza modelu ataku i demonstracji sprzedawcy, a nie raport z odtworzonego incydentu.

Jak działa Browser-in-the-Middle w demonstracji

Według Abnormal iAuthFlow v2 używa architektury określanej jako Browser-in-the-Middle. Ofiara widzi stronę stylizowaną na logowanie Google, natomiast po stronie operatora działa zdalna przeglądarka komunikująca się z prawdziwą usługą Google.

Użytkownik wpisuje dane i przechodzi kolejne etapy uwierzytelnienia. Z punktu widzenia prawdziwej usługi proces może zakończyć się poprawnym logowaniem zdalnej przeglądarki kontrolowanej przez operatora. To podobna klasa ryzyka do ataków adversary-in-the-middle, gdzie celem nie jest wyłącznie poznanie hasła, lecz uzyskanie uwierzytelnionego dostępu. Szeroki mechanizm opisujemy osobno w materiale Phishing omijający MFA AiTM.

W iAuthFlow v2 istotne jest to, co demonstracja pokazuje po udanym logowaniu. Przejęta sesja nie jest przedstawiana jako cel końcowy. Staje się narzędziem do zmiany stanu konta.

Co dzieje się po uwierzytelnieniu

Abnormal opisuje, że po zakończeniu logowania użytkownik pozostaje na stronie z komunikatem w rodzaju „Verification, Processing”. W tym samym czasie zdalna przeglądarka operatora przechodzi do ustawień passkey konta Google i rozpoczyna proces dodania nowej metody logowania.

Google może w takim momencie wymagać dodatkowego potwierdzenia tożsamości. Materiał sprzedawcy pokazuje obsługę tego kroku w ramach tej samej sesji. W logu przedstawionym przez Abnormal utworzenie nowego passkey pojawia się około sześć sekund po uwierzytelnieniu.

Tego czasu nie należy traktować jako typowego dla rzeczywistych ataków. Pochodzi z jednej demonstracji i nie ma danych pozwalających wyznaczyć średni czas w realnych incydentach. Ważniejszy jest sam model: po uzyskaniu dostępu napastnik może próbować wykorzystać legalne ustawienia konta do dodania własnej metody logowania.

Jest jeszcze jedno ograniczenie. Konto użyte w nagraniu miało już wcześniej zarejestrowany passkey. Google dokumentuje, że nowo utworzony passkey może potrzebować do siedmiu dni, zanim będzie dostępny podczas logowania, chyba że użytkownik ma już zaufany passkey lub fizyczny klucz bezpieczeństwa, co może przyspieszyć aktywację. Demonstracja nie dowodzi więc, że na każdym koncie świeżo dodany passkey będzie natychmiast użyteczny.

To odróżnia ten przypadek od opisywanej niedawno usługi NovaCookies. W artykule NovaCookies wykorzystuje prawdziwe powiadomienia Docusign do phishingu Microsoft 365 głównym skutkiem jest ryzyko przejęcia sesji po poprawnym uwierzytelnieniu. W demonstracji iAuthFlow v2 dochodzi kolejny krok: próba pozostawienia na koncie nowej metody dostępu.

Dlaczego sama zmiana hasła może nie wystarczyć

Zmiana hasła i unieważnienie aktywnych sesji nadal są podstawowymi czynnościami po podejrzeniu przejęcia konta. Problem zaczyna się wtedy, gdy reakcja kończy się właśnie na tych dwóch krokach.

Google dokumentuje passkey jako osobną metodę logowania. Na stronie Logowanie się za pomocą klucza dostępu zamiast hasła użytkownik może sprawdzić zarejestrowane passkeys i klucze bezpieczeństwa oraz osobno usunąć nieznany wpis. Google zaznacza również, że dodanie passkey nie usuwa wcześniej skonfigurowanych etapów uwierzytelniania ani odzyskiwania dostępu.

W demonstracji iAuthFlow v2 sprzedawca pokazuje zmianę hasła i unieważnienie wcześniejszej sesji. Operator wybiera następnie inną metodę logowania i używa wcześniej dodanego passkey. Abnormal przedstawia to jako sposób odzyskania dostępu do skrzynki mimo wykonanej zmiany hasła.

Wniosek dla obsługi incydentu jest szerszy niż sam iAuthFlow v2: po przejęciu konta trzeba sprawdzić, czy napastnik nie zmienił jego konfiguracji. Reset danych logowania usuwa część skutków, ale nie daje automatycznie pewności, że wszystkie dodane metody dostępu, zgody i ustawienia wróciły do znanego stanu.

To nie jest dowód, że passkeys są złamane

Opis iAuthFlow v2 łatwo skrócić do hasła „phishing omija passkeys”. Taki skrót byłby mylący.

Google opisuje passkeys jako technologię odporną na phishing. Klucz prywatny nie jest przekazywany stronie i nie działa jak hasło, które można skopiować do fałszywego formularza. Analiza Abnormal nie pokazuje przełamania kryptografii już istniejącego passkey ani skopiowania klucza prywatnego ofiary.

Demonstracja zaczyna się od innej, podatnej na phishing ścieżki uwierzytelnienia. Gdy operator uzyska uwierzytelnioną sesję, używa legalnych funkcji konta do próby zarejestrowania nowego passkey po swojej stronie. To atak na proces zarządzania tożsamością po logowaniu, a nie dowód słabości kryptograficznej passkeys.

Z tego powodu organizacja nie powinna wyciągać wniosku, że należy wycofać passkeys. Przeciwnie: warto ograniczać słabsze metody logowania tam, gdzie jest to możliwe, i jednocześnie monitorować dodawanie nowych metod uwierzytelniania.

Co sprawdzić po podejrzanym logowaniu do Google

Jeżeli użytkownik wpisał dane na podejrzanej stronie albo zespół bezpieczeństwa ma dowód przejęcia sesji, reakcja powinna objąć więcej niż zmianę hasła.

Zmień hasło i unieważnij podejrzane sesje. To nadal konieczny krok, szczególnie gdy konto korzysta z hasła lub istnieje ryzyko przejęcia sesji.

Przejrzyj passkeys i klucze bezpieczeństwa. W ustawieniach konta Google sprawdź listę zarejestrowanych metod. Usuń wpisy, których właściciel konta nie rozpoznaje. W przypadku passkey utworzonego automatycznie przez urządzenie Google opisuje także procedurę wylogowania odpowiedniego urządzenia.

Sprawdź urządzenia i metody odzyskiwania. Nieznany telefon, zmieniony numer odzyskiwania lub dodatkowy adres e-mail mogą zapewnić inną drogę powrotu do konta.

Przejrzyj zgody OAuth i dostęp aplikacji. Napastnik, który miał uwierzytelnioną sesję, mógł próbować nadać aplikacji dodatkowe uprawnienia. Nieznane zgody powinny zostać usunięte i wyjaśnione.

Sprawdź ustawienia skrzynki. W przypadku Gmail warto zweryfikować przekazywanie wiadomości, filtry, delegacje i inne reguły, które mogły zostać zmienione po przejęciu konta.

Przejrzyj logi bezpieczeństwa. Czas utworzenia nowego passkey, logowanie z nowego urządzenia i późniejsze zmiany ustawień pozwalają odtworzyć kolejność działań i ocenić, czy konto wróciło do prawidłowej konfiguracji.

Celem jest przywrócenie znanego, prawidłowego stanu konta, a nie tylko ustawienie nowego hasła.

Co może monitorować administrator Google Workspace

Google Workspace daje administratorom dodatkowe możliwości obserwowania zmian związanych z passkeys. W oficjalnej dokumentacji Allow users to skip passwords at sign-in Google opisuje wykorzystanie Security Investigation Tool do wyszukiwania zdarzenia Passkey enrolled oraz analizowania użycia passkeys podczas logowania.

Dostępność funkcji zależy od edycji Google Workspace i uprawnień administratora. Nie każda organizacja będzie więc miała identyczny zestaw narzędzi.

W środowisku, które obsługuje takie logi, nowy passkey dodany krótko po podejrzanym logowaniu, zmianie urządzenia lub zgłoszeniu phishingu powinien zostać zweryfikowany. Google udostępnia także opcję ograniczenia passkeys do sprzętowych kluczy bezpieczeństwa, ale jest to ustawienie wymagające świadomej decyzji organizacji, a nie uniwersalna odpowiedź na każdy przypadek.

Praktyczne pytanie dla administratora brzmi: czy po podejrzanym logowaniu zmieniła się lista metod, którymi można wejść na konto?

Co z tego wynika dla security awareness

Klasyczne szkolenie często kończy historię na kliknięciu linku albo wpisaniu hasła. iAuthFlow v2 pokazuje, dlaczego z punktu widzenia organizacji to za mało.

Użytkownik powinien zgłosić podejrzane logowanie nawet wtedy, gdy chwilę później nadal może normalnie korzystać z konta. Brak widocznej awarii nie oznacza, że konfiguracja tożsamości nie została zmieniona w tle.

Z kolei zespół IT lub bezpieczeństwa powinien mieć gotową procedurę, która po zgłoszeniu obejmuje sesje, metody logowania, odzyskiwanie dostępu, zgody OAuth, urządzenia i ustawienia skrzynki. Testy świadomości bezpieczeństwa mogą sprawdzać, czy pracownik rozpoznaje podejrzany proces logowania i czy szybko go zgłasza, a organizacja może ćwiczyć dalszą reakcję operacyjną.

Na stronie Testy phishingowe dla firm opisujemy sposób wykorzystania kontrolowanych kampanii do sprawdzania zachowań użytkowników. Nie wymaga to odtwarzania niebezpiecznego mechanizmu dodawania passkey do prawdziwego konta — celem szkolenia jest decyzja użytkownika i poprawne zgłoszenie zdarzenia.

Podsumowanie

iAuthFlow v2 jest interesujący nie dlatego, że pokazuje słabość kryptografii passkeys. Analiza Abnormal zwraca uwagę na etap po uwierzytelnieniu: operator mający dostęp do aktywnej sesji może próbować zmienić konfigurację konta i dodać własną metodę logowania.

Jednocześnie trzeba zachować granice dowodowe. Abnormal analizował materiały i demonstrację sprzedawcy, ale nie odtworzył pełnego ataku i nie potwierdził liczby rzeczywistych ofiar. Na dziś jest to mocny przykład modelu zagrożenia, a nie podstawa do twierdzenia o masowej, potwierdzonej kampanii.

Dla organizacji praktyczny wniosek jest konkretny: po podejrzeniu przejęcia konta reset hasła i wylogowanie sesji to początek reakcji, nie jej koniec. Trzeba sprawdzić wszystkie nowe metody uwierzytelniania i zmiany wykonane po logowaniu.