Active Directory

Un dominio es una frontera de identidad y política compartidas. Los controladores de dominio guardan la base de datos del directorio, la replican entre ellos y responden a las preguntas que hace toda máquina unida al dominio: si esta cuenta existe, si esta contraseña es correcta, si esta cuenta puede iniciar sesión en ese equipo, qué política se aplica aquí. Los dominios se agrupan en un bosque, y el bosque es la verdadera frontera de seguridad, porque la confianza entre dominios de un mismo bosque no es algo que se pueda revocar a medias.

Tres mecanismos hacen casi todo el trabajo. LDAP lee y escribe el directorio, y por defecto cualquier cuenta autenticada puede leer una cantidad enorme de él: todos los usuarios, todos los grupos, todos los equipos, todos los nombres principales de servicio, todos los campos de descripción. Kerberos emite tickets que acreditan identidad ante los servicios. NTLM es el mecanismo antiguo de desafío y respuesta que sigue funcionando en casi todas partes por compatibilidad, y que es la base de varios ataques que no tienen nada que ver con romper una contraseña. Las políticas de grupo distribuyen configuración y, como lo hacen desde un recurso compartido que leen todas las máquinas, son un canal de distribución que merece la pena atacar por sí mismo.

Los permisos son la parte que sorprende. Más allá de la pertenencia a grupos, cada objeto del directorio lleva su propia lista de control de acceso, y derechos como restablecer una contraseña, escribir en la pertenencia de un grupo o escribir un atributo concreto sobre un objeto de equipo se pueden delegar. Esas delegaciones se acumulan a lo largo de una década de arreglos operativos, y rara vez están escritas en ningún sitio.

El fallo característico de Active Directory no es una vulnerabilidad. Es privilegio acumulado que nadie puede ver, y por eso una herramienta de grafo de caminos de ataque es lo primero que ejecutamos en un encargo interno. Con acceso de lectura al directorio basta para construir un grafo de quién alcanza qué, y en casi todos los parques ese grafo contiene una ruta desde un usuario corriente hasta un administrador de dominio compuesta por entero de permisos legítimos, concedidos uno a uno por motivos defendibles, a lo largo de varios años. Nadie concedió el camino. El camino emergió.

Los eslabones concretos se repiten de un encargo a otro. Un grupo de soporte con derecho a restablecer contraseñas de cuentas que resulta que incluyen cuentas de servicio con privilegios altos. Un grupo en cuya pertenencia puede escribir un grupo en cuya pertenencia puede escribir un grupo al que se puede unir cualquiera. Un objeto de equipo cuyos ajustes de delegación le permiten pedir tickets en nombre de otros. Una plantilla de certificado que deja a una cuenta con pocos privilegios solicitar un certificado que nombre a cualquier usuario, lo que convierte el acceso de lectura al directorio en administrador de dominio sin romper una sola contraseña.

Y luego están los datos que descansan en campos que puede leer todo el mundo. Contraseñas en el campo de descripción de cuentas de servicio, algo que en 2026 sigue siendo un hallazgo real. Scripts de inicio de sesión antiguos con credenciales dentro en un recurso compartido. Recursos de despliegue legibles por todos los usuarios del dominio. Nada de esto necesita un exploit.

La reutilización de la cuenta de administrador local es la cuarta. Una imagen, una contraseña, todos los puestos de trabajo. Recuperamos el hash de la primera máquina y es válido en todas partes, lo que convierte un único punto de apoyo en movimiento lateral por todo el parque antes de intentar ninguna escalada.

Todo esto sobrevive porque Active Directory no se degrada cuando es inseguro. Sigue funcionando a la perfección. No se abre ningún ticket, no falla ninguna comprobación de salud, y los caminos acumulados son invisibles salvo que alguien se ponga a buscarlos a propósito.

Muchos parques ejecutan hoy los dos y los tratan como un solo sistema, lo que produce huecos justo en la unión. Son productos distintos con superficies de ataque distintas, y la sincronización entre ellos es un riesgo propio.

Lo importante es la última fila. La cuenta que sincroniza el directorio con el cloud tiene derechos extraordinarios en los dos lados, y con frecuencia queda excluida de los controles que se aplican a todo lo demás porque un día rompió algo. Un parque híbrido que da por asegurado su tenant cloud por separado, mientras una cuenta de sincronización tiende un puente entre ambos sin ninguna política condicional encima, tiene una sola frontera de identidad y no dos.

Creer que la pertenencia a Domain Admins es el inventario de privilegio. Es una parte pequeña. Los derechos que importan están repartidos entre permisos de objeto, administración delegada y grupos anidados.

Tratar el acceso de lectura al directorio como inofensivo. Todo lo que un atacante necesita para planificar lo puede leer cualquier cuenta autenticada, y es lo que hace tan productiva la primera hora de una prueba interna.

Ejecutar servicios con cuentas de dominio cuya contraseña eligió una persona. Esa es la condición previa del kerberoasting, y es la ruta más frecuente desde un usuario normal hasta algo que importa.

Compartir la contraseña de administrador local en toda una imagen. Es la primitiva de movimiento por todo el parque más rápida que existe y arreglarla no cuesta nada.

Dar por hecho que existe un modelo de niveles porque se diseñó. El nivel cero solo es real si una credencial de nivel cero no puede aterrizar nunca en una máquina de nivel uno, y eso es una propiedad que se prueba, no que se declara.

Mapéalo antes de cambiarlo. Ejecuta un grafo de caminos de ataque como defensor, desde la perspectiva de un usuario normal, y lee las rutas más cortas hasta tus grupos más privilegiados. Ese resultado es incómodo y es la única imagen exacta que existe del modelo de privilegio del parque.

Después corta los caminos en lugar de los síntomas. Retira las delegaciones que nadie sabe justificar. Aplana los grupos anidados que conceden derechos administrativos de forma transitiva. Pasa las cuentas de servicio a contraseñas gestionadas que rote el directorio. Aleatoriza la contraseña de administrador local en cada máquina. Y revisa las plantillas de certificado que permiten a quien solicita especificar el sujeto, que es la ruta de escalada total más silenciosa de un dominio moderno.

Separa los niveles e impón la separación por medios técnicos: cuentas administrativas que no puedan iniciar sesión en puestos de trabajo, puestos de trabajo que no puedan alcanzar los controladores de dominio por protocolos administrativos, y sesiones privilegiadas desde máquinas dedicadas. Aplica el mínimo privilegio a las cuentas que ejecutan cosas, no solo a las personas.

Para la detección, las señales útiles son propias del directorio: peticiones de replicación desde una máquina que no es controlador de dominio, tickets solicitados para muchas cuentas de servicio en una ventana corta, cambios en la pertenencia a grupos privilegiados, y solicitudes de certificado con un nombre alternativo del sujeto que no coincide con quien lo pide.

Los informes de encargo interno se organizan alrededor del camino y no alrededor de una lista de configuraciones erróneas. Enseñamos dónde empezamos, cada paso, el permiso o la credencial que lo hizo posible, y dónde terminó. Esa estructura es deliberada: un cliente puede cerrar un paso y romper la ruta entera, y una lista plana de hallazgos no le dice qué paso cerrar primero.

La evidencia son los nombres de los objetos, los permisos tal y como se leen del directorio, y los comandos en su forma mínima. Las credenciales recuperadas no se imprimen en el cuerpo del informe. Cuando el camino se apoya en una delegación, citamos la entrada de control de acceso, para que el equipo de directorio del cliente pueda verificarlo sin tener que creernos.

La severidad se pega al camino, no a cada eslabón. Una contraseña en un campo de descripción de una cuenta sin derechos es una observación. El mismo hallazgo sobre una cuenta a la que una plantilla de certificado nos deja suplantar está a un salto del bosque.

Este es el trabajo de probar un parque Windows desde dentro, y es donde se deciden de verdad la mayoría de las redes corporativas españolas.

¿Sigue siendo relevante Active Directory con la identidad en cloud? En la mayoría de los parques españoles de mediana empresa e industriales sigue autenticando los puestos de trabajo, los servidores de ficheros y las aplicaciones de negocio. La identidad cloud se añadió a su lado en lugar de sustituirlo, y la sincronización entre las dos forma parte ya de la superficie de ataque.

¿Cuál es la diferencia entre un dominio y un bosque? Un dominio es una frontera administrativa y de replicación. Un bosque contiene uno o más dominios que comparten esquema y confían entre sí de forma implícita. El bosque es la frontera de seguridad: comprometer un dominio de un bosque obliga a dar por comprometidos todos los demás.

¿Por qué puede cualquier usuario leer tanta parte del directorio? Porque de ello dependen aplicaciones, procesos de inicio de sesión y herramientas de administración, y el valor por defecto ha sido permisivo desde el principio. Parte se puede restringir, la mayoría de los parques no puede restringirlo todo, y la respuesta práctica es sacar el contenido sensible de los campos legibles.

¿Qué es lo más rápido que podemos hacer para ponerlo difícil? Aleatorizar la contraseña de administrador local en cada máquina, pasar las cuentas de servicio a contraseñas gestionadas por el directorio, y retirar el material de contraseñas de los campos de descripción y de los ficheros de script. Esos tres cambios cierran las rutas que más usamos, y ninguno de ellos exige un proyecto.