Fondamentaux des relations d'approbation Active Directory

Concept

Une relation d’approbation (Trust Relationship) est une liaison logique et cryptographique établie entre deux domaines Windows (ou entre une forêt Windows et un royaume Kerberos/MIT).

Elle repose sur deux piliers techniques :

L’objet TDO (trusted domain object) : un objet Active Directory de classe trustedDomain stocké dans la partition de domaine (CN=System,DC=domain,DC=local), décrivant les attributs de la confiance (nom de domaine distant, SID distant, direction, transitivité, drapeaux de sécurité).
Le secret partagé (trust secret) : un mot de passe partagé symétrique (défini lors de la création de la confiance et renouvelé périodiquement par le rôle PDC Emulator) matérialisé par un compte d’ordinateur inter-domaine (Inter-Domain Trust Account).

Pourquoi c’est important en DFIR

Dans une attaque ciblant des environnements multi-domaines :

Vecteur de mouvement latéral inter-domaines : l’attaquant qui compromet un DC du domaine A peut extraire le secret de confiance partagé et forger des tickets Kerberos inter-domaines pour accéder aux ressources du domaine B.
Persistance furtive (trust key persistence) : si l’attaquant modifie ou extrait le mot de passe du compte de confiance, la réinitialisation du compte krbtgt local ne révoquera pas les tickets inter-domaines forgés avec la clé de confiance.
Traçabilité des authentifications distantes : lors d’un accès inter-domaine, le KDC local n’émet pas de TGS directement pour le service cible, mais pour le compte krbtgt du domaine distant (Referral TGT). Savoir repérer ces demandes dans les événements 4769 est essentiel pour reconstituer la trajectoire de l’attaquant.

Comment ça fonctionne

Le mécanisme du secret de confiance

Lorsqu’une relation d’approbation bidirectionnelle est établie entre le Domaine A (CORP) et le Domaine B (DEV) :

Deux comptes d’approbation sont créés :
- Dans le domaine A : compte DEV$ (type TRUST_ACCOUNT, UserAccountControl 0x800 / SERVER_TRUST_ACCOUNT).
- Dans le domaine B : compte CORP$.
Ces comptes possèdent un mot de passe symétrique identique généré aléatoirement.
Lorsque l’utilisateur alice@DEV veut accéder à cifs/fileserver.CORP :
- Alice demande un TGS à son KDC (DEV).
- Le KDC DEV constate que la ressource appartient à CORP.
- Le KDC DEV chiffre un TGT spécial (nommé Inter-Realm TGT) avec le mot de passe partagé de la relation de confiance (CORP$).
- Alice présente cet Inter-Realm TGT au KDC de CORP.
- Le KDC de CORP déchiffre le ticket avec son propre compte DEV$, valide l’authenticité de l’identité, applique les filtres de sécurité (SID Filtering), et lui délivre le TGS final pour fileserver.CORP.

[Alice@DEV]
    │ 1. Demande TGS pour fileserver.CORP
    ▼
[KDC DEV] ──── Chiffre Inter-Realm TGT avec la Clé de Confiance (DEV$ / CORP$)
    │
    ▼ 2. Présente Inter-Realm TGT
[KDC CORP] ─── Déchiffre avec Clé de Confiance, valide SIDs & émet TGS
    │
    ▼ 3. Présente TGS
[fileserver.CORP] ─── Accès autorisé selon DACL locale

Ce qui est possible

Extraire les secrets de confiance depuis la base NTDS : un attaquant disposant des privilèges Domain Admins sur un DC peut exécuter secretsdump ou mimikatz lsadump::trust pour extraire les clés NTLM et AES des comptes de confiance inter-domaines.
Forger un golden ticket inter-domaine : avec le hash NTLM ou la clé AES du compte de confiance, un attaquant peut créer un TGT inter-domaine forgé en injectant des SIDs arbitraires (soumis aux restrictions de SID Filtering).
Valider l’état cryptographique d’une confiance : l’administrateur ou l’enquêteur peut vérifier la synchronisation du secret via netdom trust <Domain> /verify.

Ce qui n’est pas possible

Traverser une confiance sans connectivité réseau entre KDC : bien que l’utilisateur n’ait besoin que de contacter son propre KDC puis le KDC distant, les mécanismes d’authentification NTLM pass-through exigent quant à eux une communication directe RPC entre les DC des deux domaines.
Utiliser le hash krbtgt local pour accéder au domaine distant : le hash du compte krbtgt local ne chiffre que les TGT intra-domaine. Pour franchir la frontière de confiance, c’est impérativement la clé de compte de confiance qui est requise.
Maintenir la confiance si le mot de passe est désynchronisé : si le secret partagé est corrompu ou modifié unilatéralement, toute authentification inter-domaine échoue immédiatement avec l’erreur STATUS_TRUST_FAILURE (0xC000018B).

Confusions fréquentes en DFIR

Confusion fréquente	Réalité forensique vérifiable
« Nous avons réinitialisé le compte krbtgt deux fois, l’attaquant ne peut plus forger de tickets. »	La double réinitialisation de `krbtgt` ne réinitialise pas les clés de confiance inter-domaines. L’attaquant qui possède la clé de confiance peut toujours forger des Inter-Realm TGTs.
« Une relation d’approbation accorde automatiquement des droits d’administration. »	L’approbation n’accorde que la capacité de prouver son identité. Les droits dépendent des DACLs locales (sauf `Enterprise Admins` intra-forêt).
« Les approbations apparaissent dans les logs réseau comme des flux VPN. »	Les approbations empruntent les ports Active Directory ordinaires : Kerberos (88/tcp), LDAP (389/tcp), SMB (445/tcp), RPC Endpoint Mapper (135/tcp) et ports RPC dynamiques (49152-65535).

Exemple concret d’investigation

Dans une infrastructure bancaire, le domaine des agences (branch.bank.local) est relié au domaine central (hq.bank.local) par une approbation externe bidirectionnelle.

L’attaquant prend le contrôle d’un DC d’agence.
Il exécute Mimikatz : lsadump::trust /patch et extrait la clé RC4 du compte de confiance HQ$.
L’attaquant forge un ticket inter-domaine avec la clé de confiance pour cibler un serveur financier dans hq.bank.local.
Traces détectées : sur le DC central de HQ, l’Event ID 4769 enregistre une demande de TGS avec ServiceName: krbtgt/HQ.BANK.LOCAL émise par un compte n’existant pas dans l’annuaire de HQ mais validé via le compte d’approbation BRANCH$.

Artefacts et traces forensiques

Active Directory database (ntds.dit) :
- Objets trustedDomain : attribut trustPartner, trustDirection, trustType, trustAttributes.
- Comptes de confiance : sAMAccountType = 0x30000002 (TRUST_ACCOUNT).
Registre Windows (LSA secrets) :
- Clés sous HKLM\SECURITY\Policy\Secrets\G\$\${GUID} contenant les secrets d’approbation mis en cache.
Journaux d’événements Windows :
- Event ID 4769 (DC) : demande de ticket avec ServiceName égal au nom du domaine distant ou au compte krbtgt distant.
- Event ID 4624 (serveur cible) : connexion réseau type 3 où Workstation Name et TargetDomainName reflètent le domaine distant.
- Event ID 4625 (DC) : échecs avec status 0xC000018B (STATUS_TRUST_FAILURE) ou 0xC0000064 (STATUS_NO_SUCH_USER).

Méthodes d’investigation

Lister et caractériser toutes les approbations actives : Exécuter Get-ADTrust -Filter * | Format-List Name, Direction, TrustType, IntraForest, Target.
Vérifier l’historique de modification des objets TDO : Auditer la date de dernière modification (whenChanged) des objets dans CN=System,DC=domain,DC=local pour repérer toute création clandestine de relation de confiance par l’adversaire.
Auditer les comptes d’ordinateur de type trust : Identifier les comptes dont le nom se termine par $ et ayant le flag SERVER_TRUST_ACCOUNT activé dans l’attribut userAccountControl.

Outils d’investigation

Nltest & netdom :

nltest /domain_trusts
netdom trust <LocalDomain> /Domain:<RemoteDomain> /verify

PowerView :
Fenêtre de terminal
```
Get-DomainTrust
Get-DomainTrustMapping
```
BloodHound : Cartographie visuelle de tous les liens de confiance (Trusts) et des chemins d’attaque inter-domaines.

Points clés à retenir

Une relation d’approbation repose sur un secret symétrique partagé entre deux domaines.
La compromission d’un DC permet d’extraire les clés de confiance et de forger des tickets inter-domaines.
La remédiation post-incident exige la réinitialisation des mots de passe des comptes de confiance en plus de krbtgt.