Exploiting dMSA Migration for Domain Privilege Escalation

TLDR: Delegated Managed Service Accounts (dMSA) introduce a critical privilege escalation path when misconfigured or abused during the migration process. By manipulating the attributes that link a dMSA to a high-privileged account, an attacker can effectively hijack the service account's identity and credentials. This research demonstrates how to weaponize this process to dump sensitive domain credentials, including the KRBTGT account, without requiring Domain Admin rights initially.

Active Directory environments are rarely static, and the introduction of new features often creates unforeseen attack surfaces. The Delegated Managed Service Account (dMSA) is a prime example of a feature designed to simplify credential management that inadvertently provides a powerful primitive for privilege escalation. While Microsoft intended for dMSAs to streamline the migration from legacy service accounts, the mechanism governing how these accounts link to their predecessors is fundamentally flawed from an offensive perspective.

The Mechanics of the Migration Flaw

At the heart of this issue is the migration process itself. When an administrator migrates a legacy service account to a dMSA, the system establishes a link between the two objects. This link is governed by specific attributes within Active Directory that dictate which accounts are authorized to authenticate as the dMSA. The research presented at DEF CON 2025 highlights that these attributes are not sufficiently protected by the default security model.

An attacker who gains control over a dMSA object—or even just the ability to create one in an arbitrary Organizational Unit (OU)—can manipulate these linking attributes. By pointing the dMSA to a high-privileged account, such as a Domain Admin or a service account with extensive rights, the attacker forces the domain controller to treat the dMSA as a legitimate successor. This effectively grants the attacker the ability to authenticate as the target account.

The technical implementation of this attack relies on the fact that the dMSA migration process is essentially a wrapper for an LDAP operation. An attacker can use PowerShell to modify the msDS-ManagedAccountPrecededByLink attribute. Once this link is established, the attacker can use Rubeus to request a ticket for the dMSA, which now carries the privileges of the linked account.

# Example of linking a dMSA to a target account
Set-ADObject -Identity "CN=dMSA_Name,OU=TargetOU,DC=domain,DC=com" `
             -Replace @{'msDS-ManagedAccountPrecededByLink'='CN=Target_Account,CN=Users,DC=domain,DC=com'}

Credential Dumping Without DCsync

Perhaps the most dangerous aspect of this technique is its ability to facilitate credential dumping without needing the DS-Replication-Get-Changes or DS-Replication-Get-Changes-All extended rights typically required for a DCsync attack. By successfully assuming the identity of a high-privileged service account, an attacker can access the msDS-GroupMSAMembership or other sensitive attributes that contain the keys necessary for Kerberos authentication.

During the demonstration, the researcher showed how this process allows for the extraction of the KRBTGT account's keys. Since the KRBTGT account is the foundation of the Kerberos realm, obtaining its keys allows an attacker to forge Golden Tickets, granting them persistent, unrestricted access to the entire domain. This bypasses traditional monitoring that looks for the specific replication traffic associated with DCsync, as the attacker is simply performing legitimate, albeit unauthorized, service account operations.

Real-World Engagement Impact

For a penetration tester, this technique is a game-changer when encountering environments that have adopted dMSAs. Many organizations deploy these accounts to satisfy OWASP A07:2021 – Identification and Authentication Failures requirements by automating password rotation. However, if the OU structure is not strictly controlled, an attacker with standard user permissions might be able to create a dMSA in a "sandbox" or "test" OU and then link it to a production service account.

During an engagement, you should audit the permissions on all OUs where dMSA objects reside. If a user or group has Create or Write permissions on these OUs, they can potentially create a dMSA and link it to a more powerful account. The impact is immediate: full domain compromise. This is not a theoretical vulnerability; it is a direct consequence of how Active Directory handles object relationships during the migration phase.

Defensive Considerations

Defending against this requires a shift in how we manage service account OUs. The most effective mitigation is to restrict the ability to create dMSA objects to a highly limited set of administrative accounts. Furthermore, you should implement a System Access Control List (SACL) on the msDS-ManagedAccountPrecededByLink attribute to log any modifications. This will provide the visibility needed to detect when an attacker is attempting to link a dMSA to a sensitive account.

Monitoring for the creation of new dMSA objects is also essential. Any dMSA that appears in an unexpected OU should be treated as a high-priority security incident. While Microsoft has acknowledged the issue and indicated that a fix is forthcoming, the current reality is that the responsibility for securing these relationships lies with the domain administrators.

Do not assume that because a feature is "managed" or "automated" that it is inherently secure. The complexity of Active Directory means that even well-intentioned features can be repurposed by an attacker to gain a foothold. If you are currently auditing an environment, look for dMSAs that are linked to accounts outside of their expected scope. You might find that the "rightful heir" to your domain admin privileges is a dMSA you didn't even know existed.