BadSuccessor is a privilege-escalation technique that abuses delegated Managed Service Accounts in Active Directory. An attacker with sufficient rights can create or alter a dMSA, link it to a privileged account, and potentially obtain elevated access. The risk comes from control-plane abuse, not from a traditional software exploit alone.
Expanded Definition
BadSuccessor refers to an abuse path in Active Directory delegation where a managed service account relationship becomes the mechanism for privilege escalation. The attacker does not need to break the underlying directory software; they need sufficient control-plane access to create, alter, or rebind a delegated Managed Service Account so it inherits or reaches privileged context. That makes the issue an identity and authorization problem, not a classic code-execution flaw.
In NHI security terms, BadSuccessor sits close to service-account governance, delegated administration, and privilege inheritance. Its practical impact depends on how tightly organisations constrain who can modify account relationships, link service identities, and approve sensitive directory changes. Guidance varies across vendors on how to classify the technique, but the operational lesson is consistent: delegated identity objects must be treated as high-risk assets because their configuration can become a privilege bridge. The control-plane can be more dangerous than the workload it serves.
The most common misapplication is assuming a managed service account is safe because it is non-interactive, which occurs when teams overlook who can modify its delegation and account-linking permissions.
Examples and Use Cases
Implementing protections against BadSuccessor rigorously often introduces administrative friction, requiring organisations to balance delegated automation against tighter approval and monitoring controls.
- A directory administrator creates a delegated Managed Service Account and links it to a privileged group, turning a routine service change into an escalation path.
- A compromised tier-2 operator account is used to alter account relationships in Active Directory, allowing the attacker to inherit stronger access than the original account should permit.
- Security teams review service-account ownership, delegation boundaries, and change logs as part of the governance patterns described in the Ultimate Guide to NHIs.
- Identity engineers apply least-privilege design principles from the NIST Cybersecurity Framework 2.0 to reduce who can create, modify, or delegate service identities.
- Incident responders trace privileged access anomalies back to configuration drift in delegated account objects rather than to malware on the host itself.
BadSuccessor is most relevant in environments that use delegated administration at scale, especially where service identities are provisioned quickly and reviewed infrequently. It also appears in hybrid estates where on-prem Active Directory remains the control plane for critical workloads.
Why It Matters in NHI Security
BadSuccessor matters because it shows how NHI compromise often begins with permission design, not credential theft. If service identities can be rebound, delegated, or repurposed without strong approvals, an attacker can move from ordinary access to privileged control through the identity layer itself. That is why NHI governance must cover lifecycle, ownership, and change authority, not just secret rotation. The Ultimate Guide to NHIs reports that 97% of NHIs carry excessive privileges and only 5.7% of organisations have full visibility into their service accounts, which creates ideal conditions for delegation abuse to go unnoticed.
From a defence perspective, BadSuccessor reinforces the need to inventory service identities, restrict who can alter delegation relationships, monitor directory changes, and separate administrative tiers. It also aligns with zero-trust thinking in the NIST Cybersecurity Framework 2.0, where access decisions must remain continuously constrained rather than assumed safe after initial issuance. Organisations typically encounter the consequences only after a privileged account is misused or an incident review reveals that a delegated service identity had become the escalation route, at which point BadSuccessor becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 | Covers excessive privilege and delegated identity abuse patterns in NHI environments. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege and access management controls apply directly to delegated account modifications. |
| NIST Zero Trust (SP 800-207) | AC-3 | Zero Trust requires each access path to be explicitly authorized, including service identity delegation. |
| NIST SP 800-63 | Identity assurance concepts help separate strong admin identity proofing from low-assurance service account handling. | |
| CSA MAESTRO | Agentic and delegated identities require governance over tool access and authority boundaries. |
Apply stronger assurance and administrative separation to accounts that can alter privileged identity relationships.
