Abusing Delegated Managed Service Accounts: The BadSuccessor Vulnerability

The BadSuccessor vulnerability targets the Delegated Managed Service Account (dMSA) feature introduced in Active Directory. The vulnerability enables privilege escalation through a flaw in the migration mechanism that is intended to facilitate the replacement of legacy accounts by dMSAs. The crux of the vulnerability lies in how permissions and trust relationships are incorrectly propagated to successor objects (dMSAs), without sufficient validation of their legitimacy or the caller’s rights.

This issue primarily affects environments running Windows Server 2025 (preview versions), where dMSAs are available.

Delegated Managed Service Accounts (dMSAs)

dMSAs are a new object class in Active Directory, designed to bridge the gap between traditional service accounts and Group Managed Service Accounts (gMSAs). A dMSA (objectClass: msDS-GroupManagedServiceAccount, objectCategory: msDS-GroupManagedServiceAccount) can be created by users who have CreateChild permissions on a given OU. Unlike gMSAs, dMSAs are not tied to group membership or automatic password management via Key Distribution Services (KDS), but still benefit from some service account lifecycle simplifications.

Key attributes of a dMSA include:

• msDS-ManagedPassword: Optional, but can be used for service authentication.
• msDS-AllowedToActOnBehalfOfOtherIdentity: Controls S4U delegation.
• msDS-DelegatedServiceAccountLink: Internal linkage to “superseded” accounts.

Migration Mechanism and the Vulnerability

The Start-ADServiceAccountMigration cmdlet is used to migrate a traditional user account or gMSA to a dMSA. The process involves marking the dMSA as the logical successor to the superseded account. This is where the flaw resides.

Expected Behavior

The intended behavior during migration is:

• The dMSA is configured to inherit usage rights, delegation configurations, and in some cases, security descriptors from the legacy account.
• This enables seamless transition of services that depend on Kerberos constrained delegation or service principals.

Vulnerable Behavior

The system does not enforce verification that the dMSA is a legitimate successor to the specified superseded account. Nor does it confirm that the caller of the cmdlet has any administrative rights on the superseded account.

As a result:

1. A user with only CreateChild rights in an OU can create a dMSA.
2. That same user can call Start-ADServiceAccountMigration -SupersededObject targetUser -SuccessorObject attackerDMSA.
3. The directory updates the dMSA’s internal properties as if it is the trusted successor of targetUser.

This leads to unintended side effects such as:

• Propagation of delegation privileges, including msDS-AllowedToActOnBehalfOfOtherIdentity.
• Kerberos impersonation scenarios if the dMSA operates as a front for the superseded identity.
• Misdirected ACL propagation depending on how trust paths are interpreted by certain services.

The vulnerability hinges on two flawed assumptions in the design:

1. That the successor designation implies legitimate administrative continuity.
2. That low-privileged users will only perform migrations for accounts they control.

Security Consequences

The attacker, by declaring their dMSA as the successor of a Domain Admin account, can obtain:

• S4U2Self or S4U2Proxy capabilities on behalf of the domain admin (if services are configured with unconstrained or constrained delegation).
• The ability to request service tickets as the admin, depending on service configuration and domain Kerberos policy.
• Object control in ACLs where the original account was assigned rights.

Critically, this occurs without compromising the target account or altering group memberships—making the attack hard to detect.

Exploitation Requirements

• CreateChild permission on an OU (commonly delegated for operational reasons).
• No admin privileges on the target user.
• PowerShell with RSAT and Active Directory module installed.

For testing and learning purposes, here is a link to a PowerShell script.

https://github.com/hocinewalid/BadSuccessor

The environment must permit:

• dMSA creation.
• Unpatched or misconfigured handling of successor relationships.
• Kerberos delegation (if impersonation is to be achieved).

Post-Exploitation Behavior

Once the dMSA is linked:

• The attacker can use it as a security principal in services.
• The account can be added to service ACLs or used in Kerberos delegation chains.
• Security logs may reflect the use of the dMSA but will not indicate privilege misuse unless correlated with object history or advanced auditing.

Detection and Hardening

Detection of this activity requires:

• Monitoring invocations of Start-ADServiceAccountMigration.
• Tracking new dMSA creations and verifying if their msDS-DelegatedServiceAccountLink points to high-privilege users.
• Logging and alerting on sudden shifts in delegation chains.

Hardening actions:

• Deny CreateChild and WriteProperty on sensitive OUs except for tightly controlled administrative accounts.
• Disable or restrict use of dMSA migration in production environments until patching is confirmed.
• Periodically enumerate all objects with msDS-DelegatedServiceAccountLink or suspicious delegation attributes.