Un kit de $10.000 vendido en foros rusos inscribe passkeys del atacante en cuentas de Google comprometidas, manteniendo acceso permanente incluso después del reseteo.
Abnormal Security documentó un toolkit de phishing que resuelve el problema histórico de la persistencia post-compromiso: iAuthFlow v2 no se limita a robar credenciales ni a secuestrar una sesión temporal, sino que usa esa ventana inicial para inscribir una passkey controlada por el atacante en la cuenta de Google de la víctima. Esa passkey permanece activa después de que el usuario cambia su contraseña, termina sesiones abiertas y revoca tokens OAuth. El kit se vende en un foro de cibercrimen de habla rusa por un precio base de $10.000, con módulos adicionales disponibles por separado.
Cómo funciona el ataque browser-in-the-middle con inscripción de passkey
El toolkit implementa un ataque browser-in-the-middle: la víctima ve una página de login falsa de Google mientras otro navegador, ejecutándose en el servidor del atacante, realiza el login real. Todo lo que la víctima ingresa — correo, contraseña, código de segundo factor — se envía al navegador remoto, que obtiene las cookies de sesión autenticada. En la demostración analizada, la página falsa usó un subdominio trycloudflare.com para obtener un certificado TLS válido, aumentando la apariencia de legitimidad.
Una vez que el navegador del atacante tiene las cookies de sesión de Google, iAuthFlow v2 mantiene a la víctima en una página de «Verification, Processing» mientras trabaja dentro de la cuenta. Este estado de pausa está nombrado explícitamente en el software. Los timestamps del registro de sesión documentan la velocidad del proceso: login a las 21:37:18, passkey creada y almacenada a las 21:37:24. Seis segundos para establecer acceso persistente.
El módulo de passkey navega la configuración de passkeys de Google a través del navegador autenticado y solicita una nueva credencial. Google puede pedir re-verificación de identidad antes de permitir la inscripción; la demostración muestra que el toolkit maneja este paso. La passkey inscrita se almacena del lado del atacante, y el toolkit registra «Passkey created and saved».
Por qué una passkey no se elimina al cambiar la contraseña
Cambiar una contraseña de Google termina sesiones activas, revoca contraseñas de aplicaciones e invalida algunos tokens OAuth. Una passkey es diferente: es una credencial criptográfica separada vinculada a la cuenta, y permanece activa hasta que se elimina manualmente. Esta diferencia convierte a iAuthFlow v2 en una amenaza más seria que el simple robo de cookies de sesión.
La demostración del vendedor muestra el riesgo con claridad. Después de que la víctima cambia su contraseña, la sesión del atacante deja de funcionar. Pero el atacante puede elegir «Try another way», usar la passkey que previamente agregó y recuperar acceso al buzón. La víctima puede no tener idea de que esto ocurrió. Abnormal Security identifica como mecanismo técnico plausible el uso de autenticadores virtuales basados en software de Chromium, que soportan registro WebAuthn y retienen claves privadas sin requerir el dispositivo físico del objetivo. Los investigadores no confirman que el toolkit use exactamente este método — la demostración no revela la implementación — pero sí confirman que el comportamiento mostrado es consistente con cómo funcionan las passkeys y que existe una ruta disponible para producirlo.
Exposición en América Latina por dependencia de Google Workspace
El toolkit analizado apunta a Google, pero el vendedor anuncia versiones para Microsoft, iCloud y LinkedIn. La misma lógica de persistencia post-autenticación aplica en cualquier plataforma donde se puedan inscribir passkeys. En América Latina, donde Google Workspace tiene penetración significativa en sectores corporativo, educativo y gubernamental — particularmente en Brasil, México y Argentina — la exposición es estructural: cualquier organización que dependa de Google para correo y colaboración enfrenta este vector de ataque si no ha implementado controles específicos de autenticación.
La contención después de un compromiso con iAuthFlow v2 requiere ir más allá de lo que los equipos de respuesta a incidentes suelen hacer. Abnormal Security señala que ni el reseteo de contraseña ni la revocación de sesiones elimina una passkey inscrita por el atacante. La limpieza completa debe cubrir passkeys y security keys no autorizadas, filtros y reglas de reenvío maliciosas en Gmail, acceso delegado, permisos OAuth y configuraciones de recuperación. Las organizaciones que ejecutan Google Workspace pueden usar la Security Investigation Tool para auditar la cuenta antes de declararla limpia.
Prevención mediante autenticación resistente a phishing
La mejor forma de prevenir estos ataques es depender de métodos de autenticación que no puedan ser robados fácilmente mediante phishing. La autenticación basada en WebAuthn está atada al sitio web real, por lo que contraseñas o códigos robados no pueden usarse a través de un ataque de relay. Google Workspace puede forzar esto con la opción «Only security key» para verificación en dos pasos y a través del Advanced Protection Program. Estas configuraciones también deshabilitan contraseñas de aplicaciones, que el toolkit puede apuntar en cuentas menos protegidas.
El precio del toolkit y sus canales de venta profesionales sugieren que se trata de un negocio en curso, no de una liberación única. Si una cuenta de Google está comprometida pero aparece limpia después de un reseteo de contraseña, los equipos de seguridad deben revisar también las passkeys y security keys de la cuenta antes de cerrar el caso.
Nuestro análisis
iAuthFlow v2 representa una evolución táctica en phishing que explota una característica de seguridad — las passkeys — para convertirla en un mecanismo de persistencia. El patrón no es nuevo: los atacantes siempre han buscado formas de mantener acceso después del compromiso inicial, desde backdoors en sistemas operativos hasta tokens de API robados. Lo que cambia acá es la superficie de ataque: las passkeys fueron diseñadas para ser más seguras que las contraseñas, pero su persistencia por diseño — que las hace convenientes para usuarios legítimos — también las hace valiosas para un atacante que logra inscribir una propia.
El precio de $10.000 y la venta en foros estructurados indican que hay demanda comercial para este tipo de persistencia. La velocidad de inscripción documentada — seis segundos — sugiere que el proceso está altamente automatizado y probado. Lo que todavía no se sabe es cuántas cuentas han sido comprometidas con este toolkit específico, si hay variantes similares apuntando a otras plataformas más allá de las anunciadas por el vendedor, y si los proveedores de identidad están detectando patrones de inscripción de passkeys anómalos en tiempo real. ¿Qué pasaría si este patrón de inscripción rápida post-phishing se convierte en el estándar operativo de los grupos de cibercrimen que hoy dependen de sesiones temporales?