No todas las passkeys son iguales

La investigación de Michael Grafnetter en Black Hat USA 2026 y el artículo Pass-the-Passkey muestran que la criptografía de WebAuthn no se rompió. Lo hicieron las implementaciones. Las passkeys de Entra resisten el phishing en el momento del inicio de sesión. Eso no es lo mismo que ser a prueba de phishing.

Dos controles de MFA 2.0 responden a esta familia. El primero es cómo se vincula y se descarta el desafío de inicio de sesión. Por eso ninguno del Grupo 1 alcanza MFA 2.0. El segundo es la aplicación de la vinculación de certificados, que detiene a un atacante que opera desde su propia máquina. Ese es el caso RDP del Grupo 3.

Las dieciséis técnicas evaluadas aquí no son equivalentes, y tratarlas como una sola lista es lo que dificulta actuar sobre la investigación. Algunas son fallos del proveedor de identidad. Algunas son cuestiones de política de credenciales. Seis necesitan el código del atacante en el PC de la víctima, y ningún proveedor de identidad puede prevenirlas. Microsoft parcheó dos de las dieciséis y clasificó el resto como by-design. Este artículo las separa en tres grupos, porque la respuesta a «¿estamos expuestos?» es distinta en cada uno.

Grupo 1: Ataques al proveedor de identidad

Estas seis son responsabilidad del proveedor de identidad. El resultado depende de cómo emite, vincula y verifica un desafío WebAuthn. Entra era vulnerable a las seis. Microsoft parcheó dos: la fuga del registro de eventos y el flag de verificación de usuario. Las otras cuatro son decisiones de producto más que errores. Los desafíos de Entra son JWT de corta duración, de modo que no están ligados a una sesión ni se descartan una vez usados.

MFA 2.0 nunca estuvo expuesto, porque hace ambas cosas. Cada desafío se vincula al dispositivo y a la sesión de usuario que lo inició, y se descarta en el momento en que se usa.

Assertion Mining

Windows escribía aserciones WebAuthn utilizables en el registro de eventos. Cuentas sin privilegios podían leerlas, incluso a través de la red en algunos casos de pertenencia a grupos. Microsoft cerró esto el 14 de julio de 2026 como CVE-2026-34348. Las firmas del registro ahora se truncan. Incluso sin el parche, una aserción extraída sigue sin poder completar un inicio de sesión MFA 2.0, porque el desafío está vinculado a la sesión que lo solicitó, y el atacante no está en esa sesión. En máquinas sin parchear el registro aún puede contener una aserción para cualquier relying party, MFA 2.0 incluido. Lo que cambia es que no se puede usar contra MFA 2.0.

Replay

Los desafíos de Entra siguen siendo JWT de corta duración. No están vinculados al dispositivo y a la sesión de usuario, y no se descartan en el primer uso. Desde mayo de 2026 Entra rastrea contadores de firma para algunos autenticadores hardware, pero Windows Hello sigue informando un contador de firma de 0, de modo que una aserción de Hello capturada puede presentarse de nuevo. Microsoft lo trata como diseño, no como un CVE. SpecterOps considera ahora rota la cadena completa Windows-a-Entra que demostró originalmente tras el parche del registro de julio, y no ha vuelto a probar el comportamiento JWT de Entra desde junio. La brecha del lado de Entra no ha cambiado. MFA 2.0 vincula el desafío al dispositivo y a la sesión de usuario, lo comprueba y luego lo descarta en el momento en que se usa. Una segunda presentación no tiene nada con lo que coincidir.

Circuit Breaker

El malware pausa el navegador y roba la aserción a mitad de la ceremonia. Microsoft no tratará esa interceptación como un error de producto. La brecha real era que Entra aceptaba la aserción robada en otra sesión. Una aserción solo puede completar la sesión que posee su desafío. Otro host falla aunque la firma sea válida.

Detour Capture

El artículo trata Detour como una técnica con tres modos. Capture y Replay pertenecen aquí. Inject pertenece al Grupo 3. Capture engancha webauthn.dll y saca la aserción del equipo. Microsoft no parcheará el enganche de API en modo usuario. La reinyección fuera del equipo solo funcionaba porque Entra aceptaba la aserción robada. Un hook aún puede ver una firma. El operador no tiene sesión en la que reinyectarla.

Detour Replay

Esto usa el mismo hook. El truco de doble inicio de sesión necesitaba que Entra dejara el desafío vivo tras el primer uso. Microsoft lo dejó como diseño. MFA 2.0 descarta el desafío en el momento en que se usa, de modo que una reinyección no tiene nada a lo que vincularse.

User Verification Bypass

Entra históricamente ignoraba los flags de verificación de usuario del autenticador. Era un error de relying party, ahora parcheado. No era un CVE de Windows Hello. El inicio de sesión de MFA 2.0 siempre ha exigido verificación de usuario y valida el flag en cada aserción. Quitar el flag no debilita el inicio de sesión. Lo hace fallar.

Grupo 2: Uso indebido de passkeys

Estas tres ocurren a uno u otro lado del inicio de sesión, no durante él. Dos son cómo un atacante obtiene una passkey que sigue funcionando. Una es cómo una aserción de passkey de Entra capturada se convierte en tokens de Microsoft. Microsoft clasifica las tres como características de producto. Ninguna depende de que el proveedor de identidad compruebe una aserción correctamente, por eso las respuestas aquí se ven distintas del Grupo 1. Ninguna alcanza tampoco MFA 2.0, por tres motivos separados.

Software Authenticators

Las passkeys sincronizadas y exportables son una dirección intencionada de FIDO y Microsoft. Vinculada al dispositivo frente a sincronizable es una elección de política del tenant. Microsoft no prohibirá la exportación del vault en una actualización de seguridad. El alta de MFA 2.0 pide un autenticador de plataforma, de modo que en Windows la clave se crea en Windows Hello y la retiene el TPM. No hay copia exportable que un gestor de contraseñas pueda extraer.

Shadow Passkey

El registro administrativo FIDO a través de Microsoft Graph es una característica de Entra para que TI pueda preinscribir claves. Microsoft no la eliminará. Graph no puede escribir una credencial MFA 2.0. Tampoco hay una API equivalente: ningún endpoint administrativo registra una passkey en nombre de otra persona, y el alta ocurre en el dispositivo que posee la clave. Esa es la regla de alta de conocimiento cero, no una comodidad de administración.

Passkey to Token

La técnica consiste en canjear una aserción de passkey de Entra capturada en Entra por cookies ESTS, y luego intercambiarlas por tokens de acceso y de actualización a través de un cliente público conocido. No es un error de la ceremonia de passkey, y Microsoft no dejará de emitir tokens para un inicio de sesión que ha aceptado. El intercambio al estilo TokenTactics es un atajo nativo de Entra. Una vez que el dominio está federado a MFA 2.0, o MFA 2.0 es el proveedor de MFA externo, ese atajo no tiene nada contra lo que ejecutarse: una aserción de MFA 2.0 está firmada para el identificador de relying party, el origen y el desafío de MFA 2.0, de modo que Microsoft no la honrará. Los tokens SAML y OIDC ordinarios tras un inicio de sesión correcto son la federación funcionando según el diseño, y Entra sigue emitiendo su propia sesión una vez que acepta ese resultado federado, como hace tras cualquier inicio de sesión que acepta.

Grupo 3: Malware en el equipo, y una excepción RDP

Seis de estas requieren el código malicioso del atacante en el PC de la víctima. A partir de ese punto la máquina es suya. Se puede tomar la cookie de sesión. No interviene ninguna passkey, ningún certificado, ningún MFA. Entra, Okta, Ping y MFA 2.0 son iguales aquí. Un proveedor de identidad que afirme lo contrario no debería creérsele en nada más de lo que diga. La infección es el hallazgo. La gestión de parches, el control de aplicaciones y el EDR están aguas arriba. El diseño del inicio de sesión no lo sustituye.

La séptima es distinta. RDP Passkey Phishing se ejecuta desde el propio host del atacante. La aplicación de la vinculación de certificados es el control que responde a ese caso.

UI Overlay

Windows ya permite una ceremonia a la vez. Esperar a que termine y luego mostrar un prompt fraudulento sigue permitido. Los diálogos falsos se sitúan en el modelo de confianza de la interfaz del SO. Microsoft lo dejó como diseño. Por sí solo no inicia sesión a nadie. UI Overlay, HWND Spoofing y Metadata Spoofing disfrazan Assertion Phishing, Prompt Flooding y Detour Inject.

HWND Spoofing

Windows no valida que el llamador posea el handle de la ventana padre que suministra. MSRC evaluó el caso VULN-185216 en junio de 2026 como Low / defence in depth y lo cerró. Microsoft no lo corregirá. Es un disfraz, no un inicio de sesión.

Metadata Spoofing

El texto «Requested by…» proviene del recurso de versión del EXE. Microsoft no trató la falsificación de esa cadena como una vulnerabilidad. Compilaciones anteriores de Windows 11 usaban la firma digital en su lugar; esa comprobación se eliminó a propósito. Es un disfraz, no un inicio de sesión.

Assertion Phishing

Cualquier aplicación de Windows puede llamar a WebAuthNAuthenticatorGetAssertion. Microsoft no impedirá que código de terceros solicite una passkey. Es la misma clase que un prompt push: el SO solicita cuando se le pide. Necesita malware en el equipo.

Prompt Flooding

Windows no limitará la tasa de prompts WebAuthn repetidos desde una aplicación. Microsoft se negó a tratar el spam de prompts como un error de producto. Es la misma clase que la fatiga de MFA, salvo que el llamador ya es local.

Detour Inject

Este es el tercer modo de Detour. Un hook en proceso de webauthn.dll intercambia el desafío dentro de una sesión en vivo en la máquina del usuario. Capture y Replay son del Grupo 1. Inject es en el equipo. Microsoft no parcheará el enganche en modo usuario.

RDP Passkey Phishing

El pass-through de WebAuthn está documentado en [MS-RDPEWA] y activado por defecto. Se atrae al usuario a Remote Desktop en un host que controla el atacante. Windows retransmite el prompt de passkey de vuelta a la máquina local. Microsoft no desactivará el pass-through en una actualización de seguridad. Los administradores pueden desactivarlo en el cliente RDP. Eso es operativo, no un CVE.

Este es el único ataque del Grupo 3 lanzado desde la propia máquina del atacante en lugar de la de la víctima. Con la aplicación de la vinculación de certificados activada, ese host no presenta ningún certificado de cliente coincidente, de modo que nunca obtiene un desafío. Desactivar el pass-through WebAuthn de RDP también lo cierra en el endpoint.

El límite es simple. El malware en el PC de la víctima derrota a todo proveedor de identidad. Desde su propia máquina, un atacante nunca llega al inicio de sesión para obtener un desafío.

Si desean el recorrido del lado del control de la autenticación a prueba de phishing y vinculada al dispositivo, empiecen en prevención, no detección. Para una conversación con IDEE, usen Reservar una demo.

Preguntas frecuentes

¿Son las dieciséis técnicas Pass-the-Passkey el mismo error?

No. Seis atacan cómo el proveedor de identidad vincula y descarta un desafío. Tres son política de alta y canjear una aserción de Entra capturada por tokens. Seis necesitan malware en el PC de la víctima. RDP Passkey Phishing es la única vía del Grupo 3 que se ejecuta desde la máquina del atacante, y la aplicación de la vinculación de certificados impide que ese host reciba un desafío.

¿Microsoft parcheó Pass-the-Passkey?

Microsoft parcheó dos problemas del Grupo 1: la fuga de aserciones del registro de eventos como CVE-2026-34348 el 14 de julio de 2026, y el flag de verificación de usuario en la relying party. Replay, Circuit Breaker, Detour Capture y Detour Replay siguen by-design en Entra. Nada del Grupo 2 ni del Grupo 3 se cerró como error de producto.

¿Habría detenido MFA 2.0 a prueba de phishing la cadena de reinyección de Entra?

Para el Grupo 1, sí. MFA 2.0 vincula el desafío al dispositivo y a la sesión de usuario, lo acepta una vez y luego lo descarta. Una firma de un registro de eventos o de un hook de webauthn.dll no tiene dónde reinyectarse. Eso es vinculación de sesión a prueba de phishing, no meramente un inicio de sesión resistente al phishing. No detiene el robo de cookies después de que el malware ya se ejecuta en el PC inscrito.

¿Por qué RDP se sitúa con el malware si la aplicación de la vinculación de certificados lo detiene?

RDP Passkey Phishing está en el Grupo 3 porque SpecterOps lo listó con la familia de abuso de Windows WebAuthn. No es infección. El atacante se sitúa en su propio host y deja que Windows retransmita el prompt. Con la aplicación de la vinculación de certificados activada, ese host no tiene certificado de cliente, de modo que no se puede iniciar el inicio de sesión. Las seis técnicas de infección siguen siendo problemas de endpoint.

¿Dónde está la investigación principal?

La visión general está en specterops.io/passkeys. Las herramientas están en GitHub bajo SpecterOps/pass-the-passkey. Grafnetter presentó la familia en Black Hat USA el 5 de agosto de 2026.