Investigadores de seguridad de Proofpoint han documentado una técnica que permite a los atacantes verificar nombres de usuario y contraseñas en Microsoft Entra ID sin generar jamás un evento de inicio de sesión registrado, un punto ciego ya explotado en campañas que afectan a millones de cuentas.
¿Qué pasaría si un atacante pudiera comprobar miles de nombres de usuario y contraseñas contra el sistema de identidad en la nube de una organización sin generar jamás un único evento de inicio de sesión registrado? Según una nueva investigación del proveedor de seguridad Proofpoint, ese escenario ya no es teórico. Los investigadores han documentado una técnica denominada suplantación de client ID de OAuth que permite a los atacantes consultar Microsoft Entra ID sobre la validez de cuentas y contraseñas sin dejar apenas rastro en los registros de inicio de sesión habituales.
Cómo funciona la técnica
Microsoft Entra ID, el servicio de gestión de identidades y accesos en la nube de Microsoft, devuelve respuestas distintas según si un client ID de OAuth enviado es válido y si pertenece a una aplicación registrada. Los investigadores de Proofpoint descubrieron que este comportamiento puede utilizarse en contra de la propia plataforma. Al enviar un client ID sintácticamente válido pero no registrado, los atacantes pueden determinar si una cuenta de usuario determinada existe y si una contraseña es correcta, todo ello sin generar un inicio de sesión exitoso.
Un aspecto clave: cuando se usa un client ID falsificado, no se registra ningún nombre de aplicación en el registro de inicio de sesión, solo un identificador de aplicación en bruto. Ese único campo vacío basta para anular las reglas de detección que buscan actividad sospechosa vinculada a una aplicación concreta y con nombre. Los identificadores falsificados también eluden las políticas de Acceso Condicional limitadas a aplicaciones específicas, y al repartir las solicitudes entre miles de identificadores de aplicación ficticios, los atacantes pueden esquivar la limitación de tasa y la correlación por aplicación. Proofpoint destaca especialmente un código de error, AADSTS700016, por su peligrosidad desde la perspectiva defensiva: aparece cuando el nombre de usuario y la contraseña son correctos pero el client ID no está registrado, y puede descartarse fácilmente como un simple error de inicio de sesión cuando en realidad indica credenciales válidas y funcionales en manos de un atacante.
Proofpoint asegura haber verificado el mecanismo simulándolo en un entorno de laboratorio, enviando solicitudes al endpoint de token OAuth 2.0 de Microsoft mediante el flujo Resource Owner Password Credentials, que permite el envío directo de nombre de usuario y contraseña. Al probar cuatro escenarios —client IDs válidos y registrados, válidos pero no registrados, UUID aleatorios e identificadores mal formados—, los investigadores confirmaron que solo las aplicaciones realmente registradas generan un evento completamente registrado con identificador y nombre de aplicación. En todos los demás casos, el campo del nombre de aplicación queda vacío, sin importar si las credenciales aportadas eran correctas.
UNK_PyReq2323: enumeración a gran escala desde infraestructura de AWS
En la primera campaña rastreada por Proofpoint, un actor identificado como UNK_PyReq2323 utilizó más de 700.000 client IDs falsificados distintos, operando desde infraestructura de AWS con el user agent python-requests/2.32.3. La campaña puso a prueba más de un millón de cuentas de usuario en casi 4.000 tenants. El elevado volumen de intentos fallidos provocó el bloqueo de cuentas en aproximadamente el 28 % de los usuarios afectados.
El método de falsificación de client IDs era poco sofisticado: los atacantes tomaron el prefijo conocido de la aplicación «Exchange Online» de Microsoft y aleatorizaron únicamente los seis últimos dígitos. Al ser limitado ese margen de variación, la misma ID falsificada se reutilizó inevitablemente, en algunos casos contra hasta doce cuentas distintas, aunque nunca dos veces contra la misma.
UNK_OutFlareAZ: mayor alcance, técnica más madura
Una segunda campaña, de mayor envergadura y rastreada como UNK_OutFlareAZ, operó principalmente a través de infraestructura de Cloudflare y afectó a más de dos millones de usuarios con 3,7 millones de identificadores de aplicación falsificados. Se utilizó la cadena de user agent de Microsoft Office/Outlook, que Proofpoint afirma haber observado durante varios años en numerosas campañas, lo que sugiere el uso de herramientas de ataque ampliamente difundidas.
A diferencia de UNK_PyReq2323, este grupo generó un UUIDv4 completamente aleatorio para cada intento de autenticación, lo que dificulta considerablemente la correlación para los equipos defensivos. Proofpoint también observó que muchos de los nombres de usuario objetivo seguían patrones genéricos, como dsmith, msmith o jbrown, y se repetían en varios tenants, lo que apunta al uso de una lista de palabras compartida y preelaborada.
Dos actores, una misma técnica
Pese a explotar la misma debilidad subyacente, ambas campañas difirieron notablemente en user agent, infraestructura, método de generación de IDs y patrón de enumeración. Proofpoint interpreta esto como una prueba de que actores de amenazas distintos adoptaron la misma técnica de forma independiente, en lugar de tratarse de un único grupo detrás de ambas operaciones, una señal de que la suplantación de client ID de OAuth se está extendiendo como técnica reconocida y no como un caso aislado.
Qué deben hacer los equipos de defensa
Proofpoint recomienda a los equipos de seguridad vigilar específicamente los registros de inicio de sesión en busca de entradas sin nombre de aplicación, ya que esa ausencia puede indicar el uso de un client ID falsificado. El error AADSTS700016, en particular, no debería descartarse como un simple fallo de inicio de sesión: puede ser un indicio sólido de credenciales comprometidas. Las organizaciones también deberían revisar si sus políticas de Acceso Condicional siguen siendo eficaces frente a identificadores de aplicación no registrados, ya que las políticas limitadas a aplicaciones concretas no detectarán esta actividad.
Las herramientas de enumeración tradicionales suelen dirigirse a un puñado de aplicaciones propias codificadas de forma fija, presentes por defecto en cada tenant. Repartir las solicitudes entre miles de identificadores de aplicación ficticios hace que el tráfico sea mucho más difícil de vincular para los defensores. Los hallazgos de Proofpoint sugieren que los atacantes recurren cada vez más a los vacíos del registro, más que a fallos de la propia autenticación, para pasar desapercibidos.
El Dr. Jakob Jung es redactor jefe de Security Storage y Channel Germany. Lleva más de 20 años trabajando en el periodismo especializado en TI. A lo largo de su carrera ha colaborado con Computer Reseller News, Heise Resale, Informationweek, Techtarget (almacenamiento y centros de datos) y ChannelBiz. Además, colabora como freelance con numerosas publicaciones del sector de las TI, entre las que se incluyen Computerwoche, Channelpartner, IT-Business, Storage-Insider y ZDnet. Sus temas principales son el canal, el almacenamiento, la seguridad, los centros de datos, los sistemas ERP y CRM.
Contacto – Contacto por correo electrónico: jakob.jung@security-storage-und-channel-germany.de