BadSuccessor shows how dMSA abuse can expose Active Directory

At a glance

What this is: This is an analysis of how BadSuccessor turns delegated Managed Service Accounts into a path for Active Directory privilege escalation by abusing writable migration attributes.

Why it matters: It matters because AD teams now have to treat dMSA governance, delegation review, and schema-level safeguards as part of privilege control, not just account migration hygiene.

Context

BadSuccessor is a privilege escalation technique affecting delegated Managed Service Accounts in Windows Server 2025 Active Directory. The core issue is not dMSA migration itself, but the fact that writable attributes can be manipulated to make a migration object act like a higher-privilege account.

Semperis describes a condition where attackers can abuse a dMSA to impersonate enabled or disabled principals, including Domain Admins and KRBTGT, if they can control the right attributes. That makes delegation review and schema protection part of the access-control problem, not a separate administration task.

The article frames this as a forest-level governance issue for environments that introduce even one writable Windows Server 2025 domain controller. That starting position is atypical for legacy AD guidance because the attack surface appears with the new account type and its migration path.

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. If non-admin users can create or alter the attributes that define a dMSA’s predecessor relationship, they can manufacture authority inside Active Directory without changing group membership. That is why directory attribute governance must be treated as privilege governance.

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. In practice, that means a local directory configuration problem can become full domain compromise.

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. Those signals indicate the object is being shaped for abuse rather than used as a normal service-account transition.

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.

Technical breakdown

How dMSA migration changes authentication paths

A delegated Managed Service Account is intended to replace a legacy service account during migration while preserving application behaviour. During the normal migration flow, the directory updates linked attributes, changes the migration state, and transfers relevant configuration so the dMSA can take over authentication. The important detail is that the dMSA does not simply store credentials. It also inherits effective rights through the migration relationship, which is why the control plane around the attribute state matters as much as the account itself. When that state can be rewritten directly, the intended migration boundary stops behaving like a boundary.

Practical implication: treat dMSA migration attributes as authorization-bearing objects, not harmless metadata.

Why writable dMSA attributes create privilege escalation

BadSuccessor works because the attributes involved in dMSA migration are not fully protected from regular LDAP writes. If an attacker can set the dMSA state and point it at a chosen linked account, the writable domain controller can merge privilege data and issue authentication material that reflects the combined result. That means the attack does not need the legitimate PowerShell migration flow to succeed. It only needs enough write capability on the relevant object and the ability to influence which principal the dMSA is treated as successor to. In effect, the migration logic becomes a privilege amplifier.

Practical implication: review every permission path that can write dMSA-linked attributes, not just direct admin tooling access.

Why administrative tiering still matters for dMSA abuse

The article shows that the attack becomes especially dangerous when the linked account name is guessable or exposed, because the dMSA can be directed toward highly privileged principals such as Administrator or KRBTGT. Administrative tiering reduces that exposure by making privileged account distinguished names harder for lower-tier principals to discover or target. That does not eliminate the flaw, but it narrows the abuse path and makes the attacker’s job harder. For AD governance, the lesson is that naming, placement, and tier boundaries are part of the security control surface, not just operational structure.

Practical implication: hide Tier 0 account paths and isolate privileged OUs before introducing Windows Server 2025 writable DCs.

Threat narrative

Attacker objective: The attacker aims to impersonate highly privileged Active Directory accounts and pivot into full domain or forest compromise.

1. Entry occurs when an attacker gains Write Property access, or an equivalent path to it, on a delegated Managed Service Account object.
2. Credential or privilege abuse follows when the attacker rewrites dMSA state and linked-account attributes to make the object point at a privileged principal.
3. Impact occurs when the writable domain controller issues authentication material that reflects the merged privileges of the chosen target, enabling domain takeover.

Breaches seen in the wild

• Cisco Active Directory credentials leak 2025: Kraken leaked Cisco Active Directory hashes, including service and krbtgt accounts; Cisco says they came from its 2022 breach, not a new one.
• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Privileged name visibility is now part of the attack surface: the article shows that knowing or guessing the distinguished name of Administrator or KRBTGT can materially change the blast radius of a dMSA abuse path. Administrative tiering is therefore not only about segregation of privilege, but also about reducing target discoverability. Practitioners should treat privileged account naming and placement as a control input.

BadSuccessor belongs in the wider privilege escalation pattern for machine identities: the core problem is not a password leak but an object that can be made to inherit more authority than its intended use case allows. That makes the failure conceptually close to overprivileged NHI behaviour, even though the mechanism is directory-native. Practitioners should map dMSA governance to privilege escalation controls, not just service-account hygiene.

Blockable migration paths create a useful governance pattern, but only if ownership is explicit: Semperis describes a schema-level mitigation that can disable the migration use case while preserving the option to re-enable it for planned transitions. That is a strong signal that AD change control, schema governance, and delegation review must converge. The practical conclusion is that dMSA introduction requires named ownership and reversible policy decisions.

Excessive privilege in AD is still the enabling condition: the article’s abuse path only matters when writers, delegates, or tier boundaries are already too loose. The control question is not whether a dMSA exists, but whether the directory exposes any path from routine write access to high-value authentication outcomes. Practitioners should evaluate delegation and schema permissions as one exposure chain.

From our research library:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• Read next: Service Account Security Guide

What this signals

BadSuccessor shows that migration logic can become an access-control boundary when the underlying object is writable: AD teams should stop treating dMSA state as administrative metadata and start treating it as privilege-bearing configuration. That shift changes how delegation, schema permissions, and Tier 0 exposure are reviewed.

The practical signal for programmes is simple: if a new identity type can inherit authorization through state transitions, then the control model has to govern both the object and the transition. That is where machine identity governance meets directory administration, and where many AD programmes are still underbuilt.

For practitioners

• Review dMSA write paths Identify every user, group, and delegated process that can write to dMSA-linked attributes or reach that permission indirectly. Focus on the attributes that influence migration state and successor linkage, because those are the controls BadSuccessor abuses.
• 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. This preserves native dMSA use while reducing abuse of the migration path.
• 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. This reduces the chance that a controlled dMSA can be pointed at a critical identity.
• Monitor dMSA state changes Track changes to dMSA creation, migration state, linked-account configuration, and password or key retrieval rights. Those events are the earliest signs that a migration object is being repurposed as an escalation path.

Key takeaways

• BadSuccessor demonstrates that writable dMSA migration attributes can be turned into a privilege escalation path inside Active Directory.
• The article says the attack can be used against highly privileged accounts such as Domain Admins and KRBTGT, which makes the blast radius domain-wide.
• The key defensive move is to block or tightly govern the migration path in the schema and limit who can reach the relevant dMSA write permissions.

Key terms

• Delegated Managed Service Account (dMSA): A dMSA is a Windows service identity tied to a specific machine and designed to replace older service accounts through migration. In practice, it is a non-human identity whose trust relationship can change during migration, which makes its lifecycle state a security control, not just an administration detail.
• Privilege Escalation: An attack technique where a compromised identity, often an NHI with initially limited permissions, exploits vulnerabilities or misconfigurations to gain elevated access rights, typically leading to broader compromise.
• Administrative Tiering: Administrative tiering is a model that separates privileged accounts and systems into distinct trust levels, such as Tier 0 for the most critical identity infrastructure. The goal is to prevent high-value credentials from being exposed on lower-trust machines, where attackers could steal them and reuse them for broader compromise.
• Writable Domain Controller: A writable domain controller is an Active Directory controller that can accept directory changes, not just read them. For this topic, its importance is that a writable controller will process the manipulated dMSA state and link data that make BadSuccessor possible.

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 building or maturing an IAM programme, it is worth exploring.