Modifying the Access Control List (ACL) of the AdminSDHolder container in Active Directory enables an attacker to achieve and maintain persistence in an already compromised domain, even if an administrator finds and removes the attacker’s permission on a protected object the AdminSDHolder controls.
How the AdminSDHolder Modification Attack Works
The following is a summarization of how the attack works:
- Attacker compromises privileged credentials (e.g. via phishing or social engineering, is already a privileged insider, by exploiting weak permissions, etc.)
- Attacker modifies AdminSDHolder by adding a new user to its Access Control List (ACL)
- Via SDProp, the AdminSDHolder permissions are pushed down to all protected objects every 60 minutes (by default) including privileged groups such as Domain Admins, Administrators, Enterprise Admins, and Schema Admins
- Even if an administrator sees an inappropriate permission on a protected object and removes it, within an hour those permissions will be put back in place by SDProp
Important Notes about AdminSDHolder Modification:
- The Access Control List (ACL) of the AdminSDHolder object is used as a template to copy permissions to all “protected groups” and their members in Active Directory. Protected groups and their members are flagged in Active Directory using an attribute called “adminCount” which will be set to 1 for protected users and groups. Once a user is removed from a privileged group, they still maintain the adminCount value of 1 but are no longer considered a protected object in Active Directory. That means the AdminSDHolder permissions will not be applied to them. However, they will likely have a version of the AdminSDHolder permissions still set because the inheritance of their permissions will still be disabled as a remnant of when they were protected by the AdminSDHolder permissions. Therefore, it is still useful to look at these objects and, in most cases, to turn on inheritance of permissions.
Watch this brief video of a AdminSDHolder Modification attack in action:
Potential Solutions and Mitigating Controls for the AdminSDHolder Modification Attack
Only users with administrative rights will be able to modify AdminSDHolder permissions, so preventing the compromise of administrative credentials is the most effective mitigation of this attack.
If an administrative account is compromised, however, monitoring AdminSDHolder object permission changes and alerting is critical to detection. These changes should never happen so any alert is worth immediately investigating and reverting.
Reporting on objects with an adminCount value of 1 is also important and making sure they are still intended to have administrative rights. If they are not, put them in the right location and ensure they are inheriting permissions.
AdminSDHolder Modification Resources:
Related Attacks & Concepts: