For the purpose of my thesis, I need to find the user name/password combination on a given website. I have tried to achieve that using Hydra but failed miserably due to a hidden form value, which changes any time user enters the website (so it also changes while the user fails to log in).

I guess a much simpler solution is fairly easy to achieve in Burp's Intruder, but I cannot find it. I know the user name and password, which are both put in a Simple List payload. The problem lies in the third payload, which is a token. On the browser, it appears to be changing as described above. Because of that, I suspect Burp should dynamically request the token from the website for every user name/password pair.

Is it possible to do? According to this video, it should be: https://www.youtube.com/watch?v=OXIjNfX7BW8 . In fact, I thought the problem was solved in this video but the token payload does not change. I have also read some Burp Intruder documentation and haven't found a solution.

2 Answers 2


The protection you are speaking is called anti CSRF tokens. These tokens are random values generated by server and which can be used only once ideally (as in this case as well).

AFAIK, you need to write custom Burp Extender to refresh the token each time for making a next request.

Another, easy way to do this is use burp intruder in Pitchfork mode with two lists. This is explained below.

Step 1: (Harvest the CSRF Tokens )

You need to do a lot (equals to number of users x number of passwords you want to test) of GET requests to the login page using wget/curl and collect the CSRF tokens to a file. Lets call this list as csrftokens.txt.

So, in csrftokens.txt file you will have valid tokens collected above like


Step 2:(Generate a single username+password File)

Take your usernames file (users.txt) and password file (password.txt) . Create a list of all possible combinations in the format same as POST request parameters submit.

sample users.txt


sample password.txt


Lets say the site original post parameters string was like

token="xxxx-xxxx-xxxx"&user="exampleuser"&password=" examplepass"

Here,you create a new file with all possible username,password combinations (users_pass.txt) like


Step3:(Tweak the Burpsuite to defeat anti CSRF tokens)

Now, in burp intruder select Pitchfork mode and edit the post parameters as below


Here, you removed the password field in burp request. This will actually be comming from the users_pass.txt file.

Burp will keep submitting the requests in the format as original post request like below.


This solution needs knowledge of some scripting language for grabbing the tokens. And for generating user_pass.txt you can use a simple select on mysql database using cross join.

By using the Pitchfork mode you are make sure that you use the token only once and avoid requests getting rejected due to reuse of token.

  • 1
    hence, for different applications, there needs to be an way to bypass the Anti-CSRF tokens on such contexts. There are ways to bypass these. I think this could need some AI touch if not sounding too much. Sep 1, 2016 at 8:59
  • It should be noted that typically a CSRF token will only work for one particular session, so this method would require the user work quickly. Also, in some applications, only the most recent token is valid, or a certain number of the most recently issued tokens for a session. Sep 1, 2016 at 12:57

You should be able to use the Macros feature to achieve a similar effect.

Create a new Macro and then manually walk through the login sequence. Select the request that generates the token. Click on configure item. Click on add custom parameter. From here, search through the response for the value of the token, and highlight it. Then you want to set the name to be equal to the value of the parameter name used in the login request. Save the macro.

Then you want to create a session handling rule to use this macro. Add a "Check Session is Valid" Rule action. Configure this rule to match some condition in the response that would indicate that the token is invalid. Then, configure this rule to run a macro if the session is invalid, and add your macro. Make sure you are updating the value of the token with the value from the macro.

This is clunky, and may require some tweaking, but it should work for you. Good Luck!

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .