Active Directory Permissions Attack: Hackers Gain Persistence with AdminSDHolder
What is AdminSDHolder?
AdminSDHolder is an object in Active Directory, that by default, delegates permissions for certain privileged user accounts. According to Microsoft, the purpose of the AdminSDHolder object is “… to provide “template” permissions for the protected accounts and groups in the domain. AdminSDHolder is automatically created as an object in the System container of every Active Directory domain. Its path is: CN=AdminSDHolder,CN=System,DC=,DC=”. For more documentation from Microsoft on AdminSDHolder, and Protected Accounts and Groups in Active Directory, click here.
The access control lists (ACL) of the AdminSDHolder object acts as a template of security descriptors, copying permissions to all protected groups in Active Directory and their members. A security descriptor is a data structure that contains information related to the access control for a specific object, like owner, discretionary access control list (DACL), system access control list (SACL), security IDs (SID), and more. In other words, AdminSDHolder defines the permissions set on protected accounts and groups like Administrators, Domain Admins, Enterprise Admins, Global Admins, etc.
Security Descriptor Propagator (SDProp) is a scheduled process on the PDC Emulator (PDCE) that propagates permission changes made to AdminSDHolder object to the permissions of protected accounts and group and resets those objects’ permissions to match AdminSDHolder, if they differ. The SDProp service does this about every 60 minutes.
How Do Attackers Use AdminSDHolder and SDProp to Gain Persistence?
Attacker will abuse the SDProp process in Active Directory to establish a continual point of entry into Active Directory, also known as the AdminSDHolder modification persistence technique. As discussed above, SDProp compares permissions on protected objects, like the Domain Admins group, against those set in the AdminSDHolder ACL. If they differ, SDProp will replace the permissions on that protected object with those defined on AdminSDHolder. So, in an AdminSDHolder modification, once an attacker has gained administrative permissions, they typically will add a new user to AdminSDHolder, by modifying the ACL. Then, the next time the SDProp process runs, these new privileges will be applied to all protected objects.
If the organization happens to detect this change and tries to reverse it, 60 minutes later SDProp runs again and
reapplies the attacker’s permissions, as it will restore the ACLs listed in AdminSDHolder, previously modified by the attacker. In order for the organization to fix this and make the changes permanent, they would need to identify that the AdminSDHolder had been compromised and revoke the ACL changes made by the attacker. Unfortunately, with many organizations, in the meantime the attacker has collected enough sensitive data to cause serious financial and even reputational damage.
Best Practices to Prevent Active Directory Permission Attacks like AdminSDHolder
Best Practice #1
Relying solely on native tools, like event logs, can cause incomplete visibility leading to missed threats. Event logs are also often a target for attacks in order to blind native detection. With Cayosoft Guardian, easily monitor changes and automatic rollback changes made you Active Directories and to the AdminSDHolder object. Receive real-time alerts of suspicious activity to quickly identify and block unwanted privilege escalation before attackers have a chance to act, preventing costly compromise and potential downtime.
See how to monitor and restore changes to AdminSDHolder with Cayosoft Guardian.
Best Practice #2
Effective implementation of a least privilege model requires a way to centrally manage and secure user accounts and groups but also must include flexibility to properly balance control with operational efficiency and end-user needs. Cayosoft Administator uses roles and rules to enable least privileged delegation, targeting day-to-day admins, help desk, and end-users.