El 80% de los Active Directory que probamos tenía una vía viva a Domain Admin
Llevo años entrando en Active Directory de empresas reguladas españolas: banca, seguros, sanidad, energía, administración pública. Entornos serios, con SOC, con EDR, con políticas firmadas, con su pentest anual hecho por una Big Four. Y agregando lo que he visto al ejecutar la herramienta, el número que sale es incómodo:
En cerca del 80% de esos entornos existía, en el momento de mirar, al menos una vía viva desde un usuario de dominio cualquiera hasta el control total del directorio: Domain Admin.
No "una vulnerabilidad teórica". Una vía. Una secuencia de pasos encadenables que un atacante con un único usuario comprometido (el del help desk, el de un becario, el de una cuenta de servicio olvidada) puede recorrer hasta hacerse con el dominio entero. Y casi siempre estaba ahí desde hacía meses o años, sin que ningún escáner la marcase y sin que ningún pentest la recogiese.
Sobre el dato. El 80% es agregado y anonimizado, de mi experiencia profesional ejecutando esta clase de análisis en entornos reales. No publico el número total de entornos ni identifico a ninguna organización. El punto no es la cifra exacta: es que la mayoría de los directorios maduros tienen una vía viva, y casi nadie lo sabe.
Lo interesante no es que existan estas vías. Es por qué nadie las ve. Y la respuesta tiene que ver con cuatro patrones que se repiten, con una herramienta que mide el problema equivocado, y con la diferencia entre una foto y una película.
¿Por qué el escáner de vulnerabilidades no ve la vía a Domain Admin?
Porque ninguno de los cuatro patrones que llevan a Domain Admin es un CVE. Son configuraciones legítimas y permisos válidos mal combinados, no software sin parchear, así que el escáner, que busca versiones vulnerables, pasa por encima de ellos sin marcar nada.
Esta es la trampa mental que hay que romper antes de seguir. Cuando un CISO piensa "exposición de Active Directory", piensa en parches: el último boletín de Microsoft, el CVE de Netlogon de turno, la versión del controlador de dominio. Y está bien parchear. Pero el camino real al dominio casi nunca pasa por un CVE.
Pasa por permisos. Por una cuenta de servicio con una contraseña de 2014. Por una plantilla de certificado que alguien marcó "para que sea más cómodo". Por una opción de delegación que se activó para que una aplicación funcionara y nadie volvió a tocar. Todo eso es configuración legítima desde el punto de vista del sistema. No hay nada que parchear. El escáner de vulnerabilidades, diseñado para encontrar software desactualizado, mira esto y no ve absolutamente nada.
Por eso el problema es de relaciones, no de versiones. Active Directory es un grafo: usuarios, grupos, equipos, GPOs, plantillas de certificado, todos conectados por permisos y pertenencias. La vía a Domain Admin es un camino en ese grafo. Para verla hay que modelar el grafo entero y calcular la ruta más corta, no escanear hosts uno a uno.
Cuando ejecuto la herramienta sobre un directorio, lo primero que hago es exactamente eso: reconstruir el grafo y preguntar "¿qué caminos llegan a Tier 0?". Y casi siempre, debajo de un entorno aparentemente limpio, aparece uno de estos cuatro patrones.
Patrón 1. Abuso de ACL: el permiso que nadie revisa
Una ACL (lista de control de acceso) define quién puede hacer qué sobre cada objeto del directorio. El problema aparece cuando un objeto poco vigilado tiene, sobre un objeto que toca Tier 0, un permiso demasiado potente: GenericAll (control total) o WriteDACL (poder reescribir la propia lista de permisos).
Si la cuenta del help desk tiene GenericAll sobre un grupo que, a su vez, es miembro de un grupo con privilegios de administración del dominio, el atacante que controla esa cuenta no necesita ningún exploit. Solo usa el permiso para lo que el permiso permite: se añade al grupo, o resetea la contraseña de una cuenta privilegiada, o reescribe la ACL para concederse más. Es administración legítima, ejecutada por la persona equivocada.
Estos permisos se acumulan por sedimentación. Una migración de hace seis años que concedió control "temporal". Un grupo anidado dentro de otro grupo dentro de otro, hasta que nadie sabe que la cadena termina tocando el dominio. Una delegación de helpdesk demasiado amplia. Ninguna de estas decisiones fue maliciosa. Sumadas, abren la puerta.
MITRE ATT&CK: T1222: File and Directory Permissions Modification y T1098: Account Manipulation
Lo que veo al ejecutarlo: el grafo conecta una cuenta de bajo privilegio con Tier 0 a través de dos o tres aristas de ACL que ningún humano relacionaría revisando objetos por separado. La cadena solo es visible cuando ves el grafo completo.
Patrón 2. Kerberoasting: la contraseña de servicio que no caducó nunca
Kerberos, el protocolo de autenticación de Active Directory, tiene una propiedad por diseño: cualquier usuario autenticado puede pedir un ticket de servicio (TGS) para cualquier cuenta que tenga un SPN (Service Principal Name) asociado, típicamente cuentas de servicio. Ese ticket va cifrado con la contraseña de la cuenta de servicio. El atacante se lo lleva y lo intenta romper offline, en su propia máquina, sin volver a tocar la red.
Aquí está el detalle que lo hace tan eficaz: las cuentas de servicio suelen tener contraseñas viejas, largas en años pero no en entropía, que nunca caducan porque cambiarlas rompería la aplicación que las usa. Y muchas de esas cuentas son, además, miembros de grupos privilegiados. Una cuenta de servicio con SPN, contraseña débil y privilegios altos es la combinación perfecta: roastable, crackeable y poderosa.
El ataque no genera ruido sospechoso. Pedir un TGS es una operación normalísima del protocolo: millones de ellas ocurren cada día en un dominio sano. El crackeo ocurre fuera, donde ningún EDR mira.
MITRE ATT&CK: T1558.003: Steal or Forge Kerberos Tickets, Kerberoasting
Lo que veo al ejecutarlo: la herramienta lista las cuentas con SPN, marca cuáles tienen privilegios que tocan Tier 0 y cuáles tienen políticas de contraseña que las hacen viables. No se trata de crackear todo: se trata de saber cuál de esas cuentas, si cae, te entrega el dominio.
(Si quieres el detalle técnico completo de cómo funciona y cómo se mitiga, tengo una guía de Kerberoasting aparte.)
Patrón 3. ADCS mal configurado: cualquiera se fabrica un certificado de Domain Admin
Active Directory Certificate Services (ADCS) es la autoridad de certificación interna. Emite certificados a partir de plantillas. Y una plantilla mal configurada es una de las vías más limpias y silenciosas que existen al dominio.
La familia de fallos se conoce como ESC (la primera, ESC1, es la canónica). La idea: si una plantilla permite que un usuario sin privilegios solicite un certificado y le deja especificar él mismo a nombre de quién se emite (el SAN, Subject Alternative Name), entonces ese usuario puede pedir un certificado a nombre de un administrador de dominio. Con ese certificado se autentica como administrador. Fin del juego.
No hay malware. No hay exploit. Es la PKI haciendo exactamente lo que su configuración le dice que haga: emitir un certificado a quien lo pide, con el nombre que pide. El flag que lo habilita suele activarse por comodidad operativa ("que los usuarios puedan auto-inscribirse") sin entender que esa comodidad equivale a regalar las llaves del dominio.
ADCS es especialmente peligroso porque casi nadie lo audita. El equipo de seguridad mira el directorio; la PKI vive en una esquina, gestionada por otra gente, dada por buena desde que se instaló.
MITRE ATT&CK: T1649: Steal or Forge Authentication Certificates
Lo que veo al ejecutarlo: enumero las plantillas publicadas y reviso la combinación de flags que convierte "emisión de certificados" en "escalada a Domain Admin". Cuando una plantilla peligrosa está publicada, el camino al dominio es de un solo salto.
Patrón 4. Abuso de delegación: la máquina normal que se convierte en puente al DC
La delegación de Kerberos existe para un caso de uso legítimo: que un servicio actúe en nombre de un usuario contra otro servicio (la aplicación web que, en tu nombre, consulta la base de datos). El problema es lo potente que es cuando está mal acotada. Hay tres sabores, de peor a "mejor":
- Delegación sin restricciones (unconstrained): la máquina puede suplantar a cualquier usuario que se autentique contra ella, incluido un administrador de dominio. Si un atacante controla esa máquina y consigue que un DA se autentique (a veces se puede forzar), se lleva sus credenciales.
- Delegación restringida (constrained): acotada a servicios concretos, pero si esos servicios son sensibles, el puente sigue existiendo.
- RBCD (Resource-Based Constrained Delegation): la variante moderna, donde el permiso para delegar se configura en el objeto destino. Si un atacante puede escribir en el atributo correcto de un equipo, puede concederse a sí mismo delegación sobre él y convertir un equipo normal en un trampolín hacia el controlador de dominio.
El patrón común: un equipo o cuenta aparentemente irrelevante adquiere la capacidad de hablar en nombre de otros, y esa capacidad termina alcanzando Tier 0. Otra vez, no es un CVE. Es un atributo de configuración que alguien puso, o que un atacante puede poner si encuentra el permiso de escritura adecuado.
MITRE ATT&CK: T1558.003 y la técnica general de delegación en T1134: Access Token Manipulation
Lo que veo al ejecutarlo: el grafo marca qué equipos tienen delegación, de qué tipo, y si esa delegación, combinada con un permiso de escritura alcanzable, abre un camino a un DC. La delegación sin restricciones sobre un host expuesto es de las aristas que más me hacen levantar la ceja.
La tesis: foto contra película
Pon los cuatro patrones juntos y emerge el problema real. Ninguno es un CVE → el escáner de vulnerabilidades no los ve. Y aquí entra la segunda pieza: el pentest anual tampoco resuelve esto, por una razón estructural.
Un pentest es una foto. Captura el estado del directorio el día que el auditor miró. Excelente foto, hecha por buenos profesionales. Pero el día siguiente alguien crea una cuenta de servicio con una contraseña débil. A la semana, un administrador publica una plantilla de certificado "para agilizar". Al mes, una migración deja un GenericAll colgando. Tres de los cuatro patrones que acabo de describir nacen de cambios operativos normales que ocurren todos los días, después de que el auditor se fue.
El riesgo real no es si hoy tienes una vía a Domain Admin. Es cuánto tiempo lleva viva una vía sin que nadie lo sepa. Y ese tiempo, en la mayoría de los entornos, se mide en meses o años: la ventana entre dos fotos anuales.
Lo que hace falta es una película: validación continua de la exposición del directorio, recalculando los caminos a Tier 0 cada vez que el entorno cambia. No para sustituir al pentest, sino para cubrir los 364 días que el pentest no mira.
El contraste, en una línea: un pentest anual cubre 1 día de 365. La validación continua cubre los 365.
Por qué esto es ahora un problema de cumplimiento, no solo técnico
El argumento técnico siempre fue válido. Lo nuevo es que ahora el regulador lo respalda, y eso cambia la conversación en el board.
- DORA, el Reglamento (UE) 2022/2554, es aplicable desde el 17 de enero de 2025 (fuente: EIOPA). Exige a las entidades financieras gestión de riesgo TIC y pruebas de resiliencia basadas en amenazas reales, lo que incluye verificar técnicamente los caminos de compromiso del directorio de identidades, no solo documentar políticas.
- NIS2 amplía las obligaciones de gestión de riesgo de ciberseguridad y la rendición de cuentas a sectores esenciales, con sanciones materiales por incumplimiento grave.
- ENS Alto (Real Decreto 311/2022) exige verificación periódica del estado de seguridad de los sistemas, y el CCN-CERT pide cada vez más evidencia técnica real, no solo políticas firmadas.
Las tres normas apuntan a lo mismo: no basta con tener controles documentados; hay que demostrar técnicamente, y de forma sostenida, que tu directorio no tiene una vía viva al control total. Una foto anual no demuestra "sostenido". Una película, sí.
El contexto que debería preocupar a cualquier CISO
Estos patrones no son académicos. Son exactamente por donde entra el ransomware moderno.
Según Microsoft, en más del 78% de los ciberataques operados por humanos los atacantes consiguen comprometer un controlador de dominio, y en más del 35% de los casos el dispositivo que distribuye el ransomware a escala es un controlador de dominio (Microsoft Security Blog, abril 2025). El coste medio de un ataque de ransomware alcanzó los 9,36 millones de dólares en 2024, según la misma fuente.
El controlador de dominio no es un objetivo más. Es el objetivo. Y la vía hasta él es, casi siempre, uno de los cuatro patrones de arriba: vivo, silencioso, ahí desde hace meses.
Cómo lo hago yo (y la herramienta es open source)
Cuando entro en un entorno, el flujo es siempre el mismo: reconstruyo el grafo del directorio, calculo todos los caminos que terminan en Tier 0, y los clasifico por estos cuatro patrones. No busco CVEs. Busco caminos. La pregunta no es "¿qué software está sin parchear?" sino "¿qué secuencia de permisos, tickets, certificados y delegaciones convierte a un usuario cualquiera en dueño del dominio?".
La herramienta que uso para esto es ADscan, y es open source: el enlace está en los comentarios del post de LinkedIn que te trajo aquí, y también en GitHub. Puedes descargarla, apuntarla a tu propio entorno de laboratorio y ver tú mismo qué caminos aparecen. Ese es el punto de publicar esto: el patrón es incopiable porque es real; la herramienta que lo mide está en tus manos.
Lo que hace ADscan, en una frase: detecta de forma continua y automática todos los caminos por los que un atacante podría tomar el control total del directorio, y deja ese hallazgo mapeado a DORA, NIS2 y ENS para el supervisor.
Foto contra película. Eso es todo lo que cambia. Pero lo cambia todo.
Nota metodológica. Este artículo describe patrones, no procedimientos de explotación paso a paso. El objetivo es que un CISO entienda por qué su escáner no ve el problema y por qué el pentest anual no lo cierra, no proporcionar una receta ofensiva. Las referencias a MITRE ATT&CK enlazan la documentación pública de cada técnica para quien quiera profundizar.