DVWA - Brute Force (High Level) - Anti-CSRF Tokens
"A how to guide for brute forcing Damn Vulnerable Web Application (DVWA) on the high security level using Hydra, Patator and Burp Proxy Suite to ..

DVWA - Brute Force (High Level) - Anti-CSRF Tokens
This is the final "how to" guide which brute focuses Damn Vulnerable Web Application (DVWA), this time on the high security level. It is an expansion from the "low" level (which is a straightforward HTTP GET form attack). The main login screen shares similar issues (brute force-able and with anti-CSRF tokens). The only other posting is the "medium" security level post (which deals with timing issues).
For the final time, let's pretend we do not know any credentials for DVWA....
Let's play dumb and brute force DVWA... once and for all!
TL;DR: Quick copy/paste
1 2 3 4 5 6 7 8 9 10 11 12 |
|
Objectives
- The goal is to brute force an HTTP login page.
- GET requests are made via a form.
- The web page is in a sub folder.
- Low
- Straight forward HTTP GET brute force attack via a web form.
- Bonus: SQL injection (
See here for more information).
- Medium
- Extends on the "low" level - HTTP GET attack via a web form.
- Adds in a static time delay (4 seconds) on failed logins.
- High
- Extends on the "low" level - HTTP GET attack via a web form.
- Uses an anti Cross-Site Request Forgery (CSRF) token.
- This time uses a random time delay (between 0 and 4 seconds).
Impossible- Submits data via HTTP POST via web form
- Accounts will lock out after 5 failed logins.
- Time delay before becoming unlocked (15 minutes).
- Unable to enumerate users on the system.
- Possible "Denial of Service (DoS)" vector.
PHPIDS- Does not protect against this attack.
- All attack methods are still the same!
Setup
- Main target: DVWA v1.10 (Running on
Windows Server 2012 Standard ENG x64
+IIS 8
).- Target setup does not matter too much for this -
Debian
/Arch Linux
/Windows
,Apache
/Nginx
/IIS
,PHP v5.x
, orMySQL
/MariaDB
. - The main target is on the IP (
192.168.1.44
), port (80
) and subfolder (/DVWA/
), which is known ahead of time. - Because the target is Windows, it does not matter about case sensitive URL requests (
/DVWA/
vs/dvwa/
).
- Target setup does not matter too much for this -
- Attacker: Kali Linux v2 (+ Personal Custom Post-install Script).
Both machines are running inside a Virtual Machine (VMware ESXi).
Tools
- cURL - Information gathering (used for viewing source code & automate generating sessions).
- Patator v0.7 - A brute force tool.
- So far, we were using v0.5, however this does not have the
before_header
function. Time to upgrade!
- So far, we were using v0.5, however this does not have the
- Burp Proxy v16.0.1 - Debugging requests & brute force tool
- Using FoxyProxy to switch proxy profiles in Iceweasel.
- SecLists - General wordlists.
- These are common, default and small wordlists.
- Instead of using a custom built wordlist, which has been crafted for our target (e.g. generated with CeWL).
Creating a Session Cookie
This was explained back in the first post for the low level setting. Again, this post will be using the low level posting, and expanding on it. I will not be covering certain parts in depth here, because I already mentioned them in other posts. If a certain area is does not make sense, I strongly suggest you read over the low security post first (and maybe the medium one too).
The cookie command has not changed, plus the target has not changed, which means the output and result will be the same.
1 2 3 4 5 6 |
Object MovedThis document may be found HREF
|
Note, depending on the web server and its configuration, it may respond slightly differently (in the screenshot: 192.168.1.11
is Nginx,192.168.1.22
is Apache & 192.168.1.44
is IIS). This is a possible method to fingerprint an IIS web server.
Information Gathering
Form HTML Code
First thing we need to do is to figure out how this level is different from both of the ones before it (low and medium). We could use DVWA's in-built function to allow us to look at the PHP source code (which is stored on the server), however, let's try and figure it out ourselves as we would be doing if it was any other black box assessment. Using the same commands as before, let's see what was returned in the initial HTML response that makes up the web form.
1 2 3 4 5 6 7 8 9 10 11 |
|
Unlike the times before, this is not the same! There is now an extra input field between the
tags, call
user_token
! We can highlight this by using diff
to compare the low and high levels.
1 2 3 4 5 6 7 8 9 |
low.txt
high.txt
|
Based on the name (user_token
), the field is hidden, and as the value appears to be a MD5 value (due to its length and character range), these are all indications of the value being used for an anti-CSRF (Cross-Site Request Forgery) token. If this is true, it will make the attack slightly more complex (as testing each combination could require a new token), and we will not be able to use certain tools (such as Hydra, unless we permanently have it using a proxy).
CSRF Token Checking
Comparing requests:
Is the value in the hidden field (user_token
) static? What happens if we make two normal requests and compare the responses?
1 2 3 4 5 6 7 8 |
|
So it looks when you request a new page, the web app generates a new token (even more proof it is an anti-CSRF token).
Redirects:
What happens when we try to send a request? Once again we are pretending we do not know any valid credentials to login with (and there is still not a register/sign up page!), so we will just pick values at random, knowing they will fail (user
/pass
).
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
| html2text
|
The page loads as normal. But what happens if we repeat the last request, re-using the same CSRF token (which now would be invalid)? Are we able to-do a similar trick as we did in the main login screen, where we get a valid session and then kept using it over and over?
1 2 |
|
The page did not respond the same! Let's dig deeper...
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
Object MovedThis document may be found HREF
|
Just like before, we are being redirected after submitting, however this time it only happens when the CSRF token is incorrect - not the credentials. Something to keep in mind, would the page we are being redirected to different depending if the login was successful? Now, let's follow the redirect and see what is returned.
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
See how we get the message three times? So we are able to send multiple requests, but only show the results when the CSRF token is valid.
We are going to cheat a little here, and see what happens when we make a successful login, and compare it to an invalid one, both with an invalid CSRF token. If there are any differences (e.g. where we are being redirected to, page size, cookies etc.), is the web application checking the credentials even if the CSRF is invalid? If it is, we might be able to use this as a marker to bypass the CSRF function.
1 2 3 4 5 6 7 8 9 |
|
Nope. Sending valid credentials does not make a difference (same redirected page, same length, same cookie). Nothing to use as a marker (unlike the login screen ). This means the web application is processing the CSRF token and does not proceed any further.
Invalid token request:
Is there a way to somehow bypass the CSRF check? We already know what happens if we do not send the correct value in the CSRF token, but what happens if the token is blank, if the token field is missing, if the token value contains characters out of its normal range (0-f
), or, if the token value is too short/long?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 |
| html2text
| html2text
| html2text
| html2text
|
All failed.
The only other way to try and bypass this protection would be to predict the value. Is the "seed" (the method used to generate the token) weak? Example, what if it was only the timestamp in a MD5? However, I am going to skip doing this, because I know it is a dead end in this case.
All of this means we need to include a unique value in each request during the brute force attack, so we make a GET request before sending the login credentials in another GET request. This in itself will limit what tools we can use (e.g. Hydra v8.1 does not support this - only solution would be to use a Proxy and have it alter Hydra's requests). Plus, due to the nature of the web application being slightly different (e.g. having to be already authenticated at the screen we want to brute force), this is going to make it even more difficult. Example, the version of Patator we have been using (v0.5) does not support this, however v0.7 does! Having to be logged into the web application, means we have to use a fixed session value (PHPSESSID
), which will mean we only have one user_token
at a time. Using multiple threads, will make multiple GET requests to get a user_token
and each request resets the value, thus making the last request the only valid value (so some request would never be valid, even with the correct login details). Single thread attack, once again.
Timings
When doing our CSRF checks, we noticed that the web application response time was not always the same (unlike Medium where it would always take an extra 3 seconds).
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
|
There's a mixture of time delays, between 0-4 seconds. However, due to the "logged in CSRF token" mentioned before we are going to have to be using a single thread - so just make sure the time out value is greater than 4 seconds.
Patator
Patator is able to request a certain URL before trying a combination attempt (using before_urls
), and can then extract a certain bit of information (before_egrep
) to include it in the attack (e.g. _CSRF_
). As already mentioned, having to be already authenticated to web application in order to brute force a form is slightly different. Lucky, Patator v0.7 can also send a header (before_header
) to make sure the requests are always as an authenticated user. Note, in the low and medium levels, we were using v0.5.
Patator Documentation
Compared to the low level, the only extra arguments we are now using:
1 2 3 4 5 |
|
before_urls
- this will be the same URL as we are trying to brute force as it contains CSRF value we wish to acquire.before_header
- this will be the same as theheader
(because we need to be authenticated to being with).before_egrep
- this is where the magic will happen. This extracts the CSRF token value from the page, so we can re-use it in the main request.- We know to use
due to the information we gathered using cURL.
- Patator uses regular expressions (
egrep
) in order to locate the wanted CSRF value -(\w+)
. - We will assign the extracted value to the variable
_CSRF_
so we can use it in the same matter as the wordlists -&user_token=_CSRF_
.
- We know to use
--max-retries
- is not really required, just carried over from the medium level.
If you would like to see what is happening behind the scenes, here is a screenshot of the attack with a proxy being used.
Patator Attack Command
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 |
|
Burp Suite
Burp Suite has a proxy tool in-built. Even though it is primarily a commercial tool, there is a "free license" version. The free edition contains a limited amount of features and functions with various limits in place, one of which is a slower "intruder" attack speed.
Burp is mainly a graphical UI, which makes it harder to demonstrate how to use it (mouse clicking vs copying/pasting commands). This section really could benefit from a video, rather than a screenshot gallery....
The first section will quickly load in the valid request, which contains the user_token
field we need to automate in each request. The next part will create a macro to automatically extract and use the value. The last part will be the brute force attack itself.
Configure Burp
This is quick and simple. Get to the brute force login page and make a login attempt when hooked inside the proxy.
- The first thing we need to-do is set up our web browser (Iceweasel/Firefox) to use Burp's proxy.
- IP:
127.0.0.1
(loopback by Burp's default), Port:8080
- Using FoxyProxy to switch profiles.
- IP:
Macro
This stage will now detect, extract and act on the user_token
field.
Options
->Sessions
->Session Handling Rules
->Add
.
Rule Description
:DVWA Brute High
->Rule Action
->Add
->Run a macro
Select macro
->Add
Macro Recorder
-> Select:GET /DVWA/vulnerabilities/brute/ HTTP/1.1
-> OK
Macro description
:Get user_token
.#1
->Configure item
.
Custom parameters locations in response
->Add
.
Parameter name
:user_token
.Start after expression
:user_token' value='
.End at delimiter
:' />
- Ok
- Ok -> Ok
- Enable:
Tolerate URL mismatch when matching parameters (use for URL-agnostic CSRF tokens)
- Ok
- Result
Scope
->Tool Scope
-> Only select:Intruder
URL Scope
->Use Suite scope [defined in Target tab]
- Ok
We will come back here if we choose to use Hydra later.
Target
->Site map
->192.168.1.44
-> Right click:Add to scope
Intruder
This is the main brute force attack itself. Due to the free version of Burp, this will be "slow".
- First thing, find the request we made back at the start, when we tried to login with the bad credentials.
- Right click ->
Send to Intruder
.
Intruder
(tab) ->2
->Positions
- Attack type:
Cluster bomb
.- This supports multiple lists (based on the number of fields in scope. Defined by
§value§
), going through each value one by one in the first wordlist, then when it reaches the end to move to the next value in the next list - For more information about attack types: https://portswigger.net/burp/help/intruder_positions.html
- This supports multiple lists (based on the number of fields in scope. Defined by
Clear §
- Highlight:
user
-> Press:Add §
- Result:
username=§admin§
- Result:
- Highlight:
pass
-> Press:Add §
- Result:
password=pass
- Result:
Intruder
(tab) ->2
->Payloads
- Payload Sets -> Payload Sets:
1
. Payload type:Simple list
- Payload Options [Simple list] -> Load ->
/usr/share/seclists/Usernames/top_shortlist.txt
-> Open
- Payload Sets -> Payload Sets:
2
. Payload type:Simple list
- Payload Options [Simple list] -> Load ->
/usr/share/seclists/Passwords/rockyou-10.txt
-> Open
- Total requests:
1,012
Intruder
(tab) ->2
->Options
- Attack Results -> Untick:
Make unmodified baseline request
- Grep - Extract -> Add
Start after expression
:
.End at delimiter
:- Ok
Intruder (menu)
->Start attack
- This is the warning, informing us we are using the free edition of Burp, as a result, our attack speed will be limited.
- Ok
- Result
- We can see the value which is successful by the
being different, as well as theLength
.
Hydra
This is not a complete section, as it expands upon the "Burp Proxy" above. We will be editing values which were created, rather than adding them.
Hydra by itself is unable to perform the attack. When putting Hydra's traffic through a proxy, the proxy can handle the request, altering Hydra's request so Hydra is not aware of the CSRF tokens.
In order to get Hydra to be able to brute force with CSRF tokens, we need to:
- In Burp, edit the CSRF macro to run on traffic which is sent via the proxy (see the Burp section above for the guide to create the macro).
- Enable "invisible proxy" mode inside of Burp, allowing Hydra to use Burp as a proxy (see low level posting for why).
- Create a rule to drop the unnecessary GET requests Hydra creates (see login screen posting for why).
CSRF Macro + Proxy:
- Burp -> Options -> Sessions -> Session Handling Rules -> Edit:
DVWA Brute High
- You will need see the Burp Suite section above, which shows how to create this.
- Scope -> Tools Scope -> Enable:
Proxy (use with cation)
- Ok
Enable Invisible Proxy Mode:
- Burp -> Proxy -> Options
- Proxy Listeners -> Edit:
127.0.0.1
-> Request handling -> Tick:Support invisible proxying (enable only if needed)
Drop unwanted GET requests:
- Burp -> Proxy -> Options
- Match and Replace -> Add
- Type:
Request header
- Match:
GET /DVWA/vulnerabilities/brute/ HTTP/1.0
- Replace: < BLANK >
- Comment:
DVWA Hydra Brute High
- Enable: Regex match (Even if we did not use any expression. Oops!)
- Type:
- Ok
Result:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
|
Note, we do not see the result of the macro being used. We are only seeing the values before Burp alters the traffic, which is why the user_token
appears to be an incorrect value each time. The attack was successful, which can be seen in Burp by the length
column, and response tab, as well as in Hydra's output window.
Also note, the speed of the traffic in Burp's proxy is not filtered, unlike Burp's intruder function when using the free license.
Proof of Concept Scripts
Here are two Proof of Concept (PoC) scripts (one in Bash and the other is Python). They are really rough templates, and not stable tools to be keep on using. They are not meant to be "fancy" (e.g. no timeouts or no multi-threading). However, they can be fully customised in the attack. We cannot benchmark these, because of the random cool down times when there is a failed login attempt.
These scripts (can more) can be found on GitHub at the following repository.
Bash Template
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 |
|
Python Template
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 |
|






