GOAD Compromise Part 1: Enumeration

We have access to the network, but no understanding of the environment. The next step is to enumerate and map what exists.

Phase 1: Infrastructure Mapping (Nmap)

We start by figuring out what actually exists on the network. A basic Nmap scan across the 192.168.66.0/24 range tells us which hosts are alive and which core AD services are exposed.

nmap -p 53,88,389,445 -Pn 192.168.66.10-23 -oA initial_recon

This gives us a rough map of the domain controllers and file servers we will be working with.

---

Phase 2: User Discovery

Before touching passwords, we want names. Knowing who exists in the domain is more valuable than brute forcing blindly.

We use NetExec to attempt anonymous user enumeration over SMB using a null session. We sweep the hosts until we get a response.

nxc smb 192.168.66.11 --users

We now have valid domain users without sending a single authentication attempt.

We could start spraying here. That would be lame. Instead, we keep digging.

---

Phase 3: SMB Signing Scan

Next, we check which systems have SMB signing disabled. SMB signing blocks man in the middle attacks, and its absence usually points to weaker security controls.

nxc smb 192.168.66.11-23 --shares -u '' -p ''

One host immediately stands out.

• WINTERFELL (.11): SMB signing enabled
• CASTELBLACK (.22): SMB signing disabled

CASTELBLACK is the obvious next target.

---

Phase 4: Initial Access

Let’s try a manual connection to that file server using smbclient.

smbclient //192.168.66.22/all -N

smb: \> ls
  arya.txt                            A     413  Wed Mar  5 17:17:06 2025

smb: \> get arya.txt

Inside the share, we find a single file.

Nice hint on her password. Let’s test access.

nxc smb 192.168.66.11 -u 'arya.stark' -p 'Needle' -d 'north.sevenkingdoms.local'

We now have our first set of valid domain credentials.

---

Phase 5: Lateral Movement (Kerberoasting)

With Arya’s credentials, we move to Kerberoasting. The goal is to identify service accounts with SPNs and request their Kerberos tickets for offline cracking.

python3 /usr/share/doc/python3-impacket/examples/GetUserSPNs.py -dc-ip 192.168.66.11 'north.sevenkingdoms.local/arya.stark:Needle' -request

This returns three candidates:

• jon.snow
• sansa.stark
• sql_svc

Finding User Rights

Before cracking anything, we check delegation settings. Delegation often matters more than group membership.

We use findDelegation.py to enumerate delegation relationships in the domain.

python3 /usr/share/doc/python3-impacket/examples/findDelegation.py ‘north.sevenkingdoms.local/arya.stark:Needle’ -dc-ip 192.168.66.11

This is where things get interesting.

---

Cracking the Ticket with Hashcat

Save the exported Kerberos hashes to a file named hashes.txt. Since Kerberos 5 TGS-REP hashes use the code 13100, we fire up Hashcat with the rockyou.txt wordlist.

hashcat -m 13100 jon_snow.hash /usr/share/wordlists/rockyou.txt

$krb5tgs$23$*jon.snow$NORTH.SEVENKINGDOMS.LOCAL$cifs/WINTERFELL.north.sevenkingdoms.local*$... : iknownothing

---

Why Jon Matters

Jon has what we need to take over the domain. What matters here is delegation.

Jon is configured for Constrained Delegation with Protocol Transition to CIFS on WINTERFELL. This allows him to request service tickets on behalf of any user, including privileged ones, without knowing their credentials.

There is also Resource-Based Constrained Delegation present. Multiple machine accounts are allowed to act on behalf of others, and at least two systems are configured with unconstrained delegation.

In short, Jon can impersonate. And impersonation is how domains fall.

---

What Comes Next

Next, we use Impacket to request a service ticket as a privileged user to a delegated service. From there, we pivot, escalate, and pwn the entire forest.