Notifications
Clear all
Topic starter
24/06/2026 9:06 pm
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
25/06/2026 6:07 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: dMSA privilege escalation in active directory exposes new identity risk
