Groupes Windows et imbrication : modélisation des droits effectifs

Modèle mental en réponse à incident

Lors d’une investigation, l’appartenance directe à un groupe ne représente que la partie émergée de l’iceberg.

Un attaquant n’a pas besoin d’être explicitement listé dans Domain Admins pour posséder les droits administrateurs : l’imbrication de groupes (Nested Groups) permet d’hériter de privilèges à travers une chaîne arbitrairement complexe d’appartenances indirectes :

User → Global Group → Universal Group → Domain Local Group → Permission / Droit

Concept

Dans Windows et Active Directory, un groupe de sécurité est un principal détenant son propre SID qui sert à agréger d’autres principaux (utilisateurs, ordinateurs ou autres groupes).

La portée d’un groupe et sa capacité à franchir les frontières de domaines dépendent de son type et de son étendue (Scope) :

1. Groupes locaux (SAM) : valables uniquement sur la machine locale.
2. Groupes globaux de domaine (Global Groups) : regroupent des utilisateurs d’un même domaine pour leur attribuer un rôle.
3. Groupes locaux de domaine (Domain Local Groups) : utilisés pour affecter des permissions d’accès aux ressources hébergées dans ce domaine.
4. Groupes universels (Universal Groups) : stockés dans le Catalogue Global (GC), capables de contenir des membres de n’importe quel domaine de la forêt.

---

Pourquoi c’est important en DFIR

L’analyse forensique des groupes est le cœur de la détection des élévations de privilèges discrètes et des mouvements latéraux :

• Prouver le chemin d’élévation indirecte : lorsqu’un utilisateur standard commet une action réservée aux administrateurs, l’analyste doit immédiatement reconstruire son arborescence d’appartenance transitive.
• Détecter les portes dérobées d’accès : les attaquants avancés (ex: APT29, ransomware FIN7) créent souvent un groupe anodin (ex: Printer_Operators_L2), l’imbriquent discrètement dans un groupe sensible (BUILTIN\Administrators), puis ajoutent leur compte de persistance au premier groupe.
• Comprendre la propagation cross-domaine : dans les architectures multi-domaines, un groupe local de domaine du Domaine B peut contenir un groupe global du Domaine A, permettant à des identités de A de posséder des accès administratifs sur B sans qu’aucun compte du Domaine B ne soit créé (voir Fiche 18 : Cross-Domain Group Membership and Foreign Security Principals).

---

Comment ça fonctionne

La règle d’architecture AGDLP / AGUDLP

Microsoft préconise la stratégie AGDLP (ou AGUDLP en multi-domaines) pour régir les autorisations :

• A (Accounts) : les comptes utilisateurs.
• G (Global Groups) : les comptes sont placés dans un groupe global représentant leur métier ou rôle (ex: GG_Comptabilite).
• U (Universal Groups) : en multi-forêts/multi-domaines, les groupes globaux sont agrégés dans un groupe universel.
• DL (Domain Local Groups) : les groupes globaux sont imbriqués dans un groupe local de domaine représentant l’accès à une ressource spécifique (ex: DL_Partage_Compta_Lecture).
• P (Permissions) : la permission NTFS ou de partage est accordée uniquement au groupe local de domaine.

[Compte Utilisateur (jdoe)]
            │
            ▼ (Membre de)
[Groupe Global (GG_Finance)] (Domaine A)
            │
            ▼ (Imbriqué dans)
[Groupe Local de Domaine (DL_Billing_Write)] (Domaine B)
            │
            ▼ (DACL / ACE)
[Dossier Sécurisé (\\FS01\Factures)]

Le calcul du jeton d’accès lors du logon

Lorsque l’utilisateur s’authentifie, le système résout récursivement toutes ses appartenances directes et indirectes :

1. Le DC évalue les groupes globaux et universels du domaine.
2. La machine locale contactée évalue les groupes locaux de domaine et les groupes locaux SAM.
3. L’ensemble de ces SIDs est injecté dans le champ Groups du jeton d’accès du processus.

---

Ce qui est possible

• Imbriquer des groupes locaux dans d’autres groupes locaux : impossible dans la SAM locale, mais un groupe global peut être membre d’un groupe local SAM.
• Hériter des privilèges de multiples niveaux d’imbrication : si User A est dans Group 1, qui est dans Group 2, qui est dans Group 3, qui est dans Administrators, User A possède tous les privilèges administratifs locaux.
• Vérifier l’appartenance effective en temps réel : la commande whoami /groups affiche tous les SIDs de groupes effectivement présents dans le jeton actif, y compris les appartenances indirectes.

---

Ce qui n’est pas possible

• Un groupe global ne peut pas contenir de membres issus d’autres domaines : un groupe global n’accepte que des comptes ou des groupes globaux issus de son propre domaine.
• Un groupe local de domaine ne peut pas être utilisé pour assigner des permissions dans un autre domaine : sa portée est strictement confinée au domaine qui l’héberge.
• Actualiser les droits d’un groupe sans réouverture de session : si un attaquant est ajouté à un groupe alors que sa session est ouverte, son jeton d’accès actif ne change pas. Il doit fermer sa session et se reconnecter, ou forcer le renouvellement de son ticket TGT Kerberos.

---

Confusions fréquentes

Erreurs fréquentes en investigation

1. Regarder uniquement Get-ADUser -Properties MemberOf : l’attribut LDAP memberOf ne liste que les appartenances directes. Il n’affiche ni les groupes imbriqués, ni le groupe primaire (ex: Domain Users).
2. Confondre groupe de distribution et groupe de sécurité : les groupes de distribution ne possèdent pas de SID de sécurité et ne peuvent pas être utilisés dans les listes de contrôle d’accès (DACLs).

---

Exemple concret : l’attaque de persistance par imbrication cachée

1. L’attaquant dispose d’un accès administrateur éphémère. Il veut installer une porte dérobée discrète.
2. Il crée un groupe de sécurité VPN_Monitoring_Service.
3. Il ajoute VPN_Monitoring_Service comme membre du groupe DnsAdmins.
4. Il ajoute son compte non privilégié CORP\jdoe comme membre de VPN_Monitoring_Service.
5. Lors d’un audit de sécurité standard, l’équipe SOC examine les membres directs de Domain Admins et Administrators : rien d’anormal.
6. L’attaquant utilise son compte jdoe pour exploiter le vecteur DnsAdmins (chargement d’une DLL système par le service DNS du DC) et réexécuter du code arbitraire sous SYSTEM sur le contrôleur de domaine (voir Fiche 28 : domain controllers as lateral movement hubs).

---

Artefacts / traces

Dans Security.evtx sur les contrôleurs de domaine :

EventID: 4728 # Membre ajouté à un groupe de sécurité global
TargetUserName: GG_Support
MemberSid: S-1-5-21-111111111-222222222-333333333-1145
SubjectUserName: Administrator

EventID: 4732 # Membre ajouté à un groupe de sécurité local
TargetUserName: Administrators
MemberSid: S-1-5-21-111111111-222222222-333333333-1080 (GG_Support)

---

Méthodes d’investigation

1. Reconstituer récursivement tous les groupes d’un utilisateur (appartenance transitive) :

   Get-ADUser -Identity "jdoe" | Get-ADPrincipalGroupMembership | Select-Object Name, GroupScope, SID

2. Détecter tous les membres transitifs d’un groupe privilégié :

   Get-ADGroupMember -Identity "Administrators" -Recursive | Select-Object Name, SamAccountName, objectClass, SID

3. Cartographier les chemins d’attaque via BloodHound : Utiliser SharpHound pour extraire le graphe complet des relations MemberOf et exécuter la requête cypher : MATCH p=(u:User)-[:MemberOf*1..]->(g:Group) RETURN p

---

Points clés à retenir

1. Les droits réels dépendent de l’imbrication transitive, jamais de la seule appartenance directe.
2. memberOf dans l’AD ne reflète pas les groupes indirects : utilisez toujours des requêtes récursives. :
3. L’ajout à un groupe ne modifie pas les sessions actives : une nouvelle authentification est obligatoire. :
4. La surveillance des event IDs 4728 et 4732 est obligatoire pour détecter les modifications de groupes.

---

Références

• Microsoft Learn: Active Directory Group Scopes
• Fiche 02 : SID, RID and Windows identity
• Fiche 06 : Windows access tokens and security context
• Fiche 18 : cross-domain group membership and foreign security principals