Wprowadzenie do problemu / definicja
Nowe ustalenia badawcze pokazują, że mechanizmy uwierzytelniania bezhasłowego w Windows Hello for Business mogą zostać wykorzystane przez złośliwe oprogramowanie działające już w zalogowanej sesji użytkownika. Problem nie dotyczy wycieku prywatnego klucza ani złamania ochrony TPM, lecz możliwości legalnego wywołania operacji podpisu kryptograficznego przez proces uruchomiony w kontekście ofiary.
W praktyce oznacza to, że atakujący, który uzyska wykonanie kodu na stacji roboczej zalogowanego użytkownika, może nadużyć zaufanego mechanizmu tożsamości do uwierzytelnienia wobec Microsoft Entra ID i potencjalnie utrzymać dostęp do zasobów chmurowych.
W skrócie
- Atak nie wymaga odczytu prywatnego klucza Windows Hello for Business.
- Nie jest konieczna znajomość kodu PIN ani ponowne użycie biometrii użytkownika.
- Wystarczy malware działające w aktywnej sesji ofiary.
- Napastnik może uzyskać podpisaną asercję i wykorzystać ją do dalszego dostępu do Entra ID.
- W części środowisk możliwe jest zarejestrowanie nowego urządzenia i uzyskanie trwałości przez Primary Refresh Token.
Kontekst / historia
Windows Hello for Business od lat jest promowany jako silny, odporny na phishing mechanizm uwierzytelniania, oparty na kluczach asymetrycznych powiązanych z urządzeniem i chronionych sprzętowo, najczęściej przez TPM. Model bezpieczeństwa zakłada, że prywatny klucz nie opuszcza urządzenia, a jego użycie wymaga lokalnego potwierdzenia tożsamości użytkownika.
Wcześniejsze badania dotyczące Microsoft Entra ID koncentrowały się głównie na przejmowaniu sesji, tokenach i scenariuszach związanych z Primary Refresh Token. Najnowsza analiza rozszerza ten obszar, pokazując, że klucz Windows Hello for Business może zostać nadużyty podobnie do passkey FIDO2 w ramach przepływów WebAuthn.
To istotne rozróżnienie, ponieważ nie chodzi tu o klasyczną podatność typu CVE ani o eksport materiału kryptograficznego. Mamy raczej do czynienia z konsekwencją architektury systemu i modelu zaufania w sytuacji, gdy endpoint został już skompromitowany.
Analiza techniczna
Sednem techniki jest fakt, że w interaktywnej sesji użytkownika operacje wykorzystujące klucz Windows Hello for Business pozostają dostępne dla procesów działających w tym samym kontekście. Jeżeli atakujący uruchomi kod jako użytkownik, może zażądać od systemu podpisania danych uwierzytelniających bez konieczności eksportu klucza prywatnego.
Według opisu badacza atak wykorzystuje przepływy WebAuthn oraz zachowanie wyzwania uwierzytelniającego w Microsoft Entra ID. Kluczowy element polega na tym, że czasowo ważne wyzwanie może zostać pobrane na innym hoście i przekazane do podpisania na skompromitowanym urządzeniu ofiary. Dzięki temu malware nie musi przejmować pełnej tożsamości urządzenia w tradycyjnym rozumieniu — wystarcza mu możliwość zdalnego wykorzystania podpisu generowanego lokalnie przez system.
Po uzyskaniu poprawnej asercji napastnik może przejść do żądania tokenów lub otwarcia sesji jako ofiara. W niektórych scenariuszach wygenerowany token może nie zawierać powiązania z identyfikatorem urządzenia, co otwiera drogę do zarejestrowania nowego, kontrolowanego urządzenia i uzyskania dla niego Primary Refresh Token.
Badania wskazują również, że taki sposób logowania może spełniać wymagania polityk Conditional Access oczekujących phishing-resistant MFA. W części środowisk może on zostać potraktowany także jako świeże MFA, co zwiększa ryzyko dodania kolejnych metod uwierzytelniania, passkeys lub nowych kluczy Windows Hello for Business.
Z perspektywy detekcji istotnym artefaktem mogą być logowania Windows Hello for Business z pustym identyfikatorem urządzenia. Taki wzorzec nie zawsze musi oznaczać nadużycie, ale w połączeniu z innymi sygnałami może stanowić cenny wskaźnik kompromitacji.
Konsekwencje / ryzyko
Najważniejszym skutkiem tego scenariusza jest podważenie założenia, że uwierzytelnianie odporne na phishing samo w sobie eliminuje ryzyko trwałego przejęcia tożsamości. Poświadczenie nadal pozostaje chronione sprzętowo i niewyeksportowalne, ale malware obecne w sesji użytkownika może je wykorzystać operacyjnie.
- trwałe utrzymanie dostępu do konta bez kradzieży hasła,
- rejestrację nowych urządzeń w tenantach dopuszczających taki proces,
- uzyskanie Primary Refresh Token i długotrwałego dostępu do usług chmurowych,
- rozszerzenie kompromitacji przez dodanie nowych metod MFA,
- utrudnione wykrywanie ze względu na użycie legalnych mechanizmów systemowych i tożsamościowych.
Dla organizacji wdrażających Zero Trust to ważny sygnał ostrzegawczy. Ochrona oparta wyłącznie na sile metody logowania nie wystarcza, jeśli końcowy punkt użytkownika został już naruszony.
Rekomendacje
Organizacje powinny traktować ten scenariusz jako ryzyko post-compromise i podejść do niego warstwowo, łącząc kontrolę tożsamości z ochroną endpointów oraz monitoringiem zdarzeń.
- zwiększyć monitoring nietypowych rejestracji urządzeń i logowań Windows Hello for Business bez oczekiwanego device ID,
- ograniczyć możliwość samodzielnej rejestracji urządzeń oraz dodawania nowych metod uwierzytelniania tam, gdzie nie jest to konieczne,
- łączyć polityki Conditional Access z oceną stanu urządzenia, zgodności i ryzyka sesji,
- wdrożyć EDR/XDR z telemetrią procesów i aktywności tożsamościowej,
- ograniczać uruchamianie nieautoryzowanego kodu w kontekście użytkownika,
- przygotować playbooki SOC i IAM obejmujące unieważnianie sesji, przegląd urządzeń i audyt metod MFA.
W praktyce kluczowe znaczenie ma szybkie wykrywanie malware działającego w kontekście zalogowanego użytkownika, ponieważ to właśnie ten etap umożliwia nadużycie zaufanego mechanizmu uwierzytelniania.
Podsumowanie
Opisana technika nie łamie kryptografii Windows Hello for Business i nie prowadzi do eksportu prywatnego klucza. Pokazuje jednak, że po kompromitacji aktywnej sesji użytkownika nawet silne, sprzętowo chronione i odporne na phishing poświadczenie może zostać wykorzystane do uzyskania dostępu do Microsoft Entra ID.
Dla firm rozwijających strategię bezpieczeństwa wokół passwordless i phishing-resistant authentication to wyraźne przypomnienie, że bezpieczeństwo nowoczesnej tożsamości zależy nie tylko od jakości poświadczenia, ale również od integralności sesji, urządzenia oraz całego łańcucha zaufania.
Źródła
- https://thehackernews.com/2026/08/malware-can-abuse-windows-hello-for.html
- https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/
- https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/deploy/
- https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/
- https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/how-it-works