AdminSDHolder Attack: Tactics & Risks
One of the key responsibilities of Active Directory (AD) is to provide access privileges to objects like users, groups, and computers. Any improper change to the permissions of objects — especially powerful objects like the Domain Admins or Schema Admins group — can introduce serious security risks. Accordingly, AD provides a mechanism to regularly restore the permissions of these objects to their proper state: The AdminSDHolder object maintains a record of their correct permissions, and the process SDProp re-applies those permissions to the objects on a set schedule.
However, attackers can abuse this built-in AD mechanism to create a persistent backdoor for privileged access. Indeed, this attack is so effective, AdminSDHolder attacks have become increasingly common, causing damage to organizations across a wide range of sectors.
This blog post explains how AdminSDHolder attacks work step by step, provides real-world examples of this exploit, details the damage they can do to organizations, and offers guidance for defending against them.
What is an AdminSDHolder Attack?
AdminSDHolder is a protected container object located in the system container of an AD domain. It serves as a template for the correct permissions of protected groups and user accounts. On a defined schedule, the Security Descriptor Propagator (SDProp) process compares the current permissions of critical objects to those in AdminSDHolder and reverts any unauthorized changes.
Adversaries can abuse this standard AD mechanism by creating a modified set of permissions for a highly privileged object and making it the official record in AdminSDHolder. Then their desired permissions will be reapplied every time SDProp runs — restoring their access even if an administrator had spotted an issue and revoked permissions on a particular user or group.
AdminSDHolder Abuse: Past, Present and Future
Over time, adversaries have altered how and why they exploit the AdminSDHolder object. Here are some important changes we have seen and one to anticipate.
Shift from Overt Privilege Escalation to Stealthy Persistence Mechanisms
In the past, attackers would modify the AdminSDHolder ACL to give full control rights to a privileged account they had compromised. As defenders developed strategies to detect such sudden privilege escalation, attackers changed their techniques.
Today, they are more likely to add granular permissions, such as rights to reset passwords, modify group membership or create GPOs, to different accounts. While this shift does not give them direct membership in highly privileged groups, it provides a stealthy and persistent backdoor to the network that can be used to escalate privileges later.
Evolution of Attacker Tactics with Tools like PowerView and BloodHound
Adversaries can use PowerView, a PowerShell tool, to enumerate AD permissions, identify misconfigurations related to AdminSDHolder, and inject granular permissions into compromised accounts.
BloodHound maps the relationships and trust between users, groups and computers in an Active Directory environment, enabling the attackers to locate attack paths for privilege escalation, complementing the use of the AdminSDHolder exploit as a long-term backdoor.
Anticipated Misuse Involving AI Automation and AD Enumeration
With the rapid advancement of AI, we can expect tools that will be able to quickly identify objects protected by AdminSDHolder object, automate the modification of ACLs and validate those changes after the SDProp process runs. If permissions are removed manually by admins, the tool can add the removed permissions to a different account for the next cycle.
Fast Facts & Figures
AdminSDHolder permissions are replicated every 60 minutes via SDProp.
By default, the SDProp process re-applies the ACL of the AdminSDHolder object to all protected users and groups every hour.
Over 70% of ransomware incidents involve privilege escalation, often through AD.
Over 70% of ransomware incidents involve privilege escalation, since elevated rights are usually required to deploy ransomware across the network. Since most IT environments use Active Directory, the process usually involves AD accounts and other AD objects like AdminSDHolder.
One misconfigured ACL in AdminSDHolder can impact every protected group in the domain.
A single misconfigured AdminSDHolder ACL can grant elevated permissions to accounts under the control of attackers, potentially compromising all protected groups, including Domain Admins, Schema Admins and Enterprise Admins.
Steps in an AdminSDHolder Exploit
Account compromise → ACL edit → SDProp replication → Privilege abuse
Modify the ACL of the AdminSDHolder container
Wait for SDProp to replicate the ACLs to privileged accounts
Use the elevated privileges to accomplish additional goals
The adversaries can use their elevated rights to add accounts they control into highly privileged groups such as Domain Admins or Enterprise Admins. From there, they can perform any number of malicious actions, including the following:
- Create additional accounts to confuse defenders
- Extract password hashes or Kerberos tickets from domain controllers (DCs)
- Modify Group Policy objects (GPOs)
- Move laterally to other systems within the network
- Modify firewall rules and plant remote tools on systems
- Alter security logs to cover their tracks
- Exfiltrate sensitive data or encrypt it for ransom
Detect, Mitigate and Respond
Real-World Breaches Involving AdminSDHolder
Red Team Findings
In most cases, organizations that fall victim to a cyberattack do not reveal the full details of their forensic analysis.
Penetration test reports for clients are generally confidential. However, real-world penetration testing reveals the following:
- Red teams confirm that AdminSDHolder attacks enable them to regain administrative control even after their initial foothold is detected and mitigated (for example, by removing the compromised account).
- Red teams are able to use AdminSDHolder modifications to move laterally, compromise additional accounts, achieve objectives like disruption and data theft.
- Red teams confirm that traditional monitoring tools often fail to detect AdminSDHolder attacks.
Why Changes to the AdminSDHolder ACLs Are Missed
Red team exercises also demonstrate that organizations often fail to detect malicious modifications to the AdminSDHolder ACL. Reasons including the following:
- Organizations focus their monitoring and alerting on user accounts and groups, and fail to pay proper attention to the AdminSDHolder object.
- Organizations implicitly trust built-in Active Directory security mechanisms, including the SDProp process. They assume that it will protect them by resetting permissions, without realizing it can just as easily restore an attacker’s access rights.
- Administrators may fail to regularly review settings and permissions once they are initially configured, so they do not notice improper modifications.
- The complexity of auditing ACLs can make it challenging to quickly detect unauthorized changes to the AdminSDHolder ACL.
- Security teams may lack sufficient training about the AdminSDHolder attack, so they focus on other security risks.
Industries that Are Vulnerable to the AdminSDHolder Exploit
Any organization that relies on Active Directory for identity management is a potential target for AdminSDHolder attacks. Indeed, organizations in many different sectors have suffered theft of intellectual property, customer data and other sensitive information.
For example, government agencies, whether civilians or military, are top targets because of their role in national security. In fact, AdminSDHolder attacks have been used to steal classified data and compromise government networks. Another top target is financial institutions, since AdminSDHolder attacks enable adversaries to gain persistent access for conducting fraud, stealing financial information or disrupting operations.
Repercussions of an AdminSDHolder Attack
A successful AdminSDHolder attack can cause significant damage because adversaries gain persistent high-level access to the IT ecosystem. The impact of an attack can span all of the following areas:
- Financial costs can include direct monetary losses, decline in stock value, fraudulent transactions, manipulated records, theft of customer payment information, incident response and recovery costs, potential ransom payments, regulatory fines
- Operational damage can include downtime, lockouts, disruption of business processes and services, data manipulation, data loss, loss of control over the IT infrastructure, delayed and cancelled projects, and decreased productivity
- Reputational damage can include loss of customer trust, negative media coverage and public scrutiny, damage to business partnerships, difficulty attracting and retaining talent, and loss of investor confidence
- Legal and regulatory costs can include penalties for violations of regulations like GDPR or HIPAA, increased scrutiny and audits, civil lawsuits, and even criminal charges
Threat Evaluation and Exposure Analysis
Risk Indicators
To reduce their risk from AdminSDHolder attacks, organizations should regularly check for the following risks:
- Any regular user account with an AdminCount attribute set to 1.
- Service accounts or disabled accounts that have elevated privileges.
- Non-standard entries in the AdminSDHolder ACL with Full Control, GenericAll or Write DACL.
- Unexplained or frequent SDProp-related ACL changes.
- DCSync activity from sources other than domain controllers.
Frequency and Stealth Potential of AdminSDHolder Manipulation
Defenders should understand that adversaries need to modify the ACL of the AdminSDHolder just once, and the SDProp process will re-apply their malicious settings on a regular basis. As a result, attacks are very difficult to detect with simple threshold-based alerts. Moreover, AdminSDHolder exploits enable stealthy attacks that unfold over many days or months, since attackers maintain their elevated privileges even if the account they initially compromised is disabled or deleted.
Why This Attack Often Bypasses Standard SIEM Alerts
Standard security information and event management (SIEM) system usually focus on suspicious changes to user objects and group membership. Modifications to the AdminSDHolder ACL often do not trigger alerts unless the SIEM is configured specifically to monitor changes to this object. In addition, many SIEMs generate a large volume of alerts, which can overwhelm security teams and keep them from investigating activity related to AdminSDHolder.
Preventative Controls for AdminSDHolder Exploitation
To defend against AdminSDHolder exploitation, be sure to implement the following best practices.
Ensure domain admins never modify AdminSDHolder unless necessary.
Establish a strong change management policy that limits direct access to AdminSDHolder to trusted administrators only. Require proper review for any modification requests, and document every change, detailing why the change is needed and when it was made. In addition, configure real-time alerts for any changes made to AdminSDHolder to ensure visibility and accountability.
Regularly audit the AdminSDHolder ACL, and monitor SDProp behavior.
Review the permissions configured directly on AdminSDHolder regularly, evaluating the access level of each object to find any unexpected or extra rights that are not consistent with the documented permissions.
Monitor the SDProp process using event logs or PowerShell scripts. In particular, monitor both successful and failed scheduled runs, since frequent failures or modifications could indicate malicious activity.
Restrict who can modify ACLs.
Administrators can configure Group Policy to prevent lower privileged administrators from altering critical permissions, including the AdminSDHolder ACL. In addition, organizations can adopt a tiered administrative model that separates administrator accounts and other critical AD assets from less privileged objects, and strictly controls interactions between assets in different tiers. This approach limits the impact of a compromised account.
Invest in appropriate security solutions.
For a robust defense against AdminSDHolder attacks, consider investing in a purpose-built security solution such as the following:
- Netwrix Auditor provides detailed reporting on Active Directory permissions, risk assessments, continuous monitoring, and real-time alerts on suspicious activity. It also simplifies delegation of access reviews and supports audit readiness.
- Netwrix Privileged Access Management (PAM) enforces just-in-time access for high-privilege accounts, enabling administrators to elevate rights only when needed and only for a limited duration. This minimizes the attack surface and helps contain the impact of a compromised account.
- Netwrix Data Classification helps identify and protect sensitive information linked to privileged users, reinforcing least-privilege access and compliance efforts.
Recognizing and Responding to AdminSDHolder Abuse
Organizations need to be able to promptly detect AdminSDHolder attacks, respond effectively, and recover quickly.
Signs of Compromise
The most direct sign of an AdminSDHolder attack is suspicious changes to the ACL. Attackers may add their compromised accounts to the AdminSDHolder object, modify the existing permissions of low-privileged accounts to escalate privilege, and remove or modify permissions of legitimate administrative groups.
In addition, as mentioned above, any non-privileged objects with an AdminCount value of 1 merit immediate investigation. If an account was a member of a privileged group but has been removed, its AdminCount value should revert to 0. If it remains 1 for an extended period, check for malicious manipulation.
Response Actions
If you find evidence of an AdminSDHolder attack, take the following steps:
- Isolate the PDC emulator — The primary domain controller (PDC) emulator holds the FSMO role responsible for applying AdminSDHolder permissions to protected objects. Isolating it temporarily from the network can contain the propagation of malicious ACL changes.
- Audit AdminSDHolder — Examine the AdminSDHolder ACL for unauthorized modifications by comparing it with your record of authorized changes. Document your findings to help the team understand the attackers' probable intent.
- Remove suspicious permissions — Revert any improper changes, and force the PDC emulator to reapply AdminSDHolder permissions to all protected objects.
Recovery
After correcting the AdminSDHolder permissions and forcing replication, verify the permissions of all privileged accounts.
In addition, scan all AD domains for accounts with AdminCount=1, and revert that value back to value 0 where 1 is not required. If inheritance is disabled, re-enable it.
Security Implications for Key Industries
- Healthcare — Attackers who gain persistent access via AdminSDHolder attacks can compromise electronic health record (EHR) systems, manipulate medical devices, block or alter financial systems, encrypt data for ransom, or manipulate insurance data for financial fraud. Compromise of protected health information (PHI) can be a violation of HIPAA that results in massive fines and lasting reputation damage.
- Finance — In financial institutions like banks and trading platforms, AdminSDHolder exploits can enable attackers to steal confidential information and perform unauthorized transactions, which can result in fines related to violations of SOX, GLBA, or PCI-DSS.
- Government — AdminSDHolder attacks on government organizations can result in theft, leakage, and misuse of highly sensitive information related to national defense, intelligence, and critical infrastructure, any of which can have profound ramifications.
Real-World Breaches Involving AdminSDHolder
Red Team Findings
In most cases, organizations that fall victim to a cyberattack do not reveal the full details of their forensic analysis.
Penetration test reports for clients are generally confidential. However, real-world penetration testing reveals the following:
- Red teams confirm that AdminSDHolder attacks enable them to regain administrative control even after their initial foothold is detected and mitigated (for example, by removing the compromised account).
- Red teams are able to use AdminSDHolder modifications to move laterally, compromise additional accounts, achieve objectives like disruption and data theft.
- Red teams confirm that traditional monitoring tools often fail to detect AdminSDHolder attacks.
Why Changes to the AdminSDHolder ACLs Are Missed
Red team exercises also demonstrate that organizations often fail to detect malicious modifications to the AdminSDHolder ACL. Reasons including the following:
- Organizations focus their monitoring and alerting on user accounts and groups, and fail to pay proper attention to the AdminSDHolder object.
- Organizations implicitly trust built-in Active Directory security mechanisms, including the SDProp process. They assume that it will protect them by resetting permissions, without realizing it can just as easily restore an attacker’s access rights.
- Administrators may fail to regularly review settings and permissions once they are initially configured, so they do not notice improper modifications.
- The complexity of auditing ACLs can make it challenging to quickly detect unauthorized changes to the AdminSDHolder ACL.
- Security teams may lack sufficient training about the AdminSDHolder attack, so they focus on other security risks.
Industries that Are Vulnerable to the AdminSDHolder Exploit
Any organization that relies on Active Directory for identity management is a potential target for AdminSDHolder attacks. Indeed, organizations in many different sectors have suffered theft of intellectual property, customer data and other sensitive information.
For example, government agencies, whether civilians or military, are top targets because of their role in national security. In fact, AdminSDHolder attacks have been used to steal classified data and compromise government networks. Another top target is financial institutions, since AdminSDHolder attacks enable adversaries to gain persistent access for conducting fraud, stealing financial information or disrupting operations.
Repercussions of an AdminSDHolder Attack
A successful AdminSDHolder attack can cause significant damage because adversaries gain persistent high-level access to the IT ecosystem. The impact of an attack can span all of the following areas:
- Financial costs can include direct monetary losses, decline in stock value, fraudulent transactions, manipulated records, theft of customer payment information, incident response and recovery costs, potential ransom payments, regulatory fines
- Operational damage can include downtime, lockouts, disruption of business processes and services, data manipulation, data loss, loss of control over the IT infrastructure, delayed and cancelled projects, and decreased productivity
- Reputational damage can include loss of customer trust, negative media coverage and public scrutiny, damage to business partnerships, difficulty attracting and retaining talent, and loss of investor confidence
- Legal and regulatory costs can include penalties for violations of regulations like GDPR or HIPAA, increased scrutiny and audits, civil lawsuits, and even criminal charges
Threat Evaluation and Exposure Analysis
Risk Indicators
To reduce their risk from AdminSDHolder attacks, organizations should regularly check for the following risks:
- Any regular user account with an AdminCount attribute set to 1.
- Service accounts or disabled accounts that have elevated privileges.
- Non-standard entries in the AdminSDHolder ACL with Full Control, GenericAll or Write DACL.
- Unexplained or frequent SDProp-related ACL changes.
- DCSync activity from sources other than domain controllers.
Frequency and Stealth Potential of AdminSDHolder Manipulation
Defenders should understand that adversaries need to modify the ACL of the AdminSDHolder just once, and the SDProp process will re-apply their malicious settings on a regular basis. As a result, attacks are very difficult to detect with simple threshold-based alerts. Moreover, AdminSDHolder exploits enable stealthy attacks that unfold over many days or months, since attackers maintain their elevated privileges even if the account they initially compromised is disabled or deleted.
Why This Attack Often Bypasses Standard SIEM Alerts
Standard security information and event management (SIEM) system usually focus on suspicious changes to user objects and group membership. Modifications to the AdminSDHolder ACL often do not trigger alerts unless the SIEM is configured specifically to monitor changes to this object. In addition, many SIEMs generate a large volume of alerts, which can overwhelm security teams and keep them from investigating activity related to AdminSDHolder.
Preventative Controls for AdminSDHolder Exploitation
To defend against AdminSDHolder exploitation, be sure to implement the following best practices.
Ensure domain admins never modify AdminSDHolder unless necessary.
Establish a strong change management policy that limits direct access to AdminSDHolder to trusted administrators only. Require proper review for any modification requests, and document every change, detailing why the change is needed and when it was made. In addition, configure real-time alerts for any changes made to AdminSDHolder to ensure visibility and accountability.
Regularly audit the AdminSDHolder ACL, and monitor SDProp behavior.
Review the permissions configured directly on AdminSDHolder regularly, evaluating the access level of each object to find any unexpected or extra rights that are not consistent with the documented permissions.
Monitor the SDProp process using event logs or PowerShell scripts. In particular, monitor both successful and failed scheduled runs, since frequent failures or modifications could indicate malicious activity.
Restrict who can modify ACLs.
Administrators can configure Group Policy to prevent lower privileged administrators from altering critical permissions, including the AdminSDHolder ACL. In addition, organizations can adopt a tiered administrative model that separates administrator accounts and other critical AD assets from less privileged objects, and strictly controls interactions between assets in different tiers. This approach limits the impact of a compromised account.
Invest in appropriate security solutions.
For a robust defense against AdminSDHolder attacks, consider investing in a purpose-built security solution such as the following:
- Netwrix Auditor provides detailed reporting on Active Directory permissions, risk assessments, continuous monitoring, and real-time alerts on suspicious activity. It also simplifies delegation of access reviews and supports audit readiness.
- Netwrix Privileged Access Management (PAM) enforces just-in-time access for high-privilege accounts, enabling administrators to elevate rights only when needed and only for a limited duration. This minimizes the attack surface and helps contain the impact of a compromised account.
- Netwrix Data Classification helps identify and protect sensitive information linked to privileged users, reinforcing least-privilege access and compliance efforts.
Recognizing and Responding to AdminSDHolder Abuse
Organizations need to be able to promptly detect AdminSDHolder attacks, respond effectively, and recover quickly.
Signs of Compromise
The most direct sign of an AdminSDHolder attack is suspicious changes to the ACL. Attackers may add their compromised accounts to the AdminSDHolder object, modify the existing permissions of low-privileged accounts to escalate privilege, and remove or modify permissions of legitimate administrative groups.
In addition, as mentioned above, any non-privileged objects with an AdminCount value of 1 merit immediate investigation. If an account was a member of a privileged group but has been removed, its AdminCount value should revert to 0. If it remains 1 for an extended period, check for malicious manipulation.
Response Actions
If you find evidence of an AdminSDHolder attack, take the following steps:
- Isolate the PDC emulator — The primary domain controller (PDC) emulator holds the FSMO role responsible for applying AdminSDHolder permissions to protected objects. Isolating it temporarily from the network can contain the propagation of malicious ACL changes.
- Audit AdminSDHolder — Examine the AdminSDHolder ACL for unauthorized modifications by comparing it with your record of authorized changes. Document your findings to help the team understand the attackers' probable intent.
- Remove suspicious permissions — Revert any improper changes, and force the PDC emulator to reapply AdminSDHolder permissions to all protected objects.
Recovery
After correcting the AdminSDHolder permissions and forcing replication, verify the permissions of all privileged accounts.
In addition, scan all AD domains for accounts with AdminCount=1, and revert that value back to value 0 where 1 is not required. If inheritance is disabled, re-enable it.
Security Implications for Key Industries
- Healthcare — Attackers who gain persistent access via AdminSDHolder attacks can compromise electronic health record (EHR) systems, manipulate medical devices, block or alter financial systems, encrypt data for ransom, or manipulate insurance data for financial fraud. Compromise of protected health information (PHI) can be a violation of HIPAA that results in massive fines and lasting reputation damage.
- Finance — In financial institutions like banks and trading platforms, AdminSDHolder exploits can enable attackers to steal confidential information and perform unauthorized transactions, which can result in fines related to violations of SOX, GLBA, or PCI-DSS.
- Government — AdminSDHolder attacks on government organizations can result in theft, leakage, and misuse of highly sensitive information related to national defense, intelligence, and critical infrastructure, any of which can have profound ramifications.
MITRE ATT&CK® and ATT&CK® are registered trademarks of The MITRE Corporation.