AdminSDHolder Modification
AdminSDHolder Modification is a persistence technique in which an attacker abuses the SDProp process in Active Directory to establish a persistent backdoor to Active Directory. Each hour (by default), SDProp compares the permissions on protected objects (e.g. the Domain Admins group) in Active Directory with those defined on a special container called AdminSDHolder. If they differ, it replaces the permissions on the protected object with those defined on AdminSDHolder. An adversary who modifies the AdminSDHolder container can establish a path of shadow administration and a means to regain administrative access to Active Directory.
Threat Summary
Target:
Active Directory
Tools:
ATT&CKĀ® Tactic:
ATT&CK Technique:
N/A
Difficulty
Detection:
Low
Mitigation:
Medium
Response:
Low
How AdminSDHolder Modification Works
Hover to see each step
Detect, Mitigate, and Respond
Difficulty: Low
Watching for changes to the AdminSDHolder container ACL is a good way to detect potentially malicious activity. In a normal environment, changes to AdminSDHolder should occur infrequently and follow change control processes. Event ID 5136 in the Audit Directory Service Changes subcategory of the Windows event log monitors directory service changes. To identify changes to the AdminSDHolder container ACL, monitor events which match the ObjectDN
“CN=AdminSDHolder,DC=System” and the AttributeLDAPDisplayName
is ‘nTSecurityDescriptor’.
The following XPath filter can be used in the Windows Event Viewer to detect modifications to the AdminSDHolder container ACL.
<QueryList> <Query Id="0" Path="Security"> <Select Path="Security"> *[System[(EventID=5136)]] and *[EventData[Data[@Name='ObjectDN'] and (Data='CN=AdminSDHolder,CN=System,DC=YourDomain,DC=com')]] and *[EventData[Data[@Name='AttributeLDAPDisplayName'] and (Data='nTSecurityDescriptor')]] </Select> </Query> </QueryList>
It is also possible to detect certain signs of DCShadow in Windows event logs. In order to mimic a domain controller, DCShadow must make several changes in Active Directory: 1) add a new NTDSDSA
object, and 2) add a global catalog (GC/<host>
) servicePrincipalName to a computer object that is not a known domain controller. After the attack is completed, these items are removed.
The Windows event log Audit Directory Service Changes subcategory includes Event ID 5136 and Event ID 5141, which can be analyzed to look for creation and deletion of server objects within sites.
Difficulty: Medium
The AdminSDHolder container is a core part of Active Directory. By default, only users with administrative privileges in Active Directory are able to modify their ACL. To mitigate the risk of unauthorized modification:
- Routinely audit AdminSDHolder permissions for unauthorized or unnecessary permissions.
- Do not allow users to possess administrative privileges across security boundaries. For example, an adversary who initially compromises a workstation should not be able to escalate privileges to move from the workstation to a server or domain controller. Eliminating these pathways to privilege escalation is essential.
- Aggressively embrace the principle of least privilege.
Difficulty: Low
If unauthorized permissions are granted on the AdminSDHolder container, the following actions can be taken to respond:
- Activate the incident response process and alert the response team
- Remove the newly added ACL; if done before the
SDProp
process runs (by default every 60 minutes) no new permissions on protected objects would be propagated - Reset the password of the user that performed the unauthorized modification of the AdminSDHolder container ACL. Optionally disable the user to a) force instantaneous replication to all domain controllers, and b) disrupt the adversary’s use of that account
- Quarantine the impacted machines for forensic investigation, as well as eradication and recovery activities