Mollemas neue Arbeit baut auf einer früheren Methode auf, die er nach eigenen Angaben auf der DEF CON 32 im Jahr 2024 vorgestellt hatte. Damals konnte ein signierter Nachweis für ein Primary Refresh Token erzeugt werden, benötigte aber noch Zugriff auf ein bei Entra registriertes oder eingebundenes Gerät. Der nun beschriebene Ansatz beseitigt diese Voraussetzung, indem der Windows-Hello-for-Business-Schlüssel über WebAuthn als FIDO2-Passkey behandelt wird.

Nach Mollemas Analyse ist die fünf Minuten gültige Entra-ID-Herausforderung nicht an eine Sitzung, einen Nutzer oder einen Mandanten gebunden. Dadurch kann ein Angreifer sie auf einem anderen Host anfordern und den kompromittierten Endpunkt die signierte Bestätigung erzeugen lassen. Das Framework ROADtools zur Interaktion mit Entra ID kann diese Bestätigung anschließend nutzen, um Tokens anzufordern oder eine Browsersitzung als Opfer zu öffnen.

Ein weiterer Befund betrifft die Gerätebindung. Mollema stellte fest, dass das Token keinen Anspruch mit Geräte-ID trägt. Fehlt diese Bindung, kann ein Angreifer ein neues eigenes Gerät registrieren, dafür ein Primary Refresh Token anfordern und damit Microsoft-Cloud-Dienste erreichen. Microsoft dokumentiert, dass ein Primary Refresh Token 90 Tage gültig bleibt und fortlaufend erneuert wird, solange der Nutzer das Gerät aktiv verwendet.

Hinzu kommt, dass die WebAuthn-Anmeldung laut Mollema Richtlinien für bedingten Zugriff erfüllen kann, die eine phishing-resistente Authentifizierungsstärke von Microsoft verlangen. Außerdem werde die Anmeldung als frische Multi-Faktor-Authentifizierung gewertet. Wo Richtlinien es erlauben, kann ein Angreifer dadurch auf dem neu registrierten Gerät weitere Passkeys oder zusätzliche Windows-Hello-for-Business-Schlüssel hinterlegen. Mollema weist allerdings darauf hin, dass getrennte Richtlinien zum Gerätezustand oder zur Compliance die Kette unterbrechen können; der komplette Persistenzpfad funktioniert also nicht in jeder Bereitstellung.

Der Forscher ordnet den Befund ausdrücklich nicht als klassische Schwachstelle mit Schlüssel-Diebstahl ein. Die Grenze phishing-resistenter Authentifizierung liege vielmehr darin, dass ein an Hardware gebundener und nicht exportierbarer Berechtigungsnachweis dennoch von Malware missbraucht werden kann, solange diese innerhalb der angemeldeten Endpunktsitzung läuft. Das Verhalten sei eine Folge der Architektur von Windows Hello for Business und sei unverändert belassen worden.

Mollema veröffentlichte PowerShell-Proof-of-Concept-Skripte im ROADtools-Repository. The Hacker News fand dort die Dateien „fido_assertion.ps1“ und „hellopoc.ps1“. Eine CVE-Kennung oder einen Microsoft-Hinweis zu dieser Technik fand The Hacker News in Recherchen im Microsoft Security Update Guide, in der NVD und auf CVE.org nicht. Das Medium hat Microsoft und Mollema kontaktiert; Antworten standen noch aus.

Für die Erkennung empfiehlt Mollema, nach Windows-Hello-for-Business-Anmeldungen mit leerer Geräte-ID zu suchen. Er schränkt aber ein, dass auch legitime Inkognito- oder Browser-Sitzungen ohne Single Sign-on dasselbe Muster erzeugen können. Zudem nennt die Veröffentlichung weder die exakt getesteten Windows-Builds noch die getesteten Bereitstellungsmodelle von Windows Hello for Business.