En Azure, la mayor parte de los incidentes graves no empiezan “rompiendo” un firewall: empiezan emitiendo o aceptando un token que no debería existir. Por eso, cuando el riesgo se concentra en el Enterprise Security Token Service (ESTS) —la pieza responsable de emitir/validar tokens para Microsoft Entra ID (Azure AD)— el impacto potencial es desproporcionado: cualquier carga de trabajo que confíe en esos tokens hereda el problema.
La vulnerabilidad CVE-2026-40379 pone el foco precisamente ahí: ataques que buscan suplantar identidades (spoofing) a nivel del proveedor de tokens. No es “otro bug más”; es un recordatorio de que, si el emisor o el flujo de emisión se ve alterado o engañado, el perímetro real de tu empresa pasa a ser la validación de tokens en cada servicio que consume identidad.
Qué salió mal: por qué el spoofing en ESTS cambia el modelo de confianza
En un entorno corporativo típico, muchos sistemas dan por sentado que “si el token es de Entra ID, es válido”. Esa premisa suele traducirse en validaciones mínimas en APIs internas, proxies, apps legacy migradas a OIDC/SAML y automatizaciones que solo comprueban que el token “parece” correcto. El problema de un escenario de spoofing en ESTS es que el atacante intenta atacar el punto exacto en el que se origina esa confianza: el servicio que emite o permite obtener tokens.
Con CVE-2026-40379, la preocupación operativa no es solo el fallo en sí, sino el patrón: si un atacante consigue que el ecosistema acepte un token con una identidad falsificada, el salto a acciones de alto impacto es inmediato: acceso a aplicaciones corporativas, invocación de APIs con permisos elevados, o movimiento lateral usando identidades de servicio. En empresas con fuerte integración con Microsoft 365, la superficie se amplía porque la identidad se reutiliza transversalmente.
La consecuencia real en empresa suele verse así: aparecen accesos “válidos” (por token) a aplicaciones que nadie considera expuestas, porque en realidad confían en el mismo emisor. El incidente se vuelve confuso: no hay credenciales robadas evidentes, ni MFA fallido, ni un login interactivo sospechoso. Hay autorización “correcta” sobre una identidad que, simplemente, no debería haber podido autenticarse de esa forma.
Cómo se intenta falsificar la identidad: mecánica del abuso a nivel de proveedor de tokens
Los ataques de spoofing en este contexto buscan obtener un token con claims que representen a otra identidad (usuario, service principal, carga de trabajo) o forzar un flujo donde la validación/relación entre identidad y token quede debilitada. En términos prácticos, el atacante no necesita “vivir” dentro de tu tenant desde el minuto uno; le basta con lograr que un componente que confía en ESTS acepte un token que represente a alguien con más privilegios.
En entornos reales, los intentos suelen combinar dos elementos: primero, encontrar un punto de consumo (API, app, gateway) que valide de forma laxa; segundo, forzar un token que pase esos controles. Donde más se ve esto es en integraciones hechas deprisa: APIs internas tras un Application Gateway o un proxy que solo comprueban el “issuer” o el “audience” de manera incompleta, o servicios que aceptan tokens de distintos clientes/tenants sin un “pinning” estricto.
Hay una trampa recurrente en corporaciones con múltiples equipos: cuando se reutiliza la misma librería de validación o un middleware común sin endurecerlo por aplicación, cualquier debilidad se replica en cadena. Un problema en el punto de emisión/aceptación se convierte en un multiplicador de impacto, porque la organización estandariza su dependencia de tokens.
Señales tempranas y artefactos: lo que suele verse antes de que explote
Cuando el abuso se apoya en tokens “aparentemente válidos”, los síntomas iniciales suelen ser sutiles: accesos desde ubicaciones o agentes inusuales, llamadas a APIs con patrones no habituales, o sesiones que aparecen sin un rastro coherente de autenticación interactiva. En empresas con buen nivel de observabilidad, lo primero que “canta” es la incoherencia entre identidad, aplicación y contexto, no un error de autenticación.
Para orientar la búsqueda, ayuda pensar en “imposibles”: una app que recibe tokens con un audience correcto pero desde clientes que nunca habían usado esa app; una identidad que consume recursos a horas o con volúmenes que no encajan; o un principal que empieza a solicitar permisos o scopes que no eran parte del comportamiento normal. El valor está en correlacionar señales entre Entra ID, logs de la app y gateway/API management.
- Inconsistencias entre el flujo esperado y el observado
Ejemplo realista: tu API dice estar consumida solo por un frontend corporativo, pero aparece tráfico directo con tokens OIDC válidos desde scripts. Si el token pasa, el fallo suele estar en la validación (o en la confianza excesiva en el emisor) y no en la app cliente.
- Autorizaciones correctas con identidades “raras” para ese recurso
En empresas grandes, ciertos service principals se usan para tareas concretas. Si un principal pensado para CI/CD empieza a llamar a una API financiera, aunque el token sea válido, el evento es anómalo y suele ser de alto valor para detección.
- Saltos de privilegio sin cambios administrativos previos visibles
Cuando se ve actividad privilegiada sin un rastro claro de cambios de roles, consentimientos o elevaciones, conviene sospechar de un problema en el plano de tokens: el sistema “cree” la identidad, aunque el camino para obtenerla no sea consistente con el control interno.
Cómo hacerlo en la práctica: contención y validaciones que reducen el impacto
Si estás gestionando el riesgo de CVE-2026-40379, la prioridad operativa es doble: reducir probabilidad (aplicando mitigaciones/vías de parcheo del proveedor cuando existan) y, sobre todo, reducir el “blast radius” asumiendo que algún token podría ser sospechoso. En corporaciones, esto se traduce en endurecer validación y acotar confianza por aplicación.
Acciones concretas que suelen ser viables sin romper producción si se planifican bien: pinning estricto de issuer y tenant, validación completa de audiencia y de algoritmo/keys esperadas, y reducción de tokens aceptados por cada API a lo mínimo necesario. Es habitual descubrir que una API acepta tokens destinados a otra, o de varios tenants “por compatibilidad histórica”. Eso es exactamente lo que hay que eliminar.
- Endurecer la validación JWT en cada API (no solo en el gateway)
En la práctica: configura la librería/middleware para validar iss, aud, firma, expiración, y para rechazar tokens con claims inesperadas. Si dependes solo de un WAF/gateway, cualquier bypass interno o ruta directa puede saltarse el control.
- Validar que el emisor y el tenant son los esperados (pinning)
Esto evita aceptar tokens emitidos para otros contextos. En organizaciones con múltiples tenants o B2B, define explícitamente qué tenants están permitidos por aplicación, y revisa integraciones que “aceptan cualquier token de Microsoft” por comodidad.
- Revisar configuraciones de confianza y consentimientos
Operativamente: audita aplicaciones registradas, permisos concedidos y consentimientos de admin. Aunque el vector sea spoofing, un atacante suele combinarlo con permisos excesivos para que el token “falso” sea realmente útil.
Validación de que va bien: cuando apliques estos endurecimientos, prueba explícitamente con tokens de otros entornos/tenants (en lab) y confirma que la API los rechaza. En producción, monitoriza el ratio de rechazos por validación y correlaciónalo con endpoints específicos: una subida localizada suele indicar un consumidor que dependía de un comportamiento inseguro.
Recomendaciones para entornos corporativos
El riesgo que introduce un escenario de spoofing en Azure ESTS, como el asociado a CVE-2026-40379, no se gestiona únicamente “esperando el parche”: se gestiona reduciendo la dependencia ciega en el emisor y reforzando cómo cada aplicación acepta y valida tokens. En empresas, esto marca la diferencia entre un incidente contenido y uno que atraviesa decenas de sistemas con la misma identidad falsificada.
La operativa real pasa por hacer inventario de consumidores de tokens, endurecer validaciones (issuer/tenant/audience/firma), y mejorar detección buscando incoherencias de contexto en lugar de fallos de login. Si tu organización tiene proxies o middlewares comunes, prioriza ahí, pero no sustituyas controles en la app por controles “en la entrada”: lo que no valida el servicio final, termina siendo una deuda de seguridad que se paga en el peor momento.
¿Te interesa la seguridad en Cloud?
Comparto análisis técnicos, laboratorios prácticos y experiencias reales sobre Cloud Security.