Windows Hello for Business può essere riutilizzato dal malware per mantenere l’accesso a Entra ID

La tecnica sfrutta una sessione Windows già autenticata

Una ricerca resa pubblica il 7 agosto 2026 mostra che malware già attivo nella sessione interattiva di un utente può usare la sua chiave Windows Hello for Business (WHfB) per autenticarsi a Microsoft Entra ID.

Non servono privilegi amministrativi. Sono sufficienti l’esecuzione di codice nella sessione dell’utente e un’autenticazione già attiva.

La tecnica è stata dimostrata dal ricercatore Entra ID Dirk-jan Mollema. Non risultano CVE, advisory Microsoft, campagne di sfruttamento attivo o vittime note associate a questo comportamento. Le esatte build di Windows e i modelli di deployment WHfB testati non sono stati resi noti.

La chiave privata resta protetta, ma può essere invocata

Su sistemi dotati di TPM, l’attacco non estrae la chiave privata, non recupera il PIN e non richiede una nuova verifica biometrica. Il meccanismo di ticketing di Windows mantiene però disponibili le operazioni con la chiave finché l’utente resta interattivamente autenticato.

Il malware tratta la chiave WHfB come una passkey FIDO2, usando WebAuthn. Una richiesta Entra ID valida per cinque minuti può essere avviata anche da un altro host: l’endpoint compromesso genera l’asserzione firmata, mentre il sistema remoto gestisce il resto del flusso.

Questo elimina il precedente requisito di disporre già di un dispositivo Entra registrato o joined. Il token ottenuto tramite ROADtools può servire per richiedere altri token o aprire una sessione browser impersonando l’utente.

Dalla sessione compromessa alla persistenza cloud

Mollema ha rilevato che l’autenticazione può produrre una risposta priva del device ID. Questo consente, in determinate configurazioni, di registrare un nuovo dispositivo sotto il controllo dell’attaccante e richiedere per quel dispositivo un Primary Refresh Token (PRT).

Microsoft documenta una validità del PRT di 90 giorni, con rinnovo continuo durante l’uso attivo del dispositivo. In questo modo una compromissione inizialmente limitata alla sessione Windows può trasformarsi in accesso cloud prolungato.

L’autenticazione WebAuthn può inoltre soddisfare policy Conditional Access che richiedono autenticazione anti-phishing e viene considerata MFA recente. Se le policy del tenant lo consentono, l’attaccante può aggiungere passkey o ulteriori chiavi WHfB.

La catena non è garantita in ogni ambiente. I controlli separati sullo stato e sulla conformità del dispositivo possono interrompere la registrazione o l’ottenimento dei token.

Rilevamento e contromisure per gli amministratori

Gli amministratori dovrebbero monitorare:

• accessi Entra ID con autenticazione WHfB e device ID vuoto;
• registrazioni inattese di nuovi dispositivi;
• modifiche non autorizzate ai metodi di autenticazione;
• aggiunta di passkey o chiavi Windows Hello for Business.

Il device ID vuoto non dimostra da solo una compromissione: può comparire anche in sessioni browser in incognito o in scenari senza Single Sign-On. Va quindi correlato con utente, orario, endpoint, indirizzo di rete e attività di registrazione del dispositivo.

È opportuno applicare policy rigorose sullo stato e sulla conformità dei device, limitare dove possibile l’aggiunta di nuovi metodi di autenticazione e validare manualmente le nuove registrazioni.

Il PoC pubblicato da Mollema include gli script PowerShell fido_assertion.ps1 e hellopoc.ps1 nel repository ROADtools. In presenza di malware sull’endpoint, la sessione Windows va considerata compromessa: il TPM protegge la chiave dall’esportazione, ma non impedisce al codice malevolo di invocarne l’uso autorizzato.