Attaques de Confiance AD : Du Domaine Enfant à la Racine

Que sont les attaques de confiance AD ?

Les attaques de confiance AD (Active Directory) exploitent les chemins d'authentification et d'autorisation qui permettent à un domaine ou une forêt d'accéder à des ressources d'un autre. Les trusts font partie intégrante d'AD DS. Les trusts parent-enfant au sein d'une forêt, les trusts externes, les trusts raccourcis (shortcut trusts) et les trusts de forêt existent tous pour répondre à de véritables besoins d'accès. Le risque est qu'un trust étend également le périmètre de sécurité que les défenseurs doivent comprendre.

Un trust ne signifie pas automatiquement une compromission. Le risque réel dépend du type de trust, de sa direction, de sa transitivité, du comportement du SID filtering, de la selective authentication, du cloisonnement administratif (tiering) et du niveau de compromission dans le domaine source. Mais dans une forêt multi-domaines, la compromission d'un domaine enfant peut devenir un incident au niveau de la forêt si l'attaquant parvient à exploiter les chemins de confiance Kerberos, les SIDs privilégiés ou un accès administratif qui franchit la frontière.

Une bonne revue commence par trois questions :

• quels trusts existent et qui en est propriétaire
• quels trusts répondent encore à un besoin métier actuel
• si chaque trust limite l'autorisation inter-domaines au périmètre prévu

Comment fonctionnent les trusts Active Directory

Microsoft documente le fait qu'AD DS utilise des relations de trust de domaine et de forêt pour fournir l'authentification entre domaines et forêts. Avant qu'un accès à travers un trust soit possible, Windows calcule un chemin de confiance entre le contrôleur de domaine de la ressource et un contrôleur de domaine du domaine du compte demandeur.

Les trusts peuvent être à sens unique ou bidirectionnels. Ils peuvent aussi être transitifs ou non transitifs. Dans une forêt AD DS on-premises, les nouveaux domaines enfants créent automatiquement des relations de trust bidirectionnelles et transitives avec le domaine parent. Cette transitivité permet aux demandes d'authentification de suivre des chemins de confiance à travers l'arborescence de domaines lorsque les permissions le permettent.

Ce comportement est utile, mais il signifie que les défenseurs ne doivent pas traiter un domaine enfant comme un annuaire à faible enjeu. Si un domaine enfant est mal administré, dispose d'une confiance excessive ou est compromis au niveau du contrôleur de domaine, la forêt doit être revue comme un système de sécurité connecté.

Où s'inscrit le SID filtering

Les tickets Kerberos contiennent des données d'autorisation, dont des SIDs utilisés pour les décisions d'accès. Le SID History existe pour les scénarios de migration où un compte doit conserver l'accès à des ressources qui référencent encore un ancien SID. La documentation Microsoft sur DsAddSidHistory indique que l'ajout de SIDs à l'attribut sIDHistory d'un principal de sécurité est une opération sensible du point de vue de la sécurité, et que si un domaine de ressources fait confiance au domaine de comptes d'un SID volé ou non autorisé, l'utilisateur non autorisé peut obtenir un accès non autorisé aux ressources de ce SID.

Le SID filtering est conçu pour réduire ce risque aux frontières de trust. La spécification PAC de Microsoft décrit le comportement du SID filtering aux frontières de trust, y compris pour les trusts de forêt et les trusts externes. Le comportement exact dépend de la frontière de trust et de la catégorie de SID ; il est donc important de ne pas réduire le sujet à un simple indicateur sans comprendre le type de trust.

Pour les trusts externes, les administrateurs révisent généralement l'état de la quarantine ou du SID filtering. Pour les trusts de forêt, la selective authentication et la configuration du trust de forêt peuvent également compter. Pour les trusts parent-enfant au sein de la même forêt, l'enjeu principal est souvent architectural : tous les domaines font partie du même tissu de confiance de la forêt, donc la compromission d'un domaine peut avoir des conséquences au-delà du domaine local.

Limites du périmètre et conditions préalables

Il ne s'agit pas d'affirmer que tout trust AD est exploitable. L'abus de trust à fort impact nécessite généralement un prérequis solide, tel que :

• la compromission d'un contrôleur de domaine ou d'un secret équivalent au niveau du domaine dans le domaine source
• la capacité à forger ou manipuler des données d'autorisation Kerberos
• un chemin de trust qui accepte le contexte d'autorisation résultant
• des ressources cibles qui autorisent l'accès sur la base de SIDs privilégiés ou de groupes inter-domaines
• une séparation faible entre les niveaux administratifs (tiers) entre domaines

C'est pourquoi la revue des trusts doit être liée aux hypothèses de réponse à incident. Si le secret krbtgt d'un domaine enfant ou ses contrôleurs de domaine sont compromis, ne traitez pas l'incident comme isolé tant que les chemins de trust, les sessions privilégiées et l'autorisation inter-domaines n'ont pas été revus.

Schémas courants d'abus de trust

Du domaine enfant vers le parent ou la racine de la forêt

Le scénario d'escalade classique commence par la compromission d'un domaine enfant. Si l'attaquant contrôle suffisamment le domaine source, il peut tenter de forger du matériel Kerberos transportant des données d'autorisation privilégiées vers une ressource du domaine parent ou de la racine de la forêt. Que cela réussisse dépend du comportement du trust et du filtering, mais la leçon défensive est claire : les domaines enfants nécessitent une protection de niveau Tier 0 lorsqu'ils appartiennent à la même forêt.

Trusts externes obsolètes

Les anciens trusts externes sont courants après des migrations, des intégrations avec des partenaires, des acquisitions ou des projets temporaires. Un trust obsolète peut encore autoriser des chemins d'authentification que personne ne gère activement. Même si le SID filtering est activé, un trust inutile reste une surface d'attaque inutile.

Propriété faible du trust

Un trust sans propriétaire devient difficile à modifier car personne ne peut approuver sa suppression. Cela conduit à des exceptions permanentes. Chaque trust restant doit avoir un propriétaire applicatif, un propriétaire métier, une direction d'authentification, les utilisateurs attendus et une date de revue.

Administration privilégiée entre frontières

Les trusts deviennent plus dangereux lorsque les administrateurs utilisent des identifiants privilégiés entre domaines ou forêts. Une session privilégiée dans un domaine moins gouverné peut exposer des identifiants ou des jetons permettant un mouvement vers un domaine plus sensible. Le durcissement des trusts et le durcissement de l'accès privilégié doivent être revus ensemble.

Détection

Aucun événement Windows unique ne prouve à lui seul une attaque de trust. La détection nécessite un inventaire des trusts, une revue des événements Kerberos, le contexte des connexions privilégiées et la surveillance des changements.

Événements Windows et sources de journalisation

Les données d'événements ont besoin de contexte. Un événement 4769 inter-domaines peut être normal pour une application. Une connexion administrative inter-domaines depuis un compte inattendu, après un incident sur un domaine enfant, est très différente.

Revue de l'inventaire des trusts

Inventoriez tous les trusts et classez-les :

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

Utilisez le résultat pour le tri. SIDFilteringQuarantined = False ne constitue pas automatiquement une preuve de compromission ou de mauvaise configuration, mais cela doit avoir un propriétaire et une justification. Si personne ne peut expliquer pourquoi le trust a besoin de sa configuration actuelle, il doit rejoindre la file de nettoyage.

Remediation

Le trust le plus sûr est celui qui n'existe plus parce que la dépendance métier a pris fin. Durcissez les trusts restants selon leur type et leur finalité.

1. Supprimer les trusts obsolètes

Revoyez d'abord les anciens trusts de partenaires, de migration, de test et d'acquisition. Si un trust n'a pas de propriétaire, aucune dépendance applicative active et aucun besoin d'accès récent, supprimez-le via le processus de changement normal.

2. Revoir le SID filtering et la quarantine

Pour les trusts externes où c'est compatible, activez la quarantine ou le SID filtering et validez les flux de travail dépendants. La commande netdom trust de Microsoft prend en charge l'option /Quarantine pour la gestion des trusts, et la documentation de la commande indique que No accepte n'importe quel SID. Ce paramètre ne doit pas être laissé au hasard de l'historique.

3. Utiliser la selective authentication lorsque c'est pertinent

Pour les trusts de forêt, la selective authentication peut limiter quels utilisateurs de la forêt de confiance peuvent s'authentifier vers des ressources spécifiques. Elle ne remplace pas de bonnes ACL ni une bonne hygiène d'accès privilégié, mais elle réduit la portée d'authentification large.

4. Traiter les domaines enfants comme à forte conséquence

Ne présumez pas qu'un domaine enfant est une zone administrative à faible risque. Sécurisez les contrôleurs de domaine enfants, les groupes privilégiés, la gestion de krbtgt et les postes d'administration avec le même sérieux que la racine de la forêt lorsque les chemins de trust autorisent un accès inter-domaines.

5. Réduire les sessions privilégiées inter-frontières

N'utilisez pas de façon routinière des comptes privilégiés de la racine de la forêt ou du domaine parent dans des domaines enfants moins fiables. Si les administrateurs doivent franchir la frontière, utilisez des comptes dédiés, des postes d'administration contrôlés et une journalisation qui rend la session visible.

Ce qu'il ne faut pas changer à l'aveugle

Ne modifiez pas les contrôles de trust sans tester le flux d'authentification dépendant. Le SID filtering, la quarantine et la selective authentication peuvent casser des schémas d'accès hérités, des flux de migration ou des applications construites autour d'un accès inter-domaines étendu. Ce risque de compatibilité n'est pas une raison de laisser le trust non sécurisé ; c'est une raison de documenter la dépendance, de tester dans une fenêtre contrôlée et de remplacer le trust étendu par un accès explicite lorsque c'est possible. Si le métier ne peut pas supprimer immédiatement un trust risqué, l'exception doit inclure un propriétaire, une date de fin, un plan de surveillance et des contrôles compensatoires d'accès privilégié.

Validation après durcissement du trust

Après un changement de trust, validez à la fois la sécurité et la fonction métier :

• relancez l'inventaire des trusts et enregistrez la direction, le type, la transitivité, la selective authentication et l'état du SID filtering
• confirmez que les équipes applicatives ont retesté les flux de travail dépendant du trust
• vérifiez que les anciens trusts de migration ou de partenaires ont été supprimés et non simplement documentés
• revoyez l'activité Kerberos et de connexion à travers le trust après le changement
• vérifiez si des utilisateurs privilégiés s'authentifient encore à travers la frontière
• documentez les exceptions avec un propriétaire, une date d'expiration et des contrôles compensatoires

Une revue de trust n'est réussie que lorsque les trusts restants sont intentionnels, possèdent un propriétaire, sont surveillés et limités à l'accès dont le métier a encore besoin.

Comment EtcSec détecte cela

EtcSec audite les relations de trust et met en évidence les chemins de trust qui augmentent le risque d'escalade inter-domaines.

Les constats liés aux trusts sont les plus utiles lorsqu'ils sont corrélés avec le chemin d'attaque environnant : si un domaine enfant présente déjà une hygiène administrative faible, si un trust externe obsolète existe encore, et si des identités à forte valeur ou des droits délégués se trouvent des deux côtés de la frontière.

Lectures connexes

Revoyez l'exposition des trusts avec Chemins d'attaque AD vers Domain Admin, Imbrication dangereuse de groupes AD : chemins cachés vers Domain Admin, Abus ACL et DCSync : les chemins silencieux vers Domain Admin, Attaques de délégation Kerberos : de la non contrainte à l'abus RBCD et Attaque Golden Ticket : les clés de votre royaume. L'abus de trust est généralement un multiplicateur de chemins, pas une mauvaise configuration isolée.

Références principales

• 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