dMSA privilege escalation in active directory exposes new identity risk

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Netwrix's blog post: BadSuccessor-style dMSA abuse in Active Directory allows migration attributes to be manipulated to impersonate privileged users without obvious group changes.

Why it matters: It matters because IAM and PAM teams cannot rely on traditional account membership monitoring alone when service-account identity state itself becomes the escalation path.

By the numbers:

• Akamai found that 91% of analysed environments had at least one organisational unit where user accounts had sufficient permissions to exploit this technique.

Context

Delegated managed service accounts, or dMSAs, are a Windows Server 2025 identity type designed to bind service authentication more tightly to a machine. The governance problem is that their migration state and linking attributes become security-relevant control points, not just setup details.

In this case, the identity risk sits inside Active Directory administration and service-account lifecycle management. If an attacker can alter the migration attributes that connect a dMSA to a prior account, Kerberos can issue tickets that reflect privileges the attacker should not have.

That makes this a service-account governance issue as much as a privilege escalation issue. The article’s starting position is atypical in the sense that the attack path is new, but the control failure it exposes is familiar: weak visibility into machine-account state and delegated write rights.

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 do dMSAs create privilege escalation risk in Active Directory?

A: They create risk because the migration relationship between a dMSA and its predecessor can be manipulated to make the account appear to carry a higher privilege context. That turns identity state into an escalation mechanism. The danger is greatest where OU permissions allow creation or modification of these accounts without tight delegation boundaries.

Q: How can teams tell whether dMSA abuse is happening?

A: Look for attribute changes on dMSA objects, unexpected migration state transitions, and Kerberos ticket activity that does not match the known service-account baseline. If monitoring only follows group membership or interactive logon events, the attack can stay hidden. Detection has to follow the identity object and the ticketing path together.

Q: What should organisations do after finding risky dMSA permissions?

A: Revoke unnecessary delegated write rights, validate every dMSA migration path, and reclassify dMSAs as privileged identities for review purposes. The priority is to close the object-level control gap before it becomes a repeatable escalation route. Once the permissions are fixed, keep monitoring the attributes that define the account’s trust chain.

Technical breakdown

How dMSA migration attributes become an escalation path

A dMSA can be created as a replacement for a legacy user-based service account, and migration sets attributes that record the predecessor and migration state. Those fields are meant to preserve service continuity while moving authentication to the new object. The risk appears when an attacker can change the predecessor link or related migration state, because the directory and Kerberos components then treat the dMSA as connected to a more privileged identity than it should be. This is not group membership abuse. It is attribute abuse on the identity object itself, which makes ordinary entitlement reviews miss the dangerous change.

Practical implication: Review and lock down write access to dMSA migration attributes and the OUs where they can be created.

Why Kerberos makes the impersonation look legitimate

Kerberos does not simply ask whether a user changed groups recently. It issues tickets based on the identity state presented by the directory and the key distribution path. If the dMSA migration metadata points to a privileged predecessor, the KDC can issue tickets that behave as though the account has that user’s standing. That is why the attack can bypass traditional alerts tied to logon events or group change monitoring. The authentication flow itself is being fed manipulated identity context, so the resulting ticket appears consistent even though the underlying authorization story is not.

Practical implication: Correlate Kerberos ticket issuance with attribute-change telemetry, not just with logon and group membership events.

Why legacy AD controls miss dMSA abuse

The article shows a gap between directory-change visibility and privilege-assignment monitoring. Traditional AD defensive logic expects escalation to show up through group changes, credential theft, or obvious admin activity. dMSA abuse sidesteps those signals by preserving the outward shape of a legitimate service account while changing the identity linkage beneath it. That means detection has to move from account-state summaries to object-attribute monitoring, especially for migration logs, unexpected dMSA creation, and unusual ticket requests. In practical terms, the control surface is narrower and more technical than a normal access review.

Practical implication: Add attribute-level monitoring for dMSA creation, migration, and ticket patterns to your AD detection stack.

Threat narrative

Attacker objective: The attacker wants stealthy domain-level privilege that can be exercised through a service-account identity path without triggering the usual AD alarms.

1. Entry occurs when an attacker gains a foothold in an Active Directory environment and finds an organisational unit where delegated write rights are too broad.
2. Credential or privilege abuse follows when the attacker modifies dMSA migration attributes such as the predecessor link to steer the account toward a privileged identity.
3. Escalation happens when the Kerberos Key Distribution Center issues tickets that reflect the inherited privileged context, even though no obvious group membership change occurred.
4. Impact is persistent administrative access that looks legitimate to ordinary monitoring and can survive basic remediation that only resets passwords or checks memberships.

Breaches seen in the wild

• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.

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

NHI Mgmt Group analysis

Delegated managed service account escalation is really an object-state problem, not a group-membership problem. dMSAs shift service identity into a migration model where predecessor links and state flags matter as much as membership. That means the governance boundary is the directory object itself, not the role or group assignment layer. Practitioners should treat dMSA metadata as privileged control plane data.

The assumption that service-account privilege will surface through ordinary monitoring has already failed. The article shows that attackers can change dMSA migration attributes and still produce Kerberos activity that looks legitimate. That assumption was designed for observable account changes and durable privilege states. It fails when the privilege transition is encoded in identity attributes that do not map cleanly to group-change monitoring. The implication is that service-account governance has to move closer to attribute-level enforcement.

Identity blast radius now includes the migration path itself. The real risk is not only an overprivileged service account, but the ability to transform a low-friction migration workflow into a privilege-escalation bridge. That widens the blast radius of delegated rights on OUs and makes lifecycle design part of the attack surface. Practitioners need to assess where identity changes can silently reframe authority.

Active Directory controls must be evaluated as identity telemetry controls, not just access controls. In dMSA abuse, the ticketing system and the directory are both part of the evidence chain. If either layer is weak, the escalation can remain invisible until the attacker already operates with elevated access. Security teams should align AD monitoring with the specific object attributes that define service identity state.

Zero Trust only helps if it extends to identity state mutation. Treating dMSAs as high-value identities is necessary, but not sufficient, because the issue is who can alter the trust relationship behind the identity. The governance question is whether the organisation can prevent or detect identity-state changes before they are converted into trusted Kerberos output.

From our research library:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
• Read next: Service Account Security Guide

What this signals

Identity-state visibility is the new weak point in AD governance. dMSA abuse shows that service-account risk can be created by changing the metadata that binds one identity to another, not by taking over a password or adding a user to a group. That means access reviews that only examine durable entitlements will miss the moment when trust is rewritten.

dMSA privilege escalation is a lifecycle failure as much as a security failure. The migration path from legacy service accounts creates a short chain of accountability that can become long-lived if delegated rights are too broad. Organisations should assume that any service-account lifecycle step capable of changing identity provenance deserves the same scrutiny as privileged access provisioning.

For practitioners

• Restrict dMSA creation rights Limit CreateChild, WriteProperty, WriteDACL, Generic All, and WriteOwner permissions on organisational units that can host dMSAs. Review delegated administration paths first, because the attack depends on changing the object state that defines the account.
• Monitor migration attributes directly Track changes to msDS-ManagedAccountPrecededByLink and msDS-DelegatedMSAState, along with unexpected dMSA creation or modification. Traditional group-change alerts are not enough because the attack operates below that layer.
• Baseline legitimate dMSA behaviour Document which dMSAs exist, which machines they bind to, and what normal Kerberos ticket patterns look like. The goal is to flag impersonation behaviour, not just unusual login volume.
• Treat dMSAs as privileged identities Apply the same governance discipline you use for administrative accounts, including tighter review of lifecycle changes and continuous authentication telemetry. dMSAs should not inherit trust simply because they were created through a migration workflow.

Key takeaways

• dMSA abuse turns Active Directory migration metadata into an escalation mechanism, so the real control problem is object-state governance rather than simple group review.
• The article shows that traditional monitoring can miss the attack because Kerberos tickets can look legitimate even when the trust relationship behind them has been manipulated.
• Limiting delegated write rights and watching dMSA attributes directly are the controls most likely to interrupt the abuse path before domain-level access is obtained.

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.
• Migration Attribute: A migration attribute is directory metadata that records how a dMSA maps to a predecessor account and what migration stage it is in. These fields are important because they can influence how the identity is interpreted by authentication systems, so they must be governed like privileged configuration.
• Kerberos Ticket-Granting Ticket: A Kerberos credential that proves the user has already authenticated and can request service tickets without re-entering credentials. In delegation scenarios, it becomes valuable because a service may store it in memory, making it a target for attackers who compromise the host.
• Identity Provenance: Identity provenance is the record of how an agent was created, what authority it received, and what actions it performed over time. It turns agent activity into an auditable chain of trust that supports compliance, incident response, and post-event accountability.

Deepen your knowledge

Identity lifecycle management, secrets management, and workload identity security 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.