First published on CloudBlogs on Sep 18, 2017
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.
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.
Abstract
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.
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
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.
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.
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.
- Active Directory Access Control
- Protected accounts and groups
- Delegated permissions
- ACL’s-Only escalation path
- Hybrid path
- Takeaways
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
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. Examples:- 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 ATAResearch@Microsoft.com . 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
- For more details refer to Protected Accounts and Groups in Active Directory
- Exchange 2010 and Resolution of the AdminSDHolder Elevation Issue
- Forensics: Active Directory ACL investigation
- Introducing BloodHound
- BloodHound 1.3 - The ACL Attack Path
Published Sep 08, 2018
Version 1.0
![](\"https://techcommunity.microsoft.com/t5/image/serverpage/image-id/49174i627BD6A4E8876BE1\")
\n 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]\n\n[caption id=\"attachment_55215\" align=\"aligncenter\" width=\"1009\"]\n ![](\"https://techcommunity.microsoft.com/t5/image/serverpage/image-id/49175i9B083F7E84DF9978\")
\n Figure 2 - Access permissions of \"Authenticated Users\" applied on \"user1\" account object (e.g. CN=user1,DC=atalab,DC=local)[/caption]\n\nAmong 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.\n ![](\"https://techcommunity.microsoft.com/t5/image/serverpage/image-id/49176i6ED6125D344D701E\")
\n Figure 3 - Default ACE's in AdminSDHolder object - Windows 2012 R2[/caption]\n\nSDProp 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\n \n members\n \n of groups and\n \n disables\n \n \n inheritance\n \n on all protected accounts.\n\nSDProp 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.\n ![](\"https://techcommunity.microsoft.com/t5/image/serverpage/image-id/49177i81C594D6D14DC824\")
\n 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\n \n is not part\n \n of the accounts list that is protected by the SDProp mechanism.\n \n 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.\n \n ![](\"https://techcommunity.microsoft.com/t5/image/serverpage/image-id/49178i1015CD6F903E4B77\")
\n 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.\n