Un nuevo ataque de phishing activo aprovecha el comportamiento legítimo de redirección de OAuth, lo que le permite eludir las defensas tradicionales de correo electrónico y navegador sin robar tokens. Según investigadores de Microsoft Defender, estas campañas se dirigen principalmente a organizaciones gubernamentales y del sector público, utilizando dominios de proveedores de identidad confiables para ocultar redirecciones maliciosas. 

Un nuevo ataque de phishing activo explota el comportamiento legítimo de redirección de OAuth, permitiéndole eludir las defensas tradicionales de correo electrónico y navegador sin robar ningún token.

Según investigadores de Microsoft Defender, las campañas apuntan principalmente a organizaciones gubernamentales y del sector público, utilizando dominios de proveedores de identidad confiables para enmascarar redirecciones maliciosas.

A diferencia del phishing tradicional, que depende del robo de credenciales o exploits de software, esta técnica abusa de los flujos de manejo de errores estándar de OAuth definidos en el RFC 6749.

Los atacantes registran aplicaciones maliciosas en inquilinos controlados por ellos, configuran URIs de redirección que apuntan a dominios bajo su propiedad y luego distribuyen enlaces de phishing que activan un flujo de autorización OAuth silencioso.

Las URLs diseñadas atacan el punto final /common/oauth2/v2.0/authorize de Microsoft Entra ID utilizando parámetros intencionalmente mal utilizados:

Como la solicitud está diseñada para fallar, no para tener éxito, el proveedor de identidad evalúa el estado de la sesión y las políticas de Acceso Condicional de forma silenciosa, luego redirige el navegador al URI de redirección registrado por el atacante. Crucialmente, no se roba ningún token de acceso; el objetivo es puramente la redirección a infraestructura maliciosa, según el informe de Microsoft.

Cadena de ataque en cinco etapas

Etapa 1 – Entrega por correo electrónico: Los actores de amenazas distribuyeron correos de phishing con temas de firmas electrónicas, notificaciones del Seguro Social, reuniones de Teams y documentos financieros. Algunas campañas incrustaron URLs de redirección OAuth directamente en el cuerpo del correo, mientras que otras las ocultaron dentro de archivos PDF adjuntos. Se utilizaron herramientas de envío masivo construidas con Python y Node.js, junto con máquinas virtuales alojadas en la nube, para la distribución.

Etapa 2 – Sondeo OAuth silencioso: Al hacer clic en el enlace de phishing, se activa el flujo de autorización OAuth diseñado. El parámetro state fue reutilizado para transportar la dirección de correo electrónico codificada de la víctima —usando texto plano, hexadecimal, Base64 o esquemas de codificación personalizados—, permitiendo que se completara automáticamente en la página de destino del phishing.

Etapa 3 – Redirección por error OAuth: Cuando la autenticación silenciosa falla, Entra ID devuelve un código de error 65001 (interaction_required) y redirige el navegador al URI registrado por el atacante. Esto confirma la existencia de la cuenta y que se requiere MFA interactivo —información valiosa para el atacante incluso sin un token robado—.

Etapa 4 – Entrega de malware: Tras la redirección, las víctimas eran dirigidas a marcos de phishing como EvilProxy, que funcionan como herramientas de intermediario del atacante diseñadas para interceptar credenciales y cookies de sesión. En campañas dirigidas, se descargaba automáticamente un archivo ZIP desde una ruta /download/XXXX, que contenía archivos de acceso directo LNK y cargadores de contrabando HTML.

Etapa 5 – Persistencia en el endpoint: Al extraer el ZIP, se ejecutaba un comando PowerShell que realizaba reconocimiento del host (ipconfig /all, tasklist), seguido de la carga lateral de DLL a través de un binario legítimo steam_monitor.exe. La DLL maliciosa crashhandler.dll descifraba una carga útil en memoria y establecía una conexión saliente de C2.

Medidas de mitigación

Microsoft recomienda a las organizaciones tomar los siguientes pasos defensivos:

• Restringe el consentimiento de usuario para aplicaciones OAuth mediante políticas de consentimiento de administrador en Entra ID.
• Audita y elimina registros de aplicaciones OAuth no utilizadas, con privilegios excesivos o no reconocidas.
• Habilita políticas de Acceso Condicional y controles de protección de identidad.
• Implementa detecciones XDR entre dominios que abarquen señales de correo electrónico, identidad y endpoint.
• Supervisa URIs de redirección OAuth en busca de dominios sospechosos o recién registrados.

Microsoft Entra ya ha deshabilitado las aplicaciones OAuth maliciosas observadas, pero la actividad de abuso de OAuth relacionada sigue detectándose, lo que requiere vigilancia continua. A medida que las organizaciones fortalecen las defensas de MFA y credenciales, los adversarios están cambiando su enfoque para explotar las relaciones de confianza dentro de los propios protocolos de autenticación.