Adversary-in-the-middle (AiTM)

A la víctima se la dirige a un dominio parecido que no es una copia del sitio objetivo, sino un proxy delante de él. Cada petición se reenvía al sitio auténtico y cada respuesta se le devuelve a la víctima, así que las páginas son reales, la marca es correcta y cualquier desafío que plantee el sitio aparece exactamente como debe. La víctima escribe su contraseña, recibe y escribe su código de un solo uso o aprueba una notificación push, y el sitio real emite una cookie de sesión. El proxy guarda esa cookie antes de dejar pasar la respuesta.

A partir de ahí el atacante reproduce la sesión en su propio navegador y está autenticado. Las herramientas para esto son públicas y se configuran con una plantilla por objetivo, así que no es una capacidad avanzada.

Esta técnica invalida el consejo que se lleva dando una década, y conviene decirlo sin rodeos: activar la autenticación multifactor con códigos o con aprobación push no impide el phishing. Encarece los ataques que solo buscan credenciales y no hace nada contra un proxy en vivo, porque el segundo factor se retransmite como todo lo demás.

Lo que sí resiste es una credencial cuya respuesta está ligada al origen con el que el navegador ha hablado de verdad. Una passkey firma un desafío que incluye el dominio parecido, y el sitio real lo rechaza, así que el ataque falla en el paso de autenticación en lugar de detectarse después. Eso es una propiedad estructural, no una mejora de detección.

Donde no se pueden desplegar credenciales resistentes al phishing en todas partes, el plan B es hacer que la sesión robada valga menos: ligar los tokens al dispositivo, exigir un dispositivo conforme mediante acceso condicional, evaluar el riesgo de forma continua y no solo al iniciar sesión, y alertar cuando una sesión se use desde una dirección o un cliente distintos de aquellos para los que se emitió. Eso reduce el valor del robo; no lo impide.

Un ejercicio de phishing que solo cuenta quién hizo clic está midiendo un control que ha dejado de ser el que decide. Ejecutamos escenarios con proxy bajo acuerdo escrito e informamos de lo que le importaría a un operador real: cuántas sesiones conseguimos, si pudimos usarlas, a qué llegaron y si algo de aquello se detectó. Contra un tenant con credenciales resistentes al phishing impuestas, el resultado es ninguna sesión utilizable, y esa evidencia es el argumento más fuerte para el despliegue. Esto forma parte de cómo hacemos ejercicios de phishing que reflejan la técnica actual.