Los ataques a passkeys no buscan “romper” la criptografía que sostiene estas credenciales. En cambio, varias investigaciones recientes muestran que, dependiendo del entorno y de cómo se validan las aserciones, un atacante puede reutilizar material de autenticación ya firmado, aprovechar componentes expuestos por el sistema o actuar desde un dispositivo comprometido para lograr inicios de sesión que parecen legítimos.
Durante la última semana, tres líneas de investigación dieron un mismo mensaje: las passkeys están pensadas para reducir el phishing, pero la seguridad total depende de controles alrededor del protocolo. Cuando esos controles fallan, el impacto puede ir desde la suplantación de usuarios privilegiados hasta la recuperación de claves privadas sincronizadas.
Qué mostraron las investigaciones sobre ataques a passkeys
Las tres investigaciones coinciden en que el “cálculo” criptográfico no se rompe. Lo delicado está en el material firmado que el sistema genera o conserva, en las validaciones que se realizan (por ejemplo, en servicios en la nube) y en la forma en que el software del dispositivo maneja claves y estados.
Según los reportes, cada ataque se apoya en una debilidad distinta:
- Un encadenamiento entre Windows y Microsoft Entra ID que podría permitir suplantación de usuarios privilegiados cumpliendo MFA resistente al phishing.
- Manipulaciones en el sistema de passkeys sincronizadas de Google Password Manager en Chrome, con variantes que pueden llevar a recuperar claves privadas.
- Uso de una clave de Windows Hello for Business por procesos dentro de una sesión ya comprometida, sin pedir un nuevo desbloqueo por PIN o biometría.
Cadena Windows + Entra ID: suplantación cumpliendo MFA
La investigación de SpecterOps se centró en una cadena que vincula Windows con Microsoft Entra ID. El objetivo sería impersonar a usuarios privilegiados sin “forzar” el sistema de authenticación con MFA resistente al phishing, porque el ataque reutiliza material firmado que ya existía.
La clave aquí no es extraer una clave privada del autenticador (por ejemplo, de una YubiKey). En lugar de eso, SpecterOps indica que Windows había almacenado firmas anteriores en texto claro en un contexto donde usuarios no privilegiados (incluidos usuarios remotos) podían leerlas. El siguiente paso del atacante consistiría en encadenar esas firmas con una debilidad en la validación de passkeys en Entra ID.
CVE-2026-34348 y el alcance real
El problema en Windows está rastreado como CVE-2026-34348, descrito como una vulnerabilidad de divulgación de información en el Windows Event Logging Service. El producto afectado, según el reporte, abarca versiones de Windows 10, Windows 11 y Windows Server.
Eso no implica automáticamente que toda la cadena de SpecterOps funcione igual en cada compilación listada, pero sí marca una acción clara: instalar las actualizaciones de seguridad aplicables. Microsoft informó además que aplicó mitigaciones para un tema separado relacionado con “passkey relay assertions”, aunque el aviso técnico público ligado a la CVE se centra en el componente de logging.
Golden Pass-ta-key: recuperación de claves sincronizadas en Chrome
Unit 42 llevó la atención a las passkeys sincronizadas gestionadas por Google Password Manager en Chrome bajo Windows. En su análisis, los ataques parten de que el malware ya está ejecutándose en el equipo de la víctima, sin necesidad de escalar privilegios a nivel de administrador.
El enfoque general consiste en manipular el modo en que el cliente obtiene o presenta identidad de dispositivo y cómo maneja la verificación de usuario en el flujo WebAuthn.
Abuso de identidad del dispositivo y verificación de usuario
En una primera ruta, se aprovecha la maquinaria de identidad del dispositivo de Chrome para obtener las firmas necesarias para comportarse como un cliente legítimo de Password Manager, sin requerir un nuevo desbloqueo del dispositivo ni interacción del usuario.
Unit 42 mostró el método incluso contra un sitio que solicitaba verificación del usuario. Tras el reporte, ese sitio ajustó la validación del indicador de verificación del usuario en WebAuthn.
La variante más dañina: el secreto maestro de sincronización
La variante con mayor impacto, descrita como Golden Pass-ta-key, busca el Security Domain Secret: una clave maestra de 32 bytes usada para proteger passkeys sincronizadas.
El equipo encontró primero el secreto expuesto en el registro de dispositivos de Chrome. Posteriormente, Google eliminó esa exposición del registro. Aun así, los investigadores sostienen que el secreto puede permanecer temporalmente en la memoria del proceso de Chrome durante una re-registración.
Con ese secreto, Unit 42 afirma que un atacante puede recuperar las claves privadas de passkeys sincronizadas de la víctima.
Además, según el reporte, la implementación actual no ofrece una vía para rotar o revocar el Security Domain Secret. Eso haría que la exposición potencial sea más persistente que el simple robo de una sesión aislada.
Windows Hello for Business: reutilizar la clave sin un nuevo PIN o biometría
El trabajo independiente de Dirk-jan Mollema se enfocó en Windows Hello for Business. En la mayoría de dispositivos modernos, la clave de respaldo queda protegida por el Trusted Platform Module y no se exporta de forma simple.
Sin embargo, el hallazgo sostiene que el software dentro de una sesión ya iniciada puede usar esa clave no exportable a través de interfaces criptográficas del sistema. La consecuencia es importante: un proceso con privilegios bajos, pero dentro de una sesión comprometida, podría generar material de autenticación sin que el usuario tenga que desbloquear de nuevo con PIN o biometría.
FIDO2 contra Entra: el desafío dura y no se ata a la sesión
En el flujo descrito, Mollema utiliza la clave para crear una credencial FIDO2 y presentar autenticación ante Microsoft Entra ID. Allí encontró que el desafío WebAuthn tiene una validez de cinco minutos y no está ligado a una sesión, a un usuario o incluso a un tenant.
Esto abre una posibilidad operativa: un desafío generado en el sistema del atacante podría ser usado en la máquina de la víctima. Allí se firmaría con la clave de Windows Hello for Business y se devolvería como una aserción WebAuthn, logrando inicios de sesión que cumplen políticas de acceso condicional que exigen autenticación resistente al phishing.
El investigador también halló que el token resultante puede no incluir un identificador de dispositivo. Ese detalle, según el reporte, podría abrir la puerta a rutas de registro de dispositivo y a obtener una Primary Refresh Token, favoreciendo la persistencia.
Por qué no basta con decir “es un solo bug”
Aunque los resultados convergen en un efecto parecido (autenticaciones que parecen válidas), el contexto muestra diferencias reales. Por eso, el análisis recomienda evitar simplificarlo como si fuera un único problema de “replay” que se repite igual en todos lados.
- En el caso de SpecterOps, el riesgo se relaciona con aserciones reutilizables ya firmadas y aceptadas por una ruta de autenticación en la nube, conectadas con almacenamiento y validación.
- En Unit 42, el énfasis está en cómo el malware manipula confianza del cliente, verificación de usuario y protección de claves sincronizadas.
- En Mollema, el foco es el uso de una clave ligada al hardware desde una sesión ya comprometida para generar nuevas pruebas de autenticación.
Además, dos de los tres caminos dependen de que el atacante ya tenga capacidad dentro del endpoint: Unit 42 y Mollema parten de un sistema ya comprometido. Eso subraya que las passkeys no están diseñadas para soportar escenarios donde el dispositivo ya es controlado por malware.
Mitigaciones: qué hacer con Windows, Entra y el entorno del endpoint
Las contramedidas no son idénticas entre los tres hallazgos. Aun así, hay acciones inmediatas que se desprenden del reporte.
Para Windows: actualiza y revisa el registro y el flujo
Para el componente de Windows asociado a CVE-2026-34348, la recomendación central es instalar la actualización de seguridad correspondiente. El objetivo es reducir la exposición del material que Windows retuvo.
También se sugiere que los servicios que aceptan aserciones WebAuthn hagan cumplir exactamente los requisitos de verificación de usuario que solicitan. Si un servicio “relaja” esa exigencia, puede abrirse el camino a combinaciones peligrosas.
En términos defensivos, los almacenes de passkeys, los flujos de recuperación y la memoria del navegador deben tratarse como zonas sensibles de credenciales.
Para Entra: vigila señales anómalas y fortalece el acceso
En el lado de Entra, el reporte enfatiza que ni passkeys sincronizadas ni passkeys ligadas al dispositivo corrigen errores de implementación en el conjunto de validaciones. Como complemento, Microsoft recomendó un enfoque de menor privilegio (least privilege), adoptar métodos de autenticación resistentes al phishing y aplicar un modelo de Zero Trust para mejorar la protección.
Además, se mencionan posibles señales de monitoreo: autenticaciones de Windows Hello for Business inusuales sin identificador de dispositivo y registros de dispositivos inesperados.
Retiro de SMS/voz y empuje hacia passkeys
Finalmente, Microsoft indica que, desde el 1 de septiembre de 2026, los usuarios de Entra ID que tengan habilitada autenticación por SMS o voz se habilitarán automáticamente para passkeys y se les animará a registrarlas. También se planea retirar la entrega de SMS y voz proporcionada por Microsoft el 1 de febrero de 2027.
Conclusión
Los ataques a passkeys reportados no destruyen la base criptográfica de estas credenciales. Sin embargo, demuestran que el éxito de una autenticación depende de todo el ecosistema: cómo se genera y guarda el material firmado, cómo se validan aserciones en la nube y cómo reaccionan las aplicaciones y el sistema cuando un endpoint está comprometido.
Por eso, la mejor respuesta combina parches, validaciones estrictas y controles de seguridad reforzados en el endpoint y en Entra ID. Si quieres reducir riesgos reales, no basta con habilitar passkeys: hay que asegurar también los alrededores del flujo de autenticación.
Fuente: https://thehackernews.com/2026/08/new-passkey-attacks-can-recover-synced.html
