En varias organizaciones la “suplantación” de administradores globales no llega con un inicio de sesión interactivo sospechoso, sino con un token que parece legítimo, emitido en un contexto que las defensas modernas no controlan igual. El patrón se repite: automatizaciones históricas, integraciones con APIs en retirada y permisos heredados que nunca se revalidaron cuando Entra ID evolucionó (Acceso Condicional, restricciones de aplicaciones empresariales, endurecimiento de consentimiento, etc.).
El riesgo no es abstracto: cuando una carga de trabajo obtiene un token válido con privilegios equivalentes (o con capacidad de actuar “en nombre de”) un rol altamente privilegiado, el atacante no necesita “romper” MFA; simplemente no entra por esa puerta. En el centro del problema están tokens heredados y escenarios S2S con “actor”, sumados a endpoints y permisos que históricamente han permitido operaciones de directorio con controles inconsistentes frente a las políticas actuales.
Qué salió mal: cuando un token válido sustituyó al inicio de sesión del Global Admin
El fallo típico no es “un Global Admin reutilizó contraseña”, sino que una aplicación o identidad de workload (service principal, app registration, certificado) conserva permisos de directorio amplios y puede pedir tokens en flujos no interactivos. Si esa app fue concebida para administración (sin un modelo de mínimos privilegios) o se le concedió consentimiento de administrador hace años, el token resultante puede usarse para cambiar configuraciones críticas sin que se cumplan las mismas exigencias (MFA, device compliance, ubicación) que impondrías a un humano.
En escenarios S2S aparece además el matiz del actor: tokens donde una entidad técnica actúa como “actor” ejecutando acciones sobre un “subject”. En integraciones antiguas y migraciones, esto termina en operaciones que, a ojos de auditoría, parecen atribuibles a un usuario/admin cuando en realidad se originan en una aplicación. En empresa esto complica la respuesta a incidentes: el equipo mira primero sign-in logs y no encuentra el “login” esperado del Global Admin.
Consecuencia real: cambios de alto impacto (p. ej., modificación de credenciales de aplicaciones, ajustes de permisos, alteración de políticas o asignaciones) ejecutados desde automatizaciones, pipelines o hosts sin endurecimiento. En el mejor de los casos, acabas con una “brecha de gobernanza”: nadie puede explicar por qué una app tenía ese alcance. En el peor, es una vía de escalado silenciosa y persistente.
La superficie de ataque: tokens heredados, “actor” S2S y APIs obsoletas que esquivan guardrails
Los tokens heredados suelen entrar por dos rutas: (a) flujos y permisos históricos que no están alineados con cómo hoy se pretende controlar el acceso a privilegios, y (b) dependencia de APIs y endpoints antiguos (caso clásico: Azure AD Graph) que han tenido comportamientos y modelos de control distintos a Microsoft Graph y a los controles modernos alrededor de Acceso Condicional.
El problema operativo es que el control se diseñó alrededor del usuario (MFA, riesgo, estado del dispositivo), pero muchas operaciones sensibles se ejecutan desde identidades no humanas. Si además una API obsoleta permite ejecutar acciones equivalentes con un conjunto diferente de evaluaciones, el atacante elegirá ese camino. No necesita “by-passear” Acceso Condicional de forma mágica: le basta con operar en un carril que no está sometido a la misma evaluación o que se monitoriza peor.
- Permisos de aplicación demasiado amplios (app-only)
En empresas es habitual encontrar apps con permisos a nivel directorio concedidos “para que funcione” en un proyecto antiguo. Esos permisos son, en la práctica, una autorización permanente; si el secreto/certificado se filtra o el entorno donde vive la app es comprometido, el atacante obtiene una capacidad de administración muy cercana a la de un Global Admin, sin interacción humana.
- Dependencia de endpoints y permisos heredados (p. ej., Azure AD Graph)
Cuando conviven integraciones heredadas, el equipo puede estar endureciendo Microsoft Graph y dejando una vía paralela abierta. El impacto real en empresa se ve cuando un cambio “no autorizado” se ejecuta por una ruta que nadie revisa porque la organización ya “migró a Graph”… solo que no del todo.
Señales tempranas que sí aparecen en entornos corporativos (y suelen pasarse por alto)
La detección efectiva exige dejar de buscar únicamente “logins raros” de administradores y empezar a correlacionar actividad de aplicaciones con cambios de configuración. Cuando el abuso es vía token no interactivo, el rastro se parece más a actividad de una app “normal” que a un acceso humano sospechoso.
Lo que delata estos casos suele ser la combinación de: una identidad técnica que de repente realiza operaciones de directorio que no ejecutaba, un cambio de credenciales o permisos asociado a un service principal, o llamadas a APIs antiguas que aún existen en el entorno. El patrón es muy común en organizaciones con fusiones/adquisiciones, donde quedan apps “huérfanas” con permisos altos.
- Actividad administrativa originada por service principals
Si ves cambios de configuración críticos atribuidos a una aplicación (o a una automatización) fuera de ventanas de cambio, trátalo como incidente hasta demostrar lo contrario. La mayoría de equipos subestiman esto porque “es una cuenta de sistema”, cuando precisamente por eso es un objetivo prioritario.
- Uso residual de Azure AD Graph / endpoints heredados
En la práctica, aparece como tráfico o dependencias en scripts antiguos (PowerShell, herramientas de terceros) que nadie tocó en años. El riesgo no es solo que “sea viejo”: es que puede escapar a los mismos controles y alertas que el equipo ha afinado para Microsoft Graph y sign-ins interactivos.
Si tu SOC se basa en alertas de inicios de sesión y cambios de rol, pero no en auditoría de cambios sobre objetos (applications, service principals, credentials), puedes estar ciego ante la fase de preparación: el atacante primero asegura persistencia en apps y luego ejecuta la toma de control.
Cómo hacerlo en la práctica: inventario, bloqueo de legado y validación de que no queda “carril paralelo”
El primer paso realista en empresa es aceptar que “apagar lo heredado” sin inventario rompe cosas. Lo correcto es operar por oleadas: identificar qué apps todavía usan permisos/endpoint heredado, definir dueño, plan de migración y controles temporales. Mientras tanto, reducir radios de explosión: recortar permisos, rotar credenciales y limitar dónde puede ejecutarse la automatización.
Acciones concretas que suelen funcionar bien cuando hay presión y sistemas críticos:
- Crear un inventario vivo de apps privilegiadas
Identifica service principals y app registrations con permisos de aplicación de alto impacto (especialmente permisos de directorio). Asigna owner responsable, justificación, y fecha de revisión. En corporativo, esto evita el “nadie sabe de quién es” que hace imposible recortar permisos sin pánico.
- Configurar guardrails para impedir que una app se convierta en “Global Admin por token”
Recorta permisos a mínimos, separa apps por función (lectura vs escritura), y evita concentrar administración en una única identidad técnica. Complementa con rotación y almacenamiento seguro de secretos/certificados; si una app mantiene credenciales de larga vida en un servidor compartido, el token es el último eslabón: el problema real es la custodia de la identidad.
- Validar con evidencia: auditoría de cambios y pruebas de ruta
No basta con “creer” que Acceso Condicional protege. Verifica en logs de auditoría qué identidad realiza cambios sobre: credenciales de apps, permisos (app roles/consent), configuración de directorio y asignaciones. Además, prueba explícitamente que las rutas heredadas ya no se usan en producción (por ejemplo, retirando dependencias de scripts y monitorizando errores controlados en entornos preproductivos antes del corte).
Un error típico es dar por cerrada la brecha tras endurecer el acceso de administradores humanos. Si una app conserva permisos amplios, el atacante no necesitará suplantar al Global Admin “entrando como él”; le bastará con operar donde la organización no exige MFA porque “no aplica” a workloads.
Recomendaciones para entornos corporativos
La suplantación de Global Admins en Entra ID, cuando está mediada por tokens heredados y patrones S2S con “actor”, rara vez se detecta con controles centrados solo en inicios de sesión humanos. La clave operativa es tratar identidades de aplicaciones como identidades privilegiadas: inventariarlas, asignarles dueños, justificar permisos y auditar su actividad como si fueran administradores.
Si en tu entorno aún existe dependencia de APIs obsoletas (como Azure AD Graph) o scripts antiguos que piden tokens por rutas heredadas, asúmelo como un “carril paralelo” que puede eludir parte de tus políticas y telemetría moderna. El cierre efectivo no es solo técnico: exige disciplina de gobernanza (propiedad, revisiones periódicas y eliminación de permisos), más validación basada en evidencia (quién hizo el cambio, con qué identidad, por qué API), de forma que un token válido no pueda convertirse en una administración encubierta del tenant.
¿Te interesa la seguridad en Cloud?
Comparto análisis técnicos, laboratorios prácticos y experiencias reales sobre Cloud Security.