Hacking Tutorial

How To Route Tools (Gobuster) Through a BurpSuite Proxy

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.

Hacking Tutorial, Pentesting

How to Brute Force Websites & Online Forms Using Hydra

Encrypt and Anonymize Your Internet Connection for as Little as $3/mo with PIA VPN. Learn More

While working through NINEVAH on HackTheBack (Write-Up on this coming in a future post), I came across a couple web forms that I needed to break into. In my opinion, using the Intruder feature within BurpSuite is an easier way to run brute-force attacks, but the effectiveness of the tool is greatly reduced when using the free community version. Instead of dealing with slow brute-force attempts, I decided to give Hydra a try.


What we’re breaking into

If you’re unfamiliar with https://hackthebox.eu, I highly recommend checking them out. Click here to check out my HackTheBox related content.

NINEVAH sits on HackTheBox servers at IP address 10.1.10.43. I found a couple login pages at the following URLs. These are the addresses we’re going to attempt to break into.

1st Address: http://10.10.10.43/department/login.php

This image has an empty alt attribute; its file name is image-34.png

2nd Address: https://10.10.10.43/db/index.php

This image has an empty alt attribute; its file name is image-36.png

Using Hydra to Brute-Force Our First Login Page

Hydra is a fairly straight forward tool to use, but we have to first understand what it needs to work correctly. We’ll need to provide the following in order to break in:

  • Login or Wordlist for Usernames
  • Password or Wordlist for Passwords
  • IP address or Hostname
  • HTTP Method (POST/GET)
  • Directory/Path to the Login Page
  • Request Body for Username/Password
  • A Way to Identify Failed Attempts

Let’s start piecing together all the necessary flags before finalizing our command.

Specifying Username

In our particular case, we know that the username Admin exists, which will be my target currently. This means we’ll want to use the -l flag for Login.
-l admin

Note: If you don’t know the username, you could leverage -L to provide a wordlist and attempt to enumerate usernames. This will only be effective if the website provides a way for you to determine correct usernames, such as saying “Incorrect Username” or “Incorrect Password”, rather than a vague message like “Invalid Credentials”.

Specifying Password

We don’t know the password, so we’ll want to use a wordlist in order to perform a Dictionary Attack. Let’s try using the common rockyou.txt list (by specifying a capital -P) available on Kali in the /usr/share/wordlists/ directory.
-P /usr/share/wordlists/rockyou.txt

IP Address to Attack

This one is easy!
10.10.10.43

Specifying Method

This is where we need to start pulling details about the webpage. Let’s head back into our browser, right-click, and Inspect Element.

A window should pop-up on the bottom of the page. Go ahead and select the Network tab.

Right away, we see a couple GET methods listed here, but let’s see what happens if we attempt a login. Go ahead and type in a random username/password, and click Log In.

Of course our login attempt will fail, but we’re able to see that this website is using a POST method to log-in by looking at the requests.

Easy enough, now we know what method to specify in our command!
http-post-form
Note: You’ll need to enter https if you’re attacking a site on port 443.


Specifying the Path to Attack

So far, we’ve only told the tool to attack the IP address of the target, but we haven’t specified where the login page lives. Let’s prepare that now.
/department/login.php


Finding & Specifying Location of Username/Password Form(s)

This is the hardest part, but it’s actually surprisingly simple. Let’s head back over to our browser window. We should still have the Inspect Element window open on the Network Tab. With our Post request still selected, let’s click Edit and Resend.

Now we see a section called Request Body that contains the username and password you entered earlier! We’ll want to grab this entire request for Hydra to use.

In my case, the unmodified request looks like this:
username=InfiniteLogins&password=Password

Because we know the username we’re after is “admin”, I’m going to hardcode that into the request. I’ll also replace the “Password” I entered with ^PASS^. This will tell Hydra to enter the words from our list in this position of the request. My modified request that I’ll place into my Hydra command looks like this:
username=admin&password=^PASS^

Note: If we desired, we could also brute-force usernames by specifying ^USER^ instead of admin.


Identifying & Specifying Failed Attempts

Finally, we just need a way to let Hydra know whether or not we successfully logged-in. Since we can’t see what the page looks like upon a successful login, we’ll need to specify what the page looks like on a failed login.

Let’s head back to our browser and attempt to login using the username of admin and password of password.

As we saw before, we’re presented with text that reads “Invalid Password!” Let’s copy this, and paste it into our command:
Invalid Password!

Piecing the Command Together

Let’s take all of the components mentioned above, but place them into a single command. Here’s the syntax that we’re going to need.

sudo hydra <Username/List> <Password/List> <IP> <Method> "<Path>:<RequestBody>:<IncorrectVerbiage>"

After filling in the placeholders, here’s our actual command!
sudo hydra -l admin -P /usr/share/wordlists/rockyou.txt 10.10.10.43 http-post-form "/department/login.php:username=admin&password=^PASS^:Invalid Password!"

Note: I ran into issues later on when trying to execute this copied command out of this WordPress site. You may need to delete and re-enter your quotation marks within the terminal window before the command will work properly for you.

After a few minutes, we uncover the password to sign in!
admin:1q2w3e4r5t


Using Hydra to Brute-Force Our Second Login Page

Go through the exact same steps as above, and you should end up with a command that looks like this.
sudo hydra -l admin -P /usr/share/wordlists/rockyou.txt 10.10.10.43 https-post-form "/db/index.php:password=^PASS^&remember=yes&login=Log+In&proc_login=true:Incorrect password"

So what’s different between this command and the one we ran earlier? Let’s make note of the things that changed.

  • Method was switched to https-post-form
  • Path was updated to /db/index.php
  • Request Body is completely different, but we still hard-code admin and replace the password with ^PASS^
  • Finally, the text returned for a failed attempt reads Incorrect password

After running the command, we uncover the password after just a couple minutes.
admin:password123


Let me know if you found this at all helpful, or if something didn’t quite work for you!