Active Directory AdminSDHolder: What It Is, How Attackers Abuse It, and How to Audit It
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
AdminSDHolder is one of the most abused persistence mechanisms in Active Directory because it is invisible to most monitoring. The object exists in every AD domain, most AD admins have never checked its ACL, and an attacker who adds a backdoor ACE there will have that access automatically restored every hour indefinitely. This guide covers what AdminSDHolder does, how the abuse works, how to find unauthorized ACEs, and how to clean them.
How SDProp Works and Why It Matters
Every 60 minutes, the SDProp process on the PDC Emulator: reads the ACL from CN=AdminSDHolder,CN=System,DC=domain,DC=com; enumerates all members (direct and nested) of the protected groups; and replaces the ACL on each protected account object with the AdminSDHolder ACL. It also sets the adminCount attribute to 1 on each account it processes. The practical implication: any ACL change you make directly on a Domain Admin account (granting a helpdesk group GenericWrite, for example) will be overwritten within 60 minutes by SDProp. This is the intended protective behavior -- it prevents accidental delegation from weakening protected accounts. The attack: instead of modifying a specific account's ACL (which SDProp would restore), an attacker modifies the AdminSDHolder ACL itself. Within 60 minutes, SDProp copies the backdoor permission to all protected accounts. The attacker can then use that permission (GenericAll, WriteDACL, ResetPassword, etc.) to regain admin access any time in the future, even if they have been removed from Domain Admins.
Enumerate the Current AdminSDHolder ACL
Check the AdminSDHolder ACL immediately: Get-ACL 'AD:\CN=AdminSDHolder,CN=System,DC=yourdomain,DC=com' | Select-Object -ExpandProperty Access | Where-Object { $.IdentityReference -notlike 'Domain Admins' -and $.IdentityReference -notlike 'Enterprise Admins' -and $.IdentityReference -notlike 'Administrators' -and $.IdentityReference -notlike 'SYSTEM' -and $_.IdentityReference -notlike 'NT AUTHORITY' } | Format-Table IdentityReference, ActiveDirectoryRights, AccessControlType -AutoSize. The output should only show Domain Admins, Enterprise Admins, Administrators, SYSTEM, and NT AUTHORITY\SELF. Any other identity in this list is a finding. Common legitimate entries: 'Account Operators' has limited rights in some environments (review these carefully -- they should not have GenericAll or WriteDACL). A completely foreign identity (a service account, a user account, a non-standard group) with any meaningful rights is evidence of either misconfiguration or an adversary backdoor.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
The AdminSDHolder Backdoor Attack in Practice
The attack sequence a red team or post-exploitation toolkit uses: achieve Domain Admin access (via any standard AD attack path). Run the AdminSDHolder backdoor: Add-ObjectACL -TargetIdentity 'AdminSDHolder' -PrincipalIdentity 'compromised_user' -Rights All (using PowerView syntax). Wait up to 60 minutes for SDProp to propagate the ACE to all protected accounts, OR trigger SDProp manually (requires domain admin): Invoke-SDPropagator -ShowProgress. After propagation, the compromised_user now has GenericAll over every Domain Admin, Enterprise Admin, Schema Admin, and Backup Operator account. Revoke compromised_user from Domain Admins: SDProp runs, restores GenericAll to compromised_user on all protected accounts. The attacker now uses GenericAll to reset a Domain Admin password and regain access. The persistence survives any password change, account disabling, or group removal -- only removing the ACE from AdminSDHolder itself stops it.
Remove Unauthorized ACEs and Harden
To remove an unauthorized ACE from AdminSDHolder: open ADSI Edit (adsiedit.msc), connect to Default naming context, navigate to CN=AdminSDHolder,CN=System,DC=yourdomain,DC=com. Right-click Properties > Security tab. Find and remove the unauthorized entry. Alternatively via PowerShell: $acl = Get-ACL 'AD:\CN=AdminSDHolder,CN=System,DC=domain,DC=com'; $ace = $acl.Access | Where-Object { $_.IdentityReference -eq 'DOMAIN\suspicious_account' }; $acl.RemoveAccessRule($ace); Set-ACL 'AD:\CN=AdminSDHolder,CN=System,DC=domain,DC=com' -AclObject $acl. After removing the ACE from AdminSDHolder, the ACE on individual protected accounts remains until the next SDProp cycle or manual reset. To force removal: trigger SDProp manually from the PDC Emulator. For ongoing hardening: add AdminSDHolder ACL changes to your SIEM alerting via Event ID 5136 (directory service object modification) filtered for the AdminSDHolder DN. Any modification to this object should generate an immediate P1 alert.
The adminCount=1 Artifact and Stale Protected Accounts
Any account that was ever in a protected group has adminCount=1 set, even after leaving the group. SDProp no longer updates accounts after they leave protected groups, but the adminCount flag and the locked-down ACL remain. This creates two problems: the account's ACL may be more restrictive than needed (SDProp previously removed permissions that were legitimate for non-privileged use), and security tools may incorrectly treat it as still privileged. Find stale adminCount=1 accounts: Get-ADUser -Filter { adminCount -eq 1 } -Properties adminCount, MemberOf | Where-Object { ($.MemberOf | ForEach-Object { Get-ADGroup $ } | Select-Object -ExpandProperty Name) -notmatch 'Domain Admins|Enterprise Admins|Schema Admins|Administrators|Account Operators|Backup Operators|Print Operators|Server Operators' } | Select-Object SamAccountName, MemberOf. For each stale account: reset adminCount to 0 (Set-ADUser -Identity username -Replace @{adminCount=0}) and restore the appropriate ACL for their current non-privileged role. This cleanup reduces attack surface and false positives in BloodHound path analysis.
The bottom line
AdminSDHolder is a persistent backdoor vector that every Active Directory environment should audit. The check is a single PowerShell command against one object. Any identity beyond Domain Admins, Enterprise Admins, Administrators, SYSTEM, and NT AUTHORITY\SELF in that ACL is a critical finding. Alert on Event ID 5136 for modifications to the AdminSDHolder DN so that any future modification is caught within minutes rather than remaining undetected for months.
Frequently asked questions
How do I know if my AdminSDHolder has been backdoored?
Run Get-ACL against CN=AdminSDHolder,CN=System,DC=domain,DC=com and review the full ACL. Any identity outside the expected set (Domain Admins, Enterprise Admins, Administrators, SYSTEM, NT AUTHORITY\SELF, Creator Owner) is suspicious. Also check your historical Event ID 5136 logs filtered for the AdminSDHolder DN -- modifications to this object should be extremely rare (only during deliberate administrative changes). If 5136 events show modifications in the past that you cannot attribute to a documented change, treat it as a potential backdoor and investigate.
Can I protect AdminSDHolder itself with additional ACL restrictions?
The effective protection for AdminSDHolder is limiting who has Domain Admin access (since that is required to modify it), enabling auditing of modifications via Event ID 5136, and including AdminSDHolder in your regular AD security reviews. You cannot meaningfully restrict access to AdminSDHolder beyond the default -- it requires Domain Admin access to modify, and Domain Admins should be a small, tightly controlled group. Reducing the Domain Admin population is the primary prevention.
Does BloodHound detect AdminSDHolder backdoors?
BloodHound's standard collection does not specifically flag AdminSDHolder ACE misconfigurations as a dedicated finding, but it will show the resulting ACEs on protected accounts as attack edges (GenericAll, WriteDACL edges from the backdoored identity to Domain Admin accounts). The AdminSDHolder object itself can be analyzed by running a custom BloodHound query or by using the PowerShell ACL enumeration described in this guide. The SharpHound collector does collect ACLs and will include AdminSDHolder ACEs in the data -- the attack path will be visible in BloodHound as direct edges from the compromised account to all Domain Admin accounts.
What rights are most dangerous in an AdminSDHolder ACE?
GenericAll (full control -- can reset password, add to groups, modify ACL), WriteDACL (can grant themselves GenericAll), WriteOwner (can take ownership then grant themselves GenericAll), ResetPassword (specific right to reset password without knowing the current one), and GenericWrite (can write any attribute, including setting a SPN for Kerberoasting or modifying the logon script). Even ReadProperty is notable if the identity should have no relationship to protected accounts. Any of the write-capable rights provide a viable path to Domain Admin.
How long does it take for SDProp to propagate AdminSDHolder ACEs to protected accounts?
SDProp (Security Descriptor Propagator) runs every 60 minutes by default on the PDC emulator FSMO role holder. After a change to the AdminSDHolder ACL, it takes up to 60 minutes for the new ACE to propagate to all protected accounts' ACLs. After an attacker modifies AdminSDHolder to add a backdoor ACE, they must wait up to one SDProp cycle before the ACE appears on protected accounts and they can exercise the rights. You can change the SDProp interval by modifying AdminSDHolderInterval in the HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters registry key, but the default 60-minute cycle is well-established. During incident response, remediate the AdminSDHolder ACL and then manually trigger SDProp to propagate the fix immediately rather than waiting 60 minutes.
How do you audit AdminSDHolder for backdoored ACEs and what tools can automate this?
Regular AdminSDHolder auditing requires comparing the current ACL against a known-good baseline. Use Get-Acl 'AD:CN=AdminSDHolder,CN=System,DC=domain,DC=com' to retrieve the current ACL, then compare it against a baseline captured after initial hardening. Any ACE not present in the baseline is a candidate backdoor. Automated tools: Pingcastle includes an AdminSDHolder check in its domain risk assessment. BloodHound's 'AdminSDHolder' node shows all accounts with direct rights over the AdminSDHolder object -- any non-admin account with GenericWrite, WriteDACL, or WriteOwner is a critical finding. Microsoft Defender for Identity raises the 'AdminSDHolder backdoor' alert when it detects an ACE added to AdminSDHolder from a non-Domain Admin account. Include AdminSDHolder in your privileged access workstation (PAW) scope: manage it only from PAWs and log every access attempt.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.