Que peut faire un attaquant qui contrôle le domaine a vis-à-vis du domaine b ?

Concept

Lorsqu’un adversaire atteint le niveau de contrôle maximal sur le Domaine A (possession des hashs krbtgt, des clés de confiance et des comptes de machines DC), ses capacités d’action vis-à-vis du Domaine B s’articulent autour de 4 scénarios d’architecture :

SCÉNARIO 1 : Même Forêt (Intra-Forest)
[ Domaine A ] ──────────► [ Domaine B ]
Résultat : ESCALADE TOTALE & IMMÉDIATE (Via sIDHistory / Enterprise Admins)

SCÉNARIO 2 : Deux Forêts avec Forest Trust + SID Filtering ACTIF
[ Forêt A ]   ──(Filtre)──► [ Forêt B ]
Résultat : PAS D'ESCALADE DIRECTE vers T0. Mouvement latéral conditionné
           par les ACLs existantes, FSP, Kerberoasting ou vol de sessions.

SCÉNARIO 3 : Deux Forêts avec Forest Trust + SID Filtering DÉSACTIVÉ (/EnableSIDHistory:Yes)
[ Forêt A ]   ──(Pass)──► [ Forêt B ]
Résultat : ESCALADE TOTALE vers T0 (sIDHistory accepté par la cible).

SCÉNARIO 4 : External Trust (Non-transitive + SID Filtering ACTIF)
[ Domaine A ] ──(Strict)──► [ Domaine B ]
Résultat : STRICTEMENT LIMITÉ aux ressources du Domaine B autorisées aux FSP.

Pourquoi c’est important en DFIR

Cette analyse tranche immédiatement le périmètre de remédiation :

Si a et b sont dans la même forêt : la remédiation doit impérativement englober les domaines A et B simultanément. Il est inutile de nettoyer le Domaine A sans réinitialiser également les secrets du Domaine B et du domaine racine.
Si a et b sont dans deux forêts distinctes avec SID filtering standard : l’investigateur ne doit pas supposer la compromission automatique du Domaine B. Il doit plutôt traquer :
1. Les comptes du Domaine A imbriqués dans des groupes locaux du Domaine B (FSP).
2. Les attaques par Kerberoasting cross-forêt ciblant des SPN du Domaine B.
3. La présence de comptes d’administration du Domaine B ayant ouvert une session sur le Domaine A (vol de credentials en mémoire).
4. Les délégations Kerberos non contraintes (Unconstrained Delegation) configurées sur des serveurs du Domaine A.

Comment ça fonctionne

Vecteurs d’attaque de a vers b

Intra-forêt : l’attaque par sIDHistory (inter-realm golden ticket) :
- L’attaquant extrait la clé de confiance entre A et B ou la clé krbtgt de A.
- Il forge un Referral TGT en injectant le SID S-1-5-21-B-512 (Domain Admins de B) ou S-1-5-21-ROOT-519 (Enterprise Admins) dans le champ sIDHistory.
- Le KDC de B déchiffre le ticket, constate qu’il s’agit d’une confiance intra-forêt, n’applique pas de filtrage de SID, et émet un TGS avec les pleins privilèges.
Inter-forêts : l’abus d’unconstrained delegation :
- Si un serveur dans le Domaine A possède l’attribut TRUSTED_FOR_DELEGATION (délégation non contrainte) et qu’un administrateur du Domaine B s’y connecte (ex: via SMB ou RDP), le TGT complet de l’administrateur du Domaine B est déposé dans LSASS sur ce serveur du Domaine A. L’attaquant l’extrait avec Mimikatz (sekurlsa::tickets) et prend le contrôle du Domaine B.
Inter-forêts : Kerberoasting cross-domaines :
- N’importe quel utilisateur authentifié du Domaine A peut demander un TGS pour n’importe quel SPN du Domaine B, permettant de casser les mots de passe de comptes de service hors-ligne.

Ce qui est possible

Prendre le contrôle immédiat de b si a et b partagent la même forêt.
Kerberoaster les comptes de service du domaine b depuis le domaine a (dès lors qu’une relation d’approbation existe).
Capturer les TGTs des utilisateurs du domaine b qui visitent des serveurs du domaine a (via Unconstrained Delegation ou coercition d’authentification PrinterBug / PetitPotam).
Exploiter les droits accordés aux foreign security principals du domaine a dans le domaine b.

Ce qui n’est pas possible

Forger des SIDs administratifs de b si le SID filtering est actif entre deux forêts. Le KDC de B purgera impitoyablement ces SIDs du PAC.
Réinitialiser le mot de passe d’un utilisateur de b depuis un DC de a sans droits LDAP explicites.
Rebondir au-delà du domaine b si la relation est une approbation externe (external trust).

Confusions fréquentes en DFIR

Confusion fréquente	Réalité forensique vérifiable
« La confiance est inter-forêts, donc le Domaine B est totalement étanche. »	Non. Si un serveur de A utilise l’Unconstrained Delegation ou si des FSP de A sont admins de serveurs de B, le Domaine B peut tomber en quelques minutes.
« Pour sécuriser B, il suffit de couper le réseau entre A et B. »	Couper le réseau stoppe les flux actifs, mais si l’attaquant a déjà volé des credentials de B ou compromis un FSP, il peut réutiliser ces accès depuis une autre provenance.
« Si A contrôle B, les logs sur les DC de B sont forcément effacés. »	Les événements de logon (4624 Type 3) et de demande de TGS (4769) restent enregistrés sur les DC de B lors du passage de frontière de l’attaquant.

Exemple concret d’investigation

Dans un groupe de santé, le domaine de laboratoire (lab.local) subit un ransomware. Le domaine principal de l’hôpital (hospital.local) est dans une forêt séparée avec une Forest Trust bidirectionnelle (SID Filtering actif).

L’analyste DFIR vérifie :

Le SID Filtering est-il actif ? Oui (Quarantine: Yes). L’injection sIDHistory échoue.
L’attaquant a-t-il pu pivoter vers hospital.local ?
- Exécution de BloodHound : un serveur web dans lab.local disposait de la délégation non contrainte (TRUSTED_FOR_DELEGATION).
- Analyse des logs sur ce serveur web : 2 heures avant le chiffrement, un administrateur d’hospital.local a ouvert une session SMB d’assistance technique sur ce serveur.
- Son TGT a été extrait par l’attaquant dans LSASS, qui l’a utilisé pour déployer le ransomware sur les DC d’hospital.local.

Artefacts et traces forensiques

Journaux de sécurité sur les DC du domaine b :
- Event ID 4769 : demande de TGS par un compte de DOMAINE_A ciblant des SPN locaux (Kerberoasting cross-domaine).
- Event ID 4624 (type 3) : connexions réseau avec TargetDomainName: DOMAINE_A.
- Event ID 4672 : privilèges spéciaux attribués à un compte externe lors de son logon sur une machine de B.
Surveillance des délégations :
- Machines du Domaine A possédant userAccountControl avec TRUSTED_FOR_DELEGATION (0x80000).

Méthodes d’investigation

Classifier la frontière : Déterminer si A et B partagent la même forêt (Get-ADForest) ou si une Forest/External Trust les relie.
Auditer le SID filtering : Exécuter netdom trust <DomainB> /domain:<DomainA> /quarantine.
Identifier les serveurs avec unconstrained delegation dans le domaine a : Rechercher tout système de A pouvant avoir capturé des TGTs d’utilisateurs de B.
Vérifier les sessions d’utilisateurs de b sur les hôtes de a : Rechercher dans les événements 4624 des machines compromises de A toute connexion émise par des comptes de B.

Outils d’investigation

PowerView / SharpHound :

Get-DomainComputer -Unconstrained -Domain "domaineA.local"
Get-DomainForeignGroupMember -Domain "domaineB.local"

BloodHound : Chemin d’attaque : MATCH p=shortestPath((u:User {domain:'DOMAINEA.LOCAL'})-[*1..]->(d:Domain {name:'DOMAINEB.LOCAL'})) RETURN p.

Points clés à retenir

Même forêt = compromission immédiate et totale de b depuis a.
Forêts séparées avec SID filtering = pas de golden ticket inter-domaine direct.
Les risques réels inter-forêts résident dans l’Unconstrained Delegation, les FSP imbriqués, le Kerberoasting et le vol de credentials en mémoire.