Attaques Trust AD : Domaine Fils à Racine

Que sont les attaques de confiance AD ?

Les attaques de confiance AD exploitent le fait qu'un domaine ou une forêt accepte des identités, des SIDs et des tickets Kerberos venus d'un autre périmètre de confiance. En pratique, cela devient critique lorsque des mécanismes conçus pour la migration ou l'interopérabilité, comme SID History, sont mal contrôlés, ou lorsqu'un attaquant a déjà compromis un domaine moins critique et cherche à remonter vers un domaine plus sensible.

Le point important pour un lecteur technique est le suivant : une relation de confiance n'est pas qu'un détail d'administration. C'est une frontière de traitement de PAC, de SIDs, de tickets Kerberos et de contrôles de filtrage. Si ces éléments sont mal compris, une compromission locale peut devenir une escalade inter-domaines.

L'abus le plus connu est l'injection de SID History. Microsoft Defender for Identity le documente explicitement : un compte peu sensible peut contenir dans son attribut SID History le SID d'Enterprise Admins d'un autre domaine de la forêt, ce qui lui donne un niveau d'accès équivalent dans tous les domaines de la forêt. Microsoft précise aussi que, sur une confiance de forêt sans SID Filtering, un SID provenant d'une autre forêt peut être ajouté au token et utilisé pour les décisions d'accès.

Le mécanisme qui compte vraiment

Quand un utilisateur s'authentifie à travers une relation de confiance, l'autorisation ne repose pas seulement sur son nom. Le domaine cible traite les SIDs présents dans le PAC et dans le token résultant.

C'est là que les attaques de confiance deviennent dangereuses :

si un ticket ou un compte transporte des SIDs supplémentaires acceptés par le domaine cible, les droits accordés peuvent dépasser très largement les privilèges apparents du compte d'origine
si SID History est présent et mal encadré, le domaine cible peut l'utiliser dans ses décisions d'autorisation
si le SID Filtering n'est pas activé là où il devrait l'être, des SIDs provenant d'un autre périmètre peuvent traverser la frontière de confiance

La documentation Microsoft sur le protocole PAC décrit précisément les règles de SID Filtering and Claims Transformation selon la frontière franchie. Tous les SIDs ne sont pas traités de la même façon, et c'est précisément cette nuance qui rend les simplifications dangereuses.

Quand ce risque devient exploitable

Une attaque de confiance sérieuse demande généralement plus qu'un simple compte utilisateur. Les prérequis les plus fréquents sont :

Contrôle élevé dans un domaine source ou dans une forêt de confiance.
Connaissance de la relation de confiance et de ses propriétés : type, direction, filtrage SID, authentification sélective ou non.
Capacité à injecter ou transporter des SIDs via SID History ou via un ticket forgé.
Absence de contrôles qui filtrent ou bloquent ces SIDs au franchissement de la confiance.

Dans la vraie vie, cela signifie souvent qu'un domaine enfant, un domaine partenaire ou un domaine moins bien gouverné sert de point d'appui vers un périmètre plus critique.

Chaînes d'attaque réalistes

1. Abus de SID History

C'est le cas le plus directement documenté par Microsoft. Si un compte transporte dans son SIDHistory un SID hautement privilégié d'un autre domaine ou d'une autre forêt, et si ce SID n'est pas filtré à la frontière, il peut être pris en compte lors de l'évaluation des accès.

Ce n'est pas un comportement théorique. Microsoft Defender for Identity le traite comme un indicateur de posture à risque précisément parce qu'un compte peu sensible peut ainsi obtenir une élévation effective à très large portée.

2. Abus d'une confiance de forêt mal filtrée

Sur une forest trust sans SID Filtering, Microsoft indique qu'il est possible d'injecter un SID venant d'une autre forêt et de le faire entrer dans le token de l'utilisateur authentifié. C'est la situation classique où l'équipe considère la confiance comme un simple mécanisme d'accès, alors qu'elle devient en réalité un chemin d'autorisation.

3. Escalade après compromission d'un domaine enfant

Une fois un domaine enfant compromis, l'attaquant cherche souvent à exploiter tout ce qui permet au domaine parent ou à la forêt de faire confiance à des informations de sécurité portées par les tickets issus du domaine enfant. Là encore, le sujet n'est pas seulement "le trust existe", mais "quels SIDs et quelles autorisations sont effectivement acceptés au passage".

Ce qu'il faut vérifier côté AD

Inventaire des relations de confiance

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

Cet inventaire ne suffit pas à lui seul, mais il permet de repérer immédiatement :

les confiances externes ou de forêt
les relations bidirectionnelles
les confiances où SIDFilteringQuarantined est désactivé

Vérification de SID History sur des comptes sensibles

Get-ADUser -Filter * -Properties SIDHistory |
    Where-Object {$_.SIDHistory} |
    Select-Object SamAccountName, SIDHistory

Une présence de SIDHistory n'est pas forcément malveillante. C'est un mécanisme légitime de migration. En revanche, un SIDHistory inattendu sur un compte courant, un compte admin ou un compte de service est un signal qui mérite une revue immédiate.

Contrôle de groupes hautement sensibles

L'objectif n'est pas seulement de chercher Enterprise Admins. Il faut vérifier toute combinaison où un SID importé ou hérité peut aboutir à :

Domain Admins
Enterprise Admins
groupes d'administration d'infrastructure
comptes de réplication ou de sauvegarde sur des DC

Détection

Les événements ne suffisent pas seuls, mais ils aident

Les attaques de confiance ne se détectent pas avec un seul Event ID miracle. Il faut corréler plusieurs signaux :

demandes de tickets inter-domaines ou inter-forest
élévations inattendues sur des comptes non habituels
modifications d'attributs comme SIDHistory
changements de configuration sur les objets de confiance

Ce qu'il faut surveiller en priorité

modifications de SIDHistory sur des comptes utilisateurs ou groupes
confiances où le filtrage SID n'est pas actif alors qu'il devrait l'être
tickets ou accès inter-domaines suivis d'autorisations très élevées
comptes ayant des privilèges soudainement élargis sans justification d'exploitation

Contrôle PowerShell utile

Get-ADTrust -Filter * | Select-Object Name, SIDFilteringQuarantined

Get-ADUser -Filter * -Properties SIDHistory |
    Where-Object {$_.SIDHistory} |
    Select-Object SamAccountName, SIDHistory

Lecture défensive correcte

Ce sujet n'est pas seulement un problème de logs. C'est d'abord un problème de modèle d'autorisation. La détection doit donc répondre à une question simple :

est-ce qu'un compte franchit une frontière de confiance avec des SIDs ou des privilèges qui ne devraient jamais être acceptés de cette source ?

Remediation et reduction du risque

Les actions de remediation prioritaires sur un sujet de trust abuse sont simples a lister et plus difficiles a prouver : activer le filtrage la ou il est attendu, retirer les SIDHistory residuels et verifier qu'aucun SID importe ne peut encore produire des droits elevés dans le domaine cible.

1. Activer le SID Filtering là où il est attendu

Pour les confiances externes ou de forêt qui n'ont pas besoin de laisser passer des SIDs de migration, le filtrage SID doit être activé.

Get-ADTrust -Filter * | Select-Object Name, SIDFilteringQuarantined

Pour les modifications opérationnelles, documentez précisément le besoin métier avant de laisser une confiance sans filtrage.

2. Nettoyer SID History quand il n'est plus nécessaire

Microsoft Defender for Identity recommande explicitement de supprimer les attributs SIDHistory risqués.

Get-ADUser -Identity <compte> -Properties SIDHistory | Select-Object -ExpandProperty SIDHistory
Set-ADUser -Identity <compte> -Remove @{SIDHistory='S-1-5-21-...'}

Le point important est de distinguer :

un SIDHistory légitime, temporaire, documenté, issu d'une migration
un SIDHistory résiduel, oublié ou abusif, qui élargit silencieusement les privilèges

3. Réduire la confiance opérationnelle, pas seulement la confiance technique

Même quand la relation de confiance doit exister, il faut réduire ce qui peut voyager avec elle :

supprimer les groupes inutiles des comptes exposés
éviter les comptes à privilèges partagés entre domaines
limiter les accès transverses à ce qui est réellement requis
documenter les propriétaires techniques des trusts et des exceptions

4. Revoir les domaines moins matures comme des chemins d'accès

Un domaine enfant ou un domaine partenaire moins bien contrôlé doit être vu comme un point d'appui potentiel, pas comme un simple segment administratif. Si ce domaine peut alimenter des tickets, des SIDs ou des décisions d'accès vers un domaine plus critique, il faut gouverner la relation comme une surface d'attaque.

Validation après correction

Une clôture sérieuse d'un sujet de trust abuse doit permettre de répondre à ces questions :

Quelles confiances existent encore, avec quel type et quel sens ?
Pour lesquelles le SID Filtering est-il désactivé, et pourquoi ?
Quels comptes ont encore un SIDHistory, et lesquels sont réellement justifiés ?
Existe-t-il encore un chemin crédible par lequel un SID importé ou forgé pourrait produire des privilèges élevés dans un autre domaine ?

Si la réponse à la quatrième question n'est pas démontrée, le sujet n'est pas réellement fermé.

Erreurs classiques côté défense

Les erreurs les plus fréquentes sont :

traiter la confiance comme un simple besoin d'administration sans revoir le modèle d'autorisation
laisser SIDHistory après la fin d'une migration
conserver des confiances externes ou de forêt sans revue régulière
supposer qu'un domaine enfant peu critique ne met pas en danger le reste de la forêt
revoir les trusts sans revoir les comptes et groupes qui franchissent réellement ces frontières

Un lecteur technique ne veut pas une conclusion abstraite sur la gouvernance. Il veut savoir où les SIDs transitent, ce qui est filtré, ce qui ne l'est pas, et quels comptes deviennent plus puissants que prévu.

Références primaires

Comment EtcSec détecte cela

EtcSec audite les relations de confiance AD et les comptes pouvant transporter ou accepter des privilèges inattendus à travers ces frontières.

Selon le contexte, l'analyse sera renforcée par des constats adjacents comme :

GOLDEN_TICKET_RISK
UNCONSTRAINED_DELEGATION
DCSYNC_CAPABLE

Pris isolément, un trust n'est pas toujours un incident. Pris avec des SIDs risqués, des comptes à privilèges et des tickets forgés, il devient un vrai chemin d'escalade.

Attaques de Confiance AD : Du Domaine Enfant à la Racine