The UnRightful Heir - My dMSA Is Your New Domain Admin

The UnRightful Heir - My dMSA Is Your New Domain Admin

Speakers: Yuval Gordon

Conference: DEF CON 33

YouTube: https://www.youtube.com/watch?v=ftNaF20RWt4

Slides: https://media.defcon.org/DEF%20CON%2033/DEF%20CON%2033%20presentations/Yuval%20Gordon%20-%20The%20%28Un%29Rightful%20Heir%20My%20dMSA%20Is%20Your%20New%20Domain%20Admin.pdf

Overview

Yuval Gordon, a security researcher at Akamai Technologies, presented a critical vulnerability in Windows Server's newest identity feature: Delegated Managed Service Accounts (dMSA). Introduced by Microsoft in 2025, dMSA was designed to solve a longstanding problem with Active Directory — the difficulty of migrating legacy service accounts to more secure managed service accounts without service disruption. Gordon's research, which he named "Bad Successor," demonstrates that any attacker with write access to a dMSA object in an Active Directory (AD) Organizational Unit (OU) — even one with minimal privileges — can simulate a dMSA migration, link that dMSA to any other account in the domain including Domain Admins, and then authenticate as the dMSA to inherit the full privilege set of the target account. Crucially, the attack also yields the Kerberos credential material (password hash) of the linked account, enabling Pass-the-Hash and Golden Ticket scenarios. Microsoft acknowledged the vulnerability, classified it as moderate severity, and stated it does not meet the bar for immediate servicing — though a fix is planned.

Background

▶ Watch: Discovery: dMSA PAC-merging inherits superseded account's full privileges (1:03)

To understand Bad Successor, it is necessary to understand Active Directory service accounts and the evolution of Managed Service Accounts (MSAs).

Legacy service accounts are ordinary AD user accounts configured to run Windows services. They are a perennial target for Kerberoasting — an attack where an adversary requests a Kerberos service ticket for the account and then cracks the ticket offline to recover the account's password. Their passwords typically require manual rotation by IT staff, making them chronically weak or reused.

Group Managed Service Accounts (gMSA), introduced in 2008 and 2012, solve the Kerberoasting risk by using a cryptographically random 256-bit password that is automatically rotated by Active Directory. The password is never set by a human and is only retrievable by authorized machine accounts and service hosts. gMSA largely solved the security problem but introduced a migration problem: not all services support gMSA, and migrating an existing service from a legacy account to a gMSA requires significant IT effort and risks service downtime.

Delegated Managed Service Accounts (dMSA), introduced in 2025, were Microsoft's solution to the migration problem. dMSA provides all the security benefits of gMSA while adding an automated migration pathway: an IT administrator can initiate a migration from a legacy service account to a dMSA, and every Windows machine running a service configured with that legacy account will automatically transition to the new dMSA — regardless of whether the service itself natively supports MSA. The migration is designed to be low-risk and straightforward.

dMSA migration proceeds in three phases: (1) Start Migration — the dMSA is created and linked to the legacy account; (2) Waiting Phase — each service host authenticates normally but receives a Kerberos response indicating it will be superseded; the Kerberos client on each host then automatically grants itself permission to use the dMSA; (3) Complete Migration — the legacy account is disabled, and the dMSA fully takes over.

Key Findings

▶ Watch: Background: Active Directory delegation and service account management (6:46)

Gordon's central discovery concerns the privilege inheritance mechanism within dMSA. When a dMSA is linked to a superseded account and authentication occurs, the Kerberos Domain Controller (DC) generates a Privilege Attribute Certificate (PAC) — the structure that encodes group memberships and access rights within a Kerberos ticket — that is the union of the dMSA's own PAC and the PAC of the superseded account. Gordon describes this as a "Dragon Ball fusion" of the two PACs. This is by design: it ensures the dMSA inherits all the access rights of the legacy account so services continue functioning after migration.

The vulnerability is that any user with write access to a dMSA object can manually set the superseding-account attribute on that dMSA to point to an arbitrary account — including a Domain Admin or even the KRBTGT account — without requiring Domain Admin rights. Microsoft's official migration process is gated by a domain admin check at the LDAP operation level, but the underlying LDAP attribute write itself is not similarly protected. By directly writing to the relevant dMSA attribute, an attacker can simulate the migration and link the dMSA to any target account.

The second major finding is that the dMSA authentication response also contains the current and previous Kerberos keys (password hashes) of the superseded account. These are delivered as part of the KrbdMSAKeyPackage structure in the Kerberos response. Gordon discovered this by accident: when he linked his lab dMSA to the Administrator account, the "previous keys" field in the response contained a hash he recognized as his own default lab password — the Administrator account's credential material, directly exfiltrated through the normal dMSA authentication flow.

This means Bad Successor provides two distinct primitives:

1. Privilege escalation: Authenticate as the dMSA to receive a Kerberos TGT containing the merged PAC, granting Domain Admin rights without joining any privileged group.
2. Credential theft: Extract the Kerberos keys (NTLM hashes and AES keys) of any account in the domain, enabling offline credential use, Pass-the-Hash, DCSync equivalence, and Golden Ticket creation via KRBTGT key compromise.

Technical Deep Dive

▶ Watch: dMSA design: how delegation migration is supposed to work (9:16)

Privilege Attribute Certificate (PAC) Merging. In standard Active Directory Kerberos, a user's PAC is built at TGT issuance time from the user's group memberships in the directory. dMSA introduces a new DC-side behavior: when the authenticating account is a dMSA with a superseded-account link, the DC generates PACs for both the dMSA and the linked account, then concatenates them into a single merged PAC. No group membership change is required — the DC dynamically computes the merged PAC at authentication time.

Attribute Write Vulnerability. The msDS-DelegatedMSAState and msDS-SupersededAccount attributes on a dMSA object control the migration state and target account link, respectively. The legitimate PowerShell migration cmdlet (Start-Service-Migration) performs a privileged LDAP modify operation gated by a server-side check for Domain Admin credentials. However, directly issuing an LDAP modify request against these attributes from a non-domain-admin account succeeds if that account has write permissions on the dMSA object. There is no additional authorization check protecting the attribute write itself.

Object Placement and OU Permissions. By default, dMSA objects are created in the CN=Managed Service Accounts container, which is tightly restricted and typically not writable by non-admin users. However, dMSA objects can be created in any OU. In real-world AD environments, it is common for IT teams to delegate write access over specific OUs to team leads or administrators of less critical systems. An attacker who has inherited such delegation over even a low-priority OU can create a dMSA in that OU, link it to a Domain Admin, and escalate to full domain compromise.

KrbdMSAKeyPackage Credential Extraction. The dMSA Kerberos response includes a KrbdMSAKeyPackage structure containing currentKeys (the dMSA's own Kerberos credentials) and previousKeys (the previous credentials of the superseded account). When the superseded account's current credentials appear in previousKeys, this constitutes a full credential dump achievable by any account authorized to authenticate as the dMSA. The credential material is returned in Kerberos key format, which includes both NTLM and AES key variants.

Tooling. Gordon used Rubeus — a well-known .NET Kerberos attack toolkit — to authenticate as the newly created dMSA and demonstrate the privilege escalation in his proof-of-concept.

Demo / Proof of Concept

▶ Watch: Problem framing: legacy service accounts with excessive AD permissions (11:15)

The attack flow demonstrated at DEF CON 33:

1. Start as a low-privileged user who has been delegated write access over a low-priority OU in Active Directory (a common real-world configuration).
2. Confirm the lack of privilege: attempt to add the user to Domain Admins — the operation fails.
3. Create a dMSA in the accessible OU using standard LDAP object creation.
4. Write the superseded-account attribute on the dMSA to point to the Administrator account, simulating migration without triggering the domain-admin check.
5. Authenticate as the dMSA using Rubeus.
6. Attempt to add the user to Domain Admins again — this time the operation succeeds, as the session now carries Administrator privileges via the merged PAC.

Gordon also ran a script that dumped the Kerberos credentials of every user, computer, and the KRBTGT account in the domain — directly from the dMSA authentication responses — demonstrating mass credential harvesting as a second-order consequence.

Defensive Implications

▶ Watch: Mitigation difficulty: why patching this feature is complex for Microsoft (29:13)

Detection. Because dMSA is a new and relatively rare feature, any dMSA creation event should be treated as noteworthy. Gordon recommends configuring System Access Control Lists (SACLs) on the Managed Service Accounts container and any OU that could host dMSA objects to generate audit logs on:

• dMSA object creation (Event ID from SACL-triggered auditing on the container/OU).
• Modification of the msDS-SupersededAccount attribute on a dMSA object — the specific attribute write that implements the attack.
• GMSA/dMSA password fetch events — Gordon noted that when authenticating as a dMSA, the domain controller logs a gMSA password fetch event (format similar to gMSA fetch logs) in which the callerSid field shows Anonymous Logon and the callerIp field is blank, which is highly anomalous and should trigger an alert.

Mitigation. Microsoft has stated a patch is forthcoming. Until the patch is applied:

• Audit and restrict who has write access to any OU that could contain dMSA objects.
• Apply the principle of least privilege aggressively to OU delegation — IT delegation policies are frequently overly permissive.
• Consider whether any dMSA objects are currently deployed and audit their msDS-SupersededAccount attribute for unexpected values.

Key Takeaways

• dMSA's PAC-merging privilege inheritance design is a powerful feature that, due to insufficient authorization on attribute writes, allows any user with OU-level write access to weaponize it for full domain compromise.
• The attack requires no Domain Admin rights to initiate — only write access to a dMSA object in any OU, a condition that is common in real-world AD deployments.
• Beyond privilege escalation, the attack yields the Kerberos credential material of any linked account, enabling offline credential use and KRBTGT-based Golden Ticket attacks.
• Microsoft classified the vulnerability as moderate severity and did not issue an emergency patch, though a fix is planned.
• Detection is possible through SACL-based auditing on dMSA object creation and attribute modification, and via anomalous Anonymous Logon entries in gMSA password-fetch event logs.
• dMSA remains a valuable feature architecturally; organizations should deploy it once patched, as it genuinely improves service account security compared to legacy service accounts.

About the Speaker(s)

▶ Watch: Public disclosure: Twitter/X proof-of-concept video and community response (38:16)

Yuval Gordon is a security researcher at Akamai Technologies focusing on offensive research, with a particular specialization in identity security and Active Directory. He has spent over a decade working across various cybersecurity roles, consistently returning to identity research as a core area. Prior to his current research on dMSA, Gordon conducted research on Group Managed Service Accounts (gMSA), giving him deep familiarity with the evolution of Windows managed identity mechanisms. DEF CON 33 was his first major international conference presentation. He can be reached via his public social media profiles listed in the talk materials.