AdminSDHolder abuse is a tier-0 persistence technique. The AdminSDHolder object holds a template access control list that a process called SDProp copies onto every protected (privileged) account roughly every 60 minutes. An attacker who writes an ACE, such as GenericAll for their account, onto AdminSDHolder gets that right re-applied to all admin accounts automatically, and it self-heals if a defender removes it from an individual account. Defend by auditing and monitoring the AdminSDHolder ACL.
What AdminSDHolder abuse is
To keep privileged accounts consistently locked down, AD stamps the ACL of the AdminSDHolder object onto every protected account on a timer (SDProp). That mechanism can be turned against defenders: whatever rights sit on AdminSDHolder are pushed to all admin accounts. An attacker who edits its ACL therefore plants a backdoor that the domain itself keeps re-applying.
How the attack works
With write access to the AdminSDHolder object (CN=AdminSDHolder,CN=System,...) the attacker adds an ACE granting their account GenericAll or force-reset-password, using PowerView Add-DomainObjectAcl or Impacket dacledit. Within about an hour SDProp copies that right onto every protected admin account. If a defender strips the right from one account, SDProp restores it, which is what makes the backdoor durable. Shown for defensive testing.
How to defend against it
Treat AdminSDHolder as a tier-0 object: baseline its ACL, restrict who can write it, and alert on any change. Compare protected accounts' ACLs against a known-good baseline to catch injected rights, and remember that fixing a single account is not enough, you must remove the ACE from AdminSDHolder itself or SDProp will put it back.
References
- [1]MITRE ATT&CK Enterprise Matrix(MITRE ATT&CK)
- [2]Microsoft: AdminSDHolder, protected groups and SDProp(Microsoft)
A backdoor on AdminSDHolder heals itself every hour. Talk to a security expert about auditing your tier-0 objects.