Ciberseguridad · 12 de agosto de 2026 · 9 min de lectura
Passkeys bajo presión: cuando la autenticación segura se enfrenta a un dispositivo comprometido
Durante años, las contraseñas han representado uno de los puntos más débiles de la seguridad digital. Pueden reutilizarse, robarse mediante phishing, filtrarse en bases de datos o terminar expuestas por errores humanos.
Durante años, las contraseñas han representado uno de los puntos más débiles de la seguridad digital. Pueden reutilizarse, robarse mediante phishing, filtrarse en bases de datos o terminar expuestas por errores humanos.
Las passkeys surgieron precisamente para cambiar ese escenario. Basadas en estándares como FIDO2 y WebAuthn, están diseñadas para eliminar la dependencia de secretos compartidos y ofrecer una autenticación resistente al phishing.
Pero tres investigaciones independientes presentadas durante la última semana muestran que la historia no termina ahí.
Los investigadores demostraron distintas formas de abusar de mecanismos que rodean a las passkeys sin necesidad de romper la criptografía que las protege. Los escenarios analizados involucran material de autenticación que Windows había conservado, claves sincronizadas mediante Google Password Manager y claves de Windows Hello para empresas utilizadas desde sesiones de usuario ya comprometidas.
El punto en común es importante: el objetivo no necesariamente es romper la passkey, sino encontrar una forma legítima de utilizar la confianza que existe alrededor de ella.
La seguridad de una passkey depende de mucho más que de su criptografía
Una passkey puede utilizar criptografía de clave pública para demostrar que un usuario posee el autenticador correspondiente. La clave privada permanece protegida y el servicio verifica una firma asociada al desafío de autenticación.
Sobre el papel, esto elimina varios de los problemas tradicionales de las contraseñas.
Sin embargo, entre el usuario y el servicio existe toda una cadena tecnológica.
Está el sistema operativo, el navegador, el almacenamiento local, los mecanismos de sincronización, los procesos de recuperación, los servicios de identidad y las validaciones que realiza el sitio al recibir una aserción de autenticación.
Si alguna de esas capas maneja incorrectamente el material de autenticación, una passkey perfectamente diseñada puede terminar formando parte de un escenario de ataque.
Las investigaciones de SpecterOps, Unit 42 y el investigador independiente Dirk-jan Mollema permiten observar precisamente ese problema desde tres ángulos diferentes.
Tres investigaciones, tres caminos para abusar de la confianza
Aunque los tres trabajos estudian mecanismos relacionados con las passkeys, no describen el mismo ataque ni deben interpretarse como una única vulnerabilidad.
Cada investigación expone una debilidad diferente en la cadena de autenticación.
SpecterOps: reutilizar material de autenticación
El equipo de SpecterOps presentó en Black Hat USA 2026 una investigación denominada Pass-the-Passkey.
Su análisis identificó un escenario en el que Windows almacenaba firmas asociadas a dispositivos como YubiKey en texto plano. Según los investigadores, usuarios autenticados sin privilegios, incluidos usuarios remotos, podían acceder a ese material.
El problema adquiere mayor relevancia cuando esas firmas se combinan con determinadas condiciones de validación en Microsoft Entra ID.
El atacante no necesita extraer la clave privada de la YubiKey.
El material utilizado para el ataque es una firma que ya había sido generada y conservada por Windows.
La investigación relaciona este comportamiento con CVE-2026-34348, una vulnerabilidad de divulgación de información en el Servicio de registro de eventos de Windows, con una puntuación CVSS de 6,5.
El resultado potencial es especialmente relevante para los equipos de seguridad: un atacante podría llegar a autenticarse como otro usuario, incluso en escenarios donde la organización exige autenticación multifactor resistente al phishing.
Microsoft ha publicado una actualización de seguridad para la vulnerabilidad y también informó que implementó medidas de mitigación relacionadas con el problema de las aserciones de passkeys identificado por SpecterOps.
Unit 42: cuando la sincronización se convierte en una nueva superficie
La segunda investigación, desarrollada por Unit 42, analiza el sistema de passkeys sincronizadas de Google Password Manager en Chrome para Windows.
Aquí el escenario comienza de una manera diferente.
El atacante ya consiguió ejecutar malware en el dispositivo de la víctima. No necesita necesariamente privilegios de administrador: el objetivo es aprovechar lo que el propio entorno del navegador pone a disposición del proceso comprometido.
Unit 42 identificó tres rutas denominadas Pass-ta-key, Silver Pass-ta-key y Golden Pass-ta-key.
La más relevante por su impacto potencial es Golden Pass-ta-key.
El ataque se dirige al Security Domain Secret (SDS), una clave maestra de 32 bytes utilizada para proteger las passkeys sincronizadas.
Los investigadores encontraron que este secreto podía permanecer temporalmente en la memoria del proceso de Chrome durante determinados procesos de registro.
Google eliminó previamente una exposición del secreto relacionada con los registros de actividad del dispositivo después de que Unit 42 informara del problema. Sin embargo, los investigadores sostienen que el secreto continúa llegando temporalmente al proceso de Chrome.
Si un atacante consigue obtenerlo, podría utilizarlo para recuperar las claves privadas de passkeys sincronizadas.
Esto cambia considerablemente el escenario.
Ya no hablamos simplemente de utilizar una autenticación capturada para acceder una vez a una cuenta. El acceso a las claves sincronizadas podría proporcionar al atacante material de autenticación reutilizable.
Windows Hello: utilizar una clave legítima desde una sesión comprometida
La tercera investigación, realizada por Dirk-jan Mollema, se centra en Windows Hello para empresas.
En los dispositivos Windows modernos, las claves utilizadas por Windows Hello pueden estar protegidas por el TPM y diseñadas para que no puedan exportarse fácilmente.
Pero que una clave no pueda exportarse no significa necesariamente que un proceso malicioso no pueda solicitar al sistema que la utilice.
Mollema demostró que un proceso con privilegios limitados dentro de una sesión de usuario ya comprometida podía utilizar una clave de Windows Hello para empresas sin solicitar nuevamente el PIN ni una comprobación biométrica.
La clave continuaba protegida por el hardware.
El problema estaba en que el atacante podía conseguir que el propio sistema utilizara esa clave legítima para generar una nueva autenticación.
El investigador utilizó posteriormente esa capacidad para crear una credencial FIDO2 frente a Microsoft Entra ID.
El escenario resulta especialmente interesante porque demuestra una diferencia fundamental:
proteger una clave contra su extracción no es exactamente lo mismo que impedir que un atacante utilice esa clave.
El verdadero punto débil: el entorno que rodea a la identidad
Los tres casos presentan diferencias técnicas importantes, pero juntos permiten identificar un patrón.
SpecterOps encontró material de autenticación que podía ser reutilizado.
Unit 42 mostró cómo un malware presente en el dispositivo podía atacar los mecanismos que rodean las passkeys sincronizadas.
Mollema demostró cómo una sesión de Windows comprometida podía utilizar una clave legítima vinculada al hardware.
Ninguno de estos escenarios requiere descifrar la criptografía de FIDO2.
Y precisamente ahí está la lección.
La seguridad de una identidad digital no depende únicamente del algoritmo criptográfico utilizado para protegerla. También depende de cómo se almacenan las claves, quién puede solicitar su uso, qué información permanece en memoria, cómo se registran nuevos dispositivos y cómo los servicios validan las autenticaciones recibidas.
En otras palabras, podemos tener una cerradura extremadamente resistente y aun así encontrar una vulnerabilidad en la puerta, en el marco o en el sistema que controla quién puede abrirla.
¿Significa esto que las passkeys son inseguras?
No.
Y es importante establecer esta diferencia.
Las investigaciones no demuestran que la criptografía de las passkeys pueda romperse fácilmente ni que las passkeys hayan dejado de ser una alternativa de autenticación segura.
De hecho, continúan ofreciendo ventajas importantes frente a las contraseñas tradicionales, especialmente frente al phishing y al robo de credenciales mediante técnicas convencionales.
Lo que estas investigaciones muestran es que una autenticación resistente al phishing no convierte automáticamente en resistente a compromisos todo el dispositivo que la utiliza.
Los ataques de Unit 42 comienzan con malware que ya está presente en el equipo.
El trabajo de Mollema parte de una sesión de Windows que ya ha sido comprometida.
Por lo tanto, estos escenarios deben entenderse como ataques posteriores a una intrusión, no como métodos remotos que permitan a cualquier atacante saltarse una passkey desde Internet.
La distinción es fundamental.
El endpoint vuelve a ocupar un lugar central
Durante años, las estrategias de identidad han evolucionado para reducir la dependencia de las contraseñas.
MFA.
FIDO2.
WebAuthn.
Passkeys.
Windows Hello.
Todas estas tecnologías buscan fortalecer el momento en que una persona demuestra quién es.
Pero una vez que el usuario ya está autenticado, el endpoint continúa siendo parte fundamental de la ecuación.
Si un atacante consigue ejecutar código en ese equipo, puede intentar interactuar con los mismos componentes que utiliza el usuario legítimo.
Por eso la protección de identidad no puede funcionar aislada de la seguridad del endpoint.
La organización necesita saber qué dispositivos están registrados, qué usuarios los utilizan, qué métodos de autenticación están habilitados y qué comportamiento presentan las sesiones posteriores al inicio de sesión.
¿Qué deberían revisar las organizaciones?
La primera medida es mantener los sistemas actualizados.
En el caso de Windows, Microsoft publicó una actualización de seguridad asociada a CVE-2026-34348.
Pero el parche es solamente una parte de la estrategia.
Los servicios que aceptan autenticación mediante WebAuthn deben aplicar correctamente los requisitos de User Verification, en lugar de asumir que una autenticación es válida simplemente porque la solicitud inicial exigía esa comprobación.
También resulta necesario proteger especialmente los endpoints donde se almacenan o utilizan credenciales.
Los equipos de seguridad deberían prestar atención a:
- Registros y comportamientos anómalos de autenticación.
- Dispositivos nuevos o inesperados asociados a cuentas.
- Uso inusual de Windows Hello para empresas.
- Cambios inesperados en los registros de dispositivos.
- Procesos que interactúan con almacenes de credenciales.
- Actividad sospechosa alrededor de navegadores y gestores de contraseñas.
- Flujos de recuperación y registro de nuevos autenticadores.
Y, sobre todo, mantener una estrategia de Zero Trust que no considere que una identidad autenticada implica automáticamente que el dispositivo o la sesión son confiables.
Una identidad segura necesita una cadena segura
La evolución hacia las passkeys representa un paso importante para la seguridad digital.
Pero también está cambiando el objetivo de los atacantes.
Cuando las contraseñas dejan de ser el punto más sencillo para entrar, la atención se desplaza hacia los dispositivos, los navegadores, los procesos de recuperación, las sincronizaciones y los sistemas de identidad que permiten que esa autenticación sea aceptada.
Las tres investigaciones analizadas muestran precisamente esa transición.
La criptografía puede seguir siendo sólida mientras la implementación que la rodea presenta nuevas oportunidades para un atacante.
Por eso, adoptar passkeys no debería considerarse el punto final de una estrategia de identidad.
Es el comienzo de una arquitectura que debe proteger toda la cadena: identidad, endpoint, navegador, dispositivo, autenticación, privilegios y acceso.
La pregunta para las organizaciones ya no es solamente “¿cómo protegemos las credenciales?”.
La pregunta es mucho más amplia:
¿qué ocurre con nuestra identidad cuando el dispositivo que la utiliza deja de ser confiable?
Y esa es precisamente la conversación que la ciberseguridad moderna necesita empezar a tener.