Ataques de confianza AD: dominio hijo a raiz

Que son los ataques de confianza AD?

Los ataques de confianza AD explotan la forma en que Active Directory permite autenticacion y autorizacion entre dominios relacionados. El error de base es pensar que cada dominio del bosque es una frontera de seguridad independiente. Microsoft lleva tiempo recordando que la frontera de seguridad real es el bosque, no el child domain. En otras palabras: si un atacante obtiene control fuerte sobre un dominio hijo, la conversacion debe pasar inmediatamente de "problema local" a riesgo para todo el bosque.

Eso no significa que cualquier trust equivalga automaticamente a Domain Admin en todas partes. Significa algo mas util para un equipo tecnico: si el child domain conserva admins permanentes, estaciones administrativas mezcladas, rutas de replica excesivas o sessions de Tier 0 mal ubicadas, la confianza entre dominios deja de ser una comodidad operativa y pasa a ser un acelerador de escalada.

Ataques de confianza AD: donde suele empezar el problema

Hay tres familias de riesgo que conviene separar.

Familia	Riesgo principal	Lo que debe revisar
Child-parent dentro del bosque	un child domain comprometido se usa como base para llegar al root	admins compartidos, sesiones privilegiadas, replica, proteccion de `krbtgt`
Trusts externos o con terceros	SID filtering y selective authentication mal definidos	`SIDFilteringQuarantined`, cuarentena, autenticacion selectiva
Dependencias administrativas cruzadas	el trust no es el fallo, sino las rutas de admin que lo atraviesan	grupos delegados, RDP, servicios, GPO, cuentas de soporte

Los equipos se centran a menudo en el objeto trust y pasan por alto las dependencias reales: quien administra que, desde donde inicia sesion, que grupos tienen privilegios en varios dominios y donde aparecen identidades privilegiadas fuera de su zona.

Como se convierte en una ruta de ataque

Paso 1 - El atacante compromete un child domain

El punto de entrada puede ser una cuenta de servicio, una mala ACL, un GPO, Kerberoasting o una workstation administrativa expuesta. Una vez que el atacante alcanza privilegio equivalente a Domain Admin en el child domain, el riesgo cambia de escala.

Paso 2 - Enumera relaciones de confianza y dependencias entre dominios

El inventario minimo incluye trusts, grupos privilegiados, sesiones administrativas y derechos de replica.

Get-ADTrust -Filter * |
  Select-Object Name,Source,Target,Direction,TrustType,SIDFilteringQuarantined,SelectiveAuthentication

Get-ADForest | Select-Object RootDomain,Domains,GlobalCatalogs

Tambien conviene revisar que identidades del child domain aparecen administrando sistemas, grupos o servicios del root domain y viceversa.

Paso 3 - Busca un camino inter-dominio reutilizable

Los caminos tipicos no son teoricos. Suelen ser alguno de estos:

administradores del child domain con sesiones en servidores del root
grupos o ACLs cruzadas que sobreviven por conveniencia historica
derechos de replica o acceso a controladores de dominio fuera de la zona prevista
confianza externa sin cuarentena adecuada
usos indebidos de sidHistory o tickets con SIDs adicionales para ampliar autorizacion a traves del trust

Paso 4 - Consolida la escalada hacia el bosque

Una vez que el atacante encuentra una ruta valida, el trust deja de ser un objeto de directorio y se convierte en un problema de movimiento administrativo. La remediacion, por tanto, no se resuelve solo en el trust: hay que corregir sesiones, privilegios, replicas y flujos de admin que cruzan dominios.

Que debe auditar primero

1. El inventario real de trusts

Documente todos los trusts y separe claramente:

parent-child dentro del bosque
tree-root
forest trusts
trusts externos

En trusts externos, compruebe si SIDFilteringQuarantined y SelectiveAuthentication estan alineados con el modelo de acceso. En trusts dentro del bosque, no se conforme con decir "es normal". Pregunte que admins, sessions y derechos hacen que un child compromise escale facilmente al root.

2. Las identidades con privilegio cruzado

Busque admins, grupos delegados, cuentas de soporte y cuentas de servicio que aparezcan con privilegios en mas de un dominio. La mayor parte de las escaladas reales a traves de trusts se explican por dependencias administrativas cruzadas, no por magia del protocolo.

3. Los caminos a `krbtgt` y a replica

Si un child domain expone replica o material sensible de autenticacion, ese dominio deja de ser una unidad administrable y pasa a ser una plataforma de ataque. Revise con especial cuidado quienes tienen privilegios equivalentes a DCSync y donde se usan identidades capaces de tocar controladores de dominio.

4. La proteccion de las estaciones y sesiones administrativas

Si los administradores del root usan equipos menos protegidos o inician sesion en sistemas administrados por el child domain, el trust hereda ese riesgo. Esta es la razon por la que un review serio de trusts siempre termina revisando admin tiers, PAWs, jump hosts y session exposure.

Deteccion y telemetria util

No existe un solo evento que grite "trust attack". Necesita correlacionar cambios de directorio, uso de privilegios y logons entre dominios.

Que merece vigilancia

cambios en objetos trust y en configuracion de cuarentena o selective authentication
cambios de sidHistory
actividad privilegiada del child domain contra recursos del root domain
asignacion de miembros a grupos de alto privilegio en dominios vecinos
nuevos derechos de replica o cambios de ACL sobre objetos sensibles

Senales operativas

5136 para cambios de directorio en objetos relevantes
4728 / 4732 para altas en grupos privilegiados
4768 / 4769 para patrones de autenticacion Kerberos entre dominios que no encajan con la operacion normal
4662 cuando se quiere vigilar acceso a replicacion o a objetos especialmente sensibles

Remediacion

1. Trate el child domain compromise como incidente de bosque

El paso mas importante no es tecnico sino de criterio. Cuando un child domain cae, el equipo debe asumir riesgo para el bosque completo hasta demostrar lo contrario. Esa postura cambia la prioridad de las sesiones, de la rotacion de secretos y de los controles de contencion.

2. Reduzca dependencias administrativas cruzadas

Quite admins permanentes compartidos, cierre RDP cruzado innecesario, retire grupos delegados que administran dominios vecinos y limite donde pueden iniciar sesion las identidades de Tier 0. Si el trust sigue existiendo pero la ruta administrativa desaparece, el riesgo operativo baja mucho.

3. Endurezca trusts externos y de terceros

Donde haya trusts externos, revise SIDFilteringQuarantined, selective authentication y cualquier excepcion historica. Si no puede explicar por que un trust externo necesita una configuracion permisiva, el baseline correcto es restringirlo.

4. Proteja replica, `krbtgt` y controladores de dominio

Quien puede replicar o tocar DCs tiene capacidad para alterar el equilibrio del trust. Revise rutas a DCSync, cuentas de backup, herramientas heredadas y cualquier identidad que mantenga privilegios equivalentes por costumbre.

5. Separe administracion de root y child domains

No mezcle estaciones administrativas, cuentas de soporte ni credenciales de alto valor entre dominios con distinto nivel de confianza. La forma mas rapida de convertir un trust en problema de bosque es reutilizar las mismas identidades y los mismos endpoints de administracion.

Validacion tecnica despues del cambio

confirme que los trusts externos siguen funcionando con las restricciones esperadas
verifique que admins del child ya no tienen rutas triviales a recursos Tier 0 del root
revise que no quedan sesiones administrativas del root en sistemas administrados por dominios menos confiables
repita el inventario de trusts, grupos, replica y sesiones para demostrar que el camino se corto de verdad
documente que grupos, hosts y cuentas siguen siendo dependencias legitimas entre dominios y cuales se retiraron

Remediation y siguientes pasos

Una remediacion util de ataques de confianza AD empieza por tratar el compromiso de un dominio hijo como un incidente de bosque, no como un problema local del equipo que administra ese child domain. Eso cambia el orden de trabajo: primero se contienen sesiones y privilegios cruzados, despues se revisan replica y krbtgt, y solo al final se decide que ajustes del trust siguen siendo necesarios por razones operativas. Si se hace al reves, el trust puede quedar "mas bonito" en el inventario mientras la ruta administrativa peligrosa sigue abierta.

Tambien conviene separar claramente dos escenarios. En trusts externos, la prioridad es justificar cada excepcion en SIDFilteringQuarantined y SelectiveAuthentication. En relaciones parent-child dentro del bosque, la prioridad real suele ser otra: cuentas admin compartidas, estaciones de administracion reutilizadas, grupos delegados entre dominios y derechos de replica mal controlados. En ambos casos, el criterio correcto es el mismo: reducir las dependencias inter-dominio a las estrictamente necesarias y documentar quien las aprueba.

Validacion del bosque tras el cambio

Tras un cambio sobre trusts, no basta con releer el objeto trust. El equipo debe demostrar que el child domain ya no ofrece rutas faciles hacia Tier 0 del root, que no quedan sesiones administrativas del root en hosts controlados por el child, y que las identidades con privilegio cruzado se han reducido o documentado como excepciones temporales. Esa validacion es la unica forma de convertir una correccion de configuracion en una reduccion real del riesgo del bosque.

Que no debe asumir su equipo

Un trust sano no compensa una administracion insegura. Tampoco basta con revisar el atributo del trust una vez al anio. Los ataques de confianza AD se vuelven criticos cuando la realidad operativa contradice el dibujo formal del bosque: admins del root entrando en hosts del child, cuentas de servicio con privilegios laterales, replicas concedidas por costumbre y grupos delegados que nadie puede justificar ya.

En equipos maduros, el review de trusts se parece mas a un review de rutas administrativas que a una simple inspeccion de objetos de directorio. Esa es la diferencia entre un inventario bonito y una reduccion real del riesgo.

Referencias primarias

Microsoft Learn: Security boundaries and Active Directory forests
Microsoft Open Specifications: MS-PAC, SID Filtering and Claims Transformation
Microsoft Learn: Get-ADTrust
Microsoft Learn: Using DsAddSidHistory

Lecturas relacionadas

Lea este articulo junto con el inventario de admins, sessions y derechos de replica. En ataques de confianza AD, el trust visible rara vez es el unico problema; casi siempre lo decisivo es la ruta administrativa que lo atraviesa.