Ataque AiTM y robo de token MFA

El atacante no tiene que fabricar un sitio falso: instala un servidor web que hace pasar los paquetes HTTP entre la víctima y el servicio objetivo, en los dos sentidos¹. La página contiene dos sesiones TLS distintas, una con la víctima y otra con el sitio real, lo que le permite extraer de las solicitudes las contraseñas y, más importante, las cookies de sesión¹.

Este trabajo se puede automatizar con kits de código abierto. Microsoft cita Evilginx2, Modlishka y Muraena¹. MITRE precisa que Evilginx2 puede servir de relé AiTM entre un sitio legítimo y una persona víctima de phishing para capturar credenciales, tokens de autenticación y cookies de sesión⁵. Una vez obtenida la cookie, el atacante la inyecta en su propio navegador para saltarse la autenticación, aunque la MFA del objetivo esté activada¹.

Al principio hay un mensaje. MITRE describe el correo con enlace malicioso, que sirve, entre otras cosas, para evitar las defensas que inspeccionan los archivos adjuntos⁶. En la campaña estudiada por Microsoft, el correo llevaba un archivo adjunto HTML y anunciaba un mensaje de voz¹. La página mostraba una barra de descarga del mensaje, pero la barra estaba escrita directamente en el archivo: no se descargaba ningún archivo de audio¹. Después se redirigía a la víctima a una página que rellenaba previamente su dirección de correo, lo que reforzaba la credibilidad de la trampa¹.

Luego viene la página de inicio de sesión, copia del portal de Microsoft. Una vez introducidas las credenciales y superada la autenticación, la víctima llegaba a la página real de office.com¹. Nada señala la interceptación: en segundo plano, el atacante ya había interceptado las credenciales y abierto a su vez una sesión¹.

Esta es una ilustración neutralizada de la forma de una dirección así, para mostrar que solo la dirección delata la trampa:

Ilustración (dirección neutralizada, inventada para el ejemplo):
hxxps://login[.]exemple-portail[.]invalid/[identificador de la víctima]
Página mostrada: [copia del formulario de inicio de sesión de Microsoft]
Dirección esperada: [la dirección oficial del servicio, escrita o guardada por usted]

Un servicio web abre una sesión tras la autenticación, para no volver a pedir la identidad en cada página. Esa sesión se apoya en una cookie facilitada por el servicio de autenticación, que demuestra al servidor que el usuario ha iniciado sesión¹. MITRE señala que estas cookies suelen seguir siendo válidas mucho tiempo, incluso cuando la aplicación no se usa activamente⁷. Un atacante que posea una puede importarla en un navegador que controle e iniciar sesión en la aplicación².

En la campaña de 2022, las cookies llevaban una declaración MFA: el atacante las usaba, por tanto, para acceder a la cuenta a pesar de la política MFA de la organización¹. MITRE cita también un caso en que APT29 usó cookies robadas para acceder a recursos en la nube, y una cookie duo-sid falsificada para eludir la MFA de una cuenta de correo, durante el compromiso de SolarWinds².

En cuanto a la defensa, CISA clasifica las formas de MFA de la más fuerte a la más débil. Los códigos de un solo uso de una aplicación son vulnerables al phishing, igual que los SMS y las llamadas de voz³. Las notificaciones push con introducción de un número resisten el «push bombing», pero no el phishing³. Solo FIDO/WebAuthn es, según CISA, la autenticación resistente al phishing ampliamente disponible³. El NCSC británico dedica una guía a los métodos de MFA más sólidos⁸. Microsoft recomienda además políticas de acceso condicional, evaluadas en cada intento de uso de una cookie robada (dispositivo conforme, dirección IP de confianza)¹.

Julio de 2022: una campaña dirigida a más de 10 000 organizaciones

El 12 de julio de 2022, Microsoft publica el análisis de una campaña de phishing AiTM a gran escala. Robó contraseñas, secuestró sesiones y pasó por alto la autenticación incluso con la MFA activada. Según los datos de Microsoft, intentó atacar a más de 10 000 organizaciones desde septiembre de 2021¹. Los atacantes imitaban la página de autenticación en línea de Office, con el kit Evilginx2¹.

Después del robo: el fraude de transferencias

Los atacantes usaban después las credenciales y las cookies robadas para acceder a buzones de correo y lanzar fraudes de transferencias (BEC) contra otros objetivos¹. Microsoft observó que podían bastar cinco minutos entre el robo y el inicio del fraude¹. Durante los días siguientes, el atacante consultaba cada pocas horas los correos y archivos adjuntos financieros, buscaba conversaciones en curso y luego borraba el correo de phishing inicial¹.

A continuación creaba una regla de bandeja de entrada que movía a «Archivo», marcados como leídos, los mensajes procedentes del dominio del objetivo del fraude, para que el titular no viera nada¹. Por último, respondía a los hilos sobre pagos y facturas y luego eliminaba sus respuestas de los elementos enviados¹. En una ocasión llevó a cabo varios intentos en paralelo desde el mismo buzón¹.