Un nuevo detalle sobre Abuso de Windows Hello ha encendido las alarmas en el ecosistema de identidades. Según la demostración de un investigador, el malware que ya se está ejecutando dentro de una sesión de Windows iniciada puede aprovechar la infraestructura de Windows Hello for Business para autenticarse ante Microsoft Entra ID. El punto crítico es que no hace falta extraer la clave ni solicitar interacción biométrica en determinados escenarios.
El hallazgo no afirma que exista explotación activa en el mundo real, pero sí muestra una limitación relevante: si el software malicioso controla el endpoint mientras el usuario está autenticado, puede desencadenar operaciones de firma que terminan facilitando acceso en la nube. A continuación, te explicamos qué se observó, cómo funciona el flujo descrito y qué señales pueden servir para detectar comportamientos anómalos.
Qué se observó: autenticación silenciosa desde una sesión comprometida
El investigador demostró que, cuando el usuario ya tiene una sesión iniciada en Windows, el malware puede usar de forma silenciosa la clave asociada a Windows Hello for Business para completar la autenticación frente a Entra ID.
A partir de ese acceso, el atacante puede buscar conectividad de larga duración en la nube, registrar un dispositivo que controla y llegar a obtener un Primary Refresh Token (PRT). Con el PRT, se abre la puerta a seguir expandiendo métodos de autenticación adicionales, siempre que las políticas del tenant lo permitan.
TPM y eludir el “bloqueo” esperado
En sistemas con TPM, el comportamiento descrito resulta especialmente preocupante porque el atacante no necesita:
- extraer la clave privada,
- recuperar el PIN,
- o forzar un prompt biométrico.
La razón es operativa: el sistema de tickets de Windows mantiene disponibles las operaciones criptográficas privadas mientras el usuario sigue autenticado de manera interactiva. En otras palabras, el código que se ejecuta con acceso dentro de la sesión puede pedir a Windows que firme los datos necesarios para la autenticación, sin requerir necesariamente una nueva interacción del usuario.
Además, el proceso no requiere privilegios de administrador. Ese matiz amplía el impacto, ya que comprometer la sesión del usuario puede ser suficiente para aprovechar el mecanismo.
Requisito previo: ejecución de código dentro de la sesión iniciada
Esta técnica no es “remota” ni independiente del estado del endpoint. Para funcionar, se requiere ejecución de código en la sesión de Windows donde el usuario ya está conectado.
El investigador describe el comportamiento como una consecuencia del modo en que Windows Hello for Business realiza determinadas operaciones. Por su explicación, el mecanismo habría quedado “como estaba” y por ello el enfoque malicioso puede beneficiarse de esa característica.
Es importante recordar que el reporte no documenta explotación activa ni identifica víctimas. Aun así, la demostración sirve como evidencia de una superficie de riesgo que, si no se monitorea, puede pasar desapercibida.
Más allá de un requisito anterior: convertir la clave en passkey FIDO2
El investigador indicó que, en una presentación previa (DEF CON 32 en 2024), se mostró una forma de invocar claves de Windows Hello for Business desde un entorno comprometido. Sin embargo, aquel método requería acceso a un dispositivo registrado o unido a Entra.
En el trabajo más reciente, el enfoque se modifica: el investigador trata la clave de Windows Hello for Business como una passkey FIDO2 mediante WebAuthn.
Este detalle es clave: se observó que el desafío de Entra ID (de aproximadamente cinco minutos) no queda ligado a una sesión, a un usuario o a un tenant. Eso cambia el alcance, porque permite que el atacante solicite el desafío en otro host y haga que el endpoint comprometido produzca la aserción firmada.
¿Por qué importa el desafío no ligado?
Si el desafío no está atado a un contexto específico, el flujo malicioso puede separarse en componentes: el atacante puede generar la solicitud donde le convenga, mientras el dispositivo comprometido firma la información necesaria para que Entra ID considere la autenticación válida.
En la práctica, el investigador menciona que ROADtools, un marco pensado para interactuar con Entra ID, puede emplear esta aserción para solicitar tokens o incluso abrir una sesión en el navegador simulando al usuario.
Del token al acceso persistente: registro de dispositivo y PRT
Otro hallazgo relevante es lo que el atacante logra después de la autenticación inicial. Según la investigación, el token resultante no contiene una afirmación de identificación del dispositivo. En entornos donde eso ocurre, el atacante puede:
- registrar un nuevo dispositivo,
- pedir un PRT para ese dispositivo,
- y alcanzar servicios de nube de Microsoft.
Para entender el impacto, conviene recordar cómo se comporta el PRT: el investigador señala que un PRT permanece válido durante 90 días y se renueva continuamente mientras el usuario utiliza activamente el dispositivo.
Esta combinación (token sin vínculo de dispositivo + PRT renovable) puede convertir una intrusión localizada en un camino hacia persistencia en la nube.
Conditional Access y autenticación resistente al phishing
El investigador encontró que el inicio de sesión usando WebAuthn puede cumplir políticas de Conditional Access que exigen una fuerza de autenticación resistente al phishing.
En concreto, ese inicio de sesión también cuenta como autenticación multifactor “fresca”. ¿Qué significa esto en el contexto del ataque? Que, dependiendo de las políticas configuradas, el atacante puede:
- agregar passkeys,
- o agregar claves de Windows Hello for Business
en el dispositivo nuevo que él controla.
Ahora bien, el propio investigador advierte que políticas separadas relacionadas con estado del dispositivo o cumplimiento pueden cortar la cadena. Por ello, la persistencia completa no funcionará en todos los despliegues. El riesgo real dependerá del diseño de tu tenant.
Por qué esto revela una limitación: hardware ligado, pero no inaccesible
El hallazgo expone un matiz que vale la pena comunicar internamente: la autenticación resistente al phishing puede mantener credenciales ligadas al hardware y sin exportación, pero aun así, si el malware vive dentro de la sesión iniciada y es capaz de invocar la operación de firma, puede utilizar la credencial como palanca para completar el proceso ante el proveedor de identidad.
En otras palabras, no es que la clave sea extraíble, sino que el flujo de autenticación puede ser desencadenado desde el contexto comprometido. Esa diferencia es la que hace que el escenario sea distinto a ataques puramente “de robo de secreto”.
Disponibilidad de pruebas y cómo detectarlo
El investigador publicó scripts de prueba de concepto en el repositorio asociado a ROADtools. En la revisión realizada, se localizaron archivos como fido_assertion.ps1 y hellopoc.ps1 (según la fecha de consulta reportada).
Para detección, se recomendó buscar inicios de sesión de Windows Hello for Business con un device ID vacío. Sin embargo, el informe también aclara que sesiones legítimas en modo incógnito o flujos no relacionados con SSO pueden producir un patrón similar.
Por tanto, la recomendación práctica no es “bloquear automáticamente”, sino investigar los eventos: correlaciona el origen, revisa el contexto de usuario y compara con el comportamiento habitual del tenant.
Estado del reporte y ausencia de CVE
El reporte no identifica builds específicas de Windows ni el modelo exacto de despliegue de Windows Hello for Business probado. Además, no se reportó un CVE ni un aviso de Microsoft vinculado a esta técnica tras búsquedas en guías y registros públicos (según lo indicado en la consulta realizada a fecha 6 de agosto de 2026).
El medio que publicó la investigación afirmó que contactó a Microsoft y al investigador, pero las respuestas todavía estaban pendientes al momento del informe.
Qué puedes hacer hoy para reducir el riesgo
Si gestionas identidades y endpoints con Windows Hello for Business, el hallazgo sugiere varias acciones defensivas:
- Monitorea registros de autenticación en Entra ID y busca patrones anómalos (por ejemplo, device ID vacío en eventos relevantes), correlacionándolos con el comportamiento del usuario.
- Revisa políticas de Conditional Access: especialmente las reglas basadas en estado del dispositivo o cumplimiento que podrían cortar la cadena.
- Fortalece la seguridad del endpoint: dado que la técnica requiere ejecución dentro de la sesión iniciada, reducir la probabilidad de compromiso limita el impacto.
- Evalúa la telemetría para detectar inicios de sesión y registros de dispositivos fuera de la rutina esperada.
En resumen, el Abuso de Windows Hello descrito no cambia la necesidad de proteger endpoints, pero sí resalta que un endpoint comprometido puede convertirse en un “firmante” en nombre del usuario mientras la sesión sigue viva.
Conclusión
La investigación mostrada deja una lección clara: aunque Windows Hello for Business esté diseñado para evitar la extracción de claves, el flujo de autenticación puede ser aprovechado por malware que ya está corriendo dentro de la sesión. El resultado puede ser acceso persistente en Entra ID mediante autenticaciones firmadas, registro de dispositivos y obtención de PRT, todo ello con posibles satisfacciones de políticas resistentes al phishing.
La defensa pasa por combinar monitoreo (incluyendo señales como inicios con device ID vacío), configuración consciente de Conditional Access y, sobre todo, endurecimiento del endpoint para impedir que el atacante llegue a ejecutar código en la sesión del usuario.
Fuente: https://thehackernews.com/2026/08/malware-can-abuse-windows-hello-for.html
