Malware puede eludir las passkeys de Google Password Manager en Windows

Las passkeys o llaves de acceso se han convertido en una de las tecnologías más importantes para reemplazar las contraseñas tradicionales gracias a su mayor resistencia frente al phishing, el robo de credenciales y otros ataques comunes. Sin embargo, una reciente investigación demuestra que incluso los sistemas de autenticación más avanzados pueden verse comprometidos cuando un atacante ya ha logrado ejecutar malware en el equipo de la víctima.

Investigadores de Unit 42, el equipo de inteligencia de amenazas de Palo Alto Networks, han presentado tres novedosas técnicas de ataque bautizadas como Pass-ta-key, Silver Pass-ta-key y Golden Pass-ta-key, las cuales permiten a un malware que se ejecuta con privilegios de un usuario estándar iniciar sesión en cuentas protegidas por passkeys sin mostrar ninguna solicitud de autenticación biométrica, PIN o interacción visible para el propietario del dispositivo.

Aunque estos hallazgos no representan una vulnerabilidad criptográfica en las passkeys, sí evidencian que existen debilidades en la forma en que determinados componentes gestionan las claves y el proceso de autenticación alrededor de ellas.

La criptografía sigue siendo segura, el problema está en la implementación

Uno de los aspectos más importantes del informe es que los investigadores no lograron romper la criptografía utilizada por las passkeys.

En cambio, los ataques explotan aspectos relacionados con la implementación del Google Password Manager integrado en Chrome sobre sistemas Windows con Trusted Platform Module (TPM).

En otras palabras, los delincuentes no necesitan descifrar las claves privadas. En su lugar, aprovechan cómo Chrome administra las claves del dispositivo, cómo realiza la reinscripción cuando ese estado desaparece y cómo algunos servicios web validan (o no) la autenticación del usuario.

Esto convierte a los ataques en técnicas posteriores al compromiso (Post-Compromise Attacks), lo que significa que el atacante ya debe haber conseguido ejecutar malware previamente en el ordenador de la víctima.

Un requisito indispensable: el equipo ya debe estar comprometido

El informe deja claro que ninguno de los tres ataques constituye un método de infección.

Para que cualquiera de estas técnicas funcione, el atacante debe haber conseguido previamente instalar malware en el sistema Windows.

Es decir, estas investigaciones describen qué puede hacer un atacante una vez que ya controla parcialmente el dispositivo, pero no explican cómo obtuvo inicialmente dicho acceso.

Esta diferencia es importante porque reduce considerablemente el alcance del riesgo frente a ataques remotos masivos.

Cómo comienza el ataque

El primer paso consiste en realizar un reconocimiento local.

Chrome almacena la información relacionada con las credenciales sincronizadas en la siguiente ubicación:

%LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB

Según Unit 42, un proceso ejecutado sin privilegios administrativos puede acceder a suficiente información para identificar:

• Sitios web asociados a las passkeys.
• Nombres de usuario.
• Identificadores de credenciales.
• Material cifrado correspondiente a las claves privadas.

Aunque estos datos permanecen protegidos criptográficamente, representan una base importante para ejecutar los ataques posteriores.

Primer ataque: Pass-ta-key

La primera técnica, denominada Pass-ta-key, reutiliza la clave de identidad protegida por el TPM.

En lugar de intentar romper la protección del hardware, el malware solicita al propio TPM que firme una petición diseñada por el atacante mediante las funciones criptográficas de Windows (CNG).

El resultado es una afirmación de autenticación válida emitida por el propio dispositivo.

La diferencia respecto a una autenticación legítima radica en un único indicador denominado User Verified (UV).

Cuando un usuario introduce su PIN o utiliza reconocimiento facial o huella digital, dicho bit queda activado.

En este ataque, el bit permanece desactivado porque nunca existió una verificación real del usuario.

El papel crítico del bit User Verification (UV)

Aquí entra en juego la responsabilidad del sitio web.

La especificación WebAuthn establece que los servicios deben exigir la verificación del usuario mediante el parámetro userVerification y comprobar que el indicador UV realmente está presente.

Durante la investigación:

• GitHub rechazó correctamente las autenticaciones fraudulentas.
• eBay aceptó inicialmente dichas autenticaciones debido a una validación incompleta.

Posteriormente, eBay corrigió esta situación tras recibir la divulgación responsable de los investigadores.

Esto demuestra que parte de la seguridad también depende de cómo cada plataforma implemente WebAuthn.

Segundo ataque: Silver Pass-ta-key

La segunda técnica resulta más preocupante.

Silver Pass-ta-key obliga a Chrome a realizar una nueva inscripción del dispositivo.

Durante una pequeña ventana temporal, antes de que Chrome genere su nueva clave de verificación del usuario, el malware registra una clave controlada completamente por el atacante.

Según Unit 42, el servicio no verificaba adecuadamente si la nueva clave provenía realmente de hardware seguro.

Como consecuencia, las futuras autenticaciones realizadas con esa clave ya incluyen el indicador UV activado.

En la práctica, esto permitiría al atacante iniciar sesión posteriormente desde su propio entorno, sin necesidad de seguir utilizando el ordenador comprometido.

Tercer ataque: Golden Pass-ta-key

Golden Pass-ta-key representa el escenario más grave.

En este caso, el malware intenta obtener el denominado Security Domain Secret (SDS), un secreto criptográfico de 32 bytes utilizado para proteger las passkeys sincronizadas.

Durante el proceso de reinscripción, dicho secreto permanece temporalmente en memoria dentro del proceso de Chrome.

Los investigadores sostienen que un malware puede capturarlo antes de que desaparezca y utilizarlo posteriormente para recuperar las claves privadas sincronizadas.

El propio código fuente de Chromium confirma que este secreto existe temporalmente en memoria del navegador, aunque la explotación completa descrita continúa basándose en la investigación de Unit 42.

No existen CVE publicados

Un aspecto llamativo es que la investigación no identifica vulnerabilidades mediante identificadores CVE.

Además:

• No se indican versiones específicas vulnerables.
• No existe confirmación pública de una corrección completa.
• No se describen ataques observados activamente en campañas reales.

Hasta el 3 de agosto de 2026, las búsquedas realizadas en la National Vulnerability Database (NVD) no mostraban registros relacionados con Pass-ta-key, Silver Pass-ta-key o Golden Pass-ta-key.

Google todavía no ha confirmado el estado de todas las mitigaciones

El informe indica que Google ya eliminó una exposición anterior del SDS presente en determinados registros FIDO de Chrome.

Sin embargo, los investigadores afirman que el secreto continúa llegando al cliente y permanece temporalmente en memoria.

Hasta la fecha de la publicación:

• Google no ha documentado públicamente si estas tres técnicas han sido completamente mitigadas.
• No existe documentación que permita verificar si un SDS ha sido comprometido.
• Tampoco se ha aclarado si cambiar el PIN del Administrador de Contraseñas de Google invalida un SDS previamente robado.

Esta incertidumbre representa uno de los principales interrogantes derivados de la investigación.

Recomendaciones para organizaciones y desarrolladores

Aunque los usuarios finales deben mantener protegidos sus equipos frente al malware, gran parte de las medidas corresponde a proveedores de servicios y desarrolladores.

Entre las principales recomendaciones destacan:

• Exigir siempre userVerification durante la autenticación.
• Verificar explícitamente el indicador UV devuelto por WebAuthn.
• Validar mediante atestación que las nuevas claves registradas procedan de hardware confiable.
• Reforzar los mecanismos de reinscripción y recuperación de dispositivos.
• Reducir al mínimo la exposición de secretos criptográficos en memoria.
• Evitar almacenar información sensible en registros o archivos accesibles localmente.

En fin...

La investigación de Unit 42 demuestra que las passkeys siguen siendo considerablemente más seguras que las contraseñas tradicionales, ya que ninguno de los ataques consigue romper su criptografía. Sin embargo, también pone de manifiesto que la seguridad de un sistema de autenticación depende de mucho más que los algoritmos criptográficos.

Cuando un dispositivo ya ha sido comprometido por malware, la protección puede verse debilitada si existen fallos en la implementación, en los procesos de reinscripción o en la validación realizada por los servicios que aceptan passkeys.

Mientras Google continúa evaluando y fortaleciendo estas áreas, las organizaciones deben aplicar correctamente las especificaciones de WebAuthn y los usuarios deben priorizar la prevención del malware mediante sistemas actualizados, soluciones de seguridad confiables y buenas prácticas de ciberseguridad. En un escenario donde las amenazas evolucionan constantemente, proteger el dispositivo sigue siendo la primera línea de defensa para preservar la integridad de las credenciales digitales y evitar el acceso no autorizado a cuentas críticas.

Fuente: You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login