Let’s say you run a penetration test of a website and you have a list of credentials.
You want to check which of them belong to the administrators and which are the accounts of ordinary users.
Unfortunately, the account type is displayed on a different subpage than the one returned by the server after logging in.
Of course, you could write a script in Python, which would first log in using the given data, and then download the content of the
But you can also do it directly from Burp - using macros.
Let’s look at an example.
Here we can see a form with login and password. After successful login we can see the username.
To check user type, we need to go to the
There, depending on the account type, we’ll receive a string:
In a text file, we store logins and passwords in pairs, separated by a colon.
We will use the intruder tool for testing.
First, from the list of requests, select the one where we tried to log in.
It will be our base for further requests.
Right click and select
Send to intruder.
We go to the highlighted tab. Now we need to indicate where the login and password are - so that the software knows where to insert additional combinations. Burp by itself detected 4 potential places, marking them in green.
We remove two of them that were marked by mistake.
We can do this by selecting the appropriate string and using the
Intruder allows you to launch various types of bruteforce attacks.
We usually have a list of logins and passwords and try all possible combinations.
In our case - we know exact logins and passwords for specific accounts.
So we’ll use the
There, a separate list is defined for each item. So we have a different lists for logins and for passwords.
When creating a new request, Intruder takes the first element from the login list and matches it with the first element from the password list.
The lists are defined in the
The first set is our login, which was previously marked in green.
We load previously prepared data from a text file.
Here we come across a small problem.
Intruder treats the entire string from the file as a login - while it should be only the data before the first colon.
We can fix this by using an additional option that allows you to process the list before using it in your request.
Match/replace is like
find and replace, but using regular expressions.
We can apply it also to passwords - by changing the expression a bit. We can now test the attack.
And we can actually see that the login was successful. It’s time for the second part - checking the type of the account.
Burp allows for additional requests, made automatically, when some criteria are met.
You can set them in the tab
Project Options ->
Here we create a new rule.
As an action we set
Run a post-requst macro.
Now we are creating a new macro - that is, we choose the request to be executed automatically.
We pick the one that directs to the
This cookie is set earlier by the Intruder module.
To use it also in this request, we must select the option:
By default, Intruder would receive the result of the request from
But instead, we want the content of
profile.php to be passed.
We select the option named
Pass back the final response from the macro.
Last thing to do is to define the scope when the rule should work.
In our case, it will be the Intruder module and one specific URL.
Finally, we need to make sure that the
Intruder option is selected in the
Cookie jar tab.
Otherwise, cookies will not be properly transferred between the two Burp modules.
It’s time for testing.
Everything works fine - we see the account type in the results. But we need to open every request and check the content by ourselves - such testing is cumbersome in the long run. Our goal is to extract this information and display it in the appropriate column.
We can use
grep-extract for this.
Here we define where our specific information is located.
The account type is between the
So we’ll use a simple regular expression:
This time everything looks much better. What’s more, we can now sort the results depending on the type of user.