Amenaza de suplantación de ID de cliente OAuth en Microsoft Entra
Publicado el
Introducción
Recientemente, se ha identificado una técnica de evasión conocida como suplantación de ID de cliente OAuth, utilizada por al menos dos grupos de amenazas en campañas en la nube. Esta táctica permite a los atacantes enumerar cuentas de usuario y validar credenciales robadas en entornos de Microsoft Entra ID, sin generar eventos de inicio de sesión exitosos que alerten a los defensores.
Mecanismo del ataque
Según Proofpoint, el mecanismo detrás de esta técnica se basa en cómo Microsoft Entra ID maneja las respuestas de error. Cuando se proporciona un ID de cliente OAuth, este puede ser utilizado para inferir nombres de usuario válidos y contraseñas correctas a gran escala, lo que permite a los atacantes comprobar listas de credenciales robadas sin necesidad de un inicio de sesión exitoso.
Los atacantes aprovechan el ID de cliente OAuth, un identificador único global asignado a las aplicaciones al solicitar acceso a datos de usuario. Al presentar ID de cliente falsificados, los atacantes pueden realizar la enumeración de cuentas sin necesidad de una aplicación OAuth registrada, lo que les permite inferir la validez de contraseñas y cuentas sin generar un evento de inicio de sesión exitoso.
Actividades observadas
Se han observado grupos como UNK_CustomCloak utilizando esta táctica para llevar a cabo campañas de fuerza bruta en Microsoft Entra ID. Estos atacantes han explotado una aplicación de primera parte descontinuada llamada Windows Live Custom Domains para eludir restricciones estándar de inicio de sesión y probar contraseñas de usuarios en más de 4,000 inquilinos. La evolución de estas técnicas se manifiesta al suplantar ID de cliente OAuth a través de solicitudes POST HTTP al punto final de token de OAuth 2.0 de Microsoft utilizando el flujo de Resource Owner Password Credentials (ROPC).
En este proceso, se suministra un ID de cliente sintácticamente válido que no corresponde a una aplicación real. Como resultado, solo se registra el ID de la aplicación en los registros de inicio de sesión de Entra, sin un nombre de aplicación correspondiente. La respuesta que contiene un código de error del Azure Active Directory Security Token Service (AADSTS) puede ser utilizada para deducir si la cuenta existe y si la contraseña es correcta, todo ello sin necesidad de una aplicación registrada.
Implicaciones para la seguridad
La falta de un nombre de aplicación correspondiente en los registros de inicio de sesión dificulta la detección de actividades sospechosas. Los ataques pueden pasar desapercibidos, ya que las detecciones que buscan picos en nombres de aplicaciones específicos podrían no detectar estos intentos, ya que el campo queda vacío.
Campañas recientes
Proofpoint ha identificado dos grandes campañas que han adoptado esta técnica a finales de diciembre de 2025. La primera, UNK_pyreq2323, que operó de enero a marzo de 2026, utilizó más de 700,000 ID de cliente falsificados desde la infraestructura de Amazon Web Services (AWS) para atacar más de un millón de cuentas, provocando bloqueos en aproximadamente el 28% de los usuarios objetivo debido a intentos fallidos.
La segunda, UNK_OutFlareAZ, que comenzó en diciembre de 2025, aprovechó la infraestructura de Cloudflare para dirigirse a más de 2 millones de usuarios con 3.7 millones de ID de aplicación falsificados aleatorios. Ambas campañas han mostrado patrones que se alinean con listas de nombres de usuario precompiladas, aunque diferían en la forma en que se habían suplantado los IDs de cliente.
Recomendaciones
Para mitigar estos ataques, las organizaciones deben considerar la implementación de políticas de acceso condicional específicas para aplicaciones comúnmente atacadas. Sin embargo, los ID de cliente falsificados no activarán estas políticas, lo que requiere una atención especial por parte de los equipos de seguridad para identificar patrones inusuales de acceso y proteger sus entornos en la nube de posibles compromisos.