El error más caro que sigo viendo en identidades híbridas no es “usar AD on‑premise”, sino conectarlo a la nube como si fuera una extensión natural del datacenter: mismos grupos, mismas jerarquías y, sobre todo, mismos privilegios. En el papel suena eficiente. En un incidente real, es un multiplicador de impacto.
Cuando sincronizas sin segmentar hacia Entra ID (Azure AD) o hacia AWS IAM Identity Center, tu Directorio Activo local deja de ser “infra legacy” y pasa a ser el plano de control de acceso a tus SaaS, a tu cloud y a tus cuentas. La nube puede tener controles excelentes, pero si la identidad que la gobierna está atada a un AD expuesto, el eslabón débil decide el resultado.
Qué salió mal: el día que un servidor on‑premise abrió la puerta al cloud
El patrón suele repetirse: un servidor local (a veces un jump server, a veces un file server “olvidado”) cae por credenciales reutilizadas, un parche pendiente o un acceso RDP heredado. El equipo que opera cloud, al ver que “lo cloud está bien”, lo interpreta como un incidente acotado al entorno on‑premise. Mientras tanto, el atacante ya está jugando en el verdadero objetivo: el AD.
Con un foothold en red corporativa, el atacante busca credenciales y tickets. Si encuentra una cuenta con privilegios altos en el dominio (o una cuenta de servicio mal gestionada), la escalada es cuestión de técnica y tiempo. El punto crítico llega cuando esos mismos grupos o usuarios están sincronizados y mapeados a roles administrativos en Entra ID o en AWS. A partir de ahí, el salto a la nube no es “otro ataque”: es una consecuencia directa de cómo diseñaste la identidad híbrida.
En empresas, esto suele explotar en forma de daño operativo: creación de aplicaciones OAuth maliciosas en Entra ID, nuevas credenciales de acceso persistentes, o asignación de permisos cloud a cuentas “de dominio” que ya estaban comprometidas. El incidente deja de ser “un servidor” y pasa a ser “toda la organización”.
La superficie de ataque real: AD local como puente de privilegios hacia Entra ID y AWS
La identidad es el puente entre entornos. Si tu AD local alimenta (sin controles) a Entra ID o a IAM Identity Center, estás extendiendo al cloud la confianza en el dominio on‑premise. Esa confianza no es abstracta: es gente, grupos y memberships que terminan autorizando acciones críticas en la nube.
En la práctica, muchas compañías sincronizan “todo el dominio” porque es lo más rápido para habilitar SSO, correo, Teams, acceso a apps internas o federación con SaaS. El problema llega cuando los grupos “de siempre” (Domain Admins, Server Admins, grupos por delegaciones históricas) terminan siendo usados como fuente de verdad para permisos cloud. No hace falta que el atacante “rompa” Azure o AWS: le basta con ser “alguien” con memberships que la nube respeta.
- Sincronización sin segmentación: si cualquier OU o grupo sensible acaba en la nube, un cambio en on‑prem (legítimo o malicioso) se convierte en autorización cloud. Esto incluye altas/bajas, cambios de membresía y creación de cuentas.
- Herencia de privilegios: equipos que históricamente usaban Domain Admin para “resolver rápido” en Windows terminan con cuentas de alto privilegio que también administran cloud. Es cómodo hasta que un hash robado se convierte en un rol global.
- Cuentas de servicio con SPN y permisos excesivos: son objetivos típicos de Kerberoasting. Si además están sincronizadas o asociadas a permisos de apps/roles, la explotación puede terminar en acceso persistente en el directorio cloud.
Lo importante es el efecto empresarial: el atacante no necesita moverse lateralmente por decenas de servidores cloud. Con controlar la identidad que otorga permisos, puede operar “como administrador” desde la consola, con acciones que parecen legítimas y complican la atribución y la respuesta.
Escenarios de abuso: Pass-the-Hash y Kerberoasting que terminan en “Cloud Admin”
Dos técnicas clásicas en AD on‑premise siguen siendo devastadoras cuando hay identidades híbridas: Pass-the-Hash y Kerberoasting. No es nostalgia: siguen funcionando en entornos corporativos reales porque hay dependencia de NTLM, higiene de credenciales irregular, y cuentas de servicio que viven años sin rotación.
En Pass-the-Hash, el atacante usa hashes capturados para autenticarse sin conocer la contraseña. Si ese hash pertenece a una cuenta con privilegios en el dominio (o con acceso a un servidor donde se ejecutan tareas administrativas), puede derivar en control de AD. En Kerberoasting, el atacante pide tickets TGS para SPNs y los crackea offline; si recupera la contraseña de una cuenta de servicio con permisos amplios, el dominio cae de forma silenciosa.
El salto al cloud ocurre cuando esa cuenta (o los grupos que controla) están vinculados a roles en Entra ID o en AWS IAM Identity Center. Un ejemplo típico: una cuenta de administración on‑premise que, por “comodidad”, también se usa para administrar Microsoft 365 o asumir roles en AWS. En el timeline del atacante, el cloud es simplemente el siguiente panel de control.
- Entra ID: tras comprometer identidades sincronizadas, el atacante busca asignación de roles (por ejemplo, roles privilegiados) y persistencia vía aplicaciones/consentimientos. El impacto real suele ser acceso a correo, SharePoint y creación de identidades persistentes.
- AWS con IAM Identity Center: si el usuario o grupo sincronizado tiene asignación a Permission Sets potentes, el atacante puede obtener sesiones con privilegios altos en cuentas AWS. Desde ahí, la respuesta se vuelve compleja porque hay actividad “válida” desde un principal corporativo.
La consecuencia organizativa es que se rompe la frontera mental entre equipos: “on‑prem” y “cloud” ya no son dominios separados de riesgo. El directorio local actúa como proveedor de autoridad para ambos, y cualquier brecha en on‑premise es una brecha de identidad con efecto cloud.
Cómo hacerlo en la práctica: segmentar sincronización y separar privilegios de cloud
La mitigación no es “dejar de sincronizar”, sino diseñar la sincronización como un canal de mínimos. En producción, lo primero que recomiendo es tratar la integración AD→cloud como un sistema crítico: con alcance definido, controles y revisiones periódicas. Si hoy sincronizas “todo”, asume que tienes deuda de seguridad acumulada.
Acciones concretas que funcionan en empresas:
- Filtrar qué se sincroniza (OU y grupos): crea OUs específicas para identidades que deben existir en el cloud (usuarios finales, identidades de apps si aplica) y excluye OUs administrativas. Valida que grupos sensibles no aparecen en el directorio cloud ni se usan para asignación de roles.
- No asignar roles cloud a Domain Admins ni a grupos equivalentes: en entornos maduros, los administradores de AD y los administradores de cloud son identidades distintas (y ojalá estaciones de trabajo distintas). Si necesitas administración cruzada, que sea con cuentas dedicadas y con aprobación/justificación.
- MFA estricto para acceso administrativo federado: configura políticas para que cualquier acceso a portales y acciones privilegiadas requieran MFA fuerte (resistente al phishing cuando sea posible). A nivel operativo, esto corta muchas cadenas donde el atacante “solo” necesita credenciales.
La validación es parte del trabajo: revisa de forma rutinaria qué grupos están llegando al cloud, qué roles tienen asignados y si hay caminos indirectos (por ejemplo, un grupo “inofensivo” que contiene otro grupo privilegiado). En auditorías internas suele aparecer el mismo hallazgo: “se restringió el portal, pero se dejó una vía de asignación de permisos por sincronización de grupos”.
Un anti‑patrón frecuente es delegar el problema por silos: el equipo de Windows “solo” mantiene AD; el equipo de cloud “solo” asigna roles. En identidades híbridas, esa división crea huecos: nadie se siente dueño del riesgo end‑to‑end. La solución real es ownership compartido con controles explícitos en el puente (sincronización, mapeo de grupos, políticas de acceso).
Recomendaciones para entornos corporativos
Si tu AD on‑premise sincroniza con Entra ID o con AWS IAM Identity Center, asume que el directorio local es parte del perímetro de seguridad del cloud. El error operativo más común es sincronizar sin segmentar y permitir que grupos o cuentas de administración on‑premise tengan autoridad en la nube.
En términos prácticos, el enfoque que reduce incidentes es consistente: limitar la sincronización a lo necesario, evitar que Domain Admins (o equivalentes) sean administradores cloud, y exigir MFA estricto en cualquier acceso administrativo federado. Esto no elimina el riesgo de AD local, pero evita que un compromiso on‑premise se convierta automáticamente en un compromiso de cloud a escala.
La señal de madurez no es “tenemos SSO”, sino poder demostrar que la identidad híbrida está segmentada, que los privilegios no se heredan por comodidad y que la administración cloud no depende de credenciales reutilizadas del dominio local. Cuando esa evidencia existe, el impacto de un incidente on‑premise deja de ser catastrófico para la nube.
¿Te interesa la seguridad en Cloud?
Comparto análisis técnicos, laboratorios prácticos y experiencias reales sobre Cloud Security.