Référence pour les descripteurs de sécurité, les ACL, les ACE et le contrôle d'accès.
Abus des ACL Active Directory : quand un droit délégué ouvre un chemin d'attaque
Une délégation de droits peut simplifier l'administration d'Active Directory. Mais lorsqu'elle permet de modifier un compte, un groupe ou les permissions d'un objet sensible, elle peut aussi relier une identité ordinaire à un compte privilégié. Le risque ne tient pas au nom d'un droit isolé : il dépend de l'objet visé, de l'héritage des permissions et de la place de cet objet dans les chemins d'administration.
chemins d'attaque Active DirectoryQue contrôlent les ACL dans Active Directory ?
Les objets Active Directory possèdent des descripteurs de sécurité. Leur liste de contrôle d'accès discrétionnaire, ou DACL, définit quelles identités peuvent effectuer quelles opérations. Les entrées de contrôle d'accès, ou ACE, peuvent par exemple autoriser la lecture ou la modification d'attributs, la gestion des membres d'un groupe ou la modification des permissions elles-mêmes.
Ces droits sont nécessaires pour déléguer certaines tâches sans donner l'administration complète du domaine. Le problème apparaît lorsqu'une permission est trop large, accordée à un groupe trop vaste ou héritée par des objets plus sensibles que prévu. Cet héritage dépend toutefois des règles de propagation et des protections appliquées aux objets concernés.
Comment un droit excessif devient-il un chemin d'attaque ?
Un contrôle en écriture sur un objet peut permettre de modifier des attributs ou des appartenances. Un droit de modification de la DACL peut, lui, changer qui contrôle l'objet. Des permissions de contrôle total ou permettant de prendre possession d'un objet peuvent également étendre les capacités accordées sur un compte, un groupe, un ordinateur, une unité d'organisation ou le domaine.
Les noms de droits tels que GenericAll, WriteDACL ou WriteOwner sont donc des indicateurs à examiner dans leur contexte, pas des verdicts autonomes. Une permission déléguée sur une OU de postes n'a pas le même effet qu'une permission comparable sur un groupe d'administration, un compte de service privilégié ou une OU qui contient des contrôleurs de domaine.
Le chemin à risque se forme lorsque ces droits peuvent être combinés avec des appartenances de groupes, des permissions héritées ou des objets sensibles. C'est pourquoi une liste d'ACL isolée ne suffit pas : il faut relier chaque identité autorisée à l'objet qu'elle peut contrôler et à l'accès que cet objet ouvre.
Quels objets examiner en priorité ?
Commencez par les groupes d'administration et les comptes à privilèges, puis les comptes de service, les objets ordinateur et les unités d'organisation qui contiennent des systèmes sensibles. Vérifiez en particulier les droits permettant de modifier les membres, des attributs d'authentification ou la DACL, ainsi que le propriétaire de l'objet et l'héritage des permissions.
Les ACL des stratégies de groupe constituent un cas voisin, traité dans la fiche dédiée à l'abus des GPO. Ici, l'analyse porte d'abord sur les permissions des objets Active Directory et sur la manière dont elles créent un lien de contrôle entre une identité et une ressource sensible.
Réduire le risque sans casser la délégation
- Inventorier, pour les objets sensibles, les identités qui peuvent modifier leurs attributs, leurs membres, leur propriétaire ou leur DACL.
- Supprimer les droits trop larges et les délégations devenues inutiles ; limiter chaque délégation à l'OU et aux opérations réellement nécessaires.
- Attribuer les droits à des groupes de rôle maîtrisés plutôt qu'à des comptes individuels, puis vérifier les appartenances et les permissions héritées.
- Comparer les ACL effectives des groupes, comptes et OU sensibles à un modèle de référence afin de repérer les écarts.
- Activer l'audit approprié sur les objets sensibles et examiner les événements de modification de l'annuaire, notamment l'événement Windows 5136 lorsque la stratégie d'audit et la SACL de l'objet le permettent.
- Après correction, vérifier que les tâches d'administration prévues fonctionnent toujours avec les seules permissions requises.
Le bon indicateur : les chemins supprimés
Le but n'est pas de supprimer toute délégation. Il est de retirer les droits qui permettent à une identité non prévue de contrôler un objet sensible, puis de confirmer que cette correction rompt effectivement un chemin vers le Tier 0. Une revue priorisée des permissions peut ainsi réduire l'exposition sans transformer l'annuaire en modèle d'administration impraticable.
Techniques liées
- DCSync
Des permissions de réplication excessives sur le domaine peuvent permettre à une identité d'obtenir des secrets sensibles.
- Shadow Credentials
Le contrôle de certains attributs d'authentification d'un objet peut permettre l'ajout d'identifiants alternatifs.
- Abus des GPO
Le contrôle des permissions sur une stratégie de groupe peut ouvrir un chemin d'administration distinct, selon les droits effectifs sur la GPO et son périmètre d'application.
Sources techniques
Microsoft — Access Control in Active Directory Domain Services Microsoft — Active Directory Access Rights Référence pour GenericAll, WriteDACL et WriteOwner.
Microsoft — Access Control Inheritance Référence pour les permissions héritées et les règles de propagation.
Microsoft — Reducing the Active Directory Attack Surface Bonnes pratiques de réduction de la surface d'attaque Active Directory.
Microsoft — Event ID 5136 Journalisation des modifications des objets de l'annuaire, sous réserve de la configuration d'audit appropriée.
ANSSI — Recommandations pour l'administration sécurisée des SI reposant sur AD CERT-FR — Points de contrôle Active Directory SpecterOps / BloodHound — WriteDACL MITRE ATT&CK — T1098 MITRE T1098 ne doit pas être présenté comme la classification universelle de tous les abus d'ACL. Ce rapprochement est pertinent uniquement pour les scénarios impliquant les modifications de comptes ou de permissions entrant réellement dans son périmètre.