In this step, you will identify and analyze a target web form for password spraying. We'll use a deliberately vulnerable web application running on http://localhost:8080 for this exercise. Password spraying works by trying a few common passwords against many user accounts, so understanding the login form's structure is crucial before launching the attack.
-
First, verify the target web application is running:
curl -I http://localhost:8080/login
The -I flag tells curl to fetch only the HTTP headers. You should see a 200 OK status confirming the login page is accessible. If you get a connection error, make sure the web server is running before proceeding.
-
Examine the login form structure by viewing the page source:
curl http://localhost:8080/login | grep -A5 -B5 "form"
This command fetches the HTML content and shows 5 lines before and after any <form> tags. Look for the form's action attribute (where data gets sent) and input field names - these are usually called username and password but can vary.
-
Create a test request file to document the form's parameters:
nano form_test.txt
Add this content to record the key details Hydra will need:
Target URL: http://localhost:8080/login
Method: POST
Username field: username
Password field: password
Failure indicator: "Invalid credentials"
The failure indicator helps Hydra recognize when login attempts fail. We'll use this file later to configure our attack.
-
Test the form manually with a single credential pair:
curl -X POST -d "username=admin&password=wrongpass" http://localhost:8080/login -v
The -X POST specifies the HTTP method, while -d sends the form data. The -v flag shows verbose output so you can verify the "Invalid credentials" response. This confirms the form works as expected with failed logins.
-
Check for account lockout policies by sending 5 rapid requests:
for i in {1..5}; do
curl -X POST -d "username=admin&password=wrong$i" http://localhost:8080/login -s -o /dev/null -w "Attempt $i: %{http_code}\n"
done
This loop sends 5 quick failed attempts. Watch if the HTTP status code changes from 200 (success) to 403 (forbidden) which would indicate lockout protections. Real-world applications often have these safeguards, but our test environment doesn't.
