Que son las rutas de ataque AD?
Las rutas de ataque AD son cadenas de relaciones que permiten a una identidad poco privilegiada alcanzar privilegio elevado, a menudo hasta Domain Admin o a otro punto de control Tier 0. La clave no es un exploit aislado. La clave es el grafo: permisos sobre objetos, membresias, sesiones administrativas, derechos sobre GPO, cuentas de servicio crackeables, delegacion Kerberos y trusts que, por separado, pueden parecer tolerables pero juntos forman un camino utilizable.
Herramientas como BloodHound ayudan a visualizar esas relaciones, pero el principio no depende de una herramienta concreta. Si el directorio permite escribir sobre un usuario con SPN, si ese usuario administra un servidor donde inicia sesion un admin, y si ese admin tiene a su vez privilegios sobre un DC, el camino existe aunque nadie haya abierto un grafo todavia.
Rutas de ataque AD: que aristas importan de verdad
Un programa serio de hardening no necesita perseguir todas las aristas con la misma prioridad. Necesita saber cuales reducen mas la distancia a Tier 0.
| Arista o salto | Ejemplo | Por que importa |
|---|---|---|
| Permisos sobre objetos | GenericWrite, WriteDacl, ResetPassword | cambian control de una identidad sin tocar el endpoint |
| Membresia o nesting | grupo delegado que termina dentro de otro mas sensible | convierte permisos locales en privilegio estructural |
| Sesiones administrativas | un admin inicia sesion en un servidor alcanzable | la memoria y el contexto de la sesion valen mas que el servidor |
| GPO | permiso de editar o enlazar una GPO | permite desplegar control a gran escala |
| Cuentas de servicio | cuenta con SPN y password debil | abre Kerberoasting y escalada posterior |
| Delegacion y trusts | RBCD, unconstrained delegation, trust mal entendido | conectan zonas que el equipo creia separadas |
Como se construye una ruta real
Paso 1 - El atacante recopila relaciones
Con visibilidad LDAP y con permisos de usuario normal ya se pueden recopilar muchas relaciones del grafo. En entornos defensivos, el mismo principio sirve para descubrir donde una mala delegacion conecta usuarios corrientes con activos sensibles.
bloodhound-python -u [email protected] -p 'Password123!' -ns 10.10.0.1 -d corp.local -c All --zip
Paso 2 - Busca el camino mas corto o el mas estable
No siempre gana el camino mas corto. A veces gana el mas silencioso. Pero en ambos casos el grafo ayuda a responder la misma pregunta: que dos o tres cambios rompen mas rutas a la vez?
MATCH p=shortestPath((u:User)-[*1..]->(g:Group {name:"DOMAIN [email protected]"}))
RETURN p LIMIT 10
Paso 3 - Convierte una arista menor en privilegio mayor
Un ejemplo tipico es este:
- un usuario normal tiene
GenericWritesobre una cuenta de servicio - la cuenta de servicio es kerberoasteable o administra un servidor
- en ese servidor inicia sesion un admin de alto valor
- el atacante reutiliza esa posicion para moverse hacia DC o hacia un grupo Tier 0
Ningun salto por si solo parece dramatico. El problema es la composicion.
Que debe auditar primero
1. Los caminos hacia Tier 0, no solo hacia Domain Admins
Domain Admins importa, pero no es el unico destino. Revise tambien:
- controladores de dominio
- grupos con privilegios equivalentes
- cuentas con capacidad de replica
- sistemas de administracion y jump hosts
- cuentas usadas para GPO, backup o gestion de certificados
2. Las aristas repetidas
Si el mismo patron aparece en decenas de objetos, no tiene un error puntual; tiene un problema de modelo. Ejemplos claros:
- muchas ACLs delegadas sin revision
- GPO editables por grupos amplios
- cuentas de servicio sin gMSA ni rotacion
- admins iniciando sesion en hosts no endurecidos
3. Las rutas que sobreviven tras cambios pequenos
No se obsesione con eliminar una sola ruta. Priorice aristas cuya retirada rompe varias rutas a la vez. En muchas auditorias, las mejores victorias no son "limpiar todo" sino quitar dos grupos delegados, una GPO peligrosa y dos sesiones administrativas mal ubicadas.
Telemetria y deteccion util
Las rutas de ataque AD no se detectan con un unico evento. Se gestionan combinando inventario de grafo y telemetria de cambio.
Eventos que suelen importar
| Event ID | Uso |
|---|---|
4728 / 4732 | altas en grupos que cambian el camino de privilegio |
5136 | cambios en objetos de directorio, incluidas ACLs y atributos sensibles |
4662 | acceso a objetos especialmente relevantes, incluida replica cuando esta bien instrumentada |
4769 | senales de Kerberoasting y uso de cuentas de servicio |
4624 | logons administrativos en sistemas donde no deberian existir |
Lo que conviene medir de forma recurrente
- longitud minima de los caminos a Tier 0
- nuevos principals que aparecen con permisos de escritura sobre objetos sensibles
- nuevos hosts con sesiones administrativas de alto valor
- nuevas cuentas de servicio o cambios en SPNs
- cambios de GPO que crean alcance transversal
Remediacion que de verdad rompe el grafo
Reduzca primero las aristas de mayor impacto
Empiece por lo que rompe mas rutas a la vez:
- grupos delegados demasiado amplios
- ACLs de escritura sobre usuarios, grupos y GPOs sensibles
- sesiones administrativas fuera de PAWs, jump hosts o servidores endurecidos
- cuentas de servicio tradicionales que deberian migrar a gMSA
Trate los endpoints administrativos como parte del grafo
Muchas organizaciones limpian el directorio y olvidan donde inician sesion los admins. Si las sesiones privilegiadas siguen apareciendo en hosts alcanzables por operadores o por cuentas de soporte, el grafo vuelve a reconstruirse solo.
Recolecte y compare, no solo escanee una vez
BloodHound y herramientas similares son mas utiles cuando se ejecutan de forma recurrente y se comparan entre semanas. La pregunta operativa correcta es: que nueva arista aparecio desde la ultima coleccion y por que?
Como validar despues del cambio
- repita la coleccion del grafo y confirme que la ruta desaparecio o aumento claramente su longitud
- revise que no aparecio una ruta alternativa equivalente
- verifique que las aristas eliminadas no se recrean via GPO, automatizacion o grupos delegados antiguos
- confirme que admins y cuentas Tier 0 ya no dejan sesiones en hosts de menor confianza
Priorizar por control y no por curiosidad
Un error comun en equipos tecnicos es abrir el grafo y perseguir el camino mas llamativo. Eso consume tiempo y rara vez reduce mas riesgo. La forma profesional de priorizar es agrupar las rutas por control que las hace posibles: delegaciones ACL demasiado amplias, sesiones administrativas en hosts de baja confianza, GPOs con write access excesivo, cuentas de servicio con SPN y secretos debiles, o relaciones entre dominios que siguen expuestas por costumbre. Cuando varias rutas dependen del mismo control roto, la correccion correcta no es cerrar un camino visible, sino eliminar la condicion que genera diez caminos distintos.
En la practica, esto significa que un hallazgo sobre un servidor concreto puede ser menos prioritario que una OU entera con delegacion heredada o que una GPO editable por un grupo operativo amplio. El grafo sirve para mostrar la ruta, pero la remediacion madura siempre apunta al patron repetible.
Tres preguntas que mejoran cualquier review de rutas
Antes de aceptar o descartar una ruta de ataque AD, conviene hacer tres preguntas simples:
- que salto concreto permite pasar de un privilegio operativo comun a un privilegio Tier 0
- cuantas rutas distintas dependen del mismo permiso, grupo o sesion
- que cambio minimo rompe el mayor numero de caminos sin parar la operacion
Estas preguntas obligan a separar ruido de estructura. Un entorno puede tener cientos de relaciones interesantes y solo unas pocas que realmente cambian la distancia a Tier 0. Esas son las que deben entrar primero en backlog, en sprint de hardening o en revisión de excepciones.
Donde suelen reaparecer las rutas despues de un fix
Muchas rutas vuelven a aparecer no porque el equipo no entienda el riesgo, sino porque los procesos vuelven a crear la misma arista. Los culpables mas habituales son:
- scripts de aprovisionamiento que restauran membresias antiguas
- GPOs reaplicadas desde un backup o desde un repositorio no revisado
- cuentas de servicio recreadas sin gMSA ni rotacion
- admins que vuelven a iniciar sesion en hosts operativos por urgencia
- grupos delegados que nadie recuerda haber heredado de un proyecto previo
Por eso la validacion no termina cuando el grafo mejora una vez. Debe incluir una comprobacion posterior de drift y una explicacion clara de que proceso impide que la misma ruta reaparezca.
Indicadores de cierre que merece guardar
Cuando una ruta se da por cerrada, conviene registrar cuatro evidencias: el camino anterior, la arista eliminada, la nueva distancia minima a Tier 0 y el proceso de control que evita la reaparicion. Esa pequena disciplina cambia mucho la calidad del hardening, porque convierte un hallazgo puntual en una mejora repetible y auditable.
Referencias primarias
- SpecterOps BloodHound documentation: data collection and path analysis
- Microsoft Learn: security groups, ACLs and delegation concepts in Active Directory
- Microsoft Learn: Group Policy permissions cmdlets
- Microsoft Learn: gMSA overview
Lecturas relacionadas
- Abuso ACL y DCSync: las rutas silenciosas hacia Domain Admin
- Anidamiento de grupos AD: rutas ocultas a Domain Admin
- Malas configuraciones GPO como vector de ataque
- Kerberoasting: riesgo en cuentas de servicio
- Delegacion Kerberos: no restringida, restringida y RBCD
- Supervision de seguridad AD: los eventos que realmente importan
Use este articulo como guia para priorizar. Las rutas de ataque AD no se resuelven enumerando todas las debilidades posibles, sino identificando las pocas aristas que convierten un privilegio comun en control de Tier 0.


