dMSA privilege escalation in Active Directory: are controls keeping up?

TL;DR: Windows Server 2025 delegated managed service accounts can be abused for stealthy Active Directory privilege escalation by rewriting migration attributes so Kerberos tickets issue as a privileged user, according to Netwrix. That breaks the assumption that service-account identity changes are visible through ordinary group and logon monitoring, making attribute-level control and Kerberos telemetry essential.

NHIMG editorial — based on content published by Netwrix: dMSAs Are the New AD Privilege Escalation Target, Here’s What You Need to Know

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.

Questions worth separating out

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.

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.

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.

Practitioner guidance

• 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.
• 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.
• 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.

What's in the full article

Netwrix's full post covers the operational detail this post intentionally leaves for the source:

• The exact PowerShell migration flow and LDAP operation used to create a dMSA from a legacy service account.
• The specific Windows Server 2025 schema changes and event logging fields that can surface suspicious dMSA activity.
• The permission combinations on organisational units that let non-privileged users create exploitable service identities.
• The vendor's detection and prevention workflow for monitoring Kerberos ticketing and dMSA attribute changes.

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

dMSA privilege escalation in Active Directory: are controls keeping up?

Explore further

View Full Forum →  |  NHI Foundation Course →