Imbrication Dangereuse de Groupes AD : Chemins vers Domain Admin

Qu'est-ce que l'imbrication dangereuse de groupes ?

L'imbrication dangereuse de groupes se produit quand des chaînes d'appartenance à des groupes Active Directory créent des privilèges effectifs que les évaluateurs n'avaient pas l'intention d'accorder. Un utilisateur, un compte de service ou un groupe opérationnel peut ne pas être membre direct de Domain Admins, Enterprise Admins, Schema Admins ou d'un autre groupe sensible. Mais s'il est imbriqué via un ou plusieurs groupes intermédiaires, le compte peut malgré tout hériter du contexte d'autorisation qui en résulte.

Les groupes de sécurité Active Directory sont des objets d'autorisation. Ils peuvent être placés sur des listes de contrôle d'accès, se voir attribuer des droits, et être ajoutés à d'autres groupes. Cette imbrication est utile pour l'administration, mais elle complique aussi la revue des privilèges. L'appartenance directe ne répond qu'à une seule question : qui est explicitement membre de ce groupe ? L'appartenance effective répond à la question la plus importante : qui reçoit ce privilège une fois toutes les appartenances imbriquées résolues ?

Ce problème est courant dans les domaines de longue durée. Les groupes survivent aux migrations, réorganisations, fusions, refontes d'applications, changements d'urgence et changements de propriétaire. Un groupe créé pour l'administration de serveurs en 2016 peut toujours être imbriqué dans un chemin protégé en 2026, même si personne dans l'équipe actuelle ne se souvient pourquoi.

Comment l'imbrication de groupes crée des privilèges cachés

Quand le Groupe A est membre du Groupe B, les membres du Groupe A héritent des privilèges effectifs du Groupe B. Si le Groupe B est lui-même membre d'un groupe Tier 0, les membres du Groupe A disposent désormais d'un chemin Tier 0, même si aucun de ces comptes n'apparaît comme membre direct du groupe privilégié final.

C'est le risque central : les chemins imbriqués cachent le privilège au milieu de la chaîne. Une revue directe de Domain Admins peut ne montrer qu'un ou deux groupes. Mais chacun de ces groupes peut contenir d'autres groupes, des comptes de service, des utilisateurs obsolètes ou des identités opérationnelles partagées.

Microsoft documente les comptes et groupes protégés dans Active Directory, dont des groupes comme Domain Admins, Enterprise Admins, Schema Admins, Administrators, Account Operators, Backup Operators, Server Operators, Print Operators et d'autres. Ces groupes méritent une revue particulière car l'appartenance peut accorder une capacité administrative puissante ou déclencher un comportement de compte protégé via AdminSDHolder.

Appartenance directe vs appartenance effective

Une revue utile distingue trois vues :

Seule la troisième vue fournit un plan de remédiation. Si un utilisateur du helpdesk se résout dans Domain Admins via cinq groupes, retirer l'utilisateur du dernier groupe n'est pas la solution car il n'y est pas directement. Il faut retirer ou redessiner l'arête de groupe qui crée le chemin.

Où se cachent généralement les chemins Tier 0 cachés

Les problèmes d'imbrication dangereuse proviennent généralement de schémas prévisibles :

• des groupes de migration conservés après une consolidation d'annuaire
• des groupes d'administration de serveurs imbriqués vers le haut pour un dépannage temporaire
• des comptes de sauvegarde, de déploiement ou de supervision ayant reçu un accès large pendant une panne
• des groupes opérationnels partagés utilisés par plusieurs équipes sans propriétaire actuel
• des groupes de support applicatif ayant hérité de droits de groupes admin historiques
• des groupes créés pour une région ou une unité métier puis réutilisés ailleurs
• d'anciens groupes de projet contenant encore d'anciens employés ou comptes de service

Une revue pratique commence en haut de la frontière de privilège et descend. Commencez par les groupes Tier 0 et prouvez qui peut les atteindre de façon transitive. Passer les groupes en revue par ordre alphabétique gaspille du temps et manque généralement le chemin qui compte.

La chaîne d'attaque

Étape 1 – Trouver le chemin imbriqué

L'attaquant ou l'évaluateur cartographie l'appartenance récursive depuis les groupes privilégiés. L'objectif est de trouver un compte plus facile à compromettre qu'un Domain Admin direct, mais qui se résout tout de même dans un chemin privilégié.

Get-ADGroupMember -Identity 'Domain Admins' -Recursive |
  Select-Object SamAccountName, ObjectClass, DistinguishedName

Étape 2 – Identifier le maillon faible

Le maillon faible n'est souvent pas un administrateur nommé. Cela peut être un compte de service avec un SPN, un compte utilisateur obsolète, un compte opérateur partagé ou un grand groupe de support. Le chemin imbriqué transforme cette identité plus faible en cible d'escalade pertinente.

Get-ADGroupMember -Identity 'Domain Admins' -Recursive |
  Where-Object {$_.objectClass -eq 'user'} |
  Get-ADUser -Properties Enabled, PasswordLastSet, ServicePrincipalName, LastLogonDate |
  Select-Object SamAccountName, Enabled, PasswordLastSet, LastLogonDate, ServicePrincipalName

Étape 3 – Utiliser l'autorisation existante

Si l'identité compromise hérite déjà des droits requis, l'attaquant n'a pas besoin d'une nouvelle vulnérabilité dans Active Directory. L'annuaire accorde déjà l'accès. C'est pourquoi l'imbrication dangereuse est un problème de chemin d'attaque, pas seulement un problème d'hygiène.

Détection

Event IDs Windows

Surveillez les modifications de groupes de sécurité sur les contrôleurs de domaine. Microsoft documente les familles d'événements clés sous Audit Security Group Management, et la liste d'événements requis de Microsoft Defender for Identity inclut aussi les variantes « membre ajouté » de ces événements (4728, 4732, 4756).

N'alertez pas seulement sur les ajouts directs à Domain Admins. Alertez aussi sur les changements de groupes situés un ou deux niveaux sous Tier 0, car c'est souvent là que des chemins cachés se créent.

Contrôles pratiques de revue

Utilisez des contrôles récurrents plutôt qu'un nettoyage ponctuel :

• exporter l'appartenance récursive des groupes protégés
• comparer l'appartenance directe avec l'appartenance effective
• signaler les comptes de service, comptes partagés, comptes désactivés et utilisateurs obsolètes dans les chemins récursifs
• identifier les groupes sans propriétaire, sans description ou sans date de revue récente
• vérifier si les changements de groupe étaient approuvés et attendus
• surveiller si la même arête de groupe est recréée après nettoyage

Remédiation

L'objectif n'est pas d'aplatir chaque groupe. L'objectif est de supprimer l'héritage Tier 0 caché et de rendre les chemins privilégiés restants explicites, dotés d'un propriétaire et vérifiables.

1. Auditer l'appartenance récursive depuis Tier 0

Commencez par les groupes qui définissent la frontière de privilège.

$tier0Groups = @('Domain Admins','Enterprise Admins','Schema Admins','Administrators','Backup Operators')
$results = foreach ($group in $tier0Groups) {
  Get-ADGroupMember -Identity $group -Recursive | ForEach-Object {
    [PSCustomObject]@{
      RootGroup = $group
      Account = $_.SamAccountName
      Type = $_.ObjectClass
      DistinguishedName = $_.DistinguishedName
    }
  }
}
$results | Export-Csv tier0-recursive-membership.csv -NoTypeInformation

2. Trouver l'arête de groupe qui crée le chemin

Retirer un utilisateur du mauvais groupe ne corrige pas le modèle. Trouvez la relation de groupe intermédiaire qui accorde le privilège et déterminez si elle est toujours nécessaire. Si un groupe d'admin serveur est imbriqué dans un chemin domain admin, redessinez le modèle administratif plutôt que de créer des exceptions au cas par cas.

3. Reconstruire explicitement les frontières de tiers

L'objectif est d'empêcher les groupes de tier inférieur d'hériter de droits de tier supérieur par imbrication de confort. Un groupe helpdesk ne devrait pas devenir privilégié simplement parce qu'il a été imbriqué dans un groupe admin serveur lui-même imbriqué plus haut par la suite.

4. Assigner ownership et cadence de revue

Chaque groupe proche de Tier 0 devrait avoir un propriétaire, un objectif et une cadence de revue. Si personne ne peut expliquer pourquoi un groupe est imbriqué dans un chemin privilégié, retirez-le ou mettez-le en quarantaine jusqu'à ce que la dépendance soit prouvée. Documentez les exceptions comme des exceptions, pas comme une architecture normale.

Ce qu'il ne faut pas faire

Ne remédiez pas à l'imbrication dangereuse en supprimant des groupes à l'aveugle. Certains groupes peuvent encore soutenir l'administration applicative, des tâches de sauvegarde ou des flux opérationnels. La bonne séquence consiste à identifier le chemin exact, confirmer le propriétaire, retirer les arêtes inutiles et tester le flux dépendant. Évitez aussi de remplacer un privilège imbriqué par une appartenance utilisateur directe dans le même groupe protégé. Cela peut rendre le chemin plus visible, mais ne réduit pas le privilège. L'objectif est de réduire le privilège effectif et d'améliorer la redevabilité, pas simplement de raccourcir la liste des groupes.

Validation après nettoyage

Après la remédiation, prouvez que le chemin a disparu :

• réexécuter les exports d'appartenance récursive pour les groupes protégés
• confirmer qu'aucun compte partagé, compte de service, compte désactivé ou utilisateur obsolète ne se résout plus dans Tier 0
• revoir les événements 4728, 4732, 4756, 4735, 4737 et 4755 pendant et après la remédiation
• confirmer que les groupes imbriqués restants ont un propriétaire et un objectif documenté
• vérifier que les alertes de supervision se déclenchent sur les changements de groupes sous la frontière privilégiée
• comparer les résultats du graphe avant et après nettoyage pour prouver clairement le chemin supprimé

L'objectif de validation est simple : l'environnement ne devrait pas dépendre d'un héritage de privilège caché qu'une requête de graphe ne peut expliquer qu'après coup.

Comment EtcSec détecte cela

EtcSec cartographie le graphe de groupes effectif plutôt que de se fier uniquement à l'appartenance directe. Cela rend le constat utile pour deux raisons : il montre le chemin de privilège complet, et il aide les évaluateurs à identifier quel objet de la chaîne est le plus facile à compromettre pour un attaquant.

Lectures connexes

Examinez l'imbrication dangereuse de groupes aux côtés de Chemins d'Attaque AD : Mauvaises Configurations en Chaîne, Abus ACL et DCSync : Les Chemins Silencieux vers Domain Admin, Attaques de Confiance AD : Du Domaine Enfant à la Racine, Mauvaises Configurations GPO : Comment la Stratégie de Groupe Devient un Vecteur d'Attaque, et Comptes Privilégiés Obsolètes : Risque Caché dans Active Directory. Le privilège imbriqué compte généralement parce qu'il se connecte à un autre chemin d'attaque.

Références principales

• Active Directory Security Groups
• Protected accounts and groups in Active Directory
• Audit Security Group Management
• 4732: A member was added to a security-enabled local group
• Configure Windows event auditing - Microsoft Defender for Identity