Reference for security descriptors, ACLs, ACEs and access control.
Active Directory ACL abuse: when a delegated right opens an attack path
Delegating rights can simplify Active Directory administration. But when it allows an account, a group or the permissions of a sensitive object to be modified, it can also link an ordinary identity to a privileged account. The risk does not lie in the name of an isolated right: it depends on the target object, permission inheritance and the place of that object in administration paths.
Active Directory attack pathsWhat do ACLs control in Active Directory?
Active Directory objects have security descriptors. Their discretionary access control list, or DACL, defines which identities can perform which operations. Access control entries, or ACEs, can for example allow attributes to be read or modified, group membership to be managed or the permissions themselves to be modified.
These rights are needed to delegate certain tasks without granting full domain administration. The problem arises when a permission is too broad, granted to an overly large group or inherited by objects more sensitive than intended. This inheritance nevertheless depends on the propagation rules and protections applied to the objects concerned.
How does an excessive right become an attack path?
Write control over an object can allow attributes or memberships to be modified. A right to modify the DACL can change who controls the object. Full control permissions, or permissions to take ownership of an object, can also extend the capabilities granted over an account, a group, a computer, an organizational unit or the domain.
Right names such as GenericAll, WriteDACL or WriteOwner are therefore indicators to be examined in context, not standalone verdicts. A permission delegated on a workstation OU does not have the same effect as a comparable permission on an administration group, a privileged service account or an OU containing domain controllers.
The risky path forms when these rights can be combined with group memberships, inherited permissions or sensitive objects. That is why an isolated list of ACLs is not enough: each authorized identity must be linked to the object it can control and to the access that object opens.
Which objects should be reviewed first?
Start with administration groups and privileged accounts, then service accounts, computer objects and organizational units containing sensitive systems. Check in particular the rights allowing members, authentication attributes or the DACL to be modified, as well as the object owner and permission inheritance.
Group Policy ACLs are a related case, covered in the sheet dedicated to Group Policy abuse. Here, the analysis focuses first on the permissions of Active Directory objects and on how they create a control link between an identity and a sensitive resource.
Reducing the risk without breaking delegation
- For sensitive objects, inventory the identities that can modify their attributes, members, owner or DACL.
- Remove overly broad rights and delegations that are no longer needed; limit each delegation to the OU and operations actually required.
- Assign rights to controlled role groups rather than to individual accounts, then check memberships and inherited permissions.
- Compare the effective ACLs of sensitive groups, accounts and OUs with a reference model to identify deviations.
- Enable appropriate auditing on sensitive objects and review directory modification events, notably Windows event 5136 when the audit policy and the object's SACL allow it.
- After remediation, check that the intended administration tasks still work with only the required permissions.
The right indicator: paths removed
The aim is not to remove all delegation. It is to remove the rights that allow an unintended identity to control a sensitive object, then to confirm that this fix actually breaks a path to Tier 0. A prioritized review of permissions can thus reduce exposure without turning the directory into an unworkable administration model.
Related techniques
- DCSync
Excessive replication permissions on the domain can allow an identity to obtain sensitive secrets.
- Shadow Credentials
Control over certain authentication attributes of an object can allow alternative credentials to be added.
- Group Policy abuse
Control over the permissions of a Group Policy Object can open a separate administration path, depending on the effective rights over the GPO and its scope.
Technical sources
Microsoft — Access Control in Active Directory Domain Services Microsoft — Active Directory Access Rights Reference for GenericAll, WriteDACL and WriteOwner.
Microsoft — Access Control Inheritance Reference for inherited permissions and propagation rules.
Microsoft — Reducing the Active Directory Attack Surface Best practices for reducing the Active Directory attack surface.
Microsoft — Event ID 5136 Logging of directory object changes, subject to the appropriate audit configuration.
ANSSI — Recommendations for the secure administration of AD-based information systems (FR) CERT-FR — Active Directory checkpoints (FR) SpecterOps / BloodHound — WriteDACL MITRE ATT&CK — T1098 MITRE T1098 should not be presented as the universal classification of all ACL abuse. This mapping is relevant only for scenarios involving account or permission changes that actually fall within its scope.