Notifications
Clear all
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.
NHIMG editorial — based on content published by Semperis: BadSuccessor and dMSA abuse in Active Directory
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
Questions worth separating out
Q: What breaks when dMSA migration attributes are writable by more than Domain Admins?
A: The migration workflow stops being a controlled service-account transition and becomes a privilege escalation path.
Q: Why do delegated Managed Service Accounts increase Active Directory risk if they are misconfigured?
A: Because they can inherit permissions from a linked predecessor, and that makes the predecessor relationship security-critical.
Q: What do security teams get wrong about managed service account migration?
A: They often focus on the migration command itself and overlook the underlying write surface on directory attributes.
Practitioner guidance
- Review every path to dMSA attribute writes Map who can modify msDS-DelegatedMSAState, msDS-ManagedAccountPrecededByLink, and related properties.
- Treat dMSA creation as Tier-0 change control Require approval, logging, and dedicated ownership for any new dMSA or migration workflow that touches privileged service accounts.
- Validate schema-level blocking for successor abuse Use the article’s schema-based blocking approach where appropriate, and test that it still allows legitimate migration while preventing unauthorized predecessor changes.
What's in the full article
Semperis's full blog post covers the operational detail this post intentionally leaves for the source:
- PowerShell command sequences for starting, completing, undoing, and resetting dMSA migration
- Schema attribute behaviour and the specific write conditions that enable successor abuse
- Hands-on mitigation logic for blocking the migration use case while preserving legitimate administration
- Detection indicators for exposure and compromise in directory services telemetry
👉 Read Semperis's analysis of BadSuccessor and dMSA privilege escalation in Active Directory →
BadSuccessor and dMSA abuse: what AD teams need to block?
Explore further
25/06/2026 10:28 am
dMSA migration is a governance boundary, not just an account transition: The article shows that a modern service-account migration path can become a privilege inheritance channel if linked-object controls are too broad. The important lesson for identity teams is that modernisation features inherit the security of the delegation model around them. Practitioners should classify dMSA migration as a Tier-0 governance event, not an ordinary service-account task.
A few things that frame the scale:
- Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to The 2024 ESG Report: Managing Non-Human Identities.
- Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, according to The 2024 ESG Report: Managing Non-Human Identities.
A question worth separating out:
Q: Who is accountable when dMSA abuse exposes privileged Active Directory accounts?
A: The accountable owners are the directory and identity teams that govern delegation, schema changes, and privileged object lifecycle. For this risk, responsibility sits with the operators who control AD design and access paths, not just with the application teams using the service accounts.
👉 Read our full editorial: BadSuccessor shows how dMSA abuse can expose Active Directory
