Active Directory:
el modelo de seguridad que casi nadie entiende (y por eso cae)
Administración de sistemas Windows | unfantasmaenelsistema.com
En la mayoría de las empresas que usan Windows, Active Directory (AD) es el sistema nervioso central: decide quién es cada usuario, a qué equipos puede entrar, qué software se instala, qué contraseñas son válidas y quién manda sobre quién. Lleva funcionando desde el año 2000 y arrastra decisiones de diseño de aquella época, cuando la red interna se consideraba un lugar de confianza. Ese supuesto ya no se sostiene, pero el modelo sigue ahí.
El resultado es una paradoja conocida: casi todo el mundo administra Active Directory a diario y casi nadie entiende su modelo de seguridad completo. Los informes de intrusión repiten el mismo patrón año tras año: el atacante entra por un puesto de trabajo cualquiera y, en cuestión de horas, controla todo el dominio, no porque haya un exploit mágico, sino porque la relación de confianza entre las piezas estaba mal entendida. Este artículo es el mapa de esas piezas: para quien defiende y también para quien audita.
Qué aprenderás en este artículo
Qué son bosque, dominio y OU, y por qué el límite de seguridad real es el bosque · Cómo autentica Kerberos a alto nivel y por qué NTLM sigue siendo un problema · Qué grupos tienen poder efectivo sobre el dominio, más allá de «Domain Admins» · Qué son las GPO, SYSVOL y las delegaciones, y cómo se convierten en rutas de ataque · El modelo de tiering de Microsoft y por qué un portátil no debería poder llegar a un controlador de dominio · Defensas modernas: LAPS, gMSA, Protected Users y Authentication Policies
1. Qué es Active Directory, en una frase útil
Active Directory es una base de datos jerárquica y replicada que guarda objetos (usuarios, equipos, grupos, políticas) y las relaciones entre ellos, junto con un servicio de autenticación que verifica identidades para toda la organización. Los servidores que alojan esa base de datos y responden a las peticiones de autenticación se llaman controladores de dominio (DC). Comprometer un DC es comprometer el dominio entero: tiene una copia de todos los hashes de contraseña de todas las cuentas.
La consecuencia práctica: todo el modelo de seguridad de AD consiste en controlar quién puede, directa o indirectamente, ejecutar código o extraer credenciales en un controlador de dominio. Cualquier camino que lleve hasta ahí —por muy indirecto que sea— es una ruta de escalada.
2. La estructura: bosque, dominio, OU, sitios
Estos cuatro términos se confunden constantemente, y la confusión tiene consecuencias de seguridad reales.
| Nivel | Qué es | Para qué sirve |
|---|---|---|
| Bosque (forest) | El contenedor más externo; uno o varios dominios que comparten esquema y catálogo global | Es el LÍMITE DE SEGURIDAD real de Active Directory |
| Dominio (domain) | Una partición de la base de datos con sus propias cuentas y políticas | Límite de replicación y de administración, NO de seguridad |
| Unidad organizativa (OU) | Carpeta lógica dentro de un dominio para agrupar objetos | Aplicar GPO y delegar administración por departamento |
| Sitio (site) | Representa la topología física de red (ubicaciones, enlaces WAN) | Optimizar replicación y dirigir a los clientes al DC más cercano |
2.1 Por qué el bosque, y no el dominio, es la frontera
Durante años se vendió el dominio como frontera de seguridad: «si comprometen el dominio de filiales, el dominio de la matriz sigue a salvo». La realidad, confirmada por Microsoft desde 2016, es que dentro de un mismo bosque no hay aislamiento de seguridad garantizado. Las relaciones de confianza entre dominios del mismo bosque, la existencia de administradores del bosque (Enterprise Admins) y técnicas como el abuso del historial de SID permiten que el compromiso de un dominio se propague a todo el bosque. Si necesitas aislamiento real entre dos entornos, necesitas bosques separados.
3. Autenticación: Kerberos a alto nivel y NTLM como lastre
Cuando un usuario inicia sesión en un dominio, no envía su contraseña al servidor de destino. En su lugar entra en juego Kerberos, un protocolo de tickets diseñado en el MIT en los años 80.
3.1 El baile de tickets, resumido
- El cliente se autentica ante el KDC (Key Distribution Center, que corre en cada DC) y recibe un TGT (Ticket Granting Ticket): un vale que demuestra «soy quien digo ser», cifrado con una clave que solo conoce el KDC
- Cuando el usuario quiere acceder a un recurso (un recurso compartido, SQL Server, un sitio interno), presenta el TGT y pide un TGS (Ticket Granting Service) para ese servicio concreto, identificado por su SPN (Service Principal Name)
- El TGS va cifrado con el hash de la contraseña de la cuenta que ejecuta ese servicio; el cliente lo entrega al servicio, que lo descifra y comprueba quién es el usuario y a qué grupos pertenece
Este diseño es la razón de que dos de las técnicas de ataque más citadas contra AD —Kerberoasting y AS-REP Roasting— existan: se apoyan en piezas legítimas del protocolo. Las cubrimos aparte, con enfoque de detección y mitigación, en el artículo dedicado a Kerberoasting y AS-REP Roasting.
3.2 NTLM: el legado que sigue abierto
Antes de Kerberos, Windows autenticaba con NTLM, un esquema de desafío-respuesta basado directamente en el hash de la contraseña. NTLM sigue activo por compatibilidad y tiene debilidades estructurales: no valida la identidad del servidor (lo que habilita ataques de retransmisión o «relay»), el hash funciona como equivalente a la contraseña («pass-the-hash») y no soporta las protecciones modernas de Kerberos. La recomendación oficial es auditar dónde se sigue usando NTLM (Event ID 4624 con paquete NTLM, o la nueva auditoría de NTLM de Windows 11 24H2) e ir restringiéndolo con directivas hasta poder desactivarlo.
4. Los grupos que controlan el dominio
«Domain Admins» es el grupo famoso, pero hay varios grupos cuya pertenencia equivale, en la práctica, a control total del dominio —a veces de forma nada evidente.
| Grupo | Poder efectivo | Riesgo típico |
|---|---|---|
| Enterprise Admins | Administración de TODOS los dominios del bosque | Debería estar vacío salvo cambios puntuales de estructura |
| Domain Admins | Control total del dominio y de todos sus equipos unidos | Uso diario de estas cuentas para tareas normales |
| Schema Admins | Modificar el esquema del bosque (cambio permanente y global) | Debería estar vacío el 99,9% del tiempo |
| Administrators (del dominio) | Control del dominio; contiene a los tres anteriores | Miembros añadidos y olvidados |
| Account Operators | Crear/modificar cuentas y grupos no protegidos | Se infravalora; permite crear puertas traseras |
| Backup Operators | Leer y escribir cualquier fichero en los DC (incluida la base de datos) | Ruta directa a extraer todos los hashes |
| DnsAdmins | Históricamente, cargar una DLL arbitraria en el servicio DNS del DC | Escalada conocida; hoy parcialmente mitigada |
| Print Operators | Iniciar sesión localmente en los DC y gestionar drivers | Permiso de logon local en un DC = casi game over |
El poder real no siempre está en un grupo
Muchas rutas de escalada en AD no pasan por pertenecer a un grupo, sino por tener un permiso concreto sobre un objeto: poder cambiar la contraseña de otra cuenta (ForceChangePassword), escribir en su lista de control de acceso (WriteDacl), o tener control genérico (GenericAll). Estas ACL mal puestas son invisibles en la consola normal y son justo lo que herramientas de análisis de grafos como BloodHound sacan a la luz.
5. GPO y SYSVOL: configuración que se ejecuta sola
Las directivas de grupo (GPO, Group Policy Objects) son conjuntos de ajustes que se aplican automáticamente a los usuarios y equipos de una OU, un dominio o un sitio. Con una GPO se despliegan scripts de inicio, tareas programadas, permisos, software y configuración de seguridad en miles de equipos a la vez.
El contenido de las GPO se guarda en SYSVOL, un recurso compartido replicado en todos los DC y legible por cualquier usuario del dominio. Esto tiene dos implicaciones de seguridad:
- Quien pueda modificar una GPO vinculada a muchos equipos puede ejecutar código en todos ellos: por eso el permiso de edición de GPO debe tratarse como un privilegio de alto nivel
- Todo lo que se deje escrito en SYSVOL lo puede leer todo el dominio; el caso histórico es la contraseña de administrador local que se distribuía por GPP (Group Policy Preferences) cifrada con una clave pública y conocida —el motivo por el que nació LAPS
6. Delegaciones: la comodidad que abre puertas
AD permite delegar tareas administrativas concretas (resetear contraseñas de un departamento, unir equipos al dominio) sin dar privilegios completos. Bien hecho, es una buena práctica. El problema es la delegación de Kerberos, un mecanismo pensado para que un servicio actúe en nombre del usuario ante un tercer servicio (típico en aplicaciones web de tres capas).
| Tipo de delegación | Qué permite | Riesgo |
|---|---|---|
| Sin restricciones (unconstrained) | El servicio guarda el TGT del usuario y puede suplantarlo ante CUALQUIER servicio | Muy alto: si un DC se conecta a esa máquina, se captura su TGT |
| Restringida (constrained) | Suplantar al usuario solo ante una lista fija de SPN | Medio: acotada, pero un SPN mal elegido sigue siendo peligroso |
| Basada en recursos (RBCD) | El recurso de destino decide quién puede delegar hacia él | Medio: el más flexible, pero mal configurado permite escaladas |
La delegación sin restricciones sobre una cuenta que no sea un DC es una de las configuraciones heredadas más peligrosas que quedan en dominios antiguos. Inventariarla y eliminarla es una de las primeras tareas de cualquier revisión de seguridad de AD.
7. El modelo de tiering: por qué un portátil no debe llegar a un DC
La causa raíz de la mayoría de compromisos totales de dominio es sencilla: un administrador con credenciales de alto nivel inicia sesión en un equipo de bajo nivel (su propio portátil, el PC de un usuario para «echar un vistazo», un servidor de aplicaciones). Al hacerlo, su credencial queda en la memoria de ese equipo. Si ese equipo está comprometido, el atacante hereda la credencial.
El modelo de niveles (tiering) de Microsoft rompe ese círculo dividiendo los activos en tres capas y prohibiendo que las credenciales de una capa superior toquen una inferior:
| Nivel | Qué contiene | Regla de oro |
|---|---|---|
| Tier 0 | Controladores de dominio, AD FS, PKI, cualquier sistema que controle identidades | Sus cuentas SOLO inician sesión en sistemas Tier 0 |
| Tier 1 | Servidores de aplicación y de datos, hipervisores | Sus cuentas no tocan estaciones de trabajo ni Tier 0 |
| Tier 2 | Estaciones de trabajo, portátiles, dispositivos de usuario | Su administración se hace con cuentas dedicadas de Tier 2 |
En la práctica
El tiering se implementa con estaciones de administración dedicadas y endurecidas (PAW), cuentas administrativas separadas por nivel, y GPO de «denegar inicio de sesión» que impiden físicamente que una cuenta Tier 0 se autentique en un equipo de Tier 1 o 2. Microsoft ha reformulado esta idea en su modelo de acceso empresarial (Enterprise Access Model), pero el principio es el mismo: las credenciales poderosas nunca se exponen en máquinas menos protegidas.
8. Cuentas de máquina, de servicio, SPN y gMSA
Además de los usuarios, en AD hay cuentas de equipo (cada máquina unida al dominio tiene la suya, con una contraseña que rota sola cada 30 días) y cuentas de servicio, que ejecutan aplicaciones en segundo plano.
- Una cuenta de servicio con un SPN registrado puede ser objeto de Kerberoasting: cualquier usuario autenticado puede pedir un ticket cifrado con su hash y llevárselo para atacarlo sin conexión. Si esa contraseña es corta o débil, cae
- Las gMSA (group Managed Service Accounts) resuelven esto: Windows genera y rota automáticamente una contraseña de 240 bits que ningún humano conoce ni teclea. Son la respuesta recomendada para servicios que corren en Windows y admiten esta configuración
- Para cuentas de servicio que no pueden ser gMSA: contraseña larga (25+ caracteres) generada al azar, forzar cifrado AES en lugar de RC4, y el mínimo de privilegios y de SPN posibles
9. Defensas modernas que deberían estar activas
| Mecanismo | Qué protege |
|---|---|
| LAPS / Windows LAPS | Contraseña de administrador local única y rotada por equipo; corta el pass-the-hash lateral |
| Protected Users | Grupo que desactiva NTLM, delegación y caché de credenciales para sus miembros; para cuentas privilegiadas |
| Authentication Policies y Silos | Restringen desde qué equipos puede autenticarse una cuenta; implementan el tiering a nivel de Kerberos |
| Credential Guard | Aísla los secretos de LSASS con virtualización; dificulta el volcado de credenciales en memoria |
| Cuenta KRBTGT: rotación | Cambiar dos veces la contraseña de KRBTGT invalida los «golden tickets» tras un incidente |
| Tiered admin + PAW | Estaciones de administración dedicadas para que las credenciales Tier 0 nunca toquen un equipo de usuario |
Uso legal y ético
Este artículo es un mapa conceptual del modelo de seguridad de Active Directory con fines de defensa, administración y auditoría autorizada. Enumerar, atacar o modificar un directorio activo que no sea tuyo, o para el que no tengas autorización expresa y por escrito, es ilegal. · En España, el acceso no autorizado a sistemas de información y su mantenimiento contra la voluntad de quien tiene derecho a excluirlo está tipificado en el art. 197 bis del Código Penal; la facilitación de herramientas concebidas para ello en el art. 197 ter; y los daños o la obstaculización de sistemas ajenos en el art. 264 y siguientes. · Practica siempre en un dominio de laboratorio propio y aislado (por ejemplo, un rango 192.168.56.x sin salida a producción), nunca contra la infraestructura de un tercero.
Referencias
Microsoft — Securing privileged access y Enterprise Access Model (aka.ms/privsec) · Microsoft — Active Directory security best practices (Best Practices for Securing AD) · Windows LAPS — documentación oficial de despliegue · MITRE ATT&CK — tácticas de Credential Access y Lateral Movement sobre AD · ANSSI — «Points de contrôle Active Directory» (guía de auditoría de configuración) · Nuestros artículos sobre BloodHound y sobre Kerberoasting para el detalle de rutas de ataque y su detección
Conclusión
Active Directory no cae por un fallo espectacular, sino porque su modelo de confianza —bosque como frontera real, credenciales que se quedan en memoria, permisos delegados que nadie revisa, grupos con poder poco evidente— se administra sin entenderlo del todo. El atacante no necesita saber más que el defensor: necesita saber lo mismo y mirarlo como un grafo de rutas hacia el Tier 0.
La buena noticia es que las defensas existen y llevan años maduras: tiering, LAPS, gMSA, Protected Users, Authentication Policies y una limpieza periódica de ACL y delegaciones cierran la inmensa mayoría de esas rutas. El primer paso no es comprar nada, es dibujar el mapa de tu propio dominio y preguntarse, para cada camino: ¿esto lleva a un controlador de dominio?
unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)