Sécurité Active Directory : quand une ACL indésirable sur une GPO devient une faille de sécurité

I. Présentation

Lors d’un audit de sécurité récurrent sur un environnement AD, il m’est apparu qu’un point de contrôle essentiel concernant les GPO était régulièrement omis. Cet article met en lumière les risques liés aux ACL inhabituelles sur les fichiers du partage SYSVOL.

Pour valider cette observation, j’ai échangé avec plusieurs personnes, notamment Florian Burnel, Loïc Veirman et Guillaume Mathieu, membres actifs de la communauté HardenAD. Leur retour a confirmé que cette faiblesse, bien que peu connue, est réelle et potentiellement critique.

Cachée dans l’obscurité du dossier SYSVOL, cette faille repose sur un mécanisme rarement surveillé, mais tout à fait exploitable. Le risque ne vient pas d’une exploitation complexe, mais du fait que la plupart des outils d’audit et de surveillance se concentrent sur des indicateurs classiques, en négligeant certains comportements pourtant révélateurs...

II. À propos de l'audit AD

Malheureusement, encore aujourd’hui, de nombreuses entreprises ou responsables sécurité associent la sécurité d’un environnement Active Directory, pourtant au cœur de l’identité et de l’accès à un simple score attribué par tel ou tel outil d’audit.

Qu’il s’agisse d’outils gratuits ou payants, leur popularité ne garantit pas une couverture exhaustive, surtout lorsqu’ils passent à côté de faiblesses simples, mais mal configurées.

A. Usage des partages AD

Historiquement, les contrôleurs de domaine ont été utilisés à tort pour héberger toutes sortes de rôles ou de services, comme DFS, DHCP, ou encore des autorités de certification (CA). Cette mauvaise habitude, notamment dans les environnements mixtes ou hérités, a souvent conduit à des configurations hasardeuses.

Concernant les dossiers partagés comme SYSVOL et NETLOGON, ils sont censés héberger des éléments critiques : des scripts de connexion, des fichiers de configuration, voire parfois des binaires.

Dans certains cas, ces dossiers ont aussi été utilisés comme dépôts pour des fichiers temporaires, des journaux, ou même comme points de distribution d’applications. Ce type d’imprudence ouvre la porte à des attaques simples… mais redoutablement efficaces.

Le plus inquiétant, c’est que cette menace existe dans des environnements réels, et a été observée à plusieurs reprises. Il ne s’agit pas d’une théorie, mais bien d’un vecteur d’attaque discret et sous-estimé.

B. Architecture d'une GPO

Une GPO est un objet conteneur situé dans le dossier System d’Active Directory, au sein de la partition de configuration, cet objet contient les métadonnées de la GPO (nom, version, filtrage de sécurité, liens, etc.), ainsi qu’un attribut gPCFileSysPath qui pointe vers le chemin physique du dossier correspondant dans le SYSVOL.

Comme indiqué dans la capture ci-dessous, les outils d’audit ou la console GPMC lisent ces attributs pour afficher les informations, mais l’investigation s’arrête souvent ici.

L'occasion de faire quelques rappels sur le mécanisme d’authentification.

Lors de l’ouverture de session, le poste client (compte machine) ou l’utilisateur interroge l’annuaire Active Directory pour récupérer les GPO liées à son objet, en fonction de son appartenance à une unité d’organisation ou à un site, puis lit les informations à appliquer à partir de trois éléments clés :

• le chemin gPCFileSysPath : qui désigne le dossier SYSVOL à utiliser
• l’attribut gPCMachineExtensionNames : qui indique si des paramètres doivent être appliqués côté machine
• l’attribut gPCUserExtensionNames : qui indique si des paramètres doivent être appliqués côté utilisateur à l'aide de la présence d'un Guid correspondant à la partie de la configuration à appliquer (Scripts, GPP, Clé de registre, fichier de paramètre Registry.pol)

C. Droits ACLs sur un dossier partagé

Par défaut, seuls les administrateurs du domaine devraient avoir des droits complets sur les objets GPO. Cependant, en cas de délégation, des utilisateurs ou groupes peuvent se voir attribuer des droits supplémentaires, comme l’écriture ou la lecture.

Cela peut se faire via la console GPMC ou par des commandes PowerShell, comme nous allons le voir dans l’exemple suivant.

Dans notre cas, nous avons délégué à l’utilisateur User4 un droit de lecture sur une GPO, dans le cadre d’un filtrage par groupe de sécurité.

Ce droit s’est traduit par une modification des ACL au niveau du dossier physique de la GPO dans SYSVOL, avec en plus une propagation (héritage) sur les objets enfants.

La plupart des outils d’audit Active Directory modernes remontent ce genre de délégation. Toutefois, certains se contentent d’ignorer les droits en lecture seule.

En cas de droit en modification, des outils comme GPOZaurr ou d’autres solutions d’analyse GPO signalent l’anomalie, car ils analysent les autorisations à l’aide de la commande Get-GPPermission comme le montre la capture ci-dessous :

D. Que se passe-t-il en cas de mauvaise configuration ?

Pour mieux illustrer les risques liés à une négligence ou à une mauvaise configuration, nous allons volontairement accorder des droits de modification à un utilisateur standard, User1 sur plusieurs emplacements sensibles.

Notons que ce processus reste également valable avec des droits moindres, comme la création d’objets enfants, souvent jugés inoffensifs à tort.

Dans cet exemple, les droits sont appliqués sur les sous-dossiers Machine\Script et User d’une GPO.

Ce type de délégation peut résulter d’un ancien projet, d’une erreur d’administration, ou même d’une volonté de simplifier la gestion d’un script existant.

Comme nous pouvons le constater, la GPO ne contient aucun script configuré dans la console GPMC, ni en démarrage (Startup) ni en arrêt (Shutdown). On pourrait donc penser que ce droit ne présente aucun danger particulier. Et, pourtant, les tests montrent qu’il peut être exploité de manière silencieuse et efficace.

Après modification, nous avons scanné une nouvelle fois l’environnement avec plusieurs outils d’audit bien connus, gratuits comme payants.

Résultat : aucune alerte n’a été remontée.

Même dans la console GPMC, l’utilisateur user1 n’apparaît pas dans l’onglet sécurité ou délégations.

Des outils comme BloodHound, AD ACL Scanner, ou encore certaines solutions commerciales n’ont détecté aucun problème, malgré ce droit de modification.

Nous remarquons l'absence de User1 dans le résultat des scans de l'outil de scan des ACL.

III. Illustration du processus de compromission

Revenons maintenant sur notre machine, connectée avec un compte utilisateur standard disposant d’un droit en modification sur le dossier « Scripts » d’une GPO.

Nous allons créer un simple script .bat, car dans de nombreux cas :

• Les politiques de l’entreprise interdisent PowerShell
• Les EDR réagissent dès qu’un script .ps1 est détecté

L’idée ici est de rester discret tout en exploitant une faille réelle.

A. Étape 1 : création du script

Dans le dossier Machine\Scripts\Startup de la GPO ciblée, nous créons un fichier texte, que nous nommerons en Exploit_ACL_HardenAD.bat. Ce script exécute la commande net localgroup pour ajouter l’utilisateur user1 dans le groupe Administrateurs local de Windows.

Étant donné que cette GPO est liée à la racine du domaine, elle s’appliquera à toutes les machines du parc. Même effet si elle était liée à une OU contenant des comptes ordinateurs.

Attention toutefois : cette attaque ne fonctionne que si la GPO a déjà un paramètre de script configuré (même vide) côté machine. Sinon, la machine ne saura pas qu’elle doit aller lire le contenu du dossier Scripts ; ceci est visible par la présence du fichier Scripts.ini.

B. Étape 2 : modification de scripts.ini

Pour que le système exécute le script au démarrage, il faut modifier (ou créer) le fichier scripts.ini associé à la GPO. Au lieu de modifier un script déjà en place, nous avons simplement ajouté une nouvelle ligne dans le fichier, pointant vers notre nouveau script.

Note : Il est tout à fait possible de référencer un chemin distant, par exemple, un partage réseau ou un chemin local sur la machine, ce qui permettrait d’éviter de copier le script dans le dossier SYSVOL, rendant ainsi l’opération encore plus discrète.

Cependant, ce n’est pas l’objectif de cet article. Notre approche reste préventive, dans un cadre de sensibilisation à la sécurité, et non offensive.

C. Test du script

Après redémarrage de la machine, vous pouvez constater que le script s'est bien exécuté, en créant un fichier texte et en ajoutant l'utilisateur standard User1 comme membre du groupe Administrateurs local de l'ensemble des machines.

D. Variante : injection de paramètres via Registry.pol

Une autre forme d’exploitation consiste à injecter un fichier Registry.pol directement dans la GPO. Cela permet de modifier des clés de registre à l’insu de l’administrateur.

Il suffit alors de vérifier si la GPO dispose d’une configuration active côté Utilisateur ou Machine, et de copier un fichier .pol préconfiguré dans le bon dossier (User ou Machine).

Une fois le fichier en place :

• gpupdate /force ou un redémarrage suffit
• Les paramètres sont appliqués à la prochaine session ou au démarrage

Dans notre exemple, nous avons la clé de registre WallpaperStyle configuré comme suivant avec une valeur 10.

Nous allons tout simplement modifier la valeur en 9 à partir de la machine de l'utilisateur. Nous devons éditer ce fichier :

Au niveau de la console GPO sur l'AD, nous pouvons bien voir que la nouvelle valeur a été prise en compte.

Nous pouvons aussi injecter des fichiers .pol pour forcer un paramètre de configuration, dans notre cas le fichier .pol permet de supprimer l'icône Corbeille du bureau. Ce n’est qu’un exemple.

Sans aucune interaction directe avec l’Active Directory ni action de l’administrateur, le nouveau paramètre a été appliqué, modifiant ainsi le comportement de la GPO initiale.

Étant donné que cette modification a été effectuée uniquement au niveau du fichier SYSVOL — sans passer par la console GPMC, elle ne génère pas de logs vu que la console ne fait que lire le contenu, il ne s'agit alors pas de modification d'une GPO à partir du serveur !

Par défaut, ce type de changement passe complètement sous les radars de nombreuses solutions de sécurité, y compris certains XDR comme Wazuh dans sa configuration standard. Ci-dessous, la GPO dans son état initial.

En exécutant un gpupdate ou en redémarrant simplement la machine, les paramètres injectés via le fichier Registry.pol seront appliqués automatiquement.

Dans notre exemple, cela a entraîné la suppression de l’icône de la corbeille sur le bureau, confirmant que la GPO a bien été interprétée par le système. Voici la GPO précédente directement impactée par notre changement :

Prérequis pour que cette méthode fonctionne :

Il est essentiel de noter qu’au moins une des sections de la GPO (Machine ou Utilisateur) doit être activée pour que les fichiers correspondants dans SYSVOL soient pris en compte.

Par exemple :

• Si la GPO ne contient que des paramètres côté Machine, alors copier un fichier Registry.pol dans le dossier User n’aura aucun effet.
• Et inversement : injecter un fichier Machine\Registry.pol dans une GPO utilisateur sera ignoré si la partie Machine n’est pas activée.

Vous pouvez vérifier cela en consultant le fichier GPT.ini de la GPO, qui contient une valeur Version codant séparément les parties User et Machine.

IV. Contre-mesure

L’objectif de cet article est avant tout de sensibiliser sur un risque réel… mais aussi de proposer une approche défensive concrète. Bien entendu, nous n’allons pas vous laisser sans solution !

Auditer en continu les changements au sein du dossier SYSVOL demande des ressources importantes.

Le vrai problème, comme vu précédemment, réside dans la présence silencieuse de mauvaises ACL déjà appliquées dans le passé : une fois attribuées, elles restent difficiles à détecter, et sont rarement surveillées activement.

Pour répondre à cela, nous avons développé un script nommé Audit-SysvolAcl.ps1.

Rendez-vous sur la page du projet nommé « Check_Sysvol_ACL ».

Téléchargez le fichier ou copiez le contenu du script dans un éditeur comme PowerShell ISE, ou exécutez-le directement depuis une machine standard.

L’exécution ne nécessite aucun privilège élevé et le script ne fait que lire des informations.

L’utilisation est simple, le script parcourt les différents fichiers des GPO présents dans le dossier SYSVOL, et identifie les ACL non conformes, inhabituelles ou suspectes.

Les délégations classiques, configurées via la console GPMC, sont prises en compte et considérées comme non dangereuses.

Attention à la performance :

Si votre dossier PolicyDefinitions contient de nombreux fichiers ADMX ou ADML, l’analyse peut prendre un peu plus de temps.

Toutefois, même sur un environnement de grande taille, l’exécution dépasse rarement quelques minutes. Dans notre exemple, le script affiche les résultats inhabituels en bleu avec le préfixe Warning, si tout est correct pour vous, vous n'aurez rien comme sortie.

À noter que cette fonctionnalité est également intégrée dans le module HardenSysvol, qui permet une analyse rapide et structurée du contenu du dossier SYSVOL.

Ce module propose également d’autres vérifications utiles, telles que :

• L’analyse des ACL appliquées aux dossiers et fichiers des GPOs
• La détection de fichiers sensibles ou potentiellement suspects
• Le repérage de scripts présents dans les GPOs (.bat, .vbs, .ps1, etc.)
• L’identification de fichiers injectés discrètement, comme un Registry.pol non tracé par GPMC

V. Remédiation

En cas de détection d’anomalie, il est fortement recommandé de se rapprocher des équipes en charge de l’infrastructure Active Directory afin de procéder à une vérification précise des délégations et des droits appliqués.

Microsoft recommande de limiter les droits de modification sur les objets GPO, ainsi que sur les fichiers du dossier SYSVOL aux seuls administrateurs autorisés.

Toute délégation en écriture, même justifiée à un instant donné, doit être régulièrement réévaluée.

Les actions correctives peuvent varier selon la nature de l’anomalie, mais dans tous les cas, il est crucial de :

• Supprimer les droits non justifiés,
• Vérifier l'intégrité des fichiers de la GPO,
• Documenter les changements afin d’éviter toute récidive ou confusion future.

VI. Conclusion

Cette analyse met en lumière une faille peu visible, mais bel et bien exploitable, dans la gestion des GPOs et du dossier SYSVOL.

Elle rappelle que la sécurité d’un environnement Active Directory ne repose pas uniquement sur les objets visibles dans la console GPMC, mais aussi sur le contenu réel et les propriétés effectives des fichiers partagés, souvent laissé de côté.

Une GPO active, même apparemment vide, peut se transformer en vecteur d’attaque si les droits d’accès ne sont pas strictement contrôlés.

Auditer régulièrement les ACL, surveiller le contenu des scripts et fichiers .pol, et comprendre le lien entre l’AD et le SYSVOL sont des étapes essentielles pour durcir son environnement face aux menaces silencieuses