In our previous article part1, we had discussed how to perform a brute force attack on any web application server for making unauthorized login into it using some Payload of Burpsuite. In part 2 articles you will learn more about brute force attack with help of remaining BurpSuite payloads that might be helpful in other situation. Here you will find the typical flow that you should follow when pentesting one or more machines. Click in the title to start! If you want to know about my latest modifications / additions or you have any suggestion for HackTricks or PEASS, join the 💬 PEASS & HackTricks telegram group here, or follow me on Twitter 🐦 @carlospolopm.
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
Hf element. 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!
This function can be used to discover content and functionality which is not linked from visible content that you can browse to or spider.
To access this function, select an HTTP request anywhere within Burp, or any part of the Target site map, and choose 'Discover content' within 'Engagement tools' in the context menu.
Burp uses various techniques to discover content, including name guessing, web crawling, and extrapolation from naming conventions observed in use within the application. Discovered content is displayed within a special site map that is specific to the discovery session, and can also optionally be added to the main suite site map.
This tab shows you the current status of the discovery session.
The toggle button indicates whether the session is running, and lets you pause and restart the session.
The following information is displayed about the progress of the discovery session:
- Number of requests made
- Number of bytes transferred in server responses
- Number of network errors
- Number of discovery tasks queued
- Number of spider requests queued
- Number of responses queued for analysis
The individual discovery tasks that are queued are shown in a table. The discovery engine works recursively, and when a new directory or file is discovered, further tasks are derived from this, depending on the configuration. For example, when a new directory is discovered, Burp might add tasks to look for sub-directories and files within that directory; or, when a new file is discovered, Burp might add a task to check for the same base filename with different file extensions. Newly added tasks are prioritized according to their likelihood of quickly discovering new content.
These options let you define the start directory for the content discovery session, and whether files or directories should be targeted. The following options are available:
- Start directory - This is the location where Burp will start looking for content. Only items within this path and its subdirectories will be requested during the session.
- Discover - This option determines whether the session will look for files or directories or both. If you are checking for directories, you can choose whether and how deep to recurse into discovered subdirectories.
These options let you configure the sources that Burp should use for generating filenames to test. The following options are available
- Built-in short file list
- Built-in short directory list
- Built-in long file list
- Built-in long directory list
- Custom file list
- Custom directory list
- Names discovered in use on the target site. If this option is selected, Burp will maintain a list of all directories and filename stems that have been discovered on the target site, and will also check for these in each new directory that is tested.
- Derivations based on discovered items. If this option is selected, Burp will attempt to guess item names based on those that have already been discovered. For example, if the directory
AnnualReport2018is discovered, Burp will also check for
These settings control how the discovery session adds file extensions to file stems that are being tested. The file stems themselves are derived according to the filenames options. When each file stem is tested, Burp checks for various different extensions, according to these settings. The following options are available:
- Test these extensions - This option lets you configure a list of extensions that Burp will always check for. You can fine-tune the default list based on the technologies known to be in use on the target application.
- Test all extensions observed on target site - If this option is selected, then Burp will automatically check for file extensions that have been observed in use on the target site. This option is useful when you don't know exactly what extensions or technologies are in use. You can also configure a list of extensions that you don't want to check for even if found to be in use (such as image files).
- Test these variant extensions on discovered files - This option lets you configure a list of extensions that Burp will additionally check for using the stems of discovered filenames. This option is useful to check for backup copies of existing files.
- Test file stems with no extension - If this option is selected, Burp will check for each file stem with no extension added.
These settings control the engine used for making HTTP requests when discovering content, and interaction with the suite site map. The following options are available:
- Case sensitivity - This setting controls whether Burp will handle filenames case sensitively. If 'Auto-detect' is selected, then Burp will start by handling filenames case sensitively, and on discovering the first new item, will test the server's treatment of case variations. Depending on that treatment, Burp may revert to handling filenames case insensitively.
- Add discovered content to suite site map - If this option is selected, then new items identified in the current discovery session will be automatically added to the main suite site map.
- Copy content from suite site map - If this option is selected, then the discovery session will copy any existing relevant content from the main suite site map into the discovery site map, to provide a stronger starting basis for discovering new content.
- Spider from discovered content - If this option is selected, then the discovery session will perform conventional web crawling, and will process the responses to discovery requests looking for links to additional new content.
- Number of discovery threads - This option controls the number of concurrent requests the discovery engine is able to make.
- Number of spider threads - This option controls the number of concurrent requests the crawling function is able to make, if enabled.
Burp Suite Directory Brute Force Download
Burp Suite Directory Brute Force Download
The discovery session employs its own site map, showing all of the content which has been discovered within the defined scope. If you have configured Burp to do so, newly discovered items will also be added to Burp's main site map.