Penetration Testing: Brute Force Attacks

Overview

With the lab built and the network mapped, it was time to begin working through DVWA’s security modules. This post covers authentication brute forcing, cracking the login form at two different security levels using different tools, understanding what the defenses actually do, and why they ultimately fall short.

---

Brute Force — Low Security (Burp Suite)

At Low security, DVWA’s login form has no rate limiting, no account lockout, and no CSRF token protection. Every request is independent, making it the most permissive and easiest configuration to attack.

Approach: Intercept the login POST request with Burp Suite’s proxy, send it to Intruder, mark the password parameter as the injection point, and iterate through a wordlist.

Intercepting the Request

With Burp Suite’s proxy active and FoxyProxy routing browser traffic through it, any login attempt captures the raw POST request for analysis.

Login POST request intercepted in Burp Suite

The request was sent to Intruder, the password field was marked as the payload position, and a wordlist was loaded. Burp submitted a login attempt for every entry automatically.

Result

Sorting responses by content length immediately surfaced the successful credential — a valid login returns a different page size than a failure.

Admin account cracked — response length differential confirms valid credentials

The admin account was compromised with zero friction. At Low security this is the expected outcome, the value lies in learning the interception and attack workflow.

---

Brute Force — Medium Security (Hydra)

Medium security introduces a 2-second server-side delay between login responses. The intent is to make brute forcing impractically slow. In practice, it changes the tooling requirements more than the outcome.

For this round, Hydra was used, a command-line tool purpose-built for network authentication attacks that handles HTTP forms and timing constraints efficiently.

Preparation

Several prerequisites were addressed before executing the attack:

1. Extracting the POST URL, form parameters, and session cookie (DVWA’s medium mode requires a valid session token)
2. Building focused wordlists from SecLists, filtering out entries containing apostrophes (the reason for this is explained below)

Execution

Hydra command targeting the DVWA login form

Valid credentials recovered for both admin and pablo accounts

Both accounts were cracked despite the 2-second delay. The fundamental weakness: a time delay slows the attack but does not terminate it. Without account lockout or exponential backoff, an attacker simply waits, or uses tooling that handles the delay automatically.

---

Accidental Discovery: SQL Injection Indicator

While manually testing login inputs, submitting a username containing an apostrophe returned a raw SQL error directly in the browser.

Raw SQL error surfaced by the login form — a textbook injection indicator

This is a classic sign of string concatenation in the SQL query rather than parameterized inputs. The exposed error confirms two things:

1. SQL injection is likely viable on this form
2. The application reveals its internal query structure to the attacker

This discovery also explained why apostrophe-containing wordlist entries were producing anomalous responses during the brute force attack. They were triggering database exceptions rather than standard login failures.

---

Defensive Takeaways

Running these attacks against real infrastructure transforms abstract security recommendations into concrete understanding:

Lesson	Detail
Time delays ≠ account lockout	The 2-second delay changed the tool used but not the outcome. Effective protection requires lockout or exponential backoff.
MFA eliminates credential brute forcing	No wordlist defeats a TOTP code. Even weak passwords become irrelevant with a second factor.
Never expose raw database errors	The SQL exception was discovered passively, before actively testing for injection. Generic error messages and parameterized queries close this gap.
Authentication anomalies are detectable	Rapid failed logins from a single IP are a pattern any SIEM can alert on, a capability built into V2’s Wazuh deployment.

---

Wrapping Up V1

V1 started with a dusty all-in-one PC pulled out of storage. By the end, it was running a Type 1 hypervisor, a production DNS service, and a functional attacker-target lab with documented offensive exercises and defensive analysis.

The gap V1 could not close was visibility, attacks were running against lab machines with no centralized logging, no alerting, and no way to detect what was happening. That gap is exactly what V2 was built to address.