21-01-2020 / From 0 to pentesting hero

BURP - Intruder

Let's say you run a penetration test of a website and you have a list of credentials.

Account list

You want to check which of them belong to the administrators and which are the accounts of ordinary users.

Account type

Unfortunately, the account type is displayed on a different subpage than the one returned by the server after logging in.

Solution in python

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 profile page.

But you can also do it directly from Burp - using macros.

Let's look at an example.

Login form

Here we can see a form with login and password.

After successful login we can see the username.

Account type

To check user type, we need to go to the profile.php subpage.

There, depending on the account type, we'll receive a string: user or admin.

In a text file, we store logins and passwords in pairs, separated by a colon.

List of accounts

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.

Choose request

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 clear button.

Potential injection places

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 pitchfork option.

Pitchfork options

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 payloads tab.

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.

Choose payload

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.

Regular expressions

We can apply it also to passwords - by changing the expression a bit.

We can now test the attack.

Test 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 -> Sessions.

Here we create a new rule.

Run a post-request macro

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 profile.php subpage.

This subpage uses cookies to check if the user is logged in.

This cookie is set earlier by the Intruder module.


To use it also in this request, we must select the option: Use cookies from the session handling cookie jar in requests.

By default, Intruder would receive the result of the request from login.php.

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.

Grep-extract option

We can use grep-extract for this.

Here we define where our specific information is located.

The account type is between the <b> tags.

So we'll use a simple regular expression: <b>(.*?)</b>.

Grep-extract result

This time everything looks much better.

What's more, we can now sort the results depending on the type of user.