logo

dMSAs Are the New AD Privilege Escalation Target — Here’s What You Need to Know

Introduction

Windows Server 2025 introduced delegated managed service accounts (dMSAs) to improve security by linking service authentication to device identities. But attackers have already found a way to twist this new feature into a dangerous privilege escalation technique.

The BadSuccessor attack lets adversaries impersonate any user — even domain admins — without triggering traditional alerts. Here’s how it works, why it’s so stealthy, and what you can do to stay ahead of it.

Netwrix PingCastle

We care about security of your data.

Privacy Policy

Understanding dMSAs and Their Role in Active Directory

How dMSAs Differ from gMSAs

  • A dMSA (delegated managed service account) works like a service account but is tied to a single machine’s identity. Unlike gMSAs, which are centrally managed and can run across multiple servers, dMSAs inherit the privileges of the device they’re created on.

This tighter scope improves security in theory — but it also creates new risks when dMSAs are migrated from legacy accounts.


What to Know about Migrating to dMSAs

A dMSA can be created as a standalone account. Alternatively, it can be created as a replacement for an existing traditional user-based service account (not a managed service account or a gMSA) through migration. This is typically done using the Start-ADServiceAccountMigration PowerShell cmdlet, which triggers the MigrateADServiceAccount LDAP RootDSE operation.  Two key attributes are set as a part of this process:

  • msDS-ManagedAccountPrecededByLink — Points to the original user account
  • msDS-DelegatedMSAState — Indicates the state of the migration (e.g., ready or completed)

At the end of the migration process, the legacy service account is disabled but must remain in Active Directory. If it’s deleted, the dMSA will no longer function since many services and configurations still reference the original account. Attackers target these attributes in the BadSuccessor technique, making them critical for monitoring.

How Attackers Can Abuse a dMSA for Privilege Escalation in Active Directory

Traditional Privilege Escalation Techniques

Real-world research reveals that privilege escalation is often the second stage of attack following initial access. Once adversaries gain control of a user account, they look for pathways that enable them to systematically increase their privileges, aiming to eventually gain Domain Admin rights.

Traditional privilege escalation techniques listed in the MITRE ATT&CK catalog include Kerberoasting, AS?REP Roasting, and Golden Ticket creation. In addition, attackers today often use tools like BloodHound to map out privilege escalation paths, which involve taking advantage of issues like misconfigurations, inherited permissions, or design flaws to gain high-level permissions.

Privilege Escalation using dMSAs

Introducing dMSAs gives adversaries another option for privilege escalation, not because dMSAs are inherently insecure, but because attackers can exploit how they’re linked to legacy service accounts.  By modifying attributes like msDS-ManagedAccountPrecededByLink, a dMSA can be configured to impersonate another user and inherit that account’s access. Therefore, those rights can be exploited without changing group memberships or compromising additional credentials. As a result, even sophisticated security stacks may miss this attack vector if they rely only on traditional event ID monitoring or privilege assignment tracking.

 One common risk factor is improper delegation of control over organizational units (OUs). If an attacker compromises a user account with CreateChild or WriteProperty rights on an OU, they can potentially create a dMSA that inherits domain-level privileges. Akamai found that 91% of analyzed environments had at least one OU where user accounts had sufficient permissions to exploit this technique.

The BadSuccessor Attack and Why It Is So Dangerous

BadSuccessor is a new attack vector that abuses dMSA migration attributes. By changing the msDS-ManagedAccountPrecededByLink attribute, an attacker can make a dMSA impersonate a privileged account.

The Kerberos Key Distribution Center then issues tickets as if the dMSA was that privileged user — no group changes, no obvious login events. In other words, attackers get admin-level access that looks completely legitimate.

Making the problem worse, BadSuccessor attacks can be very difficult to detect. There are no group changes and no logon activity from the impersonated user account. While Microsoft now provides logs for the relevant attribute changes in the Windows 2025 schema (version 91), most auditing tools aren’t yet configured to flag them.  In short, this technique will likely go unnoticed if detection tools are not looking specifically for abnormal dMSA configurations or impersonation behavior in Kerberos ticket requests. Forensic review is also tricky, since the dMSA’s name might not reflect the proper privilege level it operates under.

In addition to enabling privilege escalation, BadSuccessor attacks can empower adversaries to gain long-term access to the environment, known as persistence. Persistence is critical for advanced persistent threat (APT) actors. In AD, advanced persistence techniques are those that survive password resets, reboot cycles, and standard remediation efforts. The BadSuccessor attack certainly qualifies: Once a dMSA is set up in migration mode with a succeeded account and issued Kerberos tickets, it can continue operating even if the original account is disabled. In other words, dMSAs abused in this way provide a “backdoor with a badge” — an account that appears legitimate, requests Kerberos tickets like any normal service account, and operates within defined privileges.

 Best Practices for Defending Against dMSA Abuse

A robust defense against abuse of dMSAs for privilege escalation requires a multi-layered strategy covering both prevention and detection. Key best practices include the following:

  • Review permissions. Regularly audit who has CreateChild, WriteProperty, WriteDACL (Modify Permissions), Generic All (Full Control), and WriteOWner (Change Owner) rights on all OUs and rigorously apply the principle of least privilege to reduce your attack surface area.
  • Educate teams. Ensure that all AD admins understand how dMSAs function and the risks they entail.
  • Stay informed. As Microsoft continues enhancing the dMSA feature, security teams must stay engaged with official documentation and community research to understand emerging risks. Resources like Microsoft’s dMSA documentation and the latest analysis from SpecterOps on BadSuccessor mitigations provide valuable guidance.
  • Monitor changes. Traditional indicators of compromise (IoCs) such as logon failures are insufficient to spot dMSA attacks like BadSuccessor. Organizations need real-time monitoring tools that can flag modifications to dMSA-related attributes. A robust approach includes:
    • Establishing a baseline of legitimate dMSAs and their expected behaviors
    • Watching for unexpected creation or modification of dMSAs
    • Monitoring the issuance of Kerberos tickets for dMSAs
  • Adopt a Zero Trust strategy. More broadly, integrate dMSA security into a broader Zero Trust initiative. Treat dMSAs as high-value identities, not just infrastructure accounts. Implement the same controls as you use for administrative accounts, including strictly enforcing least privilege, analyzing authentication activity and continuously monitoring behavior.

Tools for Effective Detection and Defense

Netwrix Identity Threat Detection & Response Solution provides comprehensive protection against dMSA-based privilege escalation attacks through integrated security tools that work together to assess, prevent, and detect threats:

How Netwrix Stops BadSuccessor Attacks

  • Find risky OUs fast: Netwrix PingCastle pinpoints where users have dangerous dMSA creation rights, so you can fix them before attackers strike.
  • Block exploits in real time: Netwrix Threat Prevention stops unauthorized changes to dMSA attributes — cutting off BadSuccessor attacks at the source.
  • Catch what others miss: Netwrix Threat Manager monitors Kerberos ticketing and dMSA migrations for signs of impersonation, alerting you before attackers escalate privileges.

Together, these tools give you visibility, control, and automated defense against stealth privilege escalation techniques like BadSuccessor.

Conclusion

The delegated managed service account is a powerful new feature of Windows Server that can improve both security and manageability. However, attackers can use the dMSA for privilege escalation in Active Directory. Indeed, the discovery of BadSuccessor underscores the need to implement new capabilities with due diligence, including having a suite of proven tools for ensuring both a strong security posture and rapid threat detection.

FAQ on dMSA for Privilege Escalation in Active Directory

What is the BadSuccessor attack?

BadSuccessor is a technique that exploits a dMSA for privilege escalation in Active Directory. It can enable an attacker-controlled account to impersonate other users in Active Directory, including privileged users.

How does the BadSuccessor attack work?

An attacker creates or modifies a dMSA, setting its migration attributes to reference a privileged user. As a result, the KDC issues Kerberos tickets that grant the dMSA those elevated privileges, enabling stealthy impersonation.

Why are so many environments vulnerable?

According to Akamai, 91% of real-world AD environments had at least one organizational unit where non-privileged users had CreateChild or Write permissions — enough to carry out the BadSuccessor technique.

What can organizations do to mitigate their risk?

Best practices for mitigating risk include limiting CreateChild and Write permissions on organizational units, continuously monitoring for changes to dMSA attributes, and proactively identifying and correcting risky configurations.

Is Microsoft planning to patch this?

Microsoft has classified the issue of using dMSA for privilege escalation in Active Directory as moderate severity. While a patch may be developed, organizations are smart to adopt robust threat prevention and detection strategies immediately.