🧪 DVWA LAB SERIES
FREE
FREE
Part of the DVWA Lab Series — 30 Labs
⚠️ Local Lab Only: The Burp Suite macro technique demonstrated here must only be used against your own DVWA installation or systems within an explicitly authorised penetration testing engagement. Running automated login attacks against any web application without written authorisation is illegal.
DVWA Brute Force Advanced Lab 2026 :— Lab 2 showed you brute force with Hydra against Low security. High security adds a CSRF token to the login form that changes with every single request. Standard tools fail because they submit a static token that is invalid by the time the request arrives. The bypass is a Burp Suite macro — a sequence of requests that fetches a fresh token before every login attempt. This is the most advanced Burp technique in the entire DVWA series, and it applies to any real application with CSRF-protected authentication forms. If you know how macros work, you can brute force almost any login form regardless of its token protection.
🎯 What You’ll Learn in Lab 15
Understand exactly why CSRF tokens defeat standard brute force tools
Configure a Burp Suite Macro to extract a fresh token before each request
Set up a Session Handling Rule to apply the macro to Intruder attacks
Run a successful brute force against DVWA High security login
Apply the same technique to real CSRF-protected application forms
⏱️ 45 min · 3 Burp Suite exercises
✅ Prerequisites
- DVWA running locally (Lab 1: Setup Guide)
- Lab 2: Brute Force with Hydra — understand the Low/Medium approach first
- Lab 14: Security Levels Explained — understand how the CSRF token works in source code
- Burp Suite Community or Professional with proxy configured
📋 DVWA Brute Force Advanced Lab 15 Contents — Anti-CSRF Brute Force Bypass
In Lab 14 you analysed the High security CSRF token source code — the md5(uniqid()) generation and per-request session validation. Lab 15 applies that understanding directly: you know where the token lives in the HTML and how it is validated, which is everything you need to configure the macro. The DVWA Lab Series is sequenced so each lab builds on the previous.
Why Standard Brute Force Fails at High Security
At Low and Medium security, the DVWA brute force form has no CSRF token. Tools like Hydra and Burp Intruder can send login attempts as-is — each request is independent. At High security, a hidden user_token field is added to the form. The server generates a unique token for each page load, stores it in the session, and validates that the submitted token matches when the form is submitted. A token that was valid for the last request is invalid for the current one.
⚡ EXERCISE 1 — DVWA (8 MIN)
Confirm That Standard Intruder Fails Against High Security
⏱️ Time: 8 minutes · DVWA at High security · Burp Suite active
CONFIRM TOKEN PROTECTION IS ACTIVE
# Step 1: Set DVWA to High security
# Step 2: Navigate to Brute Force module and attempt a login
# Step 3: Intercept the POST in Burp — inspect the body
username=admin&password=test&Login=Login&user_token=a8b9c1d2e3f4a5b6c7d8e9f0a1b2c3d4
# Note: user_token is a 32-character MD5 hash
# Step 4: Send to Repeater. Change password, keep same token, send again.
# Observe: the page reloads but shows NO error and NO success
# The invalid token causes silent rejection
# Step 5: Quick Intruder test — mark §password§ only, static token
# Load 5 passwords, run attack
# All responses are identical length — all silently failed
# This proves CSRF protection is active and defeats static attacks
✅ What you just learned: CSRF tokens fail silently in DVWA — no “invalid token” error appears. The application simply ignores the login attempt. A naive brute force tool would exhaust its entire wordlist and report zero credentials found — not because the passwords were wrong, but because every token was stale. This silent failure mode is what makes CSRF token protection effective, and what makes the macro approach necessary to verify the actual password security.
📸 Screenshot the Repeater showing the static token and identical response lengths in Intruder. Share in #dvwa-labs on Discord.
Configuring the Burp Macro — Token Extraction
A Burp macro is a recorded sequence of HTTP requests that Burp replays automatically. For this lab, the macro is a single GET request to the brute force page that extracts the user_token hidden field value from the HTML response. The Session Handling Rule then injects that fresh value into the POST body before each Intruder request fires.
securityelites.com
Burp Suite Macro Configuration — Token Extraction Flow
MACRO — GET request to brute force page
GET /dvwa/vulnerabilities/brute/ HTTP/1.1
→ Response contains: <input type=’hidden’ name=’user_token’ value=’a8b9c1d2…‘>
↓ Macro Item extracts user_token value ↓
SESSION HANDLING RULE — Updates Intruder request
POST: username=admin&password=§test§&Login=Login&user_token=FRESH_TOKEN
→ user_token replaced with value from macro before each Intruder request
📸 Burp macro flow — the macro GETs the login page and extracts the current user_token, then the Session Handling Rule replaces the static token in the Intruder POST with the freshly extracted value before each login attempt fires.
⚡ EXERCISE 2 — BURP SUITE (20 MIN)
Configure the Macro and Session Handling Rule Step by Step
⏱️ Time: 20 minutes · Burp Suite open · DVWA High security
MACRO SETUP — COMPLETE WALKTHROUGH
═══ PART A: Create the Macro ═══
1. Navigate to DVWA Brute Force page (Burp captures the GET request)
2. Burp Settings (top-right gear) → Sessions → Macros → Add
3. In Macro Recorder: select the GET /dvwa/vulnerabilities/brute/ request → OK
4. Double-click the GET request in the macro list → Configure Item
5. In “Custom parameter locations in response” → Add
Parameter name: user_token
In the response panel below, find the hidden input:
<input type=’hidden’ name=’user_token’ value=’a8b9c1d2e3f4…’>
Select ONLY the 32-char hash value with your cursor
Burp fills in the Before/After strings automatically → OK
6. Name the macro: “DVWA Token Extractor” → OK
═══ PART B: Create Session Handling Rule ═══
7. Still in Settings → Sessions → Session Handling Rules → Add
8. Rule Actions → Add → “Run a Macro” → select your macro
9. Tick: “Update current request with parameters matched in final macro response”
10. Under “URL Scope” tab → Add URL: http://localhost/dvwa/vulnerabilities/brute/
11. Under “Tools Scope” tab → tick ONLY “Intruder” → OK
═══ PART C: Verify Macro Works ═══
12. In Macro list, click “Test macro” → check user_token extracted successfully
Should show: user_token = [32-char-hash] in the results pane
✅ What you just learned: The macro configuration is the most complex Burp setup in the entire DVWA series, but the steps are logical once you understand the data flow. The critical step is Step 5 — the cursor selection of the token value tells Burp exactly what substring to extract from the response. The “Tools Scope” restriction to Intruder only (Step 11) is equally critical — without it, Burp runs the macro before every request in your browser session, which dramatically slows normal browsing and can break the DVWA session itself. Always scope macros to the specific tool and URL where they are needed.
📸 Screenshot the “Test macro” result showing user_token successfully extracted. Share in #dvwa-labs on Discord.
Session Handling Rule — Applying the Macro to Intruder
The Session Handling Rule is the bridge between the macro and Intruder. Without it, Burp knows how to extract the token but does not know when to do so or where to put it. The rule says: before every Intruder request to this URL, run the macro and replace the user_token parameter in the request with the freshly extracted value. The result is that every single Intruder payload gets sent with a valid, current token.
Running the Attack — Successful CSRF Bypass
⚡ EXERCISE 3 — DVWA (12 MIN)
Run the Intruder Attack and Crack the High Security Login
⏱️ Time: 12 minutes · Macro configured from Exercise 2
INTRUDER ATTACK WITH CSRF BYPASS
# Step 1: Intercept a POST login request from DVWA High security
POST /dvwa/vulnerabilities/brute/ HTTP/1.1
username=admin&password=test&Login=Login&user_token=STATIC_TOKEN
# Step 2: Send to Intruder → Positions tab
Clear § (clear all positions)
Add § around password value only:
username=admin&password=§test§&Login=Login&user_token=STATIC_TOKEN
# DO NOT mark user_token — the macro updates it automatically
# Step 3: Payloads tab
Payload type: Simple list
Add passwords: password, 123456, admin, letmein, qwerty, abc123, test
# Step 4: CRITICAL — set threads to 1
Resource Pool → New pool → Max concurrent requests: 1
# Multiple threads = race condition = all tokens invalid
# Step 5: Start attack
# Step 6: In results — sort by Response Length
# Successful login = longer response (contains “Welcome to the password protected area”)
# admin : password → different (longer) response length = SUCCESS
✅ What you just learned: Thread count 1 is non-negotiable for macro-based attacks — concurrent requests cause each token fetch to invalidate the previous one, resulting in all attempts failing. At thread 1, each fetch-use cycle is atomic: GET token → POST with that token → GET fresh token → POST again. The response length differentiation technique (longer = success) is the standard way to identify successful credentials in Intruder when there is no explicit “wrong password” message to match. In real applications, this exact workflow applies to any CSRF-protected login form — the macro configuration is identical, only the URL and parameter name change.
📸 Screenshot Intruder results showing the different response length for admin:password. Share in #dvwa-labs on Discord. Tag #dvwabrute2026
🧠 QUICK CHECK — Lab 15
You configure a Burp macro and session handling rule to bypass DVWA High security CSRF tokens, then run Intruder with 5 threads to speed up the attack. After 100 attempts, every response length is identical — suggesting all attempts failed silently. What is the most likely cause and fix?
📋 Lab 15 Key Takeaways
CSRF token protectionDefeats static brute force — token changes per request, static tokens fail silently
Burp MacroRecorded GET → extracts fresh user_token from hidden field before each POST
Session Handling RuleApplies macro to Intruder only — updates user_token parameter automatically
Thread count = 1Mandatory — concurrent threads cause race condition, all tokens become stale
Success detectionSort by response length — correct password produces longer response
Real-world applicationSame macro technique works on any CSRF-protected login form — change URL and param name only
🏆 Mark Lab 15 as Complete
Lab 15 is the most advanced Burp Suite technique in the DVWA series. Macros and session handling rules apply far beyond DVWA — any real application with CSRF-protected authentication forms can be tested using this exact approach. This is a professional-grade skill used in real penetration testing engagements.
❓ Frequently Asked Questions
What is anti-CSRF token brute force protection?
A randomly generated token per form submission that must match the server-side value. Static automated tools fail because the token is stale before the request arrives. Bypass requires fetching a fresh token before each attempt — Burp macros do this automatically.
What is a Burp Suite Macro?
A recorded HTTP request sequence replayed automatically by session handling rules. Here: GET the login page, extract user_token from the hidden field, store as variable. The Session Handling Rule then updates the POST body with the fresh token before each Intruder request.
Why does standard Hydra fail against DVWA High security?
Hydra submits login requests without first fetching the current CSRF token. DVWA validates the submitted token against the session — static or missing tokens are silently rejected with no error message, making the tool appear to work but find nothing.
What is the token parameter name in DVWA High security?
user_token — a 32-character md5(uniqid()) hash. Lives in the form as a hidden input. The macro extracts it from the GET response HTML; the session rule injects it into the POST before each Intruder request.
Why must Intruder run at 1 thread with macros?
Multiple concurrent threads create a race condition — each thread fetches a token but subsequent fetches invalidate earlier ones. Thread 1 forces sequential fetch→use→fetch→use cycles so each token is valid when its request fires.
What comes after Lab 15?
Lab 16: DVWA Command Injection Advanced — filter bypass techniques at Medium and High security levels using character substitution, encoding, and environment variable tricks to defeat blacklist filtering.
← Previous Lab
Lab 14: DVWA Security Levels Explained
Next Lab →
Lab 16: DVWA Command Injection Advanced
📚 Further Reading
- DVWA Security Levels Explained 2026 — Lab 14 reveals the exact PHP source for the CSRF token generation — understanding md5(uniqid()) and session validation is the prerequisite for configuring the Lab 15 macro extraction correctly.
- DVWA Brute Force Lab 2026 — Lab 2 covers Hydra and Burp Intruder against Low/Medium security — the baseline brute force skills that Lab 15 extends to defeat CSRF token protection at High security.
- DVWA Labs Hub — All 30 DVWA labs in sequence — Lab 15 is the halfway milestone at 50%, and the Burp macro skills learned here apply directly to upcoming web application testing labs.
- Burp Suite Macros — Official Documentation — PortSwigger’s official macro documentation covering all configuration options, response extraction methods, regex vs cursor selection, and session handling rule integration for complex authentication flows.
- PortSwigger — Password-Based Authentication Labs — PortSwigger Web Academy authentication labs that apply CSRF token bypass in real web application contexts — the natural next step after mastering the technique on DVWA.
Leave a Reply