Join our Newsletter — 33% off our NHI Course

Why do changes to AdminSDHolder create lasting risk for privileged accounts?

AdminSDHolder matters because it acts as the template for permissions on protected accounts and groups. If an attacker gains the ability to edit that template, the malicious permissions propagate automatically and are reapplied on a schedule. This creates a self-healing persistence mechanism that defeats one-off cleanup and makes credential recovery alone insufficient unless the template is also secured.

Why AdminSDHolder changes are so persistent

AdminSDHolder is not just another object in Active Directory, it is the protection template for privileged groups and accounts. Any change to that template can be copied back onto protected principals during the regular protection cycle, so a malicious ACE or delegation path can outlive the original compromise and reappear after cleanup.

The lasting risk comes from the control plane, not the one-time event. If an attacker can alter the template, they are changing how privileged access is re-applied, which means the environment can keep restoring the attacker’s foothold even after passwords are reset or a single account is fixed.

That makes AdminSDHolder especially dangerous in environments with tier-zero accounts, domain admin membership, or other protected identities where the security boundary depends on inheritance being intentionally constrained rather than left to default directory behavior.

How the persistence mechanism survives normal remediation

AdminSDHolder changes are durable because the protected principals are periodically stamped with the template’s security descriptor. That means an incorrect permission can spread to every protected account the template governs, and the system itself helps reassert the malicious setting until the template is corrected.

This is why remediation can fail if teams only remove the visible symptom. If the attacker modified the template, cleared group membership, or abused a delegated write path, the privileged object may look fixed for a short time and then become vulnerable again on the next refresh cycle.

In practice, the issue behaves like a self-healing persistence mechanism: the directory keeps returning the protected accounts to the compromised state, which makes credential rotation, group cleanup, or account disablement incomplete unless the AdminSDHolder object and its write permissions are also investigated.

What defenders should check first on protected accounts

The first question is not whether a privileged password changed, but whether the template and its edit rights changed. Review who can write AdminSDHolder, who can modify protected group memberships, and whether any unexpected ACEs or inherited permissions were introduced around the time of the incident.

Then confirm whether the protected principals have already been restamped. If the template is still hostile, any account in scope can remain exposed even after the initial intrusion path is gone, so ownership must shift from account-by-account cleanup to directory-level correction.

For deeper AD hardening context, the Active Directory and Entra ID Hardening Guide and the Privileged Access Management Guide both reinforce why protected groups and standing privilege need explicit governance rather than assumed inheritance.

Risk and Threat Considerations

AdminSDHolder is attractive to attackers because it converts a single directory write into durable control over high-value accounts. That creates persistence, privilege retention, and repeated reinfection risk, especially when incident response focuses on endpoints or passwords instead of the directory object that keeps restoring the malicious state.

Failure mechanism: A compromised principal or delegated writer modifies the template or related permissions, and the scheduled protection process re-applies the malicious access to protected accounts and groups.

Impact: Privileged accounts can remain effectively backdoored after cleanup, giving the attacker recurring access, easier privilege escalation, and a higher chance of surviving standard remediation steps.

Standards & Framework Alignment

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

NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
NIST SP 800-53 Rev 5 AC-6 — Least Privilege AdminSDHolder abuse is a privilege control failure affecting protected accounts.
AC-2 — Account Management Protected privileged accounts and group membership must be governed and reviewed.
CM-5 — Access Restrictions for Change Template modification is a sensitive change that must be tightly restricted.
Recommendation — Restrict who can modify protected account templates and delegated admin paths. Review protected account membership and admin rights for unexpected changes. Limit write access to directory security descriptors and monitor all changes.
CIS Controls v8 CIS-5 — Account Management Protected account lifecycle and privileged group membership need strong account control.
CIS-6 — Access Control Management AdminSDHolder changes are an access-control issue for privileged identities.
Recommendation — Inventory privileged accounts and remove unauthorized access paths quickly. Apply least privilege to directory objects and privileged security groups.

Practitioner Guidance

What to verify: Treat any AdminSDHolder change as a directory integrity event. Validate the object’s ACLs, compare them with a known-good baseline, and confirm whether the protection cycle has already propagated the change to protected principals.

Decision rule: If you find an unexpected write path to AdminSDHolder, prioritise revoking that path and restoring the template before rotating credentials or recertifying group membership. Account-level remediation alone is not sufficient if the control object remains compromised.

Practitioner takeaway: The durable risk is not the edited account, it is the authority that keeps re-imposing the edit on privileged identities until the template itself is repaired.