•   El malware que se ejecuta como un usuario común en una máquina Windows puede iniciar sesión en las cuentas protegidas por passkey de una víctima sin huellas dactilares, PIN ni que aparezca absolutamente nada en la pantalla de la víctima.

Unit 42 detalló tres rutas de ataque contra el autenticador en la nube del Gestor de Contraseñas de Google de Chrome, que denomina Pass-ta-key, Silver Pass-ta-key y Golden Pass-ta-key; el más fuerte se dirige a la clave maestra que protege las passkeys sincronizadas del usuario.

Nada de esto rompe la criptografía. Los ataques van dirigidos al código que rodea la passkey: cómo Chrome almacena sus claves de dispositivo, cómo vuelve a registrar un dispositivo después de que ese estado desaparece y si el sitio en el que estás iniciando sesión se molesta en comprobar si un humano fue verificado.

Los ataques pueden obtener silenciosamente una afirmación de autenticación válida, instalar una clave de verificación de usuario controlada por un 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 afirmaron que las dos últimas rutas pueden proporcionar acceso reutilizable desde el propio entorno de un atacante tras el compromiso inicial del endpoint. El informe no describe la explotación en condiciones reales y no proporciona identificadores CVE, versiones de Chrome afectadas ni el estado completo de la 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 mencionadas.

La investigación se limita al Gestor de Contraseñas de Google en Chrome en sistemas Windows equipados con un Módulo de Plataforma Confiable (TPM), y cada ruta comienza con malware que ya se está ejecutando en el dispositivo de la víctima.

El código fuente de Chromium al 3 de agosto corrobora partes de la arquitectura, no que la última versión estable de Chrome siga siendo explotable. Estas son técnicas posteriores al compromiso. Describen lo que un atacante logra en una máquina que ya ha sido perdida, no cómo se perdió la máquina.

El ataque comienza con un reconocimiento local. Chrome almacena los registros de credenciales sincronizadas en %LocalAppData%\Google\Chrome\User Data\\Sync Data\LevelDB. Los investigadores afirmaron que un proceso sin privilegios puede leer suficientes metadatos para identificar las partes dependientes y los nombres de usuario vinculados a las passkeys de la víctima, junto con los identificadores de credenciales y el material de claves privadas cifradas.

Primera ruta de ataque

La primera técnica, Pass-ta-key, extrae la clave de identidad del dispositivo envuelta de Chrome y pide al mismo TPM que firme una solicitud controlada por un atacante mediante llamadas a la API de Criptografía de Windows: Next Generation (CNG).

El código fuente actual de Chromium muestra por qué ese bloque es reutilizable: Chrome crea la clave TPM sin un nombre de clave, lo que según un comentario en el código evita que se persista en el disco. Luego, Chrome exporta la clave como un bloque opaco y la vuelve a cargar más tarde bajo un indicador que suprime cualquier aviso (prompt). Un "TODO" en el mismo archivo apunta al problema de Chromium 398125799, proponiendo que esas claves se etiqueten en su lugar.

El Autenticador de Google Cloud devuelve una afirmación válida, y lo único que la separa de una producida tras un control de usuario real es un solo bit, el indicador de Usuario Verificado (UV), que se deja sin marcar. La especificación actual de Web Authentication dice que una parte dependiente que establezca la verificación de usuario como obligatoria debe fallar la ceremonia cuando ese bit esté ausente. Los investigadores dijeron que GitHub aplicaba el control, mientras que eBay aceptaba su afirmación de prueba hasta que la empresa corrigió el fallo de validación tras la divulgación. De las tres rutas, esta es la que activa un control que la parte dependiente maneja, por lo que un sitio puede rechazarla independientemente de cómo se comporte el servicio en la nube, y de los dos nombres de Unit 42, uno lo hizo.

Segunda ruta de ataque

Silver Pass-ta-key se dirige 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 inmediatamente y, en esa ventana, un atacante puede registrar una propia.

Unit 42 dijo que el servicio no comprueba si una clave recién registrada proviene de hardware seguro. Las afirmaciones 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 independientemente que los dispositivos recién registrados pueden mantener un estado de creación de clave UV diferida, pero el código público por sí solo no verifica el ataque de sustitución de claves en el servidor reportado contra la última versión estable de Chrome.

La divulgación no dice si el servicio de producción ahora comprueba la atestación de hardware antes de aceptar una clave de reemplazo, un control que Unit 42 recomienda para mitigar esta ruta.

Tercera ruta de ataque

Golden Pass-ta-key va tras el propio SDS. Unit 42 afirmó que el malware puede activar el nuevo registro, leer el secreto de la memoria del proceso de Chrome mientras permanece brevemente allí en texto plano y usarlo para recuperar las claves privadas de las 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. Eso confirma que el secreto entra en la memoria de Chrome, aunque la extracción fiable, la toma de control de la cuenta y la persistencia a través de futuras épocas de secretos siguen basándose en Unit 42 o no han sido resueltas.

Los investigadores dijeron que Google eliminó una exposición anterior de SDS de los registros FIDO de Chrome y que eBay ahora valida el indicador UV. Afirmaron que el secreto sigue llegando al cliente y permanece en la memoria de Chrome, por lo que el cambio en el registro no cierra la ruta descrita.

La divulgación no establece si las tres 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 documentara el cambio reportado, y ninguno de ellos describe una forma para que tú compruebes si un SDS fue expuesto.

La documentación de soporte público de Google permite a los usuarios cambiar su PIN del Gestor de Contraseñas de Google o eliminar todos los datos del Gestor de Contraseñas, pero no describe un control de rotación o revocación específico para el SDS. The Hacker News se ha puesto en contacto con Google para saber si un secreto de dominio de seguridad robado sobrevive a un cambio de PIN del Gestor de Contraseñas, y con Palo Alto Networks para obtener más detalles sobre la investigación, y actualizará esta historia con cualquier respuesta.

Las partes dependientes deberían establecer la verificación de usuario como obligatoria y verificar el bit UV devuelto en lugar de confiar únicamente en la configuración de la solicitud. Los proveedores de credenciales deberían atestiguar las claves recién enroladas, reforzar los controles de registro y recuperación, restringir el acceso al estado local de la passkey y mantener las claves maestras fuera de los registros y de la memoria del cliente.

Las fuentes revisadas no indican si cambiar el PIN del Gestor de Contraseñas de Google o eliminar sus datos invalida un secreto que un atacante ya posea, que es precisamente lo que tú necesitarías hacer si sospechas que has sido comprometido.

Fuente:
THN