digitemis 
Sécurité offensive
Gouvernance & conformité
Protection des données
Dans l’univers d’Active Directory, chaque objet, qu’il s’agisse d’un utilisateur, d’un ordinateur ou d’une unité d’organisation (OU), est protégé par un ensemble de règles d’accès aussi puissantes que piégeuses : les DACL (Discretionary Access Control List). Mal configurées, ces listes de contrôle d’accès deviennent une porte d’entrée royale pour un attaquant, permettant des compromissions et escalades de privilèges silencieuses et parfois non détectées. Dans cet article, nous plongeons dans « l’enfer des DACL », un territoire méconnu, mais redoutablement exploitable lors d’un test d’intrusion.
Concepts de base : les ACL dans Active Directory
Avant de plonger dans les cas d’abus et d’exploitation, un petit rappel s’impose : qu’est-ce qu’une ACL dans Active Directory ? Et pourquoi est-ce si central pour la sécurité du système ?
Le Security Descriptor : la carte d’identité sécuritaire de chaque objet
Le Security Descriptor est la structure de sécurité associée à chaque objet Active Directory. Il comprend notamment les ACL, c’est-à-dire les règles qui définissent les accès autorisés (ou refusés) sur cet objet.
Un Security Descriptor contient plusieurs éléments clés :
- Le propriétaire (owner) : celui qui peut modifier les DACL de l’objet.
- La DACL (Discretionary Access Control List) : elle définit qui peut faire quoi sur l’objet (lecture, écriture, délégation, etc.).
- La SACL (System Access Control List) : elle spécifie les actions à auditer, c’est-à-dire celles qui déclencheront une entrée dans les journaux d’événements Windows.
- Des métadonnées de contrôle : par exemple, les options d’héritage ou les formats d’ACE étendus.
Cela dit, on se retrouve avec beaucoup d’acronymes sur les bras et un petit éclairage ne serait pas de trop !
ACL, ACE, DACL, SACL : de quoi parle-t-on ?
Chaque objet d’un environnement Active Directory est associé à un ensemble de permissions appelées ACL (Access Control List). Ces ACL sont elles-mêmes constituées d’ACE (Access Control Entities), qui décrivent ce qu’un utilisateur, groupe ou unité d’organisation est autorisé à faire ou non sur un objet Active Directory. Une ACE possède entre autres les éléments suivants :
- Type : spécifie s’il s’agit d’un droit accordé (allow) ou refusé (deny) ;
- Principal : l’identité à laquelle la règle s’applique (utilisateurs ou groupes) ;
- Permissions : les actions autorisées (écrire, modifier le mot de passe, déléguer, etc.) ;
- L’héritage : précise si l’ACE s’applique aux enfants, et à quels types d’enfants.
Le plus simple pour commencer à explorer ces permissions est de se rendre dans les propriétés de sécurité avancées d’un utilisateur dans la console Active Directory Users and Computers (ADUC) :
À l’aide de la figure 1, décortiquons le Security Descriptor de l’utilisateur g.debailly. L’onglet « Permissions » affiche la DACL : elle contient toutes les ACE, listées dans la section « Permission entries ». L’onglet « Auditing » correspond à la SACL, qui sert à définir quelles actions doivent être journalisées. En haut, la ligne « Owner » correspond à l’utilisateur ou groupe ayant la propriété de l’objet, et pouvant modifier les ACL associées.
La ligne en surbrillance bleue autorise (Allow) l’utilisateur lui-même (SELF) à changer son propre mot de passe, mais uniquement pour cet objet utilisateur spécifique (g.debailly), et sans que cela soit hérité d’un autre objet.
Quand on parle d’exploitation, c’est alors bien la DACL qui est la clé. Une DACL mal configurée peut autoriser un administrateur standard à modifier un compte, déléguer des droits, ou même effectuer un DCSync sans être administrateur.
Le casse-tête de l’héritage
L’un des grands pièges des DACL dans Active Directory, c’est l’héritage. Une permission définie sur une OU peut se propager à tous les objets enfants, y compris des comptes critiques. En pratique, cela évite à un administrateur de devoir redéfinir manuellement les ACL pour chaque utilisateur, groupe ou ordinateur dans une OU : on définit les règles en haut, elles s’appliquent en cascade.
Exemple concret : un administrateur accorde au groupe Helpdesk le droit « Reset password » sur les comptes contenus dans l’OU « Utilisateurs Standards ». Pour ce faire, il applique la permission au niveau de l’OU, en activant l’héritage : ainsi tous les objets enfants (utilisateurs et groupes) reçoivent automatiquement une ACE du type : Allow / Helpdesk / Reset password. Problème : parmi ces utilisateurs se trouve un compte privilégié oublié (svc_backup par exemple), qui possède des droits d’administration locale ou un accès à des ressources sensibles. Dès lors, un simple membre du groupe Helpdesk peut réinitialiser le mot de passe de ce compte, le compromettre et accéder aux ressources sensibles.
À cela s’ajoute la complexité liée à la visualisation : même des outils comme ADUC (Active Directory Users and Computers) ne montrent qu’une partie de la vérité. Il faut souvent passer par PowerShell ou Bloodhound pour avoir une vue fidèle et complète des droits réellement en place.
Pourquoi c’est un enfer : complexité et méconnaissance
Pour beaucoup d’administrateurs, les DACL dans Active Directory restent une boîte noire, et pour cause : leur fonctionnement est à la fois complexe, peu documenté, et piégé par l’héritage automatique. Résultat : même avec les meilleures intentions, on crée souvent des trous de sécurité sans le savoir.
Une logique puissante, mais peu intuitive
Le système de permissions d’Active Directory repose sur une logique binaire et hiérarchique, qui peut vite devenir contre-intuitive. À cela s’ajoutent des dizaines de types de droits possibles, des héritages parfois implicites, et des règles de priorité (comme le Deny qui surclasse un Allow).
Prenons un scénario possible : un administrateur, voulant renforcer la sécurité de son domaine, décide de créer une ACE de type Deny / Domain Users / Reset password sur un compte sensible, comme notre fameux compte de service utilisé pour les sauvegardes svc_backup.
L’intention est bonne : éviter que n’importe quel utilisateur puisse réinitialiser ce mot de passe.
Le problème, c’est que ce compte svc_backup est également administré par le groupe Support Technique, qui dispose par ailleurs d’une ACE Allow / Support Technique / Reset password héritée depuis une OU.
Le résultat est le suivant :
- Les membres du groupe Support Technique appartiennent également à Domain Users (un comportement par défaut la plupart du temps) ;
- L’ACE de type Deny sur Domain Users prend le pas sur le Allow explicite hérité pour Support Technique ;
- In fine, aucun membre de Support Technique ne peut plus réinitialiser le mot de passe du compte svc_backup, malgré l’intention inverse de l’administrateur.
Et le tout, sans aucun message d’erreur clair. Dans l’interface graphique, tout semble normal : les deux ACE sont bien présentes. C’est uniquement en comprenant la logique d’évaluation (priorisation des Deny) que l’on peut diagnostiquer le problème.
Ce genre de scénario alimente ce qu’on appelle parfois l’effet « boîte noire » des DACL : le comportement effectif ne correspond plus à ce que l’opérateur croit avoir configuré.
Des erreurs classiques en entreprise
On sait qu’une infrastructure Active Directory est vouée à évoluer dans le temps. Au fil des années, la gestion des ACL se transforme souvent en un mille-feuille non maîtrisé de permissions. Chaque modification, aussi légitime soit-elle à un instant T, vient s’empiler sur les précédentes… rarement revue, jamais nettoyée.
Prenons un cas réaliste :
- 2016 : l’équipe IT délègue au groupe Support Niveau 2 le droit de réinitialiser les mots de passe dans l’OU Utilisateurs.
- 2018 : un stagiaire du pôle DevOps crée un script pour automatiser la création d’utilisateurs, qui applique lui-même un set personnalisé d’ACL sur chaque nouvel objet.
- 2020 : pour contourner une limitation, un admin accorde un GenericWrite au groupe Opérations sur un compte de service critique « juste pour un test temporaire ».
- 2023 : un audit révèle un défaut d’accès sur certains comptes VIP, une ACE est ajoutée en urgence pour corriger… sans documenter l’exception.
Chacune de ces actions est isolément compréhensible. Mais mises bout à bout, elles créent une situation illisible :
Le script automatisé mis en place en 2018, par exemple, continue d’ajouter silencieusement des ACE sur chaque nouvel utilisateur, même si l’outil auquel il servait a été abandonné depuis. Résultat : ces permissions restent techniquement actives, même si plus personne ne sait à quoi elles correspondent ni qui les a initiées.
L’exception temporaire accordée en 2020 au groupe Opérations, censée être supprimée après une intervention, est toujours présente dans la DACL. Elle introduit une permission GenericWrite sur un compte de service critique, sans que cela apparaisse clairement à l’œil nu.
En résumé, les DACL sont un angle mort dans la majorité des environnements Active Directory. Trop complexes pour être gérées proprement, trop silencieuses pour être détectées facilement, elles constituent une mine d’or pour un attaquant et un cauchemar pour la défense.
Outils et techniques pour identifier et exploiter les DACL
Comprendre les permissions « exploitables » : GenericAll, GenericWrite, WriteDACL etc.
Toutes les permissions définies dans une DACL ne se valent pas. Certaines sont purement informatives, d’autres très ciblées… mais quelques-unes accordent des permissions élevées aux utilisateurs qui en bénéficient. En test d’intrusion, ce sont elles que l’on traque en priorité.
Cette figure illustre la fenêtre Active Directory permettant d’éditer une ACE, et de définir précisément ce que l’on autorise ou interdit. C’est là que s’exprime toute la richesse de ce modèle. On y trouve d’abord les droits dits « génériques », comme Full control, Modify permissions, qui correspondent à des ensembles préconfigurés de permissions. Ces options sont pratiques, mais souvent trop larges ou trop implicites pour être réellement maîtrisées. Passons en revue celles qui sont intéressantes du point de vue d’un attaquant :
GenericAll (Full control) – C’est le Graal absolu : cette permission donne un contrôle total sur l’objet cible.
GenericWrite (Write all properties) – Un peu moins puissant que GenericAll, ce droit permet d’écrire sur certains attributs de l’objet, en fonction de ce qui est autorisé dans le schéma Active Directory.
WriteDACL (Modify permissions) – Avec ce droit, un utilisateur peut modifier la DACL de l’objet comme s’il en était le propriétaire : ajouter/supprimer des ACE, changer les droits attribués à d’autres.
WriteOwner (Modify owner) – Ce droit permet de changer le propriétaire de l’objet. Et comme le nouveau propriétaire peut modifier la DACL, cela crée un enchaînement :
- S’affecter en tant que propriétaire de l’objet ;
- En tant que nouveau propriétaire, modifier la DACL (WriteDACL) ;
- S’ajouter GenericAll (ou tout autre droit) ;
- Prendre le contrôle total du compte.
AllExtendedRights (All extended rights) – Ce droit donne accès à toutes les permissions étendues disponibles sur un objet, y compris :
- ForceChangePassword (sur les utilisateurs) ;
- AddMember (sur les groupes) ;
- ReadLAPSPassword (sur les ordinateurs) ;
- Gestion de certaines délégations de service (Kerberos, certificats, etc.).
Outils pour analyser les DACL
Pour identifier les permissions « exploitables », plusieurs outils sont disponibles.
On pense tout d’abord à Bloodhound, qui est aussi intéressant du point de vue attaquant que défensif. Projet disponible en open source, il est devenu un incontournable pour visualiser les relations entre les objets Active Directory et identifier les chemins d’escalade de privilèges sous la forme d’un graphe en interface graphique.
Chaque flèche représente une permission exploitable, révélée lors de la phase de collecte des ACL. Sur la capture, le nœud de gauche correspond à un utilisateur standard, r.sisteron, a priori sans privilège particulier. Pourtant, le graphe montre clairement qu’il détient une permission GenericAll sur un autre compte, qui lui-même possède des droits étendus (GenericWrite) sur un objet hautement sensible : un compte membre du groupe « IT » pouvant se connecter en Bureau à distance sur le contrôleur de domaine. Ce type de représentation met en évidence ce que l’œil humain ne perçoit pas dans l’interface graphique d’ADUC : la chaîne d’héritages, de délégations et de droits implicites qui permet à un utilisateur de remonter jusqu’à une position de contrôle total sur le domaine. Dans un environnement de production, ce chemin n’est pas toujours direct : il peut passer par des comptes de service, des objets GPO, ou des OU entières mal sécurisées. BloodHound synthétise ces enchaînements en quelques clics, ce qui en fait un outil redoutablement efficace, autant pour les attaquants que pour les auditeurs.
Dans la même veine, il est possible de citer l’équivalent français AD Miner qui permet également de repérer les permissions dangereuses dans une jolie interface graphique.
Par ailleurs, PowerView est un module PowerShell offensif, issu du projet PowerSploit, qui permet une approche plus granulaire que Bloodhound. Il est particulièrement utile lorsque l’on souhaite travailler de manière ciblée, ou dans des contextes où la collecte graphique complète n’est pas possible.
Avec PowerView, un attaquant peut analyser les DACL d’un seul objet, rechercher les comptes ayant des droits abusifs sur des groupes ou comptes privilégiés, ou encore scripter l’analyse de chemins d’attaque grâce au cmdlet Find-InterestingDomainAcl qui va notamment se focaliser sur les permissions dangereuses (WriteDACL + GenericWrite, etc.).
Enfin, ADACLScanner est également un script PowerShell défensif à l’origine, mais extrêmement utile pour l’attaquant. Il fournit une vue détaillée, texte, et filtrable des ACE d’un objet ou d’un ensemble d’objets AD, un peu sur le même principe que PowerView.
Comment se défendre ? Audit et durcissement des ACL
Auditer régulièrement les DACL sensibles
Du côté des équipes IT et sécurité, il est essentiel d’auditer les DACL de façon proactive. Car les DACL sont souvent modifiées pour déléguer des tâches… mais rarement revues ensuite. Un audit régulier permet de :
- Repérer les dérives de permissions ;
- Identifier des configurations risquées (héritage non maîtrisé, Full Control abusif, etc.) ;
- Documenter et contrôler les droits sur des objets critiques.
Paradoxalement les outils permettant d’auditer les règles vont être les mêmes que ceux exposés ci-dessus et utilisés par les attaquants. On peut cependant mentionner les outils d’audit Active Directory tels que PingCastle ou PurpleKnight.
En matière de méthodologie, il est recommandé de prioriser l’analyse de certains objets, parmi lesquels :
- Les comptes à privilèges (Domain Admins, Enterprise Admins, etc.) ;
- Les OU contenant des ressources critiques ;
- Les groupes de sécurité privilégiés ;
- Le conteneur AdminSDHolder, qui propage des ACL via le mécanisme SDProp.
Surveiller les modifications de DACL en continu
Bien que des audits ponctuels soient une bonne pratique, permettant de limiter la surface d’attaque, ils ne peut pas se suffire à eux-mêmes : il faut mettre en place également une surveillance continue. Lorsque l’audit avancé sur les contrôleurs de domaine et que la génération des logs de sécurité est activée (via la SACL), plusieurs types d’événements peuvent remonter dans le journal Security.
Voici ceux qui sont essentiels à suivre pour détecter des modifications suspectes de DACL, des escalades de privilèges ou des actes non autorisés.
| Événement | Dénomination | Description |
| 4662 | An operation was performed on an object | Permet de surveiller des opérations de modification sur les objets Active Directory, y compris les changements de permissions (ACL), d’attributs, ou d’appartenance à un groupe |
| 4670 | Permissions on an object were changed | Permet de détecter un changement de DACL |
| 5136 | A directory service object was modified | Permet de détecter qu’un attribut a été modifié. Dans notre cas, l’attribut sera nTSecurityDescriptor (la DACL) |
| 4907 | Auditing settings on object were changed | Permet de détecter un changement de SACL (si un attaquant souhaite désactiver l’audit pour ne pas laisser de traces) |
Intégrez ces logs à votre SIEM pour déclencher des alertes en cas de changement sur des objets critiques.
Appliquer le principe du moindre privilège
Le principe du moindre privilège est essentiel pour limiter les risques liés aux DACL. Voici quelques bonnes pratiques :
- Restreindre les permissions : Accordez uniquement les droits nécessaires pour accomplir une tâche spécifique.
- Éviter les permissions génériques : Préférez des permissions granulaires (comme Reset password) plutôt que des droits génériques (comme GenericAll).
- Désactiver l’héritage par défaut : Lorsque cela est possible, désactivez l’héritage des permissions pour éviter que des droits non intentionnels ne s’appliquent à des objets sensibles.
- Appliquer un modèle en Tier dans son environnement Active Directory : bien que celui-ci demande des changements architecturels relativement importants, il est très efficace pour empêcher toute élévation de ses privilèges.
Documenter et revoir les permissions
Chaque modification de DACL doit être documentée, avec une justification claire et une date de révision. Une revue périodique des permissions permet de supprimer les droits obsolètes et de corriger les erreurs accumulées au fil du temps.
