Se vende en foros rusos iAuthFlow v2, un kit de phishing que utiliza un modelo de navegador intermedio para registrar llaves de acceso (passkeys) controladas por el atacante. Esto permite el acceso persistente a cuentas de Google, Microsoft y otras, incluso después de que la víctima cambie su contraseña. Los expertos advierten que la recuperación de cuentas ya no basta con reiniciar contraseñas, sino que requiere una investigación exhaustiva de credenciales y configuraciones alteradas.



Un kit de phishing a la venta en foros de cibercrimen en idioma ruso afirma que puede registrar llaves de acceso (passkeys) controladas por el atacante en cuentas comprometidas, proporcionando acceso persistente incluso después de que se cambien las contraseñas.

Anunciado a un precio aproximado de 10.000 dólares para el paquete básico, con módulos adicionales vendidos por separado, iAuthFlow v2 pretende resolver un problema común para los atacantes: quedar bloqueados después de que la víctima detecte el compromiso.

Normalmente, los defensores revocarían los tokens de sesión y rotarían las credenciales. Esas medidas siguen siendo necesarias, pero podrían no ser suficientes si el atacante ha registrado una llave de acceso en la cuenta comprometida.

Según Abnormal Security, que examinó la documentación y los vídeos de demostración del kit, la técnica utiliza un modelo de navegador intermedio (Browser-in-the-Middle o BitM) que implica dos entornos de navegador independientes.

En un ataque BitM, la víctima parece completar el inicio de sesión en su propio dispositivo, mientras que la infraestructura del atacante retransmite la interacción a través de una sesión de navegador separada.

La víctima ve una página de phishing que suplanta al servicio objetivo. Las demostraciones de iAuthFlow v2 se centraron en Google, pero el vendedor también anuncia paquetes para iCloud, LinkedIn y Microsoft.

La víctima introduce los datos de su cuenta en la página de phishing, mientras iAuthFlow v2 opera un navegador independiente en el servidor del atacante. Este envía la entrada de la víctima a Google y retransmite las solicitudes de Google de vuelta a la víctima. El proceso se repite hasta que el flujo de autenticación se completa.

Una vez completada la autenticación, iAuthFlow v2 controla una sesión de navegador autenticada y la utiliza para registrar una llave de acceso controlada por el atacante, afirma Abnormal. Esa credencial puede seguir siendo válida después de que la víctima cambie su contraseña.

En lugar de enviar a la víctima a su bandeja de entrada de Gmail tras la autenticación, iAuthFlow v2 muestra una breve pantalla de carga que dice: "Verificación, Procesando". Mientras tanto, el kit de herramientas trabaja en segundo plano para registrar una llave de acceso en un dispositivo controlado por el atacante.

"Durante esa pausa, la demostración del vendedor muestra el módulo de llaves de acceso abriendo la configuración de llaves de acceso de Google del objetivo a través del navegador autenticado y solicitando una nueva credencial", dijo Abnormal [https://abnormal.ai/blog/iauthflow-v2-phishing-google-passkeys].

"Google puede requerir una verificación de identidad adicional antes de permitir el cambio. En la ejecución grabada, el registro del kit indica que la llave de acceso se creó seis segundos después de la autenticación".

No está claro dónde se almacena la clave privada asociada a la llave de acceso del atacante. Abnormal hipotetizó que el kit podría utilizar un autenticador virtual basado en Chromium capaz de completar el registro WebAuthn sin almacenar la clave privada en el dispositivo de la víctima.

Sin embargo, debido a que los investigadores no compraron ni probaron el kit, no pudieron confirmar su mecanismo de almacenamiento ni verificar independientemente las afirmaciones más amplias del vendedor.

Independientemente del mecanismo de almacenamiento, las organizaciones deben buscar llaves de acceso recién registradas al investigar el compromiso de una cuenta.

Los responsables de la respuesta también deberían buscar otros cambios posteriores al compromiso, incluyendo llaves de acceso fraudulentas, concesiones de OAuth, métodos de recuperación, filtros de Gmail y reglas de reenvío.

"La respuesta y la recuperación no pueden terminar con un restablecimiento de contraseña o la revocación de la sesión", dijo Abnormal. "Las organizaciones también deben examinar qué cambió después de la autenticación —especialmente las credenciales recién inscritas, los métodos de recuperación, las concesiones de OAuth y la configuración del buzón de correo— y eliminar cualquier cosa que el atacante haya dejado atrás.

"A medida que kits de herramientas como iAuthFlow v2 amplían sus capacidades post-autenticación, la respuesta efectiva depende cada vez más de tratar la restauración de la cuenta como una investigación exhaustiva, no como un simple restablecimiento".

Las llaves de acceso se presentan habitualmente como el futuro de la seguridad de las cuentas. Diseñadas para resistir el phishing, pueden reemplazar las contraseñas y formas más vulnerables de MFA.

Registrar una llave de acceso no hace que una cuenta sea blindada. Los atacantes pueden, en su lugar, dirigirse a los métodos de inicio de sesión alternativos, sesiones activas, procesos de recuperación de cuenta y otras debilidades que rodean la credencial.

El robo de cookies de sesión, a menudo a través de malware infostealer, puede otorgar acceso a una sesión autenticada sin activar una solicitud de llave de acceso.

Otra ruta es el phishing de código de dispositivo, aunque depende de que la organización permita el flujo de dispositivo OAuth subyacente, algo que generalmente se desaconseja a menos que sea operativamente necesario.

Fuente:
TheRegister