Topic starter
25/06/2026 1:12 am
TL;DR: BadSuccessor exploits delegated Managed Service Accounts in Windows Server 2025 Active Directory to let attackers impersonate highly privileged principals, including Domain Admins and KRBTGT, according to Semperis. The core governance failure is that migration controls assume only intended account paths will be used, but writable attributes can be abused to collapse that boundary.
Editorial analysis by NHI Mgmt Group, based on content published by Semperis: “How to Block BadSuccessor: The Good, Bad, and Ugly of dMSA Migration”.
Key questions
Q: What breaks when dMSA migration attributes are writable by non-admin users?
A: The boundary between a benign service account and a privileged impersonation path breaks.
Q: Why does BadSuccessor create such a high-impact AD risk?
A: 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.
Q: What signs suggest dMSA abuse is underway?
A: Watch for unexpected dMSA creation, unusual changes to migration state, altered successor links, or password and key retrieval activity that does not match a planned migration.
Practitioner guidance
- Review dMSA write paths Identify every user, group, and delegated process that can write to dMSA-linked attributes or reach that permission indirectly.
- Block migration use until needed Use the schema-level block on the migration scenario where your organisation does not need dMSA migration yet, then remove it only for controlled transitions and restore it afterwards.
- Isolate Tier 0 account paths Move highly privileged accounts into separate, tightly controlled OUs and make their distinguished names harder for lower-tier principals to discover or guess.
Bottom line: BadSuccessor demonstrates that writable dMSA migration attributes can be turned into a privilege escalation path inside Active Directory.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 10:28 am
BadSuccessor is a schema trust failure, not just an account abuse issue: the attack works because migration metadata is treated as reliable even when it is writable. That assumption fails when a low-friction LDAP write can redirect the successor path to a privileged principal. The implication is that AD teams must reclassify dMSA migration state as a security boundary, not an implementation detail.
A few things that frame the scale:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: How should AD teams prevent dMSA abuse during Windows Server 2025 rollout?
A: Separate planned migration from standing privilege, restrict who can write the dMSA attributes that influence successor behaviour, and keep privileged account paths hidden in protected administrative tiers. That combination reduces the chance that a writable dMSA becomes a takeover path.
👉 Read our full editorial: BadSuccessor shows how dMSA abuse can expose Active Directory