Phishing con redirección OAuth en Entra ID: alerta

Introduction: why this matters

Los enlaces OAuth hacia proveedores de identidad (IdPs) conocidos como Microsoft Entra ID suelen ser confiables para los usuarios y, en algunos casos, reciben un trato más permisivo por parte de los controles de seguridad. La investigación más reciente de Microsoft destaca un comportamiento de redirección OAuth “por diseño” que está siendo abusado para enviar a los usuarios desde dominios legítimos de inicio de sesión hacia infraestructura de atacantes, habilitando phishing y entrega de malware mientras aparenta ser un flujo normal de inicio de sesión.

Esto es especialmente relevante para administradores de TI en organizaciones gubernamentales y del sector público, que fueron objetivo específico en la actividad observada.

What’s new / key findings

El Microsoft Defender Security Research Team observó explotación, iniciada por phishing, de mecánicas de redirección OAuth a través de señales de correo electrónico, identidad y endpoint:

• Abuse of silent OAuth flows: Los atacantes crean URLs de autorización OAuth usando parámetros como prompt=none para intentar una comprobación de autenticación silenciosa (sin UI).
• Intentionally invalid scopes to force an error path: Las solicitudes incluyen scope=<invalid_scope> (u otros disparadores de fallo) para generar de forma confiable un error OAuth.
• Error-driven redirect to attacker-controlled URI: Cuando el IdP devuelve un error (por ejemplo, interaction_required), el navegador es redirigido al redirect URI registrado de la app, que el atacante configura para apuntar a páginas de phishing o sitios de descarga de malware.
• No token theft required for the redirect: El atacante no necesariamente intenta completar OAuth con éxito; la redirección es el objetivo principal.
• State parameter misuse for personalization: El parámetro state—destinado a la correlación solicitud/respuesta—se reutilizó para pasar la dirección de correo de la víctima (texto plano, hex, Base64 o codificación personalizada) de modo que las páginas de phishing puedan autocompletar identificadores.
• Campaign delivery patterns: Los señuelos de phishing incluyeron solicitudes de firma electrónica, temas financieros/de seguridad social, uso compartido de documentos, contenido de Teams/reuniones y avisos de restablecimiento de contraseña. Algunos usaron adjuntos PDF con enlaces incrustados e incluso invitaciones de calendario .ics.
• Downstream tooling: Las páginas posteriores a la redirección usaron con frecuencia frameworks de phishing como EvilProxy (attacker-in-the-middle) diseñados para capturar credenciales y cookies de sesión, a veces agregando pasos de CAPTCHA/intersticial.

Impact on IT administrators and end users

• Higher click-through risk: Los enlaces comienzan en dominios confiables del IdP (por ejemplo, login.microsoftonline.com), lo que aumenta la confianza del usuario.
• Defense bypass pressure: Las comprobaciones tradicionales de reputación de URL pueden centrarse en el dominio inicial y pasar por alto el destino final.
• Visibility needs across layers: Microsoft indica que Defender correlacionó señales a través de email, identity, and endpoint, destacando que la detección con un solo control puede ser insuficiente.
• Ongoing threat: Microsoft Entra deshabilitó las aplicaciones OAuth maliciosas observadas, pero la actividad relacionada persiste; sigue siendo necesario monitorear.

Action items / next steps

1. Hunt for suspicious OAuth authorize patterns en logs y telemetría de proxy, especialmente:
   • prompt=none combinado con valores inusuales/inválidos de scope
   • Fallos de OAuth frecuentes seguidos de redirecciones hacia dominios no corporativos
   • Uso de /common/ en contextos inesperados de phishing de alto volumen
2. Review and restrict app consent and app registrations:
   • Auditar apps creadas recientemente y redirect URIs para detectar dominios no confiables
   • Endurecer quién puede registrar aplicaciones/modificar redirect URIs en Entra ID
3. Strengthen phishing protections beyond “trusted domain” checks:
   • Asegurar que las herramientas de detonación de URL/safe-link sigan las redirecciones
   • Educar a los usuarios: “empieza en Microsoft sign-in” no garantiza seguridad
4. Validate Conditional Access and session controls:
   • Monitorear telemetría de inicio de sesión y errores de OAuth para detectar anomalías y grupos de usuarios objetivo
5. Use Defender correlation:
   • Aprovechar Microsoft Defender for Office 365 + Defender for Identity/Endpoint para correlacionar el señuelo por correo, el comportamiento de inicio de sesión y la actividad de payload en el endpoint.