Un nouveau résultat de recherche remet en question la façon dont certaines protections “phishing-résistantes” peuvent être contournées lorsqu’un système est déjà compromis. Selon Dirk-jan Mollema, Malware Windows Hello pour Business peut profiter d’une session Windows déjà ouverte pour utiliser silencieusement une clé Windows Hello for Business et s’authentifier à Microsoft Entra ID.
Ce qui rend la découverte particulièrement préoccupante, c’est l’absence de besoin d’exfiltrer la clé, de récupérer le code PIN ou de provoquer une validation biométrique. Autrement dit, l’attaquant n’a pas forcément besoin de “casser” la protection au sens classique : il exploite le fait que l’authentification peut être déclenchée tant que l’utilisateur est connecté.
Pourquoi la clé Windows Hello for Business peut être invoquée
Le point de départ est simple : lorsque du code malveillant s’exécute dans une session Windows déjà authentifiée, le système conserve certaines capacités nécessaires aux opérations de signature. Sur des configurations qui s’appuient sur le TPM, le chercheur indique que l’attaque ne nécessite pas d’extraire la clé privée. Elle ne requiert pas non plus de récupérer le PIN ni d’afficher un prompt biométrique.
Le mécanisme repose sur le “ticketing” côté Windows : tant que la session reste active et que l’utilisateur est interactivement connecté, des opérations liées à la clé peuvent rester disponibles. Dans ce contexte, Malware Windows Hello pour Business peut demander à Windows de signer des données d’authentification au profit de l’attaquant.
Autre élément important : cette technique ne réclame pas de droits administrateur. Elle dépend avant tout de l’exécution de code dans la session de l’utilisateur.
De l’authentification à l’accès cloud durable
Une fois l’authentification vers Entra ID obtenue, l’attaquant peut construire une persistance côté cloud. Mollema décrit un enchaînement qui peut inclure :
- l’établissement d’un accès plus long à la plateforme cloud,
- l’enregistrement d’un appareil contrôlé par l’attaquant,
- l’obtention d’un Primary Refresh Token (PRT),
- l’ajout d’autres méthodes d’authentification si les politiques du tenant le permettent.
Ce schéma s’explique par la façon dont certaines sessions et jetons peuvent rester valides. Le chercheur rappelle que le PRT reste valable pendant une période pouvant atteindre 90 jours et qu’il est renouvelé tant que l’utilisateur utilise activement l’appareil.
Le rôle clé de WebAuthn et des assertions signées
Le travail met en évidence un changement par rapport à une approche antérieure. Mollema explique que la capacité d’invoquer une clé Windows Hello for Business pour produire une assertion signée avait déjà été démontrée, notamment lors d’une présentation à DEF CON 32 en 2024. Toutefois, cette méthode nécessitait alors l’accès à un appareil enregistré ou joint à Entra.
Dans les nouvelles observations, le chercheur “traite” la clé Windows Hello for Business comme une passkey FIDO2 via WebAuthn. Résultat : le défi Entra ID, qui dure environ cinq minutes, ne serait pas lié à une session, à un utilisateur ou à un tenant spécifique.
En pratique, cela signifie qu’un attaquant peut demander le défi sur un autre hôte, puis faire produire sur l’extrémité compromise l’assertion signée. Le compromis de l’endpoint devient alors un poste de signature, sans que l’attaquant ait besoin d’exporter la clé.
ROADtools, jetons et ouverture de session
Pour illustrer le scénario, Mollema publie des scripts de preuve de concept en PowerShell dans le dépôt ROADtools. Le suivi réalisé par The Hacker News mentionne la présence de fichiers tels que fido_assertion.ps1 et hellopoc.ps1 dans le dossier au moment de la vérification.
Le framework ROADtools peut ensuite exploiter l’assertion signée pour obtenir des jetons ou ouvrir un navigateur “comme la victime”, selon le flux d’authentification visé.
Un détail technique renforce encore la capacité d’exploitation : d’après Mollema, le jeton obtenu ne porte pas d’allégation d’identifiant d’appareil. Autrement dit, l’attaquant peut enregistrer un nouvel appareil, demander un PRT pour cet appareil, puis accéder aux services cloud de Microsoft.
Impact sur l’authentification résistante au phishing
Le résultat interroge une idée largement répandue : les mécanismes phishing-résistants restent-ils fiables si le poste est déjà sous contrôle ? Mollema indique que l’authentification WebAuthn obtenue peut satisfaire des politiques de Conditional Access exigeant un niveau d’authentification “phishing-resistant”.
Dans le même temps, il affirme que cette connexion compte comme une authentification multi-facteurs “fraîche”. Cela ouvre la porte à l’ajout de passkeys ou de clés Windows Hello for Business sur le nouvel appareil, tant que les politiques autorisent cette étape.
Bien entendu, tous les environnements ne seront pas identiquement vulnérables. Des politiques distinctes peuvent interrompre la chaîne, par exemple des exigences liées à l’état de l’appareil ou à la conformité. Le chercheur suggère donc que la persistance complète ne s’appliquera pas partout, mais qu’elle peut fonctionner dans certains déploiements.
Ce que la recherche ne prouve pas (et ce qu’elle signale)
Il est important de distinguer la démonstration technique de l’exploitation réelle. La divulgation ne rapporte pas de victimes identifiées et ne décrit pas d’exploitation active observée. The Hacker News précise également ne pas avoir trouvé de CVE ni d’avis Microsoft explicitement liés à cette technique, à la date de recherche mentionnée.
La recherche ne spécifie pas non plus les versions exactes de Windows ou les modèles de déploiement Windows Hello for Business évalués. De plus, des échanges avec Microsoft et avec Mollema étaient en attente au moment de la publication initiale.
Indicateurs de détection et pistes de surveillance
Malgré l’absence de preuve d’exploitation généralisée, la méthode suggère des traces à surveiller. Mollema recommande notamment d’observer des enregistrements inattendus d’appareils côté Entra ID.
Pour la détection technique, il propose une chasse orientée vers les signatures Windows Hello for Business avec un identifiant d’appareil vide. Cependant, le chercheur souligne aussi un point de nuance : des sessions de navigation “incognito” ou des cas non liés à l’SSO peuvent produire un schéma similaire.
Autrement dit, la surveillance ne doit pas être aveugle. L’idéal consiste à croiser l’indicateur avec d’autres signaux : contexte de session, patterns d’appareil, fréquence inhabituelle, et incohérences entre l’identité attendue et le comportement observé.
Pourquoi c’est un rappel utile pour la sécurité des postes
Cette découverte illustre une limite plus générale : si un attaquant parvient à exécuter du code dans la session d’un utilisateur déjà authentifié, les protections basées uniquement sur la résistance au phishing peuvent ne pas suffire. Le credential peut rester “matériel”, non exporté et bien protégé… tout en étant néanmoins utilisé comme moyen de signature par le système compromis.
En conséquence, la défense doit rester multi-couches : durcissement des postes, réduction de la surface d’exécution, détection des tentatives d’inscription d’appareils, et vérification continue des comportements d’authentification.
Conclusion
En résumé, Malware Windows Hello pour Business pourrait tirer parti d’une session Windows déjà ouverte pour invoquer des clés Windows Hello for Business et obtenir un accès durable à Entra ID. Grâce à WebAuthn et à l’usage d’assertions signées, l’attaque peut mener à l’enregistrement d’appareils et à l’obtention de jetons, sans extraction de clé sur les systèmes avec TPM et sans demande biométrique.
Même si la divulgation ne mentionne pas d’exploitation active observée, elle fournit des pistes concrètes : surveiller des enregistrements d’appareils inattendus et rechercher des schémas d’authentification Windows Hello for Business avec identifiant d’appareil vide, tout en tenant compte des faux positifs possibles. Pour les organisations, c’est un rappel clair : la sécurité de l’authentification doit s’accompagner d’une sécurité solide des endpoints et de contrôles continus.
Source: https://thehackernews.com/2026/08/malware-can-abuse-windows-hello-for.html
