What happens when AdminSDHolder is modified by an attacker?

If an attacker changes AdminSDHolder, the SDPROP process can keep restoring the attacker’s unauthorized permissions every hour. That means even after defenders fix the visible permission change, the malicious modification can come back unless the underlying AdminSDHolder object is cleaned up. This is why monitoring privileged-object changes and auditing propagation behavior are essential in Active Directory.

How AdminSDHolder Turns One Change into Repeated Privilege Restoration

AdminSDHolder is not just a protected object, it is the template that SDPROP uses to reapply permissions to privileged accounts and groups. When an attacker changes it, they are often not trying to win a one-time ACL edit, they are trying to persist control through the directory’s own protection process. That is why the effect can survive well beyond the initial compromise window.

The key behaviour is periodic propagation. Every SDPROP cycle, the directory rechecks protected principals and rewrites their security descriptors from the AdminSDHolder template. If the attacker has inserted an unauthorized ACE, that access can be restored on schedule even after a defender removes the visible change elsewhere. The real problem is not the symptom on one account, it is the compromised template that keeps projecting the symptom back into the environment.

This is a privilege persistence mechanism, not a simple misconfiguration. Once the template is altered, the attacker can influence every protected object that inherits from it, which makes the blast radius much larger than a single admin account. In practical terms, the directory can become the attacker’s recovery system unless the template itself is identified, corrected, and verified.

Why the Hidden Control Plane Matters More Than the Visible ACL

Defenders often focus on the account or group where the odd permission first appears, but AdminSDHolder is the control plane behind that appearance. If the underlying object is still malicious, cleaning the affected user or group alone is incomplete remediation. The next propagation cycle can reintroduce the same effective access, which creates a false sense of recovery.

That makes change monitoring on privileged directory objects especially important. A small, hard-to-notice modification in the template can have a disproportionate effect because it governs how protected identities are continually rewritten. In other words, the security issue is not just unauthorized access, it is unauthorized access that the platform itself may reassert.

For incident handling, this shifts the question from “what permissions were changed?” to “what privileged inheritance source was tampered with?” That distinction matters because the attacker may use a short-lived foothold to plant long-lived privilege through normal directory maintenance, even if their original access path is later removed.

What a Defender Should Verify Before Declaring the Incident Closed

After any suspected AdminSDHolder tampering, the immediate task is to confirm whether the template, the protected objects, or both were modified. You need to check whether the malicious ACE was copied into protected groups, whether propagation has already occurred, and whether additional privileged principals now carry the same unwanted rights. The incident is not closed until the template and its downstream effects are both clean.

It is also worth verifying whether monitoring covered the protected-object path itself. A lot of response effort is wasted when teams watch ordinary account changes but do not alert on privileged template changes. In this scenario, the most important evidence is the change history on the template and the propagation pattern across protected accounts.

Successful remediation should leave the directory in a state where the next SDPROP run does not reintroduce attacker access. If the fix only removes the visible symptom and not the root template, the environment is still functionally compromised.

Risk and Threat Considerations

AdminSDHolder abuse is dangerous because it weaponizes a built-in protection mechanism. An attacker who can modify the template can create durable privilege persistence, regain access after cleanup, and spread the effect across multiple protected accounts without needing repeated hands-on activity.

Failure mechanism: The attacker alters the AdminSDHolder security descriptor, and SDPROP later reapplies that altered template to protected principals, restoring the unauthorized permissions on a recurring basis.

Impact: Defenders may believe they have removed the compromise, but the attacker’s access can return on the next propagation cycle, increasing dwell time, complicating eradication, and broadening the risk to high-value directory assets.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
MITRE ATT&CK	T1098 — Account Manipulation	AdminSDHolder tampering changes account permissions for persistence.
Recommendation — Map the change to account manipulation and hunt for persistence across protected principals.
NIST SP 800-53 Rev 5	AU-6 — Audit Review, Analysis, and Reporting	Privileged template changes need review and correlation to spot reintroduced access.
	CM-5 — Access Restrictions for Change	Restrict who can modify security descriptors on sensitive directory objects.
	AC-6 — Least Privilege	Minimize who can touch the template that governs privileged access.
Recommendation — Review audit events for privileged-object changes and propagation activity. Limit AdminSDHolder modification rights to tightly controlled administrators. Apply least privilege to directory objects that control inherited admin permissions.

Practitioner Guidance

What to prioritise: Treat any AdminSDHolder change as a directory integrity incident, not a routine ACL event. The first priority is to identify whether the template itself was altered, because that object can re-seed the compromise into every protected principal.

What to verify: Confirm that the malicious permissions are removed from the template and from every affected protected account or group after the next propagation window. If the same rights reappear, the root cause has not been eradicated.

Common mistake: Teams often remediate the visible account permission and stop there. That is insufficient when the source template remains poisoned, because the system will keep restoring the attacker’s access for them.

Practitioner takeaway: In AdminSDHolder incidents, durable recovery depends on cleaning the template and then validating that propagation no longer reproduces the attacker’s permissions.