Chemin d'attaque Active Directory · Délégations et stratégies de groupe · MITRE T1484.001

Abus des stratégies de groupe (GPO) dans Active Directory

Une stratégie de groupe permet de déployer des paramètres de configuration et de sécurité sur un grand nombre de postes et de serveurs Windows. Cette capacité de centralisation en fait un outil essentiel d'administration Active Directory, mais également un point de contrôle sensible lorsque ses permissions ne sont pas correctement gouvernées.

Lorsqu'une identité dispose de droits excessifs sur une GPO appliquée à des ressources critiques, elle peut potentiellement modifier leur configuration sans avoir à compromettre directement chacune des machines concernées. L'exposition dépend toutefois des droits réellement détenus, du périmètre effectif de la stratégie et de ce que ses paramètres permettent d'exécuter ou de modifier.

La vraie question

Qui peut modifier une GPO appliquée à un système critique, et qui peut modifier les liaisons permettant à une stratégie d'atteindre ces systèmes ?

Cette distinction est fondamentale : modifier le contenu d'une GPO et modifier sa liaison à une unité d'organisation sont deux opérations différentes, qui reposent sur des permissions distinctes.

Comprendre vos chemins d'attaque Active Directory
Technique MITRE ATT&CK
T1484.001 — Group Policy Modification
Composants concernés
Objet GPO dans l'annuaire · fichiers SYSVOL
Stratégie de détection
MITRE DET0305
Signaux Windows
Event ID 5136, 4663, 4670 — sous réserve d'audit configuré

Pourquoi une GPO peut devenir un chemin d'attaque

Une GPO associe des paramètres administratifs à un périmètre d'utilisateurs ou d'ordinateurs. Dans Active Directory, sa configuration repose notamment sur un objet dans l'annuaire et des fichiers stockés dans SYSVOL. Les GPO sont ensuite liées à des sites, domaines ou unités d'organisation pour déterminer où leurs paramètres peuvent s'appliquer.

Une délégation historique, un groupe d'administration trop large ou des permissions héritées peuvent permettre à une identité de modifier une stratégie qui concerne des systèmes plus sensibles que ceux qu'elle devrait administrer. La configuration est alors modifiée depuis un point central et peut être appliquée aux machines concernées lors du traitement des stratégies de groupe.

Le risque doit être évalué en tenant compte des liaisons, de l'héritage, du filtrage de sécurité et, lorsqu'ils existent, des filtres WMI. Une GPO modifiable mais qui ne s'applique à aucun système critique ne constitue pas, à elle seule, un chemin d'attaque vers ces systèmes.

Le chemin d'attaque, étape par étape

  1. 01

    Identité compromise

    Un utilisateur ou compte technique est compromis. Il ne possède pas nécessairement de privilèges administratifs élevés, mais appartient à un groupe bénéficiant d'une délégation historique.

  2. 02

    Permission excessive sur une GPO

    Cette identité dispose directement ou indirectement du droit de modifier une GPO existante, dont les paramètres sont appliqués à des serveurs sensibles.

  3. 03

    Modification de la stratégie

    L'attaquant pourrait modifier des paramètres de sécurité ou introduire un mécanisme d'exécution, par exemple une tâche planifiée ou un script, selon les capacités et configurations disponibles.

  4. 04

    Application sur les machines concernées

    Lors du traitement des stratégies de groupe, les machines effectivement ciblées peuvent appliquer ces modifications. Les privilèges associés à l'action dépendent du mécanisme configuré et du contexte d'exécution.

  5. 05

    Obtention d'une capacité privilégiée

    Si la configuration malveillante le permet, l'attaquant peut obtenir une capacité d'administration locale, altérer des protections ou disposer d'un nouveau point d'appui sur un système sensible.

  6. 06

    Progression éventuelle vers une ressource critique

    Lorsque le système atteint est impliqué dans l'administration du domaine ou entretient une relation privilégiée avec des ressources Tier 0, cette nouvelle capacité peut constituer une étape supplémentaire dans un chemin d'attaque.

Chaque étape dépend des permissions, des paramètres appliqués et de l'architecture réelle. Une GPO modifiable ne signifie pas automatiquement qu'un domaine Active Directory est compromis.

Les permissions GPO à ne pas confondre

CapacitéPortéeEnjeu de sécurité
LectureLire une GPONe permet pas, seule, de modifier ses paramètres.
Application de stratégieDéterminer avec les autres conditions si une stratégie s'appliqueNe donne pas de droit d'édition.
Modification des paramètresModifier une GPOPeut affecter les ordinateurs et utilisateurs sur lesquels elle est effectivement appliquée.
Modification de sécuritéModifier les permissions de la GPOPeut permettre d'étendre les droits de gestion.
SuppressionSupprimer une GPOPeut affecter les mécanismes de sécurité ou d'administration qui en dépendent.
Liaison de GPOModifier les liaisons sur un site, domaine ou OUPeut modifier le périmètre d'application d'une GPO existante.

La capacité de modifier une liaison repose sur les permissions du conteneur concerné et ne doit pas être confondue avec le droit d'éditer le contenu de la GPO.

Les contrôles doivent également examiner les appartenances indirectes aux groupes, les permissions héritées et les possibilités de modifier les ACL. Une vérification limitée aux membres des groupes Domain Admins et Enterprise Admins ne suffit donc pas à identifier toutes les identités capables d'influencer les stratégies de groupe.

Vérifier le périmètre réel d'une stratégie

Une GPO peut être liée à plusieurs conteneurs et subir des règles d'héritage ou de priorité différentes. Le fait de constater une liaison dans la console GPMC ne suffit donc pas toujours à déterminer quels paramètres seront finalement appliqués à une machine.

Une analyse rigoureuse tient compte des liaisons actives, de leur ordre de priorité, des mécanismes Enforced et Block Inheritance, du filtrage de sécurité et des filtres WMI éventuels. Les fonctionnalités Group Policy Results et Group Policy Modeling peuvent aider à examiner les paramètres effectivement appliqués ou à simuler leur application.

Cette vérification est particulièrement importante pour les contrôleurs de domaine, les serveurs d'administration, les postes d'administration privilégiés et les systèmes qui participent à la sécurité du Tier 0.

Comment auditer les GPO Active Directory

  1. 01

    Identifier les stratégies sensibles

    Recenser les GPO appliquées aux contrôleurs de domaine, serveurs d'administration et autres systèmes critiques. Identifier également les stratégies de sécurité liées au domaine ou à des unités d'organisation dont l'impact dépasse l'administration de postes standards.

  2. 02

    Examiner les délégations

    Analyser les permissions d'édition, de suppression et de modification de sécurité des GPO, ainsi que les droits permettant de modifier leurs liaisons. Reconstituer les appartenances aux groupes pour identifier les droits effectifs, y compris lorsqu'ils proviennent de délégations historiques.

  3. 03

    Vérifier les effets possibles

    Pour chaque délégation sensible, rapprocher les permissions détenues du périmètre effectif de la stratégie. Déterminer si une modification de configuration pourrait affecter des machines ou des identités d'un niveau de privilège supérieur.

  4. 04

    Réduire les privilèges

    Supprimer les délégations devenues inutiles, restreindre les droits d'administration aux populations autorisées et isoler la gestion des stratégies critiques. Un groupe administrant des postes standards ne devrait pas pouvoir modifier une stratégie effectivement appliquée aux ressources Tier 0.

  5. 05

    Valider et surveiller

    Documenter les changements, sauvegarder les stratégies sensibles, vérifier leur application effective après correction et maintenir un contrôle régulier des délégations. Une remédiation n'est complète que lorsque la relation de contrôle dangereuse a disparu sans compromettre les besoins légitimes d'administration.

Détecter les modifications suspectes

La surveillance des GPO doit couvrir deux composants complémentaires : les objets de stratégie dans Active Directory et les fichiers correspondants dans SYSVOL. Une modification de l'un ou de l'autre peut être utile à l'investigation, mais elle doit être analysée avec le contexte de l'opération.

MITRE ATT&CK documente notamment la stratégie de détection DET0305, qui rapproche les modifications des objets de stratégie et les activités sur les fichiers. Parmi les événements Windows mobilisables figurent l'Event ID 5136 pour les modifications d'objets Active Directory ainsi que les événements 4663 et 4670 pour certaines opérations sur les fichiers et permissions.

Ces événements ne constituent pas automatiquement des alertes d'attaque GPO. Leur disponibilité dépend de la configuration des politiques d'audit, des SACL concernées et de la collecte des journaux. Une détection pertinente doit corréler le compte à l'origine de la modification, l'objet concerné, le changement effectué, sa temporalité et son appartenance ou non à une opération d'administration autorisée.

Les changements hors fenêtre, les délégations nouvellement accordées et les modifications de stratégies affectant des ressources critiques doivent être priorisés. Le suivi doit aussi permettre de comprendre ce qui a changé et de disposer d'une procédure de retour arrière adaptée.

Notre approche : casser la relation de contrôle

Une GPO n'est pas simplement un fichier de configuration. Ses permissions d'administration, ses liaisons et son périmètre d'application définissent une capacité d'action sur le système d'information. Lorsqu'une identité ordinaire peut agir indirectement sur un actif critique au moyen de cette capacité, le problème principal est la relation de contrôle qui relie les deux.

La démarche Ariovis consiste à cartographier les identités, les groupes, les ACL et les délégations, à déterminer les ressources réellement atteignables, puis à prioriser les remédiations qui suppriment les chemins les plus dangereux. L'objectif n'est pas de retirer indistinctement toutes les permissions, mais de conserver des mécanismes d'administration exploitables tout en réduisant les capacités de progression vers les systèmes sensibles.

Sources techniques