Because it can be used to impersonate highly privileged principals, including Domain Admins and KRBTGT, if the attacker can control the right dMSA state and linkage. In practice, that means a local directory configuration problem can become full domain compromise.
Why BadSuccessor is so dangerous in Active Directory
BadSuccessor is high impact because the abuse path is not just “get access”, it is “become someone who can act as the most trusted principal in the domain”. If an attacker can control the right dMSA state and linkage, the issue can cross from a local directory misconfiguration into domain-wide impersonation and takeover.
That is why the risk feels disproportionate to the initial weakness. The vulnerable condition lives in directory configuration and delegated identity state, but the payoff lands at the top of the trust hierarchy, where Domain Admin-style authority and KRBTGT-level control can rewrite what the rest of the domain trusts.
In practice, the concern is not limited to one compromised account. Once the attack path can impersonate high-value principals, the attacker can move from access to authority, which is what makes this class of AD issue so severe compared with ordinary account compromise.
How the attack path turns a configuration flaw into domain compromise
BadSuccessor matters because it weaponises a trust relationship inside AD rather than relying on password guessing or obvious malware. The attacker is exploiting how directory objects, linkage, and privileged identity state interact, so the control failure is structural: the directory believes the action is legitimate because the surrounding state looks valid.
That makes the exploit attractive in environments where administrative controls are fragmented. If the relevant dMSA state is reachable through weak delegation, overbroad rights, or poor change control, the attacker does not need to break cryptography or defeat a strong login control first, they need to steer the directory into granting authority that was never meant to be granted.
Once that happens, the blast radius is large because AD is a shared trust fabric. A successful impersonation path can affect authentication, authorization, group control, and ticket-granting trust, so the same flaw can create privilege escalation, persistence, and lateral movement opportunities.
Why defenders should treat it as a domain trust issue, not a single-object bug
BadSuccessor should be understood as a trust-boundary failure with enterprise consequences. The immediate object manipulation is only the mechanism; the real security problem is that a low-level directory condition can be converted into the authority to issue, inherit, or impersonate domain-critical identity state.
That is why local-only thinking underestimates it. If defenders review only the affected object or the obvious admin path, they can miss the higher-order effect, which is that compromise of one managed state can become control over many downstream access decisions, especially where legacy AD design centralises trust and privilege.
For that reason, the right mental model is “who can cause AD to accept a higher privilege identity outcome?” rather than “which account was directly touched?” That shift exposes why the issue is operationally severe even before visible abuse appears.
Risk and Threat Considerations
BadSuccessor is dangerous because it converts an authorisation and delegation weakness into a path for privileged impersonation. The main risk is domain compromise through abuse of trusted directory state, which can remain hard to spot if normal administrative workflows and attack activity look similar at the object level.
Failure mechanism: An attacker manipulates the relevant dMSA linkage or state so the directory accepts a privileged identity relationship that should not exist, then uses that relationship to impersonate high-value principals and extend control across the domain.
Impact: The result can include Domain Admin-level takeover, KRBTGT abuse, ticket forgery potential, and broad loss of trust in AD authentication and authorisation decisions.
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 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | BadSuccessor abuses excessive directory authority and delegated change paths. |
| IA-5 — Authenticator Management | The issue can end in impersonation of highly privileged principals. | |
| Recommendation — Restrict directory write paths to the minimum set of trusted operators. Protect, rotate, and tightly govern credentials that can enable privileged impersonation. | ||
| NIST CSF 2.0 | PR.AA-05 — Least Privilege | The attack depends on rights that let a low-level change become high-trust authority. |
| Recommendation — Enforce least-privilege access for directory administration and privileged state changes. | ||
| MITRE ATT&CK | T1098 — Account Manipulation | BadSuccessor-like abuse manipulates identity state to gain durable privileged access. |
| T1558 — Steal or Forge Kerberos Tickets | KRBTGT-level impact can enable ticket forgery and domain-wide impersonation. | |
| Recommendation — Monitor for account and directory object manipulation that changes effective authority. Hunt for signs that privileged Kerberos trust material or ticket paths are being abused. | ||
Practitioner Guidance
What to verify: Check whether delegated rights, object ownership, and change paths around dMSA-related state are tightly bounded and independently reviewable. If a small set of accounts can create or alter relationships that affect high-trust principals, treat that as a high-risk control gap.
What good looks like: High-value directory state changes are rare, explicitly approved, and attributable, with monitoring that can distinguish legitimate administrative work from privilege-bearing linkage changes. The important question is whether you can prove who changed trust-relevant state, when, and under whose authority.
Practitioner takeaway: Do not assess this as a normal AD hygiene issue; assess it as a path from directory state to domain authority, and prioritise controls that make privileged linkage changes both hard to perform and easy to detect.
Related resources from NHI Mgmt Group
- Why do Windows admin gateways create such high-risk identity exposure when AD CS is nearby?
- Why does SIM swapping create such a high impact credential theft risk for organisations?
- Why does a validation bypass in ingress controller annotations create such a high-impact security risk?
- Why does a compromise in privileged management software create such a high-impact security risk?