Cada vez es más común iniciar sesión en una app con un solo clic usando cuentas como Microsoft o Google. Rápido, conveniente… y, en algunos casos, riesgoso. Lo que muchos no saben es que al aceptar ciertos permisos sin pensarlo dos veces, podrían estar entregando las llaves de su información a un atacante. No hace falta robar una contraseña: basta con engañar al usuario para que autorice algo que parece inofensivo.
Recientemente, se ha detectado una preocupante campaña dirigida a trabajadores de organizaciones vinculadas con Ucrania y la defensa de los derechos humanos. Los atacantes, que operan desde Rusia, se hacen pasar por funcionarios europeos y contactan a sus objetivos a través de plataformas como WhatsApp y Signal. Su objetivo: engañar a las víctimas para que entreguen códigos de autorización de Microsoft o hagan clic en enlaces maliciosos que capturan sus credenciales y accesos temporales.
Esta es la base de una técnica cada vez más común en el arsenal del cibercrimen: el abuso de los flujos de autenticación legítimos de OAuth 2.0.
¿Cómo empezó el ataque?
Todo comenzó con un simple mensaje por Signal o WhatsApp. Según los investigadores, en al menos un caso, ese primer contacto vino desde una cuenta del gobierno ucraniano que ya había sido comprometida. Es decir, los atacantes estaban usando identidades reales para parecer más creíbles y ganar la confianza de sus víctimas desde el primer momento.
Correo electrónico enviado a los objetivos (Fuente: Volexity)
Los atacantes se hacen pasar por diplomáticos ucranianos o funcionarios europeos y contactan a sus víctimas con invitaciones bastante convincentes para participar en videollamadas privadas sobre temas relacionados con Ucrania.
Una vez que tienen la atención del objetivo y ya hay cierta confianza, envían un enlace de phishing disfrazado como si fuera el acceso a la videollamada. En realidad, ese link es una trampa para robar permisos de acceso a la cuenta de Microsoft de la víctima.
Mensajes enviados a los objetivos
En algunos casos, UTA0352 también envía un archivo PDF con supuestas instrucciones para unirse a la reunión. Dentro del documento, hay un enlace que en realidad lleva a una página maliciosa diseñada para hacer que la víctima inicie sesión con su cuenta de Microsoft, aprovechando los flujos OAuth que usan muchas apps conectadas a Microsoft 365.
Si la persona cae en la trampa e ingresa sus datos, termina siendo redirigida a lo que parece ser una versión en el navegador de Visual Studio Code, alojada en insiders.vscode.dev. Según explican los investigadores, esta página está preparada para capturar los parámetros de inicio de sesión de Microsoft 365, y lo primero que ve el usuario es un cuadro de diálogo que parece completamente legítimo.
El atacante usa ingeniería social para convencer a la víctima de que le envíe un código, diciéndole que es necesario para poder entrar a la reunión. Todo parece parte del proceso normal, así que es fácil caer.
El problema es que ese código no es cualquier cosa: es un código de autorización válido por 60 días, que el atacante puede usar para conseguir un token de acceso con todos los permisos que normalmente tiene ese usuario. Es decir, acceso total a su cuenta.
Un detalle importante es que ese código también aparece en la barra de direcciones del navegador, lo que facilita que lo copien y lo compartan. Todo parece indicar que la versión web de Visual Studio Code fue configurada a propósito para que esto fuera así. En otras plataformas, lo más común es que simplemente se muestre una página en blanco, sin nada útil a la vista.
Los investigadores incluso armaron un diagrama que resume cómo se lleva a cabo este ataque usando una app personalizada que imita Visual Studio Code.
Flujo de ataque completo
Así engañan a las víctimas paso a paso: del mensaje al control total
Los investigadores encontraron que este tipo de ataque no es completamente nuevo. Ya habían visto versiones anteriores donde los atacantes usaban un formato más viejo (el de AzureAD v1.0 en lugar del más reciente v2.0), y la principal diferencia estaba en los parámetros que ponían en la URL para engañar al usuario.
Una campaña más reciente, lanzada en abril y atribuida a otro grupo llamado UTA0355, sigue un patrón muy parecido al de UTA0352. Esta vez, el primer contacto llegó desde una cuenta de correo del gobierno ucraniano que ya había sido hackeada, lo que daba aún más credibilidad al mensaje.
En este caso, el atacante usó un código de autorización OAuth robado para registrar un nuevo dispositivo en la cuenta de Microsoft Entra de la víctima (antes conocida como Azure Active Directory). Pero eso no fue todo. También necesitaban que la persona aprobara una solicitud de autenticación de dos factores (2FA), así que recurrieron, una vez más, a la ingeniería social.
¿Cómo lo hicieron? Le dijeron a la víctima que ese código 2FA era necesario para acceder a una supuesta instancia de SharePoint vinculada a una conferencia. Bastante convincente si no estás prestando demasiada atención.
Con ese paso final, no solo obtuvieron un token para leer correos y acceder a información sensible, sino que también lograron registrar un nuevo dispositivo, lo que les permitió mantener el acceso por más tiempo sin levantar sospechas.
Según los registros que revisaron los investigadores, el dispositivo se registró justo después de que la víctima interactuó con el atacante. Al día siguiente ya estaban accediendo a sus correos, y para entonces, ya habían preparado todo para que la víctima aprobara sin darse cuenta la solicitud de 2FA.
¿Y cómo protegerse? Los expertos recomiendan configurar alertas para detectar inicios de sesión que usen el client_id asociado con Visual Studio Code, y bloquear dominios como insiders.vscode.dev y vscode-redirect.azurewebsites.net. También es buena idea aplicar políticas de acceso condicional que limiten el acceso solo a dispositivos autorizados. Porque sí, a veces un simple código o una aprobación sin pensar pueden abrirle la puerta a alguien que no debería estar ahí.