Skip to content

Enterprise Mobility + Security

Recently there has been a lot of attention and a few different blog posts (references at the end of the post) regarding the use of Discretionary Access Control List (DACL) for privilege escalation in a Domain environment. This potential attack vector involves the creation of an escalation path based in AD object permissions (DACLs). For example, gaining “Reset Password” permissions on a privileged account is one possible way to compromise it by DACL’s path.

Although DACL permissions are not the easiest topic to cover in one post and should be digested slowly, there are examples of potential attack scenarios we want to share. The following blog tries to shed some light on the subject, present the possible escalation paths and suggest relevant mitigations.


  • Active Directory Access Control
  • Protected accounts and groups
  • Delegated permissions
  • ACL’s-Only escalation path
  • Hybrid path
  • Takeaways

Microsoft Windows environment implements access control by assigning security descriptors to objects stored in Active Directory. A Security Descriptor is a set of information attached to every object and contains four security components. In this blog, we will focus on the object creator (which user owns the object) and the Discretionary Access Control List (DACL – which users and groups are allowed or denied access) components. The two others components are the SACL, which defines which users and groups’ access should be audited and the inheritance settings of access control information.

A DACL is a list of access control entries (ACE). Each ACE represents a security identifier (SID) which specifies the access rights allowed or denied for that SID. When an access request is performed to an object, the system checks the ACEs in a sequence until it finds one or more ACEs that match the SIDs in the requestor’s token, and either denies or allows the requested access.

Figure 1 – The DACL (discretionary access control list) applied on an OU named “New York”. By default, permissions of Active Directory objects are controlled by the built-in security accounts (Users & Groups) and they populate most, if not all, of the Active Directory objects DACL. Those ACEs are usually inherited from the domain object itself (e.g. DC=atalab,DC=local).
Figure 2 – Access permissions of “Authenticated Users” applied on “user1” account object (e.g. CN=user1,DC=atalab,DC=local)

Among the domain accounts, the most attractive ones are the privileged built-in accounts, e.g Domain Admins, Enterprise Admins, etc. These privileged built-in accounts are protected by a mechanism, Security Descriptor propagation or SDProp in short, that enforces a secured ACL on the account objects in Active Directory. This enforcement is done in order to prevent unauthorized modifications to these privileged accounts.

Protected Accounts and Groups

Most of the privileged built-in accounts are considered protected accounts and groups. Each of the protected account’s object permissions are set and enforced via an automatic process. This process, named SDProp, ensures the permissions on the object remain secured.

Figure 3 – Default ACE’s in AdminSDHolder object – Windows 2012 R2

SDProp runs by default every sixty minutes. In every run, the permissions on the protected accounts are reset to match those of the AdminSDHolder container, located under the system container in the domain partition. The process applies its task recursively on all members of groups and disables inheritance on all protected accounts.

SDProp significantly reduces the potential attack vector against the privileged built-in accounts. However, there could be scenarios exposing the DACLs on non-built-in privileged accounts leading to potential escalation. Let’s have a look at some of these scenarios.

Scenario 1: Delegated permissions

Active Directory allows an administrator to delegate permissions to regular domain accounts, e.g. user, group, computer, without adding the account to an administrative group. Commonly delegated permissions include “Reset Password” on user accounts, usually granted to helpdesk personnel, and the ability to add “New Member” to a group, often granted to the group’s business owners. In addition, the owner of an object can modify permissions and delegate specific permissions to other users, for example, updating the title of a user account delegated to an HR service account.

When talking about the offensive use of ACL’s, adversaries may try to escalate privileges by abusing the delegated permissions and obtain access to accounts which have specific permissions on other AD objects.


  • A low-privileged account who has “Modify Group Membership” permissions on a help-desk group, may add any account to that group and effectively gain the same permission as the privileged group.
  • A helpdesk group which has the “Reset Password” permissions on an organization unit (OU) in the domain, will effectively gain full object control on the OU and all its child objects, as the OU permissions are inherited by its child objects (excluding objects protected by the SDProp process).

When the examples above are combined, they form a path. Attackers may use the path available after compromising the first account to gain permissions on multiple other objects. This “ACL path” will allow the attackers to escalate privileges to a privileged account which is not part of the accounts list that is protected by the SDProp mechanism.

However, an attacker won’t be able to escalate privileges to privileged built-in accounts, as the ACLs on these accounts are protected by the SDProp mechanism.

Scenario 2: Changing the default ACL on the AdminSDHolder


Why would you change AdminSDHolder manually? No idea.

You should be careful with changing the AdminSDHolder, the Exchange team faced several issues with that (in a release candidate) which were all fixed for RTM as the granted permissions on the AdminSDHolder enabled an elevation of privilege scenario that is unacceptable in any environment. If you have a good reason (as we couldn’t find one) please leave us comments at

However, if you did change the DACL on the AdminSDHolder and added permissions to an additional user or group, you probably extended the domain’s attack surface. That’s because, with the new permission, there is an additional user or group that can manage the privileged built-in accounts.
These accounts which were granted permissions on the AdminSDHHolder can be compromised (and often are less protected and monitored than the privileged built-in accounts). Once compromised they can be used as the initial user in the “ACL path” to the privileged built-in account (e.g. – a domain admin).

Rohan Vazarkar (@CptJesus), Will Schroeder (@harmj0y) and Andy Robbins (@_wald0) did a great job with bringing ACL’s to the front (literally…) with announcing BloodHound 1.3. Though the example in their blog post (on how to plan an ACL-only attack path ending as a domain admin) may prove difficult in practice, due to the AdminSDHolder and SDProp (in case the permissions weren’t modified).

The hybrid path

However, the ACL attack path could be combined with other lateral movement scenarios. For example, an ACL attack-path could be used to compromise a helpdesk user, which in turn, can be used to connect to a server where a Domain Admin user is logged-in, then compromising the DA account.

Both attack surfaces in the hybrid path can be visualized in a graph and allow Blue Teams as well as Red Teams to map their Domain environments. BloodHound 1.3 is an open-source tool which uses a PowerShell script to collect the required data for creating the graph and graph theory to find potential attack paths. If you find a path with no obstacles, it probably leads somewhere.

ATA can detect multiple reconnaissance methods, including the ones used by BloodHound, to detect advanced attacks happening in your network.

Additional Resources


Advanced Threat Analytics is part of the Microsoft Enterprise Mobility + Security Suite or the Microsoft Enterprise CAL Suite (ECAL). Start a trial or deploy it now by downloading an Advanced Threat Analytics 90-day evaluation.

Ask questions and join the discussion with our team on the Microsoft Advanced Threat Analytics Tech Community site!

This blog post is authored by

Michael Dubinsky: Principal PM Manager, Microsoft Advanced Threat Analytics
Igal Gofman: Security Researcher, Microsoft Advanced Threat Analytics
Tal Maor: Security Researcher, Microsoft Advanced Threat Analytics