BadSuccessor shows how dMSA abuse can expose Active Directory

At a glance

What this is: This is a Semperis analysis of BadSuccessor, a dMSA abuse path in Windows Server 2025 Active Directory that can be used to impersonate privileged accounts.

Why it matters: It matters because AD teams now have to treat dMSA introduction, delegation, and schema-level controls as part of privileged identity governance, not just service-account hygiene.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.

👉 Read Semperis's analysis of BadSuccessor and dMSA privilege escalation in Active Directory

Context

BadSuccessor is a privilege escalation path in Active Directory that turns delegated Managed Service Account, or dMSA, migration logic into an abuse primitive. The issue matters to Active Directory and non-human identity governance because a control designed to modernise service accounts can be repurposed to inherit privileged access if its trust boundary is too loose.

The article’s central point is not that dMSAs are unsafe by design, but that migration workflow, writable attributes, and delegation assumptions can be separated in practice. For AD teams, that means the security model for service-account modernisation has to be treated as a governance problem, not just a configuration task.

Key questions

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. If attackers can write dMSA state or predecessor-link attributes, they can influence which identity is inherited during authentication and use that relationship to impersonate more privileged accounts.

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. If the object model allows unauthorized changes to that relationship, a service-account feature can be repurposed into a domain impersonation mechanism rather than a maintenance improvement.

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. The real control problem is whether any account outside the intended admin set can alter the dMSA objects that determine who receives inherited privileges.

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.

Technical breakdown

How dMSA migration is supposed to work

Windows Server 2025 introduces delegated Managed Service Accounts to migrate legacy service accounts into a managed form with automated credential rotation. In the intended flow, an administrator starts migration, the system discovers where the old account is used, and the dMSA inherits the service context needed to keep applications running. The key mechanism is the linked relationship between the legacy account and the dMSA, plus state transitions stored on the object. This is meant to preserve functionality while reducing manual password management. The design assumes the migration path is tightly controlled and that only authorised administrators can shape the relationship.

Practical implication: treat dMSA migration as a privileged change workflow and control who can create, link, or modify those objects.

Why writable dMSA attributes create abuse conditions

The BadSuccessor technique works because some migration-related dMSA attributes can be written through regular LDAP permissions, not only through the intended PowerShell migration commands. That matters because the Windows Server 2025 domain controller relies on state and linked-account attributes during authentication, so an attacker who can alter those values can influence which identity is treated as the predecessor. Once that link exists, the domain controller can merge privileges in a way that was meant for legitimate succession. The flaw is less about a broken protocol than about an overly permissive object model around a high-impact identity transition.

Practical implication: restrict write access to dMSA-linked attributes and review any delegation that can reach them indirectly.

How privilege inheritance becomes domain takeover

When the dMSA is set to the completed migration state and pointed at a chosen predecessor, the domain controller can merge the Privileged Attribute Certificate of the linked account with the dMSA’s context. That means the attacker does not need the original privileged account’s password if they can control the dMSA and the linked reference. Because the referenced account can be a high-value target such as Administrator or KRBTGT, the abuse can escalate from service-account manipulation to full domain compromise. The technical risk is the combination of object state, linked identity, and privilege inheritance inside the KDC flow.

Practical implication: monitor for unexpected state transitions and linked-account changes on dMSAs before they are used to authenticate.

Threat narrative

Attacker objective: The attacker’s objective is to turn a delegated service-account mechanism into privileged Active Directory impersonation and, in the worst case, full domain compromise.

1. Entry occurs when an attacker gains write access to a dMSA or to attributes that can influence dMSA linkage in Active Directory.
2. Escalation occurs when the attacker sets the dMSA state and linked predecessor so the domain controller treats the dMSA as inheriting another account’s privileges.
3. Impact occurs when the merged PAC grants high-value AD rights, enabling impersonation of privileged principals and potential domain takeover.

Breaches seen in the wild

• Cisco Active Directory credentials breach — Kraken ransomware group leaked Cisco Active Directory credentials.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Write permissions on migration attributes are the real control gap: BadSuccessor worked because regular LDAP writes could manipulate dMSA state and predecessor linkage even when the official migration commands looked controlled. That means the effective security boundary was not the PowerShell workflow, but the attribute-level write surface underneath it. Practitioners should review every path that can lead to write access on dMSA-linked properties.

Privilege inheritance in AD becomes dangerous when the predecessor can be chosen: The article makes clear that the attack depends on controlling which account the dMSA appears to succeed. Once that reference can point at a highly privileged principal, the whole succession model stops being a narrow service migration and becomes a domain impersonation primitive. Practitioners should treat predecessor identity as a protected control point, not metadata.

Delegation review must expand to schema-level controls: Semperis’ mitigation approach is telling because it moves the defense into the AD schema rather than relying only on detection. That reflects a broader pattern in machine identity governance: when identity objects can inherit power, the schema is part of the access model. Practitioners should validate whether their governance model includes the directory design itself, not only account reviews.

Standing privilege assumptions survive inside managed identity features: The article reinforces that reducing password handling does not remove privilege risk if the underlying object still inherits high-value access. The named concept here is privilege inheritance drift, where a service identity gains more power than the migration story implies. Practitioners should verify that managed identities cannot be repurposed into broader authority than intended.

From our research:

• 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.
• For the broader control model behind these failures, see NHI Lifecycle Management Guide for lifecycle ownership and offboarding discipline.

What this signals

Privilege inheritance drift: dMSA adoption does not just modernise service accounts, it can widen the blast radius of identity governance mistakes if predecessor links and state changes are not tightly controlled. Teams should expect schema-level reviews to matter as much as access reviews for this class of risk.

The operational signal is simple: if your AD team cannot explain who can write migration attributes, who can approve dMSA creation, and how those objects are monitored, you do not yet have a defensible governance model. That gap will matter most when privileged service identities are migrated under pressure.

The broader pattern is that NHI risk often hides inside legitimate administration paths. As service-account modernisation accelerates, practitioners should pair directory telemetry with lifecycle discipline from the NHI Lifecycle Management Guide and align control ownership to the identity object, not just the workload.

For practitioners

• Review every path to dMSA attribute writes Map who can modify msDS-DelegatedMSAState, msDS-ManagedAccountPrecededByLink, and related properties. Remove indirect write paths, delegated admin shortcuts, and tooling permissions that can reach those attributes through inherited rights.
• 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. Include computer accounts, gMSAs, and any delegated admin role that can influence the object lifecycle.
• 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. Recheck the configuration after every directory change or forest upgrade.
• Add directory detections for state and link manipulation Alert on unexpected dMSA state transitions, changes to the predecessor link, and privilege-bearing account references such as Administrator or KRBTGT. Correlate those events with account creation and LDAP write activity.

Key takeaways

• BadSuccessor shows that a managed service-account migration feature can become a domain-wide escalation path when directory attributes are writable in the wrong places.
• The exposure is severe because dMSA abuse can pivot into privileged impersonation of accounts such as Domain Admins or KRBTGT.
• Schema-level blocking, write-path review, and state-change monitoring are the controls that determine whether dMSA modernisation stays safe.

Key terms

• Delegated Managed Service Account: A delegated Managed Service Account, or dMSA, is a Windows Server 2025 account type designed to help migrate legacy service accounts into a managed form. It supports credential rotation and service continuity, but its security depends on tightly controlled migration state, linking, and directory permissions.
• Privilege Inheritance Drift: Privilege inheritance drift is the gap between the access a managed identity is supposed to have and the access it can actually inherit through linked objects or migrated configuration. In Active Directory, the problem becomes severe when successor relationships can be manipulated to pull in rights from a more privileged predecessor.
• Directory Schema Control: Directory schema control is the governance of how identity objects behave at the attribute level, including which fields can be written, by whom, and under what state conditions. In this article’s context, schema control is part of the security boundary because the attack depends on manipulating object properties, not just logging in.
• PAC Merging: PAC merging is the process by which a domain controller combines Privileged Attribute Certificate data from related account objects during authentication. It is intended to preserve service access during legitimate migration, but it becomes dangerous if an attacker can choose the predecessor account and inherit a wider set of privileges.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Semperis: BadSuccessor and dMSA abuse in Active Directory. Read the original.