Active Directory delegations: finding and cleaning up excessive rights on OUs and objects

How an ACL becomes an attack path

Every directory object carries an access control list. Some rights are, in practice, equivalent to taking control of the object:

• GenericAll: full control, including resetting a user's password or adding members to a group;
• WriteDacl: changing permissions, and therefore granting yourself any right afterwards;
• WriteOwner: becoming the owner, which implicitly grants the right to change permissions;
• GenericWrite or write access to specific attributes: for example servicePrincipalName to make an account Kerberoastable, msDS-KeyCredentialLink to add shadow credentials, or a computer's resource-based constrained delegation attribute;
• Extended rights: password reset or, on the domain object, the replication rights that enable a DCSync attack.

An attacker does not need to be an administrator: compromising an account that holds one of these rights over a more privileged object is enough, and the chain continues from there.

Common sources of excessive rights

In the directories we audit, the same causes keep coming up:

1. password reset delegations set at the domain root or on an OU that also contains administrator accounts;
2. permissions inherited from older Exchange versions, sometimes very broad on the domain object, never reduced;
3. rights granted to individual accounts rather than groups, impossible to keep track of;
4. objects owned by a standard user, such as whoever joined a computer to the domain;
5. use of built-in groups such as Account Operators, whose rights are wider than people think.

Analysis tools

Reading ACLs one by one is not realistic. Attack path analysis tools such as BloodHound collect permissions and memberships, then compute the possible chains to privileged groups. PingCastle, Purple Knight or ADACLScanner flag dangerous delegations and allow successive states to be compared. These tools should be used with the security team's approval and with the monitoring team informed, since attackers use them too.

Cleaning up without breaking things

Clean-up follows a careful approach:

• back up the security descriptors of the OUs and objects concerned before any change;
• define the target delegation model: which groups, which rights, on which OUs, consistent with the tiering model;
• keep administrator accounts in dedicated OUs, with no helpdesk delegation;
• replace rights granted to individual accounts with groups;
• reassign ownership of sensitive objects to Domain Admins;
• handle legacy Exchange permissions according to Microsoft's current guidance.

Then run the analysis again: the number of paths to privileged groups should fall, and stay down over time.

For the clean-up to last, new drift must be detected too. Directory service changes auditing, combined with system access control lists on sensitive objects, generates events when a security descriptor is modified (event 5136 on domain controllers). Forwarded to the SIEM, they make it possible to alert on any change to the permissions of the domain object, AdminSDHolder or Tier 0 OUs. Re-running the attack path analysis at regular intervals, quarterly for example, completes the picture and provides a simple metric to track.

What an audit checks

• Control rights (GenericAll, WriteDacl, WriteOwner, GenericWrite) on the domain object, AdminSDHolder and sensitive OUs.
• Replication rights granted outside domain controllers and legitimate accounts.
• Password reset delegations and their actual scope.
• Owners of privileged objects and sensitive computer accounts.
• The number of attack paths to privileged groups and how it evolves.