Ataques de confianza AD: del dominio hijo a la raiz del bosque

¿Qué son los ataques de confianza AD?

Los ataques de confianza AD (Active Directory) abusan de las rutas de autenticación y autorización que permiten que un dominio o un bosque acceda a recursos de otro. Los trusts son una parte normal de AD DS. Los trusts padre-hijo dentro de un bosque, los trusts externos, los trusts de acceso directo (shortcut trusts) y los trusts de bosque existen para dar soporte a necesidades de acceso reales. El riesgo es que un trust también extiende el límite de seguridad que los defensores deben entender.

Un trust no significa automáticamente compromiso. El riesgo práctico depende del tipo de trust, la dirección, la transitividad, el comportamiento del SID filtering, la selective authentication, la segmentación administrativa (tiering) y el nivel de compromiso en el dominio de origen. Pero en un bosque multi-dominio, el compromiso de un dominio hijo puede convertirse en un incidente a nivel de bosque si el atacante puede abusar de las rutas de confianza Kerberos, los SIDs privilegiados o el acceso administrativo que cruza el límite.

Una buena revisión empieza con tres preguntas:

• qué trusts existen y quién es su propietario
• qué trusts todavía tienen un requisito de negocio vigente
• si cada trust limita la autorización entre dominios al alcance previsto

Cómo funcionan los trusts de Active Directory

Microsoft documenta que AD DS utiliza relaciones de trust de dominio y de bosque para proporcionar autenticación entre dominios y bosques. Antes de que el acceso a través de un trust sea posible, Windows calcula una ruta de confianza entre el controlador de dominio del recurso y un controlador de dominio del dominio de la cuenta solicitante.

Los trusts pueden ser unidireccionales o bidireccionales. También pueden ser transitivos o no transitivos. En un bosque AD DS on-premises, los nuevos dominios hijo crean automáticamente relaciones de trust bidireccionales y transitivas con el dominio padre. Esa transitividad permite que las solicitudes de autenticación sigan rutas de confianza a través del árbol de dominios cuando los permisos lo permiten.

Ese comportamiento es útil, pero significa que los defensores no deben tratar un dominio hijo como un directorio de bajo impacto. Si un dominio hijo está mal administrado, tiene una confianza excesiva o está comprometido a nivel de controlador de dominio, el bosque debe revisarse como un sistema de seguridad conectado.

Dónde encaja el SID filtering

Los tickets Kerberos incluyen datos de autorización, incluidos los SIDs usados para tomar decisiones de acceso. El SID History existe para escenarios de migración en los que una cuenta debe conservar el acceso a recursos que todavía hacen referencia a un SID antiguo. La documentación de Microsoft sobre DsAddSidHistory señala que añadir SIDs al atributo sIDHistory de un principal de seguridad es una operación sensible desde el punto de vista de la seguridad, y que si un dominio de recursos confía en el dominio de cuentas de un SID robado o no autorizado, el usuario no autorizado puede obtener acceso no autorizado a los recursos de ese SID.

El SID filtering está diseñado para reducir este riesgo en los límites de trust. La especificación PAC de Microsoft describe el comportamiento del SID filtering en los límites de trust, incluidos los trusts de bosque y los trusts externos. El comportamiento exacto depende del límite de trust y de la categoría de SID, por lo que es importante no reducir el tema a un único flag sin entender el tipo de trust.

En los trusts externos, los administradores suelen revisar el estado de quarantine o de SID filtering. En los trusts de bosque, la selective authentication y la configuración del trust de bosque también pueden importar. En los trusts padre-hijo dentro del mismo bosque, el problema más importante suele ser arquitectónico: todos los dominios forman parte del mismo tejido de trust del bosque, por lo que el compromiso de un dominio puede tener consecuencias más allá del dominio local.

Límites de alcance y condiciones previas

Esto no es una afirmación de que cualquier trust de AD sea explotable. El abuso de trust de alto impacto normalmente requiere un requisito previo sólido, como:

• el compromiso de un controlador de dominio o de un secreto equivalente a nivel de dominio en el dominio de origen
• la capacidad de forjar o manipular datos de autorización Kerberos
• una ruta de trust que acepte el contexto de autorización resultante
• recursos objetivo que autorizan el acceso en función de SIDs privilegiados o grupos entre dominios
• una separación débil entre los niveles administrativos (tiers) entre dominios

Por eso la revisión de trusts debe vincularse a las hipótesis de respuesta a incidentes. Si el secreto krbtgt de un dominio hijo o sus controladores de dominio están comprometidos, no trate el incidente como aislado hasta haber revisado las rutas de trust, las sesiones privilegiadas y la autorización entre dominios.

Patrones comunes de abuso de trust

Del dominio hijo al padre o a la raíz del bosque

El escenario de escalada clásico empieza con el compromiso de un dominio hijo. Si el atacante controla el dominio de origen con suficiente profundidad, puede intentar forjar material Kerberos que transporte datos de autorización privilegiados hacia un recurso del dominio padre o de la raíz del bosque. Que esto tenga éxito depende del comportamiento del trust y del filtering, pero la lección defensiva es clara: los dominios hijo requieren una protección de nivel Tier 0 cuando forman parte del mismo bosque.

Trusts externos obsoletos

Los trusts externos antiguos son habituales después de migraciones, integraciones con partners, adquisiciones o proyectos temporales. Un trust obsoleto puede seguir permitiendo rutas de autenticación que nadie gestiona activamente. Aunque el SID filtering esté habilitado, un trust innecesario sigue siendo una superficie de ataque innecesaria.

Propiedad débil del trust

Un trust sin propietario se vuelve difícil de modificar porque nadie puede aprobar su eliminación. Eso genera excepciones permanentes. Cada trust que se mantenga debe tener un propietario de aplicación, un propietario de negocio, una dirección de autenticación, los usuarios esperados y una fecha de revisión.

Administración privilegiada entre límites

Los trusts se vuelven más peligrosos cuando los administradores usan credenciales privilegiadas entre dominios o bosques. Una sesión privilegiada en un dominio con menor gobernanza puede exponer credenciales o tokens que permitan el movimiento hacia un dominio más sensible. El endurecimiento del trust y el endurecimiento del acceso privilegiado deben revisarse juntos.

Detección

Ningún evento de Windows por sí solo demuestra un ataque de trust. La detección requiere inventario de trusts, revisión de eventos Kerberos, contexto de inicio de sesión privilegiado y monitorización de cambios.

Eventos de Windows y fuentes de registro

Los datos de eventos necesitan contexto. Un evento 4769 entre dominios puede ser normal para una aplicación. Un inicio de sesión administrativo entre dominios desde una cuenta inesperada, tras un incidente en un dominio hijo, es muy distinto.

Revisión del inventario de trusts

Inventaríe todos los trusts y clasifíquelos:

Get-ADTrust -Filter * |
  Select-Object Name, TrustType, TrustDirection, ForestTransitive, SelectiveAuthentication, SIDFilteringQuarantined

Use el resultado para la triaje. SIDFilteringQuarantined = False no es automáticamente una prueba de compromiso o de mala configuración, pero debe tener un propietario y una razón. Si nadie puede explicar por qué el trust necesita su configuración actual, pertenece a la cola de limpieza.

Remediation

El trust más seguro es el que ya no existe porque la dependencia de negocio terminó. Endurezca los trusts restantes según su tipo y su propósito.

1. Elimine los trusts obsoletos

Revise primero los trusts antiguos de partners, migración, pruebas y adquisiciones. Si un trust no tiene propietario, ninguna dependencia de aplicación activa y ningún requisito de acceso reciente, elimínelo mediante el proceso normal de cambios.

2. Revise el SID filtering y la quarantine

Para los trusts externos donde sea compatible, habilite la quarantine o el SID filtering y valide los flujos de trabajo dependientes. El comando netdom trust de Microsoft admite la opción /Quarantine para la gestión de trusts, y la documentación del comando señala que No acepta cualquier SID. Esa configuración no debería dejarse al azar histórico.

3. Use la selective authentication donde sea apropiado

Para los trusts de bosque, la selective authentication puede limitar qué usuarios del bosque de confianza pueden autenticarse frente a recursos específicos. No sustituye unas buenas ACLs ni una buena higiene de acceso privilegiado, pero reduce el alcance de autenticación amplio.

4. Trate los dominios hijo como de alta consecuencia

No asuma que un dominio hijo es una zona administrativa de bajo riesgo. Asegure los controladores de dominio hijo, los grupos privilegiados, el manejo de krbtgt y las estaciones de trabajo administrativas con la misma seriedad que la raíz del bosque cuando las rutas de trust permiten el acceso entre dominios.

5. Reduzca las sesiones privilegiadas entre límites

No use de forma rutinaria cuentas privilegiadas de la raíz del bosque o del dominio padre en dominios hijo menos confiables. Si los administradores deben cruzar el límite, use cuentas dedicadas, estaciones de trabajo administrativas controladas y registro que haga visible la sesión.

Qué no cambiar a ciegas

No habilite ni elimine controles de trust sin probar el flujo de autenticación dependiente. El SID filtering, la quarantine y la selective authentication pueden romper patrones de acceso heredados, flujos de trabajo de migración o aplicaciones construidas en torno a un acceso amplio entre dominios. Ese riesgo de compatibilidad no es una razón para dejar el trust inseguro; es una razón para documentar la dependencia, probar en una ventana controlada y sustituir el trust amplio por un acceso explícito cuando sea posible. Si el negocio no puede eliminar de inmediato un trust arriesgado, la excepción debe incluir un propietario, una fecha de fin, un plan de monitorización y controles compensatorios de acceso privilegiado.

Validación tras el endurecimiento del trust

Después de un cambio en un trust, valide tanto la seguridad como la función de negocio:

• vuelva a ejecutar el inventario de trusts y registre la dirección, el tipo, la transitividad, la selective authentication y el estado del SID filtering
• confirme que los equipos de aplicaciones han vuelto a probar los flujos de trabajo que dependen del trust
• verifique que los trusts antiguos de migración o de partners se eliminaron en lugar de solo documentarse
• revise la actividad Kerberos y de inicio de sesión a través del trust después del cambio
• compruebe si los usuarios privilegiados todavía se autentican a través del límite
• documente las excepciones con un propietario, una fecha de caducidad y controles compensatorios

Una revisión de trust solo tiene éxito cuando los trusts restantes son intencionados, tienen propietario, están monitorizados y se limitan al acceso que el negocio todavía necesita.

Cómo lo detecta EtcSec

EtcSec audita las relaciones de trust y destaca las rutas de trust que aumentan la probabilidad de escalada entre dominios.

Los hallazgos relacionados con trusts son más útiles cuando se correlacionan con la ruta de ataque circundante: si un dominio hijo ya tiene una higiene administrativa débil, si todavía existe un trust externo obsoleto y si las identidades de alto valor o los derechos delegados están presentes en ambos lados del límite.

Lecturas relacionadas

Revise la exposición de trusts junto con Rutas de ataque de AD hacia Domain Admin, Anidamiento peligroso de grupos: rutas ocultas hacia Domain Admin, Abuso de ACL y DCSync: las rutas silenciosas hacia Domain Admin, Ataques de delegación Kerberos: de no restringida a abuso de RBCD y Ataque Golden Ticket: las llaves de su reino. El abuso de trust suele ser un multiplicador de rutas, no una mala configuración aislada.

Referencias primarias

• How trust relationships work for forests in Active Directory
• MS-PAC: SID Filtering and Claims Transformation
• Using DsAddSidHistory: sIDHistory security implications
• netdom trust command
• Securing domain controllers against attack
• Planning for compromise in Active Directory