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
ACL’s-Only escalation path
Microsoft Windows environment implements access control by assigning security descriptors to objects stored in Active Directory. A
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
, 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
(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.
[caption id="attachment_55205" align="aligncenter" width="1009"]
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).[/caption]
[caption id="attachment_55215" align="aligncenter" width="1009"]
Figure 2 - Access permissions of "Authenticated Users" applied on "user1" account object (e.g. CN=user1,DC=atalab,DC=local)[/caption]
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.
[caption id="attachment_55225" align="aligncenter" width="1157"]
Figure 3 - Default ACE's in AdminSDHolder object - Windows 2012 R2[/caption]
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
of groups and
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 (
), Will Schroeder (
) and Andy Robbins (
) did a great job with bringing ACL’s to the front (literally…) with announcing BloodHound 1.3. Though the example in their
(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.
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.
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