AdminSDHolder SDProp Backdoor Active Directory Persistence: The Hourly Process for Permanent Privileged Access

What Is AdminSDHolder and SDProp

AdminSDHolder SDProp backdoor active directory persistence is the technique this guide breaks down in full: exactly how attackers plant permanent privileged access, how defenders detect it, and how to remediate it before it becomes a standing risk. AdminSDHolder is a container object that lives at CN=AdminSDHolder,CN=System,DC=<domain>,DC=<tld> in every AD domain, and SDProp — the Security Descriptor Propagator — is the background process that copies its ACL onto every object it protects, by default once an hour (Microsoft Learn — Appendix C: Protected Accounts and Groups in Active Directory).

SDProp runs every 60 minutes (by default) on the domain controller holding the PDC Emulator (PDCE) role. It compares the permissions on AdminSDHolder with the permissions on the domain's protected accounts and groups — and where they differ, it overwrites the object's ACL to match AdminSDHolder exactly. The interval is controlled by the AdminSDProtectFrequency DWORD value under HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters on the PDCE, valid from 60 to 7200 seconds; most environments never touch it and simply run on the 60-minute default.

The following built-in groups and accounts are protected by AdminSDHolder/SDProp in every AD domain:

Two side effects mark every protected object: the adminCount attribute is set to 1, and ACL inheritance from the parent OU is disabled permanently — until something explicitly clears it. Microsoft designed SDProp to stop privileged accounts from silently inheriting weaker permissions if someone moves them in the directory. It is the same underlying mechanism attackers already abuse for ACL abuse and DCSync on individual objects — this backdoor just moves the abuse one level up, onto the template object that feeds every protected account at once.

AdminSDHolder SDProp Backdoor Active Directory Persistence, Step by Step

The technique is not new — Sean Metcalf documented it in 2015 — and it still works exactly as described today, because it abuses an intentional mechanism rather than a bug (AD Security — Sneaky Active Directory Persistence #15). Unlike other Active Directory attack paths that chain several misconfigurations together to reach Domain Admin, this one only needs a single write to a single object.

Step 1 — Add a Rogue ACE to AdminSDHolder

An attacker who can already write to CN=AdminSDHolder,CN=System,DC=... — typically because they are Domain Admin/Enterprise Admin, or picked up WriteDacl/GenericWrite there through prior ACL abuse — grants a low-privilege or throwaway account Full Control (or GenericAll) directly on the AdminSDHolder object. In Metcalf's original write-up, an ordinary user account is given full control over AdminSDHolder itself. Nothing about that account changes — it still isn't a member of any privileged group, and it still looks unremarkable in a routine group-membership review.

Step 2 — Wait for (or Force) SDProp to Propagate It

On its next cycle — up to 60 minutes later — SDProp copies AdminSDHolder's ACL, rogue ACE included, onto every account and group with adminCount=1: Domain Admins, Enterprise Admins, every existing member's user object, and any account added to those groups afterward. The throwaway account never has to join Domain Admins; it only needs modify rights on the objects that matter. The cycle can also be forced immediately — by an administrator testing a change, or by an attacker impatient to confirm the backdoor took — via Ldp.exe, setting the RunProtectAdminGroupsTask attribute to 1 on the rootDSE (Microsoft Learn — Appendix C).

Step 3 — Keep Using Rights That Never Show Up as Group Membership

Because the ACE lives on the template object rather than on any single account, it comes back every time SDProp runs — even after a defender spots the rogue permission on one Domain Admin's user object and clears it there. Unless the fix is applied to AdminSDHolder itself, the next SDProp cycle silently re-applies it everywhere. That is what makes this persistence rather than a one-off privilege escalation: password rotations, account disabling, or removing the attacker's account from Domain Admins do nothing, because the account was never a member — it was granted rights through the ACL template. This is also what separates it from ordinary dangerous group nesting: nesting hides in group membership, this technique hides in a single ACL that most admins never think to review.

Defenders can inventory candidate targets and leftover artifacts of this technique with a single LDAP query:

Get-ADObject -LDAPFilter "(&(admincount=1)(|(objectcategory=person)(objectcategory=group)))" -Properties MemberOf,Created,Modified,AdminCount

Any result whose MemberOf no longer includes a protected group, or whose effective permissions look unrelated to its actual role, is worth investigating further before assuming it is legitimate cleanup debt.

Detection

The mechanism only touches one object, so detection is narrow but reliable — provided the right audit policy and SACL are already in place.

Two things must be true before event 5136 ever fires: the Advanced Audit Policy → DS Access → Audit Directory Service Changes subcategory has to be enabled, and a SACL covering the security descriptor (or "Write All Properties") has to exist on the AdminSDHolder object itself. Neither is on by default in most environments. Elastic's published detection rule for this exact technique depends on both being configured before it can fire — its query is event.code:5136 and host.os.type:"windows" and winlog.event_data.ObjectDN:CN=AdminSDHolder,CN=System*, mapped to MITRE ATT&CK T1098 (Account Manipulation) and T1078.002 (Valid Accounts: Domain Accounts), rated High severity (Elastic — AdminSDHolder Backdoor detection rule). Splunk's equivalent Security Content rule confirms the same 5136/nTSecurityDescriptor logic and the same SACL prerequisite (Splunk Security Content — Windows AD AdminSDHolder ACL Modified).

Auditing the ACL Directly

Event logs only help once auditing is turned on — a point-in-time ACL review works regardless of audit policy and is a reasonable first check in an environment that has never enabled Directory Service Changes auditing:

Get-Acl -Path "AD:\CN=AdminSDHolder,CN=System,DC=corp,DC=local" | Select-Object -ExpandProperty Access

Review every entry in the output against the known-good baseline in the remediation section below. Anything that isn't a well-known built-in principal is worth escalating immediately, regardless of whether logging is in place yet.

Remediation

Immediate Response

1. Audit the AdminSDHolder ACL now. Compare its trustees against a known-good baseline (Domain Admins, Enterprise Admins, Administrators, SYSTEM, and any explicitly delegated service account) and remove anything unexpected — as Metcalf put it, "these should be kept at the default."
2. Force SDProp to re-run immediately after remediation, via Ldp.exe → RunProtectAdminGroupsTask=1 on the rootDSE, rather than waiting up to 60 minutes to confirm the fix propagated (Microsoft Learn — Appendix C).

Ongoing Hardening

3. Enable Directory Service Changes auditing and set a SACL on AdminSDHolder so future modifications generate event 5136, per the detection section above.
4. Inventory every adminCount=1 object with the LDAP query shown earlier and reconcile it against current protected-group membership. For accounts confirmed to no longer belong to a protected group, clear adminCount and re-enable inheritance only after confirming the group membership is already gone — clearing it first lets SDProp revert the fix on its next run. These orphaned accounts are the same cleanup debt covered in Stale Privileged Accounts.
5. Restrict who can write to AdminSDHolder. Only Domain Admins, Enterprise Admins, and Administrators can modify or take ownership of it by default — keep it that way. Any GenericWrite or WriteDacl delegated on the System container, or on AdminSDHolder specifically, is a standing risk and should be treated as Tier 0.

How EtcSec Detects This

EtcSec's Active Directory audit checks ADMIN_SD_HOLDER_MODIFIED for unexpected trustees or dangerous rights (Full Control, GenericAll, WriteDacl, WriteOwner) on the AdminSDHolder object's ACL, ADMINSDHOLDER_BACKDOOR for the specific pattern of a non-privileged principal holding those rights, and ADMIN_COUNT_ORPHANED for accounts still flagged adminCount=1 after leaving a protected group — cleanup debt that both hides genuine backdoors and inflates your privileged-account count. This backdoor rarely shows up alone: it is frequently found alongside broader privileged access drift, so both checks are worth running together as part of a routine audit rather than treated as separate one-off findings.