GPO ACL faible, OU Tier 0, Active Directory : le pivot qui annule le modèle de tiers que vous venez de construire

GPO ACL Faible, OU Tier 0, Active Directory : Ce Que Cette Mauvaise Configuration Signifie Vraiment

GPO ACL faible, OU Tier 0, Active Directory : ce lien est le contrôle que la plupart des équipes oublient de vérifier une fois leur modèle de tiers déjà en place. Créer une unité d'organisation Tier 0 dédiée et y bloquer l'héritage des stratégies est une étape bien connue — c'est R58 et R59 de l'ANSSI-PA-099, le guide de l'agence française de cybersécurité sur la sécurisation de l'administration Active Directory (voir notre tour d'horizon des recommandations ANSSI pour l'ensemble plus large). R58 exige une OU dédiée regroupant les objets Tier 0 — avec une exception explicite : les comptes ordinateur des contrôleurs de domaine et les utilisateurs et groupes intégrés restent dans leurs OU par défaut ; R59 exige que cette OU « restreigne les stratégies de sécurité applicables à l'unité d'organisation Tier 0 » en bloquant l'héritage et en s'assurant que tout GPO lié ou appliqué à cette OU est dédié aux ressources Tier 0 et modifiable uniquement par les administrateurs Tier 0.

Cette seconde moitié de R59 — « modifiable uniquement par les administrateurs Tier 0 » — est la partie qui sort discrètement du périmètre une fois la structure d'OU construite. Bloquer l'héritage ferme un premier plan de contrôle : quelles stratégies s'appliquent vers le bas sur l'OU. Cela ne dit rien d'un second plan de contrôle, indépendant : qui peut écrire sur les objets GPO déjà liés à cette OU. Un GPO est lui-même un objet Active Directory doté de sa propre liste de contrôle d'accès. Si cette ACL accorde des droits de modification à quiconque en dessous du Tier 0 — un groupe de support, une délégation laissée par un départ jamais nettoyée, un groupe de sécurité imbriqué un niveau plus bas que prévu — ce principal peu fiable peut réécrire le contenu de la stratégie, et Active Directory appliquera ses modifications à chaque ordinateur et compte Tier 0 que le GPO atteint, blocage d'héritage ou non.

C'est une défaillance plus étroite et plus spécifique que la question générale de la construction d'un modèle de tiers en elle-même. Une équipe peut implémenter correctement la hiérarchie d'OU issue de R58, passer chaque revue de la structure d'OU elle-même, et livrer malgré tout une OU Tier 0 avec un GPO faiblement permissionné qui y est attaché — parce que l'ACL propre au GPO est un objet distinct que personne n'a pensé à revérifier une fois le modèle de tiers déclaré terminé.

Comment Cela Fonctionne

Un Group Policy Object est en réalité deux artefacts maintenus synchronisés : le Group Policy Container (GPC), un objet Active Directory sous CN=Policies,CN=System,DC=<domaine> qui porte le descripteur de sécurité propre au GPO, et le Group Policy Template (GPT), le dossier correspondant dans le partage SYSVOL qui contient les fichiers de paramètres réels. Le lien entre un GPO et une OU est une troisième pièce distincte : l'attribut gPLink sur l'OU, qui se contente de référencer le GPO par son GUID.

La documentation Microsoft sur le traitement des stratégies de groupe confirme la mécanique derrière l'exigence « bloquer l'héritage » de R59 : chaque OU possède un attribut GPOptions qui peut bloquer les stratégies venant des conteneurs de niveau supérieur, mais « si l'héritage bloqué empêche la plupart des paramètres de s'appliquer à une OU, cela n'affecte pas les paramètres appliqués via des GPO dotés de l'option forcée (enforced) » — enforced est une propriété du lien et prime sur le blocage d'héritage, qui est une propriété du conteneur. C'est exactement pour cette raison que R59 exige aussi de vérifier qu'aucun GPO appliqué en mode forcé depuis une OU parente n'est modifiable par quiconque en dehors du Tier 0 : le blocage d'héritage seul n'arrête pas le problème de permissions d'un GPO forcé, seulement celui de priorité normale.

Rien de tout cela ne touche à l'ACL propre de l'objet GPC. Par défaut, seuls les Domain Admins, les Enterprise Admins et SYSTEM disposent de droits de modification sur un GPO — la référence Microsoft Get-GPPermission montre exactement cet ensemble par défaut dans son propre exemple de sortie, et nomme ce niveau de permission GpoEditDeleteModifySecurity. Les ACL faibles apparaissent par dérive, pas par une seule mauvaise décision : un GPO est créé par un administrateur de tier inférieur via GPMC puis lié plus tard à l'OU Tier 0 sans que personne ne réaudite qui détient encore des droits de modification dessus, ou une délégation de support technique scopée à un GPO précis pour une tâche précise n'est jamais révoquée, ou un groupe de sécurité destiné au Tier 1 se voit accidentellement accorder « Edit settings » lors d'un nettoyage de permissions.

La Chaîne d'Attaque

Étape 1 — Trouver le maillon faible

Un attaquant (ou un auditeur) énumère l'ACL de chaque GPO à la recherche des droits GenericAll, GenericWrite, WriteDacl ou WriteOwner détenus par un principal en dessous du Tier 0, puis croise le résultat avec le gPLink de chaque GPO sur une OU Tier 0 — directement, ou via un GPO forcé depuis une OU parente. Get-GPPermission -Guid <GUID du GPO> -All ne fait remonter qu'un seul GPO à la fois — -Guid (ou -Name) est obligatoire, donc le balayage doit itérer plutôt que s'exécuter en une seule fois : tout titulaire dont la Permission remonte comme GpoEditDeleteModifySecurity — ou une ACE personnalisée que la cmdlet ne peut pas rattacher à un niveau nommé — et qui n'est pas un principal Tier 0 reconnu constitue un résultat positif.

Étape 2 — Armer la stratégie

La documentation BloodHound de SpecterOps sur l'arête d'abus GenericWrite décrit la technique standard : ouvrir le GPO dans l'éditeur de gestion des stratégies de groupe et y ajouter « une stratégie malveillante permettant le ciblage au niveau de l'élément, comme une nouvelle tâche planifiée immédiate » — une fonctionnalité des Group Policy Preferences qui exécute une commande arbitraire en tant que NT AUTHORITY\SYSTEM au prochain rafraîchissement de la stratégie. Les outils nommés pour cela — SharpGPOAbuse sous Windows, pyGPOAbuse sous Linux — automatisent l'écriture de ce XML de tâche planifiée dans le GPO. La même documentation signale une limite importante : GenericWrite scopé à « cet objet uniquement », sans autre ACE, ne suffit pas à lui seul — les paramètres du GPT résident dans SYSVOL, donc l'attaquant a aussi besoin d'un accès en écriture au dossier SYSVOL de ce GPO pour réellement modifier ce qui est déployé. En pratique, les deux voies d'accès sont accordées ensemble assez souvent pour que ce soit un véritable chemin d'attaque, pas seulement théorique — mais c'est aussi le détail qui sépare un vrai GPO à ACL faible d'un faux positif.

Étape 3 — Attendre la fenêtre de rafraîchissement

Aucun accès supplémentaire n'est requis après la modification. Selon la documentation Microsoft citée plus haut, les ordinateurs membres et les serveurs revérifient les changements de GPO toutes les 90 minutes avec un décalage aléatoire pouvant aller jusqu'à 30 minutes, tandis que les contrôleurs de domaine vérifient toutes les cinq minutes. Le contenu SYSVOL lui-même se réplique entre contrôleurs de domaine selon une planification DFSR pouvant descendre à 15 minutes au sein d'un même site. Une fois le changement en place, chaque ordinateur Tier 0 atteint par le GPO — pour un GPO lié à l'OU Tier 0, cela signifie les postes d'administration Tier 0, les comptes d'administration et les comptes de service qui y sont hébergés — exécute la tâche de l'attaquant en tant que SYSTEM selon son propre calendrier, sans aucune interaction requise. Les contrôleurs de domaine constituent un saut séparé : R58 conserve leurs comptes ordinateur dans l'OU par défaut OU=Domain Controllers, donc un GPO à ACL faible n'atteint un DC que s'il est également lié à cette OU ou appliqué à un conteneur parent en mode forcé.

Détection

L'Event ID 5136 (« Un objet de service d'annuaire a été modifié ») se déclenche sous la sous-catégorie Audit Directory Service Changes chaque fois qu'un objet doté d'une entrée SACL appropriée pour l'audit « Écriture » est modifié — il n'apparaîtra pas du tout à moins que cette SACL ne soit configurée au préalable sur les objets conteneurs GPO (ou héritée depuis CN=Policies,CN=System). Le champ AttributeLDAPDisplayName de l'événement est ce qui permet à un SIEM de distinguer une modification de stratégie de routine d'un changement de descripteur de sécurité ; filtrer sur ObjectClass=groupPolicyContainer isole l'activité GPO de tous les autres changements de service d'annuaire que cet événement couvre également.

# Sweep every GPO for trustees with edit/full-control rights, then
# cross-reference against GPOs linked to a Tier 0 OU
Get-GPO -All | ForEach-Object {
    $gpo = $_   # keep the GPO: inside the nested pipeline $_ is a GPPermission
    Get-GPPermission -Guid $gpo.Id -All |
        Where-Object { $_.Permission -match 'GpoEdit|GpoCustom' } |
        Select-Object @{N='GPO';E={$gpo.DisplayName}}, Trustee, TrusteeType, Permission
}

Remediation

1. Inventorier l'exposition. Lister chaque GPO lié à l'OU Tier 0, ainsi que tout GPO appliqué en mode forcé depuis une OU parente — selon ANSSI-PA-099 R59, les deux comptent. (Get-GPInheritance -Target "<DN de l'OU Tier0>").GpoLinks renvoie l'ensemble directement lié ; vérifiez manuellement les OU parentes pour les liens forcés.
2. Examiner l'onglet Délégation. Pour chaque GPO, ouvrez-le dans GPMC et vérifiez l'onglet Délégation, puis cliquez sur Avancé pour voir l'ACL brute plutôt que les niveaux de permission résumés — les conseils de délégation de Microsoft documentent ceci comme la voie prise en charge pour ajouter, retirer ou inspecter les droits Edit settings, delete, and modify security sur un GPO.
3. Retirer tout titulaire hors Tier 0 disposant d'un niveau Edit, Edit/Delete/Modify Security, ou Custom. Confirmez que le dossier SYSVOL correspondant à ce GPO n'accorde pas séparément le même accès en écriture à ce principal — l'ACL AD et l'ACL SYSVOL sont deux contrôles distincts sur deux objets distincts.
4. Revérifier l'autre moitié de R59. Confirmez que l'héritage est toujours bloqué sur l'OU Tier 0, que la Default Domain Policy y est liée en priorité la plus basse comme le spécifie R59, et qu'aucun GPO forcé depuis une OU parente ne porte encore une ACL faible.
5. Relancer le balayage de la section Détection selon une planification récurrente, pas une seule fois — les permissions GPO dérivent de la même manière que les appartenances de groupe, via des délégations ponctuelles que personne ne pense à révoquer. Ce contrôle relève de la même rotation qu'un audit de sécurité Active Directory plus large, pas d'un nettoyage ponctuel.

Comment EtcSec Détecte Cela

Le catalogue de conformité d'EtcSec suit exactement ce mode de défaillance sous l'identifiant ANSSI_R59_TIER0_OU_POLICIES : il énumère chaque lien GPO activé, signale ceux qui pointent vers un GPO dont l'ACL propre accorde un accès en écriture à un principal non-administrateur, et remonte un constat pour chaque lien qui atterrit sur une OU Tier 0. Il est associé à GPO_DANGEROUS_PERMISSIONS pour le cas général des ACL GPO faibles n'importe où dans le domaine, PATH_GPO_TO_DA pour la vue chemin d'attaque de cette même exposition, et ANSSI_R15_TIER_MODEL_VIOLATION pour la question plus large de savoir si le modèle de tiers lui-même est intact.