There are times where you will need to troubleshoot or route your tools through a proxy in order to get the result you need. This post will serve as a general guide for configuring BurpSuite as a proxy so you can route tools through it easily, and troubleshoot things as needed.
In this specific example, we showcase how to route Gobuster through Burpsuite so we can analyze traffic.
Table of Contents:
- Identifying the Problem
- Configuring Proxy in BurpSuite
- Testing the Proxy
Identifying the Problem
On HackTheBox, there is a box called Node where you can’t use Gobuster for enumeration. When you’re able to analyze requests through a tool like Burpsuite, you can identify this early on and save a ton of time by dodging a rabbit hole.
Note: This is NOT a write-up on Node. We will not be resolving the problem of enumerating Node using Gobuster, but instead will simply use Node as an example for this blog post.
Node lives at 10.10.10.58, and has a webserver listening on port 3000. Let’s start by browsing to that webpage to see what we get once we’re connected to the HackTheBox VPN.
http://10.10.10.58:3000

Anytime I see a webpage, I always like to start Gobuster to try and enumerate any directories that may be living under the hood. Let’s give that a shot.
gobuster dir -u http://10.10.10.58:3000 -w /usr/share/dirbuster/wordlists/directory-list-2.3-medium.txt

Very quickly we get a response back that states “Error: the server returns a status code that matches the provided options for non existing urls. http://10.10.10.58:3000/febbf4ec-069f-4b87-a671-a07ses, specify the ‘–wildcard’ switch“
Specifying the --wildcard
switch as it suggests in this case will just cause every page to report back with a 200 status code. Not very helpful.
gobuster dir -u http://10.10.10.58:3000 -w /usr/share/dirbuster/wordlists/directory-list-2.3-medium.txt --wildcard

Configuring Proxy in BurpSuite
Let’s spin up BurpSuite and navigate to the Proxy tab. Let’s then go into Options, and Add a new proxy listener.

In the Binding tab, enter a Port that you’d like to use. In this case, I’ll just use 8081.

Click on the Request Handling tab. Fill out as needed.
Redirect to host: Enter the host that you wish to send traffic to. I’ll be sending my traffic to 10.10.10.58
Redirect to port: Enter the port that the host is listening on. In my case, it will be 3000.
Force use of TLS: That is not necessary in my example, but it may be a requirement for you depending on your use-case.
Support Invisible Proxying: N/A
Click OK.

The add listener screen should close, and you should be taken to the Proxy Listeners table with a new entry shown. Make sure that your new listener is Running.

Testing the Proxy
Now, let’s open a browser and see what happens when we browse to localhost on the port we specified earlier.
http://localhost:8081

Great! We know our proxy is working and we’re able to route traffic through BurpSuite. Let’s do the same, but with Gobuster this time.
gobuster dir -u http://localhost:8081 -w /usr/share/dirbuster/wordlists/directory-list-2.3-medium.txt

We notice that we are still getting the same error message. Let’s see if we can analyze this traffic within BurpSuite and identify why. Let’s head back into Burp and select the Proxy tab. Turn Intercept On.

Let’s run the same Gobuster command again. You’ll notice the tool will spin up, but then appear to hang.
gobuster dir -u http://localhost:8081 -w /usr/share/dirbuster/wordlists/directory-list-2.3-medium.txt

Heading back to Burp, we have a chance to modify the request if we desire. I will go ahead and click Forward. You may need to click it a few times if multiple requests are being sent.

Gobuster still reports the same error as before, but now we have a chance to go into the HTTP History within Burp. From here, we can review the Response received from the webserver and have a chance to troubleshoot.

This proves that we are routing fully through Burp, and now have a chance to utilize some of its features while running our tools.
That’s it for this post! Again, the goal was to learn how to route tools through BurpSuite so that you can leverage all of its features. Let me know if this is at all helpful, or if there is more that you’d like me to add.
I’m not sure I understand… In the end, gobuster still doesn’t work right?
LikeLike
In this example, yes, Gobuster still didn’t work for this box. When Node was created, the version of Gobuster available at the time would use a particular header in the web request that would trigger the webpage to respond with a troll face in ASCII art. You’d only be able to see this response if you were capturing and analyzing traffic in a tool like BurpSuite. Ippsec has a great video on YouTube showcasing this; https://www.youtube.com/watch?v=sW10TlZF62w
The goal of my post wasn’t to explain or identify why Gobuster wouldn’t work on this machine, but rather I used it as an example to show how you can route Gobuster through BurpSuite. With this proxy configuration, you’d be able to troubleshoot this issue further and also take advantage of BurpSuite’s features (such as Repeater or viewing HTTP Request History). This extends much further than just applying to Gobuster.
LikeLike
Thanks a lot for the great explanations!
LikeLike