Un malware que se ejecuta como usuario normal en una máquina Windows puede iniciar sesión en cuentas protegidas con claves de acceso (passkeys) de una víctima sin necesidad de huella dactilar, PIN o cualquier interacción visible en la pantalla. Unit 42, el equipo de investigación de Palo Alto Networks, ha detallado tres rutas de ataque contra el autenticador en la nube del administrador de contraseñas de Google en Chrome, denominadas Pass-ta-key, Silver Pass-ta-key y Golden Pass-ta-key. La más grave se dirige a la clave maestra que protege las passkeys sincronizadas.
Estos ataques no vulneran la criptografía subyacente, sino que explotan el código alrededor de las passkeys: cómo Chrome almacena sus claves de dispositivo, cómo se re-registra un dispositivo tras la pérdida de ese estado, y si el sitio web verifica realmente que un humano ha sido autenticado. Los atacantes pueden obtener silenciosamente una aserción de autenticación válida, instalar una clave de verificación de usuario controlada por el atacante o extraer el Secreto de Dominio de Seguridad (SDS) de 32 bytes utilizado para descifrar las claves privadas de las passkeys sincronizadas.
Los investigadores indican que las dos últimas rutas pueden proporcionar acceso reutilizable desde el entorno del atacante después del compromiso inicial. El informe no describe explotación en la naturaleza y no proporciona identificadores CVE, versiones afectadas de Chrome ni un estado completo de remediación. Una búsqueda en la Base de Datos Nacional de Vulnerabilidades el 3 de agosto de 2026 no encontró ningún CVE que coincidiera con las tres técnicas nombradas.
La investigación se limita al Administrador de Contraseñas de Google en Chrome en sistemas Windows equipados con un Módulo de Plataforma Confiable (TPM), y todas las rutas comienzan con malware ya ejecutándose en el dispositivo de la víctima. El código fuente de Chromium al 3 de agosto corrobora partes de la arquitectura, aunque no confirma que la última versión estable de Chrome siga siendo explotable. Estas son técnicas posteriores al compromiso; describen lo que un atacante puede alcanzar en una máquina ya perdida, no cómo se perdió la máquina.
Primera ruta de ataque: Pass-ta-key
La primera técnica, Pass-ta-key, extrae la clave de identidad del dispositivo envuelta de Chrome y solicita al mismo TPM que firme una solicitud controlada por el atacante a través de las llamadas de Windows Cryptography API: Next Generation (CNG). El código fuente actual de Chromium muestra por qué ese blob es reutilizable: Chrome crea la clave TPM sin nombre, lo que, según un comentario en el código, evita que se persista en el disco. Chrome exporta la clave como un blob opaco y la recarga más tarde bajo una bandera que suprime cualquier aviso. Un TODO en el mismo archivo hace referencia al problema 398125799 de Chromium, proponiendo que esas claves se etiqueten en su lugar.
El autenticador en la nube de Google devuelve una aserción válida, y lo único que la separa de una producida tras una verificación real del usuario es un solo bit, el indicador de Usuario Verificado (UV), que queda sin establecer. La especificación actual de Web Authentication dice que una parte confiable que establece userVerification como required debe fallar la ceremonia cuando ese bit esté ausente. Los investigadores dijeron que GitHub aplicaba la verificación, mientras que eBay aceptaba su aserción de prueba hasta que la empresa corrigió la brecha tras la divulgación. De las tres rutas, esta es la que depende de un control que la parte confiable maneja, por lo que un sitio puede fallarla independientemente de cómo se comporte el servicio en la nube; de los dos nombres que Unit 42 menciona, uno lo hizo.
Segunda ruta de ataque: Silver Pass-ta-key
Silver Pass-ta-key apunta a la siguiente capa. El malware obliga a Chrome a volver a registrar el dispositivo. Chrome no crea su clave de verificación de usuario de inmediato, y en esa ventana un atacante puede registrar una propia. Unit 42 dijo que el servicio no verifica si una clave recién registrada proviene de hardware seguro. Las aserciones firmadas con esa clave llevan el indicador UV, lo que, según los investigadores, permite inicios de sesión posteriores sin el dispositivo de la víctima. El código fuente actual de Chromium confirma de manera independiente que los dispositivos recién registrados pueden conservar un estado deferred_uv_key_creation, pero el código público por sí solo no verifica el ataque de sustitución de clave reportado contra la última versión estable de Chrome.
La divulgación no dice si el servicio de producción ahora verifica la atestación de hardware antes de aceptar una clave de reemplazo, una verificación que Unit 42 recomienda para mitigar esta ruta.
Tercera ruta de ataque: Golden Pass-ta-key
Golden Pass-ta-key va tras el SDS. Unit 42 dice que el malware puede activar el re-registro, leer el secreto de la memoria del proceso de Chrome mientras está brevemente en texto plano, y usarlo para recuperar las claves privadas de passkeys sincronizadas. El código fuente actual de Chromium corrobora la exposición subyacente: Chrome crea o recibe secretos de dominio de seguridad de 32 bytes en estructuras de datos del proceso cliente. Esto confirma que el secreto entra en la memoria de Chrome, aunque la extracción confiable, el compromiso de la cuenta y la persistencia a través de futuros cambios de secreto siguen basándose en Unit 42 o sin resolverse.
Los investigadores dijeron que Google eliminó una exposición anterior del SDS de los registros FIDO de Chrome y que eBay ahora valida el indicador UV. Dijeron que el secreto aún llega al cliente y permanece en la memoria de Chrome, por lo que el cambio de registro no cierra la ruta que describen. La divulgación no establece si todas las rutas de ataque han sido cerradas. Al 3 de agosto de 2026, las búsquedas en los materiales públicos de Chrome de Google y en las páginas de soporte y prensa de eBay no encontraron ningún aviso que documente los cambios reportados, y ninguno describe una forma para que el usuario verifique si un SDS fue expuesto.
Recomendaciones y estado actual
La documentación de soporte público de Google permite a los usuarios cambiar su PIN del Administrador de Contraseñas o eliminar todos los datos del Administrador de Contraseñas, pero no describe un control específico de rotación o revocación del SDS. The Hacker News contactó a Google para preguntar si un secreto de seguridad robado sobrevive a un cambio de PIN, y a Palo Alto Networks para obtener más detalles sobre la investigación, y actualizará esta historia con cualquier respuesta.
Se recomienda a las partes confiables que establezcan userVerification como required y verifiquen el bit UV devuelto, en lugar de confiar solo en la configuración de la solicitud. Los proveedores de credenciales deben atestar claves recién registradas, fortalecer los controles de re-registro y recuperación, restringir el acceso al estado local de las passkeys y mantener las claves maestras fuera de los registros y la memoria del cliente.
Las fuentes revisadas no dicen si cambiar el PIN del Administrador de Contraseñas de Google o eliminar los datos del Administrador de Contraseñas invalida un secreto que un atacante ya posee, que es lo que un usuario que sospeche un compromiso necesitaría para actuar.
Deja una respuesta