Forêts, arbres et domaines : qui fait confiance à qui et pourquoi ?

Concept

Au sein d’une forêt Active Directory, les relations de confiance ne sont pas configurées manuellement au cas par cas : elles sont automatiquement établies, bidirectionnelles et transitives dès la création d’un sous-domaine ou d’un nouvel arbre dans la forêt :

Approbation parent-enfant (parent-child trust) : créée automatiquement entre un domaine parent et son domaine enfant direct.
Approbation racine d’arbre (tree-root trust) : créée automatiquement entre le domaine racine de la forêt et la racine d’un nouvel arbre de domaines au sein de la même forêt.
Transitivité automatique : si le domaine A fait confiance au domaine B, et que le domaine B fait confiance au domaine C, alors le domaine A fait automatiquement et implicitement confiance au domaine C.

Pourquoi c’est important en DFIR

L’architecture de confiance dicte comment un attaquant peut pivoter entre plusieurs domaines :

Chemins d’attaque implicites : les attaquants n’ont pas besoin de forcer de nouvelles approbations. Dès qu’un pied est posé dans un domaine secondaire, les flux RPC (SMB 445, Kerberos 88, LDAP 389) sont autorisés vers les DC des autres domaines pour négocier des referrals Kerberos.
Confusion fréquente sur la direction de confiance : en réponse à incident, de nombreux analystes inversent la portée d’une confiance. Si Finance.corp fait confiance à Usine.corp, c’est un compte de l’Usine qui peut accéder aux serveurs de la Finance, et non l’inverse !
Périmètre des comptes à privilèges universels : le groupe Enterprise Admins n’existe physiquement que dans le domaine racine de la forêt, mais par défaut, il est automatiquement membre du groupe Administrators (RID 544) de chaque domaine de la forêt.

Comment ça fonctionne

Topologie des flux de confiance intra-forêt

                       ┌────────────────────────────┐
                       │    Domaine Racine Forêt    │
                       │        corp.local          │
                       │  (Contient Enterprise Adm) │
                       └─────────────┬──────────────┘
                                     │
           ▲                         │ Bidirectionnelle      ▲
           │ Flux d'authentif.       │ Transitive            │ Flux d'authentif.
           │                         ▼                       │
    ┌──────┴──────────────┐                   ┌──────────────┴──────┐
    │    Domaine Enfant   │                   │    Domaine Enfant   │
    │   emea.corp.local   │◄─────────────────►│   apac.corp.local   │
    └─────────────────────┘   Transitivité    └─────────────────────┘
                               Implicite

La transitivité intra-forêt : un utilisateur de apac.corp.local voulant accéder à un serveur de fichiers situé dans emea.corp.local n’a pas besoin d’approbation directe : le DC d’APAC génère un referral vers le DC racine, qui génère un referral vers le DC d’EMEA.
Les comptes de confiance inter-domaines (Trust Accounts) : chaque relation d’approbation est matérialisée dans la base ntds.dit par un compte d’ordinateur spécial se terminant par un dollar (ex: EMEA$ dans le domaine racine, et CORP$ dans le domaine EMEA). Le mot de passe de ce compte est partagé entre les DC des deux domaines et renouvelé automatiquement tous les 30 jours.

Ce qui est possible

Traverser toute la forêt via des tickets inter-domaines : un utilisateur légitime ou un attaquant peut obtenir un Service Ticket (TGS) pour une ressource située dans n’importe quel domaine de la forêt.
Accéder aux machines de tous les domaines avec Enterprise Admins : les membres du groupe Enterprise Admins sont administrateurs locaux de chaque machine et de chaque DC de l’ensemble de la forêt.
Exploiter la non-application du SID filtering par défaut : au sein d’une même forêt, les DC font implicitement confiance aux SIDs déclarés dans le champ sIDHistory des tickets émis par les autres DC de la forêt.

Ce qui n’est pas possible

Rupture de transitivité au sein d’une forêt : il n’est pas possible de désactiver la transitivité entre deux domaines d’une même forêt sans rompre l’appartenance à la forêt.
Existence du groupe Enterprise Admins dans un sous-domaine : ce groupe n’existe que dans le domaine racine (S-1-5-21-ROOT-519). Un sous-domaine ne possède qu’un groupe Domain Admins.
Accès automatique sans autorisation (DACL) : la relation de confiance permet l’authentification inter-domaine. Elle n’accorde aucune autorisation par défaut sur les partages ou fichiers, sauf si des permissions ont été explicitement configurées ou héritées par des groupes privilégiés.

Confusions fréquentes en DFIR

Confusion fréquente	Réalité forensique vérifiable
« La confiance va du domaine A vers le domaine B, donc A contrôle B. »	Inversion classique : Si A fait confiance à B, c’est B qui a la possibilité d’accéder aux ressources de A.
« Les comptes du domaine parent ont automatiquement accès à toutes les données des enfants. »	Seuls les groupes explicitement imbriqués (comme `Enterprise Admins`) ont des droits. Un utilisateur standard du domaine parent n’a aucun accès dans l’enfant sans DACL explicite.
« Les approbations externes sont identiques aux approbations de forêt. »	Une approbation externe (External Trust) est non transitive par défaut et applique le SID Filtering.

Exemple concret d’investigation

Un attaquant a compromis le serveur d’administration d’un domaine enfant dev.corp.local.

L’attaquant souhaite atteindre un serveur hébergeant du code source confidentiel situé dans prod.corp.local.
Il utilise BloodHound pour tracer le chemin d’authentification : dev.corp.local $ ightarrow$ corp.local (racine) $ ightarrow$ prod.corp.local.
Il découvre qu’un groupe du domaine dev.corp.local (DEV-Engineers) a été ajouté dans les administrateurs locaux du serveur de build de production dans prod.corp.local.
L’attaquant usurpe un membre de ce groupe et saute directement de DEV à PROD via le protocole Kerberos referral, sans jamais avoir besoin des droits de Domain Admin sur la racine.

Artefacts et traces forensiques

Active Directory trust objects :
- Objets de classe trustedDomain situés dans CN=System,DC=domain,DC=local.
- Attributs cruciaux : trustDirection (1=Inbound, 2=Outbound, 3=Bidirectional), trustType (2=Upx / Active Directory), trustAttributes (ex: TRUST_ATTRIBUTE_WITHIN_FOREST = 0x20).
Journaux d’événements de sécurité (DC source et cible) :
- Event ID 4769 (Kerberos ticket-granting service) : demande de TGS pour le compte de confiance inter-domaine (ex: Service Name = krbtgt/CORP.LOCAL).
- Event ID 4624 (logon type 3) : sur le serveur de destination, avec LogonProcessName = Kerberos ou NtLmSsp, indiquant le domaine d’origine dans TargetDomainName.

Méthodes d’investigation

Énumérer toutes les relations de confiance du domaine analysé : Utiliser nltest /domain_trusts /v ou PowerShell Get-ADTrust -Filter *.
Identifier les comptes de confiance : Vérifier la présence et la date de modification des comptes d’ordinateur inter-domaines (Get-ADComputer -Filter 'OperatingSystem -like "*Trust*"' ou nom se terminant par $).
Cartographier les groupes globaux imbriqués dans d’autres domaines : Identifier quels utilisateurs d’un domaine tiers ont reçu des droits sur les serveurs locaux via des groupes locaux de domaine.

Outils d’investigation

Nltest & netdom :

nltest /domain_trusts /v
netdom trust <DomainLocal> /Domain:<DomainDistant> /verify

PowerShell AD module :

Get-ADTrust -Filter * | Select-Object Name, Direction, TrustType, IntraForest, SIDFilteringForestAware

Points clés à retenir

Le sens de la confiance est l’inverse du sens de l’accès : Domaine de ressources $ ightarrow$ fait confiance $ ightarrow$ Domaine de comptes.
Les approbations intra-forêt sont toutes bidirectionnelles et transitives par conception.
L’existence d’une confiance permet de s’authentifier, mais les autorisations dépendent des DACLs locales et de l’imbrication de groupes.