Rutas de ataque AD: como se encadenan hasta Domain Admin

¿Qué son las rutas de ataque en Active Directory?

Las rutas de ataque en Active Directory son cadenas de relaciones — membresías de grupo, permisos ACL, vínculos de GPO, configuraciones de delegación, cuentas kerberoasteables — que conectan a un atacante con pocos privilegios con Domain Admin. Ninguna mala configuración aislada necesita ser crítica por sí sola: lo que importa es si pueden encadenarse entre ellas.

Los adversarios modernos no explotan vulnerabilidades individuales. Mapean todo el entorno de Active Directory como un grafo, identifican el camino más corto desde su posición actual hasta Domain Admin, y siguen ese camino — un salto a la vez. Cada salto aprovecha una mala configuración distinta: una contraseña que han crackeado, un camino de anidamiento de grupos, una ACL que pueden abusar, o un certificado que han forjado.

Este artículo cubre las tres categorías de camino más fiables: rutas ACL, rutas GPO y rutas de Kerberoasting hacia Domain Admin.

Cómo funcionan las rutas de ataque en Active Directory

El análisis de rutas de ataque trata Active Directory como un grafo dirigido:

• Nodos = usuarios, equipos, grupos, GPOs, OUs, dominios
• Aristas = relaciones que pueden abusarse (MemberOf, GenericAll, WriteDACL, GpLink, etc.)

Herramientas como BloodHound (open source) recopilan estos datos de grafo y usan Neo4j para encontrar los caminos más cortos entre dos nodos cualesquiera. Un atacante que ejecuta BloodHound desde una cuenta de usuario estándar comprometida puede visualizar todo el camino hasta Domain Admin en minutos — a menudo encontrando rutas que tardaron años de mala configuración acumulada en crearse.

Categorías de rutas comunes

La cadena de ataque

Paso 1 - Recopilar datos del grafo de AD

# Desde Linux con credenciales válidas — recolector de BloodHound CE (pip install bloodhound-ce)
bloodhound-ce-python -u [email protected] -p password -ns 10.10.0.1 -d corp.local -c All --zip

# bloodhound-python (pip install bloodhound) es el recolector legacy: solo BloodHound 4.2/4.3

# Desde Windows
.\SharpHound.exe -c All --zipfilename corp_bloodhound.zip

Paso 2 - Encontrar los caminos más cortos hacia Domain Admin

En la interfaz de BloodHound o en el navegador Neo4j:

// Camino más corto desde cualquier usuario hasta Domain Admins
MATCH p=shortestPath((u:User {enabled:true})-[*1..]->(g:Group {name:"DOMAIN [email protected]"}))
RETURN p ORDER BY length(p) ASC LIMIT 10

// Encontrar todos los usuarios kerberoasteables con camino hacia DA
MATCH (u:User {hasspn:true})-[*1..]->(g:Group {name:"DOMAIN [email protected]"})
RETURN u.name, u.pwdlastset

// Encontrar rutas de derechos de edición de GPO hacia DCs
MATCH p=(u:User)-[:GenericAll|GenericWrite|Owns|WriteDacl|WriteOwner*1..]->(g:GPO)-[:GPLink]->(c:OU)
WHERE c.blocksinheritance = false
RETURN p

Paso 3 - Seguir el camino más corto

Una ruta real típica:

1. El atacante compromete a jsmith (usuario estándar) mediante phishing
2. jsmith tiene GenericWrite sobre svc_deploy (resto de un proyecto anterior)
3. svc_deploy es kerberoasteable con una contraseña de 3 años de antigüedad
4. El atacante escribe un SPN en svc_deploy vía GenericWrite y crackea el ticket de servicio resultante (Kerberoasting dirigido), o escribe msDS-KeyCredentialLink para Shadow Credentials — GenericWrite por sí solo no permite restablecer la contraseña, lo cual requiere ForceChangePassword o GenericAll
5. svc_deploy es miembro del grupo IT_Admins
6. IT_Admins está anidado dentro de Domain Admins
7. Compromiso total del dominio — 3 saltos de grafo, ningún exploit

Paso 4 - Mantener persistencia

Una vez alcanzado el acceso DA, el atacante establece persistencia mediante Golden Ticket, nuevas cuentas backdoor, o backdoors de certificados ADCS — asegurando que sobrevivan a restablecimientos de contraseña e intentos de remediación.

Detección

Detectar el recorrido de una ruta de ataque requiere monitorizar cada salto individual — ningún registro único revela el camino completo.

Event IDs de Windows

Consulta de correlación SIEM

KQL solo filtra documentos — no puede agregar — así que la correlación en sí se expresa en ES|QL:

// Detectar eventos rápidos y secuenciales de escalada de privilegios desde el mismo origen
FROM logs-*
| WHERE event.code IN ("4769", "4724", "4728", "5136")
    AND @timestamp > NOW() - 1 hour
| STATS event_count = COUNT(*) BY winlog.event_data.SubjectUserName
| WHERE event_count > 3

Remediation

1. Eliminar primero los caminos más cortos

Ejecute BloodHound y exporte los 10 caminos más cortos hacia Domain Admin. Para cada camino:

• Arista ACL: elimine la ACE peligrosa del objeto
• Arista de anidamiento de grupos: retire el grupo del grupo privilegiado
• Arista kerberoasteable: rote la contraseña o migre a gMSA
• Arista GPO: retire los derechos de edición de la cuenta no administrativa

2. Implementar monitorización continua de rutas de ataque

# Recopilación semanal de BloodHound mediante tarea programada
# SharpHound es un ejecutable nativo: pase los flags explícitamente (el splatting de hash-table solo
# se vincula a cmdlets de PowerShell, no a un .exe)
.\SharpHound.exe -c All `
    --outputdirectory "C:\BloodHound\Collections\" `
    --zipfilename "weekly_$(Get-Date -Format yyyyMMdd).zip"
# Comparar con los datos de la semana anterior y alertar sobre nuevas rutas DA

3. Priorizar cuentas kerberoasteables en la ruta DA

# Encontrar todas las cuentas kerberoasteables con cualquier camino hacia privilegios DA
# -Filter espera una cadena de texto; krbtgt tiene un SPN pero no es roasteable en la práctica
Get-ADUser -Filter 'ServicePrincipalName -like "*"' -Properties MemberOf, PasswordLastSet |
    Where-Object { $_.SamAccountName -ne "krbtgt" } |
    Where-Object {
        $_.MemberOf | Get-ADGroup | Where-Object { $_.Name -match "Admin" }
    } | Select-Object SamAccountName, PasswordLastSet
# Migrar estas cuentas a gMSA de inmediato

Cómo lo detecta EtcSec

EtcSec realiza análisis continuo de rutas de ataque en todo su grafo de Active Directory, identificando todas las rutas desde cuentas con pocos privilegios hasta Domain Admin.

PATH_ACL_TO_DA mapea cada ruta basada en ACL desde usuarios estándar hasta Domain Admin, incluidas cadenas de múltiples saltos a través de objetos intermedios.

PATH_GPO_TO_DA identifica rutas donde los derechos de edición de GPO sobre políticas vinculadas a OUs de Tier 0 proporcionan una ruta indirecta hacia el compromiso del controlador de dominio.

PATH_KERBEROASTING_TO_DA señala cuentas de servicio kerberoasteables que tienen — directa o transitivamente — privilegios de Domain Admin, representando la ruta de ataque de alto impacto más común en entornos reales.

Prioridades de revisión

Las rutas de ataque de Active Directory hacia Domain Admin deben tratarse como una exposición real dentro de su entorno de Active Directory, no como un ajuste aislado. Empiece por definir el perímetro de revisión: qué grupos privilegiados, cuentas de servicio, ACLs, vínculos de GPO, trusts, configuraciones de delegación, plantillas de certificados y estaciones de administración están afectados, qué flujos de trabajo de negocio dependen de ellos, qué privilegios exponen, y qué excepciones de emergencia se añadieron con el tiempo. Ese paso de alcance evita una remediación superficial, porque el síntoma técnico suele ser más pequeño que el radio de impacto operativo. Al documentar el camino completo desde la configuración hasta el privilegio, el equipo puede priorizar cambios que reduzcan el riesgo rápidamente sin romper el acceso de producción. Esto también crea una base defendible para validaciones posteriores y le da a la dirección una explicación clara de por qué el problema importa ahora.

Controles adyacentes a revisar

Cuando los atacantes llegan a su entorno de Active Directory, rara vez se detienen en el primer punto débil. Alrededor de las rutas de ataque de Active Directory hacia Domain Admin, normalmente prueban si la ruta expuesta puede encadenarse con cuentas privilegiadas obsoletas, anidamiento inseguro de grupos, delegación excesiva, políticas de contraseña débiles, rutas de GPO escribibles y abuso de ACL heredadas. Eso significa que los defensores deben revisar no solo la debilidad principal, sino también cada dependencia cercana que convierte el acceso en persistencia o escalada de privilegios. Confirme qué identidades, roles, permisos y suposiciones de confianza pueden ser reutilizados por un operador motivado. Si una corrección cierra solo un objeto mientras deja intactas rutas de privilegio adyacentes, el riesgo efectivo apenas cambia. Una revisión disciplinada de las oportunidades de encadenamiento es lo que convierte este tema en un ejercicio práctico de hardening en lugar de una simple casilla marcada una sola vez.

Evidencia y telemetría a recopilar

Una respuesta sólida a las rutas de ataque de Active Directory hacia Domain Admin necesita evidencia que puedan revisar tanto los equipos de ingeniería como los de detección. Recopile los Event IDs 4624, 4662, 4670, 4688, 4728, 4732, 4768, 4769, 5136, cambios de SYSVOL y actividad de certificados o de la CA, compare los cambios recientes con las ventanas de mantenimiento conocidas, y aísle las cuentas o sistemas que cambiaron de comportamiento sin una razón de negocio clara. Use esa evidencia para responder tres preguntas: cuándo apareció la ruta de riesgo, quién todavía puede usarla, y si existe una exposición similar en otro lugar de su entorno de Active Directory. Una buena revisión de telemetría también ayuda a separar la deuda técnica heredada del uso indebido activo. Esa distinción importa, porque el plan de remediación para una mala configuración antigua es distinto del plan para una ruta que ya muestra actividad similar a la de un atacante o excepciones de política repetidas.

Debilidades adyacentes que merece la pena revisar

Muy pocos entornos contienen únicamente rutas de ataque de Active Directory hacia Domain Admin. En la práctica, el mismo segmento de tenant o de directorio suele contener también cuentas privilegiadas obsoletas, anidamiento inseguro de grupos, delegación excesiva, políticas de contraseña débiles, rutas de GPO escribibles y abuso de ACL heredadas, y esas debilidades vecinas deciden si el problema es simplemente ruidoso o realmente crítico. Revise propietarios compartidos, permisos heredados, excepciones duplicadas y atajos administrativos de larga duración. Compruebe si el mismo equipo aprobó patrones de riesgo similares en varios lugares, porque las decisiones repetidas suelen señalar un vacío de proceso más que un único error técnico. Esta revisión más amplia evita una limpieza parcial y le da mejores probabilidades de eliminar toda la ruta de ataque. También mejora la preparación para auditorías, porque el estado final es más fácil de explicar y de monitorizar con el tiempo.

Lecturas relacionadas

Revise este tema junto con Abuso de ACL y DCSync: las rutas silenciosas hacia Domain Admin, Anidamiento peligroso de grupos: rutas ocultas hacia Domain Admin, Ataques de trust en Active Directory: del dominio hijo a la raíz del bosque, Malas configuraciones de GPO: cómo Group Policy se convierte en vector de ataque, y Monitorización de Active Directory: los Event IDs de seguridad que importan. Esos artículos relacionados muestran cómo las mismas debilidades de identidad suelen encadenarse en una evaluación real en lugar de aparecer como hallazgos aislados.

• Abuso de ACL y DCSync: las rutas silenciosas hacia Domain Admin
• Anidamiento peligroso de grupos: rutas ocultas hacia Domain Admin
• Ataques de trust en Active Directory: del dominio hijo a la raíz del bosque
• Malas configuraciones de GPO: cómo Group Policy se convierte en vector de ataque
• Monitorización de Active Directory: los Event IDs de seguridad que importan

Usar esas referencias mantiene la discusión de remediación centrada en la ruta de ataque completa en lugar de en una sola brecha de control.

Lista de validación

Antes de cerrar la revisión, vuelva a ejecutar las mismas comprobaciones que expusieron el problema y confirme que la ruta de riesgo ya no existe desde la perspectiva del atacante. Verifique las identidades, privilegios, rutas de herencia y controles compensatorios relevantes en producción, no solo en staging o en la documentación. Registre el propietario técnico, la dependencia de negocio esperada, y la evidencia que muestra que la nueva configuración es tanto más segura como operativamente sostenible. Ese paso final de validación es lo que mantiene el artículo anclado en cómo los equipos realmente reducen el riesgo de identidad.