dMSA privilege escalation in active directory exposes new identity risk

At a glance

What this is: This is an analysis of how delegated managed service accounts can be abused to escalate privileges in Active Directory through migration attribute manipulation and Kerberos ticket impersonation.

Why it matters: It matters because AD service identities are often treated as routine infrastructure, yet dMSA abuse can silently convert them into high-value escalation paths that standard IAM and PAM controls may miss.

By the numbers:

• 91% of analyzed environments had at least one OU where user accounts had sufficient permissions to exploit this technique.
• 45% of organisations cite lack of credential rotation as the top cause of NHI-related attacks.

👉 Read Netwrix's analysis of dMSA privilege escalation in Active Directory

Context

Delegated managed service accounts, or dMSAs, are Windows service identities tied to a device rather than a human user. The governance problem is that the identity can inherit powerful access through migration attributes and OU permissions, which means an account that looks ordinary can become an escalation path in Active Directory.

The article shows that the issue is not just new account creation. It is the combination of legacy service-account migration, attribute changes, and Kerberos ticket issuance, which makes impersonation appear legitimate unless teams monitor the right directory events and privilege-bearing object 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 delegated managed service accounts increase privilege escalation risk in Active Directory?

A: They increase risk because a service identity can inherit authority through migration state and device linkage, not just through obvious admin assignment. If attackers can reach the object-level permissions that control that state, they may turn a routine service account into a stealth escalation path. The risk is structural, not cosmetic.

Q: How do security teams detect BadSuccessor-style abuse in practice?

A: They need to monitor dMSA attribute modifications, unusual Kerberos ticket issuance, and the creation of new service identities in risky organisational units. Detection has to be state-based, not logon-failure-based, because the attack can preserve normal-looking authentication. Baselines for legitimate dMSAs are essential for spotting drift.

Q: Who should be accountable for dMSA abuse in Active Directory?

A: Accountability should sit with the team that owns directory governance, because the abuse path depends on who can create, modify, and migrate service identities. Security operations can detect the event, but IAM and AD administrators control the permissions that make the attack possible. That separation matters for ownership and remediation.

Technical breakdown

dMSA migration attributes and privilege inheritance

A dMSA is created either as a standalone service identity or as a replacement for an older user-based service account. During migration, attributes such as msDS-ManagedAccountPrecededByLink and msDS-DelegatedMSAState connect the new object to the old one. That linkage is operationally useful, but it also creates an identity bridge an attacker can abuse if they gain write rights on the relevant OU or account object. The key issue is that privilege is not only granted through group membership. In this case, identity state stored in directory attributes becomes the mechanism for inheritance.

Practical implication: audit OU rights and attribute-level write permissions, not just group membership changes.

Kerberos ticket issuance hides impersonation

BadSuccessor works because the Key Distribution Center issues tickets based on the modified dMSA relationship. Once the predecessor link is rewritten, Kerberos can treat the dMSA as if it were the privileged account referenced in migration state. That means the attack does not require obvious password theft or a noisy group change. Traditional alerting that focuses on failed logons, admin group edits, or new privileged logons can miss the event entirely because the authentication flow still appears valid from the directory’s point of view.

Practical implication: monitor Kerberos ticket requests alongside dMSA attribute changes and migration logs.

Why legacy AD monitoring misses dMSA abuse

Many security stacks are tuned to look for classic Active Directory escalation patterns such as Kerberoasting, Golden Ticket abuse, or new privileged group memberships. dMSA abuse sits outside that narrow lens because the object may already be valid, the account may not log on interactively, and the escalation is encoded in directory metadata. Microsoft now exposes logs for the relevant schema changes, but tools must be configured to interpret them. Without that, the attacker’s activity blends into normal service-account administration.

Practical implication: baseline normal dMSA state and alert on unexpected migration or attribute edits.

Threat narrative

Attacker objective: The attacker aims to obtain durable domain-level access through a service identity that appears legitimate to routine monitoring.

1. Entry occurs when an attacker gains control of a user account with CreateChild or WriteProperty rights on an organisational unit.
2. Escalation happens when the attacker creates or modifies a dMSA and rewrites migration attributes so the account inherits privileged access.
3. Impact follows when Kerberos tickets are issued as the impersonated account, giving the attacker stealthy admin-level access and persistence.

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 privilege escalation is an attribute-governance failure, not just an Active Directory bug. The attack succeeds because directory metadata can confer authority without a visible role or group change. That means the control problem sits at the level of object ownership, write permissions, and migration state, not only at the level of account review. Practitioners should treat dMSA lifecycle state as a privileged control surface.

Access review processes were designed for stable entitlement states, and that assumption weakens here. The article shows that a dMSA can inherit powerful access through a migration path that looks administratively normal. The implication is that access certification built around periodic snapshots can miss fast-moving or attribute-driven privilege shifts in AD.

Runtime trust in Kerberos becomes brittle when identity meaning is stored in mutable directory attributes. Kerberos ticketing can still look legitimate while the underlying identity relationship has been rewritten. That is why this pattern belongs in OWASP-NHI thinking even though it occurs inside human IAM infrastructure: the non-human identity is the escalation vehicle.

Identity blast radius expands when one OU permission can mint a privileged service path. The article’s 91% figure shows that risky OU permissions are not edge cases, they are common enough to create systemic exposure. The practical conclusion is that AD governance has to narrow the set of principals allowed to create or modify service identities.

Zero Trust only helps if it is applied to directory mutation as well as authentication. Treating dMSAs as high-value identities is correct, but the deeper issue is whether any actor can alter the attributes that make those identities authoritative. The control boundary is the directory itself, so governance must extend to who can redefine trust.

From our research:

• Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, according to The State of Non-Human Identity Security.
• A separate finding from the same research shows that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps.
• That visibility gap makes the next step NHI Lifecycle Management Guide useful for teams reworking service-identity ownership and offboarding.

What this signals

OU permissions are becoming the control point that defines dMSA risk. Teams that only review admin group membership will miss the real exposure because this abuse path depends on who can write service-account attributes and create child objects. The practical signal is clear: directory governance now has to track mutation rights as closely as it tracks authentication.

Service identity governance and human IAM are converging at the directory layer. The same AD environment can host user identities, service identities, and delegated managed identities, but their failure modes differ. Teams should expect more attacks that use legitimate identity mechanics rather than stolen credentials, which makes baseline state and attribute telemetry more valuable than event-noise triage.

Identity blast radius is the right concept for this pattern. When one writable OU can create a path to domain-level impersonation, privilege scope is no longer a role question alone. That should push practitioners toward tighter object ownership, narrower delegation, and a review of where directory write access has quietly outgrown its original purpose.

For practitioners

• Inventory dMSA creation and migration paths Map every delegated managed service account, the predecessor account it references, and the OU rights that allow creation or modification. Flag any path where non-admin users can write CreateChild, WriteProperty, WriteDACL, GenericAll, or WriteOwner on service-account objects.
• Alert on migration attribute changes Build detections for changes to msDS-ManagedAccountPrecededByLink and msDS-DelegatedMSAState, then correlate those edits with Kerberos ticket issuance and service-account behaviour. Attribute changes should be treated as privilege events, not routine directory housekeeping.
• Re-scope Active Directory privilege reviews Move beyond group membership checks and include object-level permissions on organisational units, especially where service identities can be created or migrated. Review who can create delegated managed service accounts and whether those permissions are still justified.
• Baseline normal dMSA behaviour Establish which dMSAs exist, what hosts they belong to, and what ticketing patterns are expected. Any new dMSA, unexpected predecessor link, or unusual service-ticket pattern should trigger investigation before the account is trusted in production.

Key takeaways

• dMSA abuse turns directory metadata into an escalation mechanism, so the real control gap is object-level write authority, not just account sprawl.
• The article shows that Kerberos can issue apparently legitimate tickets even when privilege has been rewritten through migration attributes, which makes traditional logon-based detection insufficient.
• Limiting OU permissions and monitoring dMSA attribute changes are the practical controls most directly capable of preventing or exposing BadSuccessor-style abuse.

Key terms

• Delegated Managed Service Account: A delegated managed service account is a Windows service identity tied to a device and managed through directory attributes. It is meant to reduce password handling, but its migration and delegation state can become a control point for privilege escalation if object permissions are too broad.
• Kerberos Ticket Granting: Kerberos ticket granting is the process by which the Key Distribution Center issues tickets that let an identity access resources. In dMSA abuse, the ticket can reflect a manipulated identity relationship, so the ticket looks valid even when the underlying authorization path has been rewritten.
• Organisational Unit Delegation: Organisational unit delegation is the set of permissions that determine who can create, modify, or control objects inside an AD container. For service identities, it matters because a user with write rights may be able to create or alter accounts that inherit far more privilege than intended.
• Identity Blast Radius: Identity blast radius is the amount of access an attacker can reach after compromising one identity or one control point. In Active Directory, a single writable OU or migrated service account can expand that blast radius into domain-level impersonation, which is why object permissions matter so much.

Deepen your knowledge

NHI governance, machine identity security, and identity lifecycle management 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 operational governance in your organisation, it is worth exploring.

This post draws on content published by Netwrix: dMSAs Are the New AD Privilege Escalation Target, Here’s What You Need to Know. Read the original.