Przejęcia kont mimo passkeys i uwierzytelniania MFA odpornego na phishing. Trzy badania z sierpnia 2026 pokazują luki w implementacji

Trzy niezależne zespoły badawcze pokazały w pierwszej połowie sierpnia 2026 r., jak przejść uwierzytelnianie oparte na passkeys bez znajomości klucza prywatnego użytkownika, a w jednym przypadku także jak ten klucz odzyskać.

Michael Grafnetter ze SpecterOps zaprezentował atak Pass-the-Passkey na Black Hat USA 2026 w dniu 5 sierpnia, Unit 42 z Palo Alto Networks opisała rodzinę ataków Pass-ta-key wymierzonych w Google Password Manager w Chrome, a Dirk-jan Mollema wykazał możliwość użycia Windows Hello for Business bez PIN-u i biometrii.

Relację z całości opublikował 10 sierpnia 2026 r. serwis The Hacker News. Żadna z tych metod nie łamie kryptografii FIDO2/WebAuthn, wszystkie celują w infrastrukturę wokół standardu, a każda wymaga, żeby napastnik miał już dostęp do środowiska ofiary, czyli konta uwierzytelnionego użytkownika bez podwyższonych uprawnień albo złośliwego oprogramowania działającego w jego sesji.

Trzy niezależne badania, jeden wspólny mianownik

Passkeys to poświadczenia oparte na kryptografii asymetrycznej, w których klucz prywatny nie opuszcza urządzenia ani chronionego magazynu użytkownika, a serwis weryfikuje wyłącznie podpis wygenerowany na żądanie. Taka konstrukcja usuwa hasło jako sekret możliwy do przekazania napastnikowi, dlatego logowanie passkeyem uchodzi za odporne na phishing i w politykach dostępu figuruje jako phishing-resistant MFA. Sierpniowe badania nie podważają tej właściwości na poziomie protokołu, pokazują natomiast, że status phishing-resistant da się uzyskać bez klucza prywatnego ofiary i bez jej udziału w logowaniu.

Trzy linie badawcze uderzają w różne elementy łańcucha uwierzytelniania:

• Pass-the-Passkey (SpecterOps, Black Hat USA 2026, 5 sierpnia) – ponowne wykorzystanie podpisów WebAuthn zapisywanych w dzienniku zdarzeń Windows do uwierzytelnienia w Microsoft Entra ID jako inny, uprzywilejowany użytkownik.
• Pass-ta-key wraz z najgroźniejszym wariantem Golden Pass-ta-key (Unit 42, Palo Alto Networks) – trzy ścieżki ataku na zsynchronizowane passkeys w Google Password Manager w Chrome, łącznie z odzyskaniem kluczy prywatnych ofiary.
• Windows Hello for Business bez PIN-u i biometrii (Dirk-jan Mollema) – generowanie świeżych asercji WebAuthn kluczem chronionym przez moduł TPM, bez ponownego potwierdzenia tożsamości przez użytkownika.

Kolejność zdarzeń jest w każdym z tych scenariuszy taka sama – napastnik najpierw uzyskuje dostęp do środowiska ofiary, a dopiero potem sięga po passkey. Różni je skutek oraz stan poprawek, od luki w pełni załatanej przez producenta po ochronę wciąż częściową.

Podpisy WebAuthn zapisywane w dzienniku zdarzeń Windows

Michael Grafnetter ze SpecterOps wykazał, że do uwierzytelnienia w Microsoft Entra ID wystarczy podpis WebAuthn wygenerowany wcześniej przez cudzy klucz sprzętowy, o ile da się go odczytać z logów systemowych. Windows zapisywał takie podpisy, między innymi pochodzące z kluczy YubiKey, w postaci jawnej, dostępnej dla uwierzytelnionego użytkownika bez podwyższonych uprawnień, również pracującego zdalnie.

Atak przebiegał w czterech krokach:

1. Odczytanie podpisu WebAuthn z dziennika zdarzeń Windows, bez podwyższonych uprawnień i bez fizycznego dostępu do klucza sprzętowego ofiary.
2. Przesłanie tego podpisu do Entra ID jako odpowiedzi na challenge WebAuthn, czyli jednorazowe wyzwanie wysyłane przez usługę do podpisania.
3. Uwierzytelnienie się jako inny, uprzywilejowany użytkownik – wydobycie klucza prywatnego z YubiKeya nie było potrzebne, bo Entra przyjmowała sam podpis jako dowód posiadania passkeya.
4. Zachowanie statusu phishing-resistant MFA i przejście reguł Conditional Access, które ten scenariusz miały wykluczać.

Podatność na ponowne użycie podpisu wynikała także z konstrukcji challenge’y po stronie Entra. Według SpecterOps „Entra nadal używa tokenów JSON Web Token (JWT) jako challenge’y WebAuthn zamiast pseudolosowo generowanych nonce’ów i nie wydaje się wiązać challenge’y WebAuthn z ciasteczkami sesji” . 

Stan podatności i poprawek wygląda następująco

• CVE-2026-34348 dotyczy usługi Windows Event Logging Service i została oceniona na CVSS 6.5.
• Podatne są Windows 10, Windows 11 i Windows Server.
• Poprawki Microsoft wydał 14 lipca 2026 r., skracając pole podpisu w logowanych asercjach do sześciu bajtów.
• SpecterOps ocenia, że po ich zainstalowaniu pełny łańcuch ataku z Windows do Entra jest niewykonalny, ponieważ zapisy w logach nie nadają się już do ponownego odtworzenia.
• Mechanizm challenge’y po stronie Entra pozostał bez zmian, a badacze zaznaczają, że nie testowali go ponownie od czerwca 2026 r.

Microsoft odniósł się do zgłoszenia w wypowiedzi dla The Hacker News:

Doceniamy pracę SpecterOps, która zgłosiła ten problem w ramach skoordynowanego ujawniania podatności. Zastosowaliśmy mitygacje dla zgłoszonego problemu dotyczącego przekazywania asercji passkey i nadal inwestujemy w usprawnienia bezpieczeństwa metod uwierzytelniania. Zalecamy przyjęcie podejścia least-privilege, korzystanie z metod uwierzytelniania odpornych na phishing oraz utrzymywanie ochrony urządzeń końcowych w modelu Zero Trust, aby zapewnić lepszą ochronę.

Microsoft

Klucz nadrzędny chroniący synchronizację passkeys w Chrome

Zsynchronizowane passkeys różnią się od poświadczeń przypisanych do jednego urządzenia tym, że ich zaszyfrowane kopie trafiają na konto użytkownika u dostawcy i schodzą na kolejne urządzenia po zalogowaniu. Unit 42 z Palo Alto Networks opisała wymierzoną w ten model rodzinę ataków Pass-ta-key na Google Password Manager w przeglądarce Chrome. Wszystkie warianty zakładają, że na urządzeniu ofiary działa już złośliwe oprogramowanie, przy czym uprawnienia administracyjne nie są do nich potrzebne.

Badacze opisali trzy ścieżki

• Nadużycie tożsamości urządzenia w Chrome – złośliwy kod podszywa się pod legalnego klienta Password Managera i uzyskuje podpisy uwierzytelniające, mimo że użytkownik nie odblokował w tym czasie urządzenia.
• Manipulacja flagą user verification – flaga mówi serwisowi, czy użytkownik potwierdził tożsamość PIN-em lub biometrią. Jej podmiana pozwala wyłudzić od serwisu zgodę na logowanie, którego nikt nie zatwierdził. Unit 42 zademonstrowała tę technikę na serwisie eBay.
• Golden Pass-ta-key – najgroźniejszy wariant, celujący w Security Domain Secret, czyli 32-bajtowy klucz nadrzędny, którym Google chroni zsynchronizowane passkeys użytkownika.

Zdobycie Security Domain Secret pozwala odzyskać prywatne klucze passkeys ofiary, a nie tylko wygenerować pojedynczy podpis. Skutek jest przy tym trwały, ponieważ dla tego sekretu nie istnieje obecnie mechanizm rotacji ani unieważnienia – ofiara nie może go zmienić tak, jak zmienia hasło.

Reakcje po zgłoszeniu były częściowe. Google usunął Security Domain Secret z logów urządzenia, ale według badaczy sekret nadal pojawia się przejściowo w pamięci procesu Chrome podczas ponownej rejestracji. eBay poprawił walidację flagi user verification po otrzymaniu zgłoszenia. 

Klucz w module TPM użyty bez PIN-u i biometrii

Dirk-jan Mollema pokazał trzecią drogę, tym razem przez Windows Hello for Business – metodę logowania, w której klucz uwierzytelniający jest chroniony przez moduł TPM i odblokowywany PIN-em albo biometrią. Proces o niskich uprawnieniach, działający w już zalogowanej sesji użytkownika, może odwołać się do interfejsów kryptograficznych Windows i użyć tego klucza bez ponownego podania PIN-u i bez skanu biometrycznego. Klucz pozostaje niemożliwy do wyeksportowania, ale generuje świeże asercje WebAuthn na żądanie atakującego.

Sprzyja temu sposób, w jaki Entra wystawia wyzwania do podpisania. Challenge WebAuthn zachowuje ważność przez pięć minut i nie jest powiązany z sesją, użytkownikiem ani tenantem, więc podpis wykonany w tle spełnia reguły Conditional Access wymagające uwierzytelnienia odpornego na phishing. Mollema wskazał też, że w takim uwierzytelnieniu może zabraknąć informacji o identyfikatorze urządzenia, co otwiera drogę do pozyskania Primary Refresh Token i utrzymania dostępu do środowiska na dłużej.

Warunkiem wstępnym pozostaje złośliwe oprogramowanie działające w sesji zalogowanego użytkownika. Relacja The Hacker News nie podaje informacji o poprawce dla tego scenariusza.

Co zalecają badacze i dostawcy

Zalecenia sformułowane po sierpniowych publikacjach dotyczą dwóch obszarów jednocześnie: łatania konkretnych podatności i pilnowania miejsc, w których passkeys istnieją w formie możliwej do przechwycenia.

• Instalacja poprawek dla CVE-2026-34348 na wszystkich objętych systemach Windows.
• Egzekwowanie wymogu user verification po stronie serwisów przyjmujących asercje WebAuthn, zamiast przyjmowania flagi bez weryfikacji.
• Traktowanie magazynów passkeys, pamięci przeglądarki oraz procesów odzyskiwania konta, wykorzystywanych już wcześniej do przejmowania kont na dużą skalę, jako obszaru wrażliwego na równi z samymi poświadczeniami.
• Monitorowanie nietypowych uwierzytelnień Windows Hello for Business pozbawionych identyfikatora urządzenia oraz nieoczekiwanych rejestracji nowych urządzeń.
• Śledzenie liczników podpisów (signature counter), które ujawniają ponowne użycie tego samego poświadczenia.

Microsoft w cytowanej wyżej wypowiedzi dokłada do tego podejście least-privilege i ochronę urządzeń końcowych w modelu Zero Trust.

Passkeys zastępują kody SMS w Entra ID

Od 1 września 2026 r. użytkownicy Entra ID korzystający z uwierzytelniania SMS-em lub połączeniem głosowym będą automatycznie obejmowani passkeys i zachęcani do ich rejestracji. Dostarczanie kodów SMS i połączeń głosowych przez Microsoft kończy się 1 lutego 2027 r. Sierpniowe publikacje badawcze wypadają więc w okresie, w którym liczba kont chronionych passkeys w Entra ID rośnie.