La estafa de redirección OAuth que roba credenciales

Hace poco los investigadores de seguridad de Microsoft alertaron sobre una técnica que está aprovechando una función legítima del ecosistema de identidad para colar páginas maliciosas sin recurrir al engaño clásico de suplantación directa. En lugar de falsificar remitentes o enmascarar dominios, los atacantes están explotando el mecanismo de redirección de OAuth para “forzar” al navegador o al cliente de correo a llevar al usuario a un recurso controlado por el atacante. El resultado es una estafa de phishing mucho más difícil de detectar por filtros automáticos y por la simple inspección visual.

El vector que describen los analistas combina mensajes que aparentan urgencia —peticiones de firma electrónica, avisos del seguro social, invitaciones a reuniones o reinicios de contraseña— con enlaces que aparentan ser solicitudes de autorización legítimas. A veces esas URLs maliciosas se ocultan dentro de archivos PDF para evitar los controles de correo. Cuando la víctima hace clic, la cadena de eventos aprovecha cómo los proveedores de identidad manejan errores de autorización para redirigir al usuario hacia una URI que los atacantes han registrado en aplicaciones OAuth bajo su control. Puede leerse el informe técnico en la nota publicada por Microsoft: Microsoft Security Blog.

Para entender por qué este truco funciona hace falta recordar que OAuth es un estándar diseñado para delegar permisos entre servicios. Un proveedor de identidad —como Microsoft Entra ID— permite que aplicaciones registradas soliciten acceso en nombre de usuarios siguiendo reglas muy concretas (RFC 6749). Cuando algo va mal durante la negociación —por ejemplo, parámetros que piden una autenticación “silenciosa” (prompt=none) o un scope inválido— la especificación contempla que el servicio de identidad genere un error y, en muchos casos, responda con una redirección hacia la URI registrada por la aplicación. Los atacantes han aprendido a provocar ese comportamiento de forma deliberada para convertir una respuesta de error en una ruta hacia su propia infraestructura.

En la práctica los abusadores crean aplicaciones OAuth en un tenant que controlan y registran una redirección que apunta a su servidor. Luego construyen enlaces de autorización que parecen legítimos y los distribuyen en campañas dirigidas, sobre todo contra organismos públicos y entidades gubernamentales. Cuando el proveedor de identidad detecta el “error” intencional, envía al usuario exactamente a la dirección que el atacante configuró. En algunos casos esa página es un sitio de phishing que reproduce la interfaz de inicio de sesión; en otros, la redirección apunta a un recurso que entrega automáticamente un ZIP con atajos (.LNK) y técnicas de HTML smuggling para sortear detecciones y ejecutar código en el equipo de la víctima.

Los investigadores también describen variantes en las que los delincuentes usan frameworks de ataque hombre-en-medio especializados para interceptar credenciales o tokens de sesión y así eludir barreras como la autenticación multifactor. Herramientas de este tipo —por ejemplo proyectos conocidos en código abierto que facilitan ataques de proxy sobre sesiones web— permiten que un atacante capture cookies o tokens válidos y los reutilice antes de que la víctima note algo extraño; una referencia técnica de proyectos similares está disponible en el repositorio de Evilginx2: Evilginx2 (GitHub).

Un detalle particularmente eficaz en estas campañas es el abuso del parámetro “state” de OAuth. Normalmente se usa para mantener contexto entre la solicitud y la respuesta de autorización; los atacantes lo emplean para insertar la dirección de correo de la víctima en la página de phishing, lo que aumenta la sensación de autenticidad y reduce las sospechas al ver su propio correo ya rellenado. En otras variantes, la apertura del atajo .LNK ejecuta PowerShell que realiza reconocimiento local y desencadena una cadena de carga lateral de DLL: un binario legítimo carga un DLL malicioso que descifra y ejecuta el payload final en memoria, un patrón conocido y documentado por la comunidad de detección de amenazas (ver técnicas relacionadas en MITRE: PowerShell, DLL Side-Loading).

La clave de esta campaña no es una vulnerabilidad en OAuth, sino el aprovechamiento de un comportamiento previsto por el propio estándar: los proveedores de identidad están respondiendo exactamente como deben ante ciertos errores, y los atacantes están manipulando esos errores a su favor. Por eso las defensas puramente basadas en listas de URL o en heurísticas de correo pueden fallar si una petición de autorización legítima —aparentemente— sirve como cubierta.

¿Qué pueden hacer las organizaciones para reducir este riesgo? Las recomendaciones de Microsoft apuntan en varias direcciones complementarias: limitar quién puede registrar aplicaciones en el tenant, exigir consentimiento administrativo para permisos sensibles, aplicar políticas sólidas de identidad y Conditional Access, y coordinar detección entre correo, servicios de identidad y endpoints para identificar patrones cross-domain. La documentación oficial sobre permisos y consentimiento y sobre políticas de Conditional Access ayuda a entender cómo aplicar estos controles en entornos Azure: Permisos y consentimiento en Azure AD y Guía de Conditional Access. También es buena práctica restringir el registro de aplicaciones mediante políticas y auditar regularmente las aplicaciones con permisos delegados.

Al nivel del usuario final conviene extremar la precaución con enlaces inesperados, incluso cuando provengan de servicios legítimos o cuando el mensaje parezca dirigido: los archivos adjuntos que contienen URLs, como PDFs, son una técnica habitual de evasión. La combinación de educación, filtros de correo avanzados, análisis de comportamiento en endpoints y una configuración de identidad rigurosa es la mejor defensa. Para quien quiera profundizar en cómo funcionan las autorizaciones OAuth y cómo evitar malos usos, el proceso de registro de aplicaciones en la plataforma de identidad de Microsoft ofrece una base técnica útil: Registrar aplicaciones en Microsoft identity platform.

En resumen, nos enfrentamos a ataques que no rompen la criptografía ni explotan fallos tradicionales, sino que sacan ventaja de comportamientos estándar y de cadenas de confianza humanas. El remedio parte por reconocer que la superficie de ataque ahora incluye la propia infraestructura de autorización y por aplicar controles de gobernanza de identidad con el mismo cuidado con el que se protege la red y el endpoint. Como siempre, la seguridad es una coordinación entre tecnología, procesos y concienciación.