Hack the Box Starting Point: Responder

- 7 mins read

Responder

Screenshot 2025-11-14 102616.png Hello and welcome back to the little Starting Point series I’ve been doing on the HacktheBox main platform. Today we’re going to be looking at the Responder box which definitely looks interesting. Just peaking at the questions ahead of us we’re going to be dealing with some stuff that I haven’t touched too mouch. Yeah we have some web stuff, but it looks like it may be hosted on a Windows server? It also looks like (per the name) we may be using responder to do some nefarious things.

What is Responder?

Responder is another security tool that we’ll be using in this engagement and it’s main purpose is to capture crednetials on the local network. It does this by impersonating legitimate network services and then responding to clients before the real network service can and therefore getting in the middle of all of those communications. I apologize if that’s not the best explanation, feel free to refer to this post here if you’d like a little more info. With that all being said though, let’s go ahead and fire up our attacking machine of choice and get after it.

Task 1

Screenshot 2025-11-14 103910.png Well, seems like an easy enough first task, let’s fire up our web browser and check it out. Screenshot 2025-11-14 104158.png Hmmm, so after just entering the IP address of the target in our browser we get brought to the page above. Now, it appears the site is having trouble rendering for some reason, but we see we’ve been redirected to http://unika.htb/.

Task 2

Screenshot 2025-11-14 104741.png Now, we all probably have a feeling we know what the answer here is, but let’s do our due diligence. We see that the web page is struggling in the browser, let’s see if we can get a little more information from the command line. Screenshot 2025-11-14 105011.png In the HTTP response under the Server header we see a lot of info actually. The target web server is running Apache, is a Windows 64 bit system and is using the PHP scripting language. Now, we had a feeling about this, but it’s always important to verify.

Task 3

Screenshot 2025-11-14 105831.png Alright, well now we’re going to need to fix the connection issue when we’re trying to vaigate to the website. Just for curiositites sake let’s try adding the targets IP to our /etc/hosts file and see if that maybe fixes it. Screenshot 2025-11-14 110657.png Here you can see that at the bottom of the file I’ve added the IP and domain name of the host we want to be able to navigate to. Do remember /etc/hosts needs root priviliges to edit. Now that we’ve added that, let’s go ahead and try going to the target URL again. Screenshot 2025-11-14 110959.png Awesome, there we go. Now time to actually answer the question. There’s not a parameter currently in the URL that looks like we can modify, but it can’t help but notice on that menu bar there it looks like we can change our language. We can hover over it and select between French and German, I’m going to select German. Screenshot 2025-11-14 111319.png And there in the URL we see index.php?page=german.html so the page parameter is what sets the language.

Task 4 and 5

So for these two tasks we’re not exploiting anything yet, just understanding the difference between Local and Remote File Inclusion Vulnerabilities. The idea behind both is the same though, by abusing poorly configured web applications we are able to call other files via different parameters on the target. The only difference is for Local you are absuing some kind of path traversal bug in order to read local files where as Remote you are suppling the URI of a remote file from somewhere else. So going to our first quesiton here. french.html and mimikatz.exe. are just two files the only one that has any directory traversal even in it is the file path ending with /etc/hosts so… For the second question, you can just tell it’s a Remote File Incusion (RFI) as we can see that there is a path to a remote host and that will be our answer this time. If you want to read up more on RFI and LFI I would maybe take a peak here.

Task 6

Screenshot 2025-11-14 111527.png NTLM stands for New Technology LAN Manager and is an authentication protocol used in Widnows Environments. There’s a post from CrowdStrike if you want to read more about it. For our purposes though, it’s important to know that NTLM uses a client-server model that performs a kind of three way handshake challenge with the client. This is what Responder is going to be looking for when we use it here in just a moment.

Task 7

Screenshot 2025-11-14 113537.png Alright, time to start getting some hands on with responder let’s check it’s help utility to see how it works. Running responder -h gives us the help we’re looking for. Screenshot 2025-11-14 113833.png So the -I flag is what we’ll use to specify the interface we want to run Responder on.

Task 8

Screenshot 2025-11-14 115139.png The hash cracking tool being referenced here is John the Ripper, a very popular password cracking tool that you should definitely be aware of if you’re not already. Now we’re starting to see how this attack is going to work a little bit. NTLM passes password hashes over the network, not jusst plaintext. So we need to use responder to capture that hash and then crack it with John the Ripper. How do we go about actually forcing the target to try to authenticate to our NTLM server?

Task 9

Screenshot 2025-11-14 115743.png Okay, so full transparency, I referenced the official writeup here as I was note exactly sure how to leverage the RFI vulnerability to cause the web server to initiate NTLM authenticaiton. But to be honest this is pretty cool. First things first though, we are going to want to start Responder on out tun0 interface (the interface connected to the HTB lab). Screenshot 2025-11-14 120148.png Okay aawesome, we have responder set up. Now here’s the cool part, Responder is running opned a few different ports so it can listen for a dew different kinds of authentication and one service it’s spoofing right now is SMB. SMB being a network file share, allows us to abuse the RFI vulnerability to make the web server request a file from our machine using SMB which uses? NTLM to authenticate that’s right so… Screenshot 2025-11-14 120821.png So we inject our RFI payload into the vulnerable URL parameter and after hitting enter… Screenshot 2025-11-14 121006.png We see that the web server throws an error about not having permissions to access our placeholder file, so it tried to authenticate… So if we look at our running Responder. Screenshot 2025-11-14 121150.png Beautiful. Okay awesome, we have our file hash, time to use John the Ripper. First things first is we’re going to want to save that hash to a file. Screenshot 2025-11-14 121430.png Awesome. Now John can bruteforce things, but most of the time we’re going to want to use a word list like so. Screenshot 2025-11-14 122649.png And we see the password is badminton. Awesome, we have our creds, but where are we logging into?

Task 10

Screenshot 2025-11-14 122835.png Well we should all know what to do here. Screenshot 2025-11-14 123142.png We see a service running on 5985, Microsfot HTTPAPI or more commonly referred to as WinRM or Windows Remote Management. As the name implies it’s another method of emotely adminsitering Windows systems. Let’s try logging into there with our stolen credentials. To interact with that service we will be using a tool called evil-winrm.

Root Flag and Conclusion

Screenshot 2025-11-14 123720.png Uh oh… Screenshot 2025-11-14 124232.png And under the user mike’s Desktop directory we see our flag. Screenshot 2025-11-14 124406.png This box was great, I learned a lot and it’s really cool to start to see some of these different exploit techniques be used together now instead of us just finding an open port and finding a flag. Hope you all enjoyed and I’ll see you next time!