This is the third HTB machine I’ve attempted while preparing for the TCM PJPT exam. Compared to the Forest and Sauna machines I attempted previously, this machine was much more straightforward and relatively easier. That said, it was still a nice and fun machine to work through, and I picked up a few useful things along the way.
OS: Window
Difficulty: Easy
After the nmap enumeration:
└─# nmap -T4 --min-rate 5000 -p- -sV -sC 10.129.93.29
Starting Nmap 7.99 ( https://nmap.org ) at 2026-09-25 07:06 -0400
Warning: 10.129.93.29 giving up on port because retransmission cap hit (6).
Nmap scan report for 10.129.93.29
Host is up (0.23s latency).
Not shown: 65513 closed tcp ports (reset)
PORT STATE SERVICE VERSION
53/tcp open domain Microsoft DNS 6.1.7601 (1DB15D39) (Windows Server 2008 R2 SP1)
| dns-nsid:
|_ bind.version: Microsoft DNS 6.1.7601 (1DB15D39)
88/tcp open kerberos-sec Microsoft Windows Kerberos (server time: 2026-09-25 11:07:13Z)
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 kpasswd5?
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
49152/tcp open msrpc Microsoft Windows RPC
49153/tcp open msrpc Microsoft Windows RPC
49154/tcp open msrpc Microsoft Windows RPC
49155/tcp open msrpc Microsoft Windows RPC
49157/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
49158/tcp open msrpc Microsoft Windows RPC
49162/tcp open msrpc Microsoft Windows RPC
49167/tcp open msrpc Microsoft Windows RPC
49169/tcp open msrpc Microsoft Windows RPC
Service Info: Host: DC; OS: Windows; CPE: cpe:/o:microsoft:windows_server_2008:r2:sp1, cpe:/o:microsoft:windows
Host script results:
| smb2-time:
| date: 2026-09-25T11:08:12
|_ start_date: 2026-09-25T11:04:38
| smb2-security-mode:
| 2.1:
|_ Message signing enabled and required
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 117.51 seconds
From the scan results, we can identify several services and pieces of information that give us a good indication of the target’s role:
- DNS is running, which is commonly used within Active Directory environments for name resolution.
- Kerberos is running, which is a key authentication protocol used by Active Directory.
- LDAP is running, which is commonly used to query and interact with Active Directory directory services.
- The domain name is active.htb
The combination of Kerberos, LDAP, and DNS, along with the presence of an Active Directory domain, is a strong indicator that this machine is a Domain Controller (DC).
I first tried to enumerate the Active Directory environment using anonymous LDAP enumeration with windapsearch. However, the LDAP bind failed, and the output indicated that a successful bind must be completed on the connection.
This suggests that the target does not allow anonymous LDAP binding, meaning we cannot query LDAP without first authenticating with valid credentials.
From the Nmap enumeration, we can see that port 445 (SMB) is open. This gives us an opportunity to enumerate the SMB shares available on the target and check whether any of them can be accessed anonymously.
After enumerating the available shares, we found that the Replication share allows anonymous access.
Command: smbclient //{target ip}/Replication -N
After navigating through the SMB share, we reach:
smb: \active.htb\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\MACHINE\Preferences\Groups
Here, we find a file named Groups.xml.
Some information about GPP file:
Microsoft patched the underlying Group Policy Preferences (GPP) password-storage vulnerability in 2014, and newer GPP deployments should no longer create new exploitable cPassword credentials. However, older GPP configurations can still contain these stored credentials.
From our Nmap enumeration, we can see that the DNS service identifies the target as Microsoft DNS 6.1.7601, running on Windows Server 2008 R2 SP1:
53/tcp open domain Microsoft DNS 6.1.7601 (1DB15D39) (Windows Server 2008 R2 SP1)
This suggests that we are dealing with an older Windows environment, so finding a Groups.xml file under the Group Policy Preferences directory is worth investigating. There is a possibility that this is a legacy GPP configuration containing a cPassword.
Given its location and the age of the target environment, we should inspect the file for any stored credentials or cPassword values.
We can use the get command to download Groups.xml to our Kali machine for further analysis.
After opening the Groups.xml file in Firefox, we can see that it contains credentials for a service account:
Username:active.htb/SVC_TGS
cPassword: edBSHOwhZLTjt/QS9FeIcJ83mjWA98gw9guKOhJOdcqh+ZGMeXOsQbCpZ3xUjTLfCuNH8pG5aSVYdYw/NglVmQ
The cPassword value is the encrypted password stored by Group Policy Preferences (GPP).
We can use gpp-decrypt to decrypt the cPassword value we found in Groups.xml:
gpp-decrypt <cPassword>
Running the command reveals the plaintext password for the SVC_TGS service account:
GPPstillStandingStrong2k18
We now have valid credentials for the SVC_TGS account, so I tried using impacket-psexec to obtain a remote shell as this user.
However, the attempt was unsuccessful. The output indicated that none of the available SMB shares were writable.
This is important because psexec typically needs to upload a service executable to a writable administrative share, such as ADMIN$, in order to execute commands remotely.
To put it simply, psexec works by creating a Windows service remotely, and to do that it needs a way to place the service executable on the target machine and thus, requiring writable access.
Since the SVC_TGS account does not have the required write access, psexec cannot use this method to obtain a shell.
Since SVC_TGS does not have the required permissions to use psexec, the next step is to identify which SMB shares the account can access and what level of access it has.
To enumerate the available SMB shares and check the permissions of the SVC_TGS account, I used NetExec (NXC):
nxc smb 10.129.93.33 -u 'SVC_TGS' -p 'GPPstillStandingStrong2k18' --shares
The --shares option enumerates the SMB shares available on the target and shows the access level that the provided account has for each share, such as READ or WRITE permissions.
This allows us to identify shares that the SVC_TGS account can read and potentially investigate for additional information or credentials.
From the output, we can see several SMB shares that the SVC_TGS account has READ access to. Among them, I was particularly interested in the Users share, as user-specific directories are often a good place to look for user-related files, including the user flag in an HTB machine.
I used smbclient to connect to the Users share using the SVC_TGS credentials:
smbclient //10.129.93.33/Users -U 'SVC_TGS'
After connecting, I navigated to the user’s Desktop, where I was able to retrieve the user flag.
Use the get command to download the user.txt file and read it to get the flag
Privilege Escalation
I started to understand why this machine was labelled as Easy, especially after obtaining the SVC_TGS account. The username itself can be seen as a hint, since TGS is commonly associated with Kerberoasting and the Ticket Granting Service (TGS) in Kerberos authentication.
Normally, my next step would have been to use BloodHound to enumerate the relationships between domain objects and identify users that could potentially be Kerberoasted, especially if those accounts had interesting privileges or access to higher-privileged groups. However, I decided to skip that step this time because the SVC_TGS username gave me a strong intuition that Kerberoasting was likely to be one of the main attack paths on this machine and I wanted to save time too lol...
Kerberoasting is a technique where an attacker requests Kerberos service tickets (TGS tickets) for accounts that have a Service Principal Name (SPN) registered. These tickets can then be taken offline and subjected to password cracking. If the associated service account is using a weak or guessable password, this can potentially allow us to recover its plaintext password.
We can perform Kerberoasting using impacket-GetUserSPNs. Since we already have valid credentials for SVC_TGS, we can use them to query the domain for accounts with registered Service Principal Names (SPNs) and request their Kerberos service tickets:
impacket-GetUserSPNs active.htb/SVC_TGS:'GPPstillStandingStrong2k18' -dc-ip 10.129.93.33 -request
The -request option tells GetUserSPNs to request the TGS tickets for the accounts it finds. In the output, we received a TGS hash for the Domain Administrator account.
This is significant because the TGS can be taken offline and subjected to password cracking, potentially allowing us to recover the plaintext password for the associated account.
I saved the TGS hash to a file so that it could be cracked offline using Hashcat.
After running Hashcat against the TGS hash, we were able to successfully crack it and recover the plaintext password for the Domain Administrator account -> Ticketmaster1968 (The mode for cracking TGS Hash is 13100)
Now that we have valid credentials for the Domain Administrator account, we can use impacket-psexec to obtain a shell on the target machine.
Unlike the previous attempt with SVC_TGS, the Domain Administrator account has the required privileges to access the necessary administrative resources and create a remote service. This allows psexec to successfully execute commands on the target.
After obtaining a shell, I navigated to the Administrator’s Desktop, where I was able to retrieve the root flag and complete the machine.
Top comments (0)