Access privileges for resources in Active Directory Domain Services are usually granted through the use of an Access Control Entry (ACE). Access Control Entries describe the allowed and denied permissions for a principal (e.g. user, computer account) in Active Directory against a securable object (user, group, computer, container, organizational unit (OU), GPO and so on)
DACLs (Active Directory Discretionary Access Control Lists) are lists made of ACEs (Access Control Entries) that identify the users and groups that are allowed or denied access on an object. SACLs (Systems Access Control Lists) define the audit and monitoring rules over a securable object.
When misconfigured, ACEs can be abused to operate lateral movement or privilege escalation within an AD domain.
If an object's (called objectA) DACL features an ACE stating that another object (called objectB) has a specific right (e.g.
GenericAll) over it (i.e. over objectA), attackers need to be in control of objectB to take control of objectA. The following abuses can only be carried out when running commands as the user mentioned in the ACE (objectB) (see impersonation techniques).
Other tools like,
Add-DomainObjectAclfrom Powersploit's Powerview,
Set-Aclofficial Powershell cmdlets, or Impacket's dacledit.py script (Python) can be used in order to manually inspect an object's DACL.
At the time of writing, the Pull Request (#1291) offering that dacledit is still being reviewed and in active development. It has the following command-line arguments.
In order to navigate the notes, testers can use the mindmap below.
All of the aforementioned attacks (red blocks) are detailed in the child notes, except:
If attacker can write an ACE (
WriteDacl) for a container or organisational unit (OU), if inheritance flags are added (
0x01+ 0x02) to the ACE, and inheritance is enabled for an object in that container/OU, the ACE will be applied to it. By default, all the objects with
AdminCount=0will inherit ACEs from their parent container/OU.
With enough permissions (
GenericWrite) over a disabled object, it is possible to enable it again (e.g.
set-aduser "user" -enabled 1)
AddSelf, similar to
WritePropertyaccess right on the target's
Selfaccess right on the target's
Memberattribute, allowing the attacker to add itself to the target group, instead of adding arbitrary principals.
WriteAccountRestrictions, which refers to the
User-Account-Restrictionsproperty set, which contains enough permissions to modify the
msDS-Allowed-To-Act-On-Behalf-Of-Other-Identityattribute of the target objects, for Kerberos RBCD attacks
The following table should help for better understanding of the ACE types and what they allow.