Active Directory Access Control List – Attacks and Defense

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

• Active Directory Access Control
• Protected accounts and groups
• Delegated permissions
• ACLs-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 requestors token, and either denies or allows the requested access.

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 accounts object permissions are set and enforced via an automatic process. This process, named SDProp, ensures the permissions on the object remain secured.

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. Lets 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 groups 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 theoffensive use of ACLs, 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 wont 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?To date, our team hasn’t found a solid reason.

You should be careful with changing the AdminSDHolder. The Exchange 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. More information can be found in the documentation,Appendix C: Protected Accounts and Groups in Active Directory.

If you have a good reason to change AdminSDHolder manually, please leave it in the comments below.

However, if you did change the DACL on the AdminSDHolder and added permissions to an additional user or group, you probably extended the domains attack surface. Thats 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 Robbinsdid a great job with brining ACLs to the front, literally, with the announcement of 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 werent 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

Advanced Threat Analytics is part of the Microsoft Enterprise Mobility + Security Suite (E3) 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!