La trampa de OAuth: cuando una redirección legítima se convierte en phishing, malware y robo de credenciales

Microsoft publicó esta semana una alerta que debería poner en guardia a administradores y usuarios del sector público: atacantes están aprovechando mecanismos legítimos de redirección en flujos OAuth para llevar a víctimas hasta infraestructuras controladas por los delincuentes, eludiendo así muchas de las protecciones habituales de correo y navegador. No se trata tanto de vulnerar un servicio como de explotar el comportamiento previsto por el estándar de autorización para que una URL aparentemente inocua termine en una trampa.

OAuth es la pieza técnica que permite a aplicaciones pedir permiso para actuar en nombre de un usuario sin requerir su contraseña, y es la base de los inicios de sesión "Iniciar sesión con Google" o "Iniciar sesión con Microsoft". La especificación contempla que, en determinados escenarios (por ejemplo errores o flujos concretos), el proveedor de identidad redirija al usuario a una URL determinada. Los atacantes han diseñado aplicaciones maliciosas y enlaces que abusan de esa redirección para dirigir al usuario a páginas alojadas por los propios delincuentes. Si quieres revisar el funcionamiento del protocolo, la explicación básica está en oauth.net y la documentación concreta de los proveedores como Google y Microsoft detalla cómo se gestionan las URI de redirección en sus plataformas (Google OAuth, Microsoft Entra/Identity).

El modo de operación descrito por Microsoft combina ingeniería social y abuso del flujo OAuth: los atacantes crean una aplicación en un inquilino que controlan y le ponen como URI de redirección un dominio malicioso. Luego envían enlaces de phishing en correos —con señuelos cuidadosamente elaborados como solicitudes de firma electrónica, grabaciones de Teams o temas financieros y administrativos— que piden al usuario autenticarse con la aplicación maliciosa, a menudo usando un "scope" intencionalmente inválido para forzar la ruta de error/redirección deseada. El resultado no es siempre el robo directo de tokens; en varias campañas la finalidad fue forzar descargas que infectaran el propio equipo del usuario.

En los casos analizados, el archivo que termina llegando al dispositivo suele ser un ZIP que contiene un acceso directo de Windows (LNK). Al abrir ese acceso directo se ejecuta inmediatamente un comando de PowerShell que inspecciona el equipo y extrae un instalador MSI. Ese instalador deja a la vista un documento señuelo mientras, detrás de escena, se sideloadea una biblioteca maliciosa (una DLL con nombre como "crashhandler.dll") aprovechando un binario legítimo para cargarla, descifra un archivo adicional y lanza la carga final en memoria. Desde ahí el malware establece comunicación con un servidor de mando y control para continuar la intrusión, que puede terminar en actividad de tipo pre-ransom o acciones manuales por parte de operadores humanos.

Además de las campañas que entregan malware, la misma técnica de redirección se ha usado para páginas que implementan kits de phishing tipo adversary-in-the-middle (AitM). Esos marcos permiten capturar credenciales, cookies de sesión o incluso intercambiar códigos OAuth en tiempo real; frameworks conocidos en la comunidad de seguridad han demostrado la eficacia de estos enfoques cuando el usuario confía en el flujo y el proveedor de identidad nunca bloquea la redirección.

Otro detalle relevante detectado por Microsoft es el uso creativo del parámetro "state": originalmente pensado para correlacionar peticiones y respuestas y proteger contra CSRF, en estas cadenas los atacantes codifican la dirección de correo del objetivo para que aparezca automáticamente en la página de phishing, aumentando su credibilidad. Es un recordatorio de que una pieza diseñada para seguridad puede ser reutilizada de forma perversa si no se verifica su contenido.

Microsoft ya ha eliminado varias aplicaciones maliciosas identificadas, pero la conclusión para equipos de seguridad y responsables TI es clara: hay que combinar controles técnicos con buenas prácticas administrativas. Limitar el consentimiento que los usuarios pueden dar a aplicaciones de terceros, auditar con regularidad los permisos concedidos y revocar aplicaciones innecesarias u overprivileged son pasos críticos. Microsoft ofrece herramientas de gestión de aplicaciones y políticas de consentimiento en su plataforma; revisar esas opciones puede reducir la superficie de ataque (gestión de aplicaciones en Azure AD / Entra).

Para complementar esas medidas, conviene reforzar protecciones en endpoints y correo: impedir la apertura automática de adjuntos peligrosos, bloquear dominios y archivos conocidos maliciosos en puerta de enlace y correo, y mantener soluciones de detección capaces de identificar técnicas como la ejecución de PowerShell desde LNK o el sideloading de DLLs. También es importante enseñar a usuarios y equipos a sospechar de enlaces incluso cuando parecen originarse de un proveedor legítimo; la Agencia de Seguridad de EE. UU. y otras entidades publican recomendaciones prácticas contra phishing que pueden incorporarse a los programas de concienciación (CISA — Phishing guidance).

Además, las organizaciones con identidad centralizada deberían valorar políticas más estrictas: impedir el consentimiento de usuarios no administradores para ciertas aplicaciones, exigir revisiones administrativas para permisos especialmente sensibles y activar controles condicionales que obliguen a verificación adicional o bloqueen el acceso desde entornos no confiables. Herramientas nativas de los proveedores permiten crear listas permitidas o denegadas de aplicaciones y supervisar intentos de consentimiento inusuales.

Este episodio recuerda que la seguridad en la era de la identidad como perímetro es multidimensional: no basta con proteger la infraestructura perimetral si el propio modelo de autorización puede ser manipulado socialmente. La prevención exige coordinar políticas de identidad, controles en el correo y en endpoints, y formación continua de las personas para que no sean el eslabón más débil.

Si quieres revisar el informe técnico de Microsoft con todos los indicadores y ejemplos mostrados por el equipo de Defender, está disponible en su blog de seguridad: Microsoft Security Blog — OAuth redirection abuse. Para profundizar en cómo se gestionan redirecciones y URIs en los distintos proveedores, la documentación oficial de Google y Microsoft sobre OAuth/Identity es un buen punto de partida (Google, Microsoft Entra), y para entender el diseño del propio protocolo, la referencia en oauth.net resulta útil.

En resumen: no es sólo una cuestión técnica, sino de gobernanza y cultura. Mantener un inventario de aplicaciones, limitar lo que los usuarios pueden autorizar y revisar activamente los permisos son medidas que, combinadas con controles técnicos, dificultan que ataques como este lleguen a buen puerto.