Brute Forcing with Burp Suite
One of our newer initiatives at SNT is to post a weekly blog that contains some of our favorite pentesting tips and tricks, usually containing something that we’ve found success with during penetration testing/researching in the past month or so.
One of my absolute favorite things to do is to use Burp as a brute forcing tool. Burp is an absolute monster of a program when it comes to web application assessments and analyzing responses, not to mention the proxy functionality of Burp is second to none. However, that doesn’t stop me from firing it up to perform one of the oldest tricks in the book: bruteforcing.
One of my favorite things to brute force during a client pentest are OWA portals. These are often left open and do not have any IP restrictions in terms of access, or blocking when someone is clearly brute forcing down an entire list.
Finding the OWA Portal
The first step is going to find the active OWA portal or webmail portal that the target is using. This involves some simple enumeration. Usually you can find it by performing one of the following.
- Navigating to https://webmail.acme.com or https://mail.acme.com.
- Using dnsdumpster.com to find some information such as MX records and subdomains that may exist.
For demonstration purposes, we are going to target acme.org, and I happened to find an OWA portal at thisdoesntexist.acme.org!
SETTING THE PROXY
Now that we have our OWA portal, it’s time to fire up Burp Suite. I use Burp Professional, so mine might look a little different than if you are using the free version of Burp. If you’ve never used Burp before, you are going to need to do the following.
For Firefox (what I use)
Settings > Preferences > Advanced > Network > Select “Settings” Next to “Connections”
In Connection Settings
- Check the radio button for “Manual Proxy Configuration”
- Set HTTP Proxy to “127.0.0.1” and the port to “8080”
- Check the box that says “Use this proxy server for all protocols”. If you don’t you will notice that Burp will not pick up any HTTPS requests or responses.
If you’re confused, see the GIF below.
USING THE PROXY
Perfect. If configured correctly, all requests sent by your Firefox browser should be intercepted by Burp. To test this, we can navigate to the OWA page in question, in this case, thisdoesntexist.acme.org. When you navigate to it, it should appear that your Firefox is “hanging”. Fear not, it is waiting for you to forward these requests via Burp.
Once you submit the URL request and hit enter, go to Burp and click on the “Proxy” tab. Make sure that “Intercept is on” is depressed. If it isn’t you will need to submit the requests again. If all is well, you should see some data in the “Raw” box. Sometimes, you may need to hit “Forward” a couple times before you’re actual requests shows up. Here is a screenshot of the OWA request my browser is making, which was intercepted by Burp.
Keep clicking forward until the page is present with no other values being passed through the proxy. Stellar, at this point you have mastered some of the most basic functionality within the Burp proxy! The next step is going to be to log into the portal using a username and password combination. The credentials entered here are just test credentials which will be mapped to Burp Intruder. For this example, I’m going to use the username of “administrator” and the password of “leetpassword”.
Once you enter this into the login box and hit enter or “sign in”, your Burp raw data should light up with the request, similar to what is shown below. Notice the two boxes I have highlighted which contain the username and password fields, as well as the values I have entered.
Right click anywhere in the white area, and choose the option “Send to Intruder”. Intruder is the Burp tool that we will be using that will replay the request and let us brute force the page. You can forward the request now, and keep forwarding all requests until there are no more (alternatively you can forward the page and then turn the proxy off, however, mashing the forward button is far more enjoyable).
USING BURP INTRUDER
Next, you are going to click on the “Intruder” top on the top burp Menu Bar. This will bring up a page that look something along the lines of this.
Next, click the “positions” tab and you should have a request with a bunch of things highlighted. Click the “clear” button on the right then highlight the word “username” and click “add, then highlight the word “password” and click “add”, as shown below.
In Burp, these fields are known as “positions”. These positions are the fields that are going to be brute forced.
Next, you are going to change the “Attack Type” to “Cluster Bomb”. This will allow us to set a custom payload (word) set for the “username” position and the “password” position. For example, it will allow us to add the usernames of:
Attempting to use the passwords of.
To add the payloads, you are going to click on the “Payloads” tab next to “Positions” and set them. The image below explains some of the options that are important for this specific attack. I added the payloads manually.
Once you have these payloads set, click on the “Payload set” dropdown and click the number “2”. This payload set will be the passwords that you will be using.
What this will do is perform the following brute force attempts.
- JSmith Using the passwords Password1 and WhiteHouse1
- BClinton using the passwords Password1 and WhiteHouse1
- HClinton using the passwords Password1 and WhiteHouse1
- BObama using the passwords Password and WhiteHouse1
Before you start the attack, I usually set Burp to follow redirects. To do this, click on the “options” tab, and then scroll all the way to the bottom and set the “Follow Redirections” option to “Always” and check the box to “process cookies in redirections”.
To start the attack, click the button on the upper right hand corner called “Start Attack” Another window should pop up with the login attempts.
Once you start the attack, you should see some attempts being made. Since my example site does not exist, I used some screenshots from the burp manual to demonstrate how to do this. The window should look something along the lines of the following.
Once we start it, we are going to play a game that I like to call “duck duck goose”. There are going to be requests that look the same. Same Status, Length, etc. Then, there are going to be some requests that have a different length and possibly different status. These are the interesting ones that might have had a successful login and are the ones that you are going to focus on. For example, in Figure 9, we see a 302 status and different length for the top 5 requests, showing that something interesting might be going on there.
If we double click the request and look at the raw results, we will find a header that shows that the user successfully logged in. You can click on the “render” tab and might even grab a shot of the user’s inbox or GUI verification of the user being logged in using those credentials.
You can then go back to the login portal and use these credentials, verifying that the credentials are valid and you have successfully brute forced the account!