This chapter covers Hydra, a powerful network authentication brute-forcing tool essential for penetration testing credential security. For the PT0-002 exam, understanding Hydra's syntax, modules, and practical usage is critical as it appears in multiple objectives under Tools & Scripts (5.1) and Attack Execution (3.1, 3.2). Expect 5-10% of exam questions to reference Hydra directly or require knowledge of its capabilities for credential attacks.
Jump to a section
Imagine you are a locksmith trying to open a high-security lock that has a combination of 4 digits (0-9). You have a set of 10,000 possible combinations. Instead of trying each combination manually, you build a machine that automatically dials the combination, checks if the lock opens, and if not, moves to the next combination. However, the lock has a security feature: after 3 wrong attempts, it delays for 10 seconds before accepting the next try. Your machine must respect this delay to avoid being locked out entirely. Hydra works similarly: it systematically tries username and password combinations against a service (like SSH or HTTP login). It sends the authentication request, waits for the server's response (success or failure), and then tries the next combination. It can be configured to handle delays, use different protocols, and even parallelize attempts across multiple targets or threads, just as you might build multiple machines to try combinations simultaneously. But if the server has rate limiting or account lockout, Hydra must respect those constraints or risk being blocked.
What is Hydra?
Hydra (THC-Hydra) is an open-source parallelized network login cracker that supports numerous protocols to brute-force authentication. Developed by van Hauser and the THC team, it is designed to perform rapid dictionary attacks against services like SSH, FTP, HTTP, SMB, MySQL, and many more. Its primary purpose is to test the strength of passwords by attempting many combinations in a short time, highlighting weak credentials.
How Hydra Works Internally
Hydra operates by establishing a network connection to the target service, sending authentication requests with a guessed username and password, and analyzing the response to determine success or failure. The process involves:
- Service Module: Hydra uses a specific module for each protocol (e.g., ssh, ftp, http-post-form). Each module knows the exact protocol handshake and authentication message format.
- Parallelization: By default, Hydra uses 16 parallel tasks (threads) per target, configurable with -t. It forks multiple processes to send attempts concurrently, drastically reducing total time.
- Retry and Error Handling: If a connection fails (e.g., timeout), Hydra retries up to a configurable number of times (-c). It also handles server-side delays or lockouts by adjusting timing.
- Success Detection: The module checks the server's response. For example, in SSH, a successful login returns a shell prompt; in HTTP, a successful login returns a different status code or page content. Hydra uses patterns (like FAIL or SUCCESS strings) to determine outcome.
Key Components, Defaults, and Timers
Default Ports: Hydra automatically uses default ports for each service (e.g., SSH=22, FTP=21). Use -s to specify custom ports.
Threads (`-t`): Default is 16. Higher values increase speed but may overwhelm the target or trigger rate limiting. For services with lockout policies, use -t 1 to avoid rapid failures.
Timeouts: Default connection timeout is 30 seconds (-w). Adjust for slow networks.
Rate Limiting: Hydra does not automatically respect rate limits; use -W (wait between attempts) to add delays.
Modules: Over 50 modules available, including http-get, http-post-form, ssh, ftp, smb, mysql, postgres, vnc, pop3, imap, ldap2, cisco, telnet, etc.
Configuration and Verification Commands
Basic syntax:
hydra -l username -P password_list.txt target service-l : single username
-L : username list file
-p : single password
-P : password list file
-t : tasks (parallel connections)
-vV : verbose mode (show attempts)
-o : output file for successful logins
Example brute-forcing SSH:
hydra -l admin -P /usr/share/wordlists/rockyou.txt 192.168.1.100 ssh -t 4 -vVFor HTTP POST forms, use the http-post-form module with a specific format:
hydra -l user -P pass.txt target.com http-post-form "/login.php:user=^USER^&pass=^PASS^:F=incorrect" -t 64^USER^ and ^PASS^ are placeholders.
F=incorrect defines a failure string from the response.
Optionally S=success for success string.
Interaction with Related Technologies
Hydra often works in conjunction with other tools:
- Wordlists: Commonly used with rockyou.txt, SecLists, or custom lists generated by crunch or cewl.
- Proxies: Use -E to exit if no proxy works, or -P for proxy list (HTTP/SOCKS). Hydra can route traffic through proxies to avoid IP blocking.
- Password Spraying: Hydra can be used for password spraying (one password against many usernames) by swapping -l and -p options.
- Service Enumeration: Before brute-forcing, use nmap or medusa to identify running services and versions.
Advanced Usage
Resume: Use -R to restore a previous session if Hydra was interrupted.
SSL: Add -S to force SSL connection (e.g., HTTPS).
IPv6: Use -6 for IPv6 targets.
Custom Module: Hydra allows writing custom modules in C.
Limitations and Detection
Hydra's traffic is easily detectable by intrusion detection systems (IDS) due to rapid failed login attempts. It also triggers account lockouts if configured. To evade detection, pen testers may slow down attempts (-W), use proxies, or rotate user agents. Hydra does not bypass CAPTCHAs or multi-factor authentication.
Identify Target and Service
First, determine the target IP address and the service you want to brute-force. Use reconnaissance tools like Nmap to discover open ports and service versions. For example, `nmap -sV 192.168.1.100` might show SSH on port 22. This step is crucial because Hydra needs the correct service module and port. If the service runs on a non-default port, you must specify it with `-s`. Also, check if the service requires authentication over SSL (e.g., HTTPS) – use `-S` flag. Document the target's IP, port, and protocol to avoid misconfiguration.
Prepare Username and Password Lists
Create or obtain wordlists for usernames and passwords. Common lists include `/usr/share/wordlists/rockyou.txt` for passwords and custom username lists like `names.txt`. For targeted attacks, use information from OSINT to generate likely usernames (e.g., `admin`, `root`, `user`). Ensure the lists are in plain text, one entry per line. If you have a single username, use `-l`; for a list, use `-L`. Similarly for passwords. The quality of lists directly impacts success rate. For password spraying, use a single password with many usernames.
Construct Hydra Command
Build the Hydra command with necessary options. Example: `hydra -l admin -P rockyou.txt 192.168.1.100 ssh -t 4`. Choose an appropriate thread count (`-t`). For services with lockout policies, use `-t 1` to avoid locking accounts. Add `-vV` for verbose output to see each attempt. If the service uses a non-standard port, add `-s port`. For HTTP forms, use the `http-post-form` module with a string that includes the form path, POST data with `^USER^` and `^PASS^`, and failure/success indicators. Test the command first with a single attempt to confirm syntax.
Execute and Monitor Attack
Run the Hydra command and monitor output. Hydra will display each attempt if verbose mode is on. Watch for `[SUCCESS]` messages indicating found credentials. If no success after many attempts, consider stopping and adjusting strategy (e.g., different wordlist, lower threads, or add delays). Be aware of network conditions; timeouts may indicate the target is rate-limiting or blocking your IP. Use `-W` to add a wait between attempts (in milliseconds). If Hydra crashes or is interrupted, use `-R` to resume from the last state.
Analyze and Document Results
Once Hydra completes, collect the successful credentials. They are printed to stdout and optionally saved to a file with `-o`. Verify the credentials by manually logging in. Document the findings, including the username, password, target, service, and any observations like account lockout behavior. In a pentest report, include the risk level and recommendation (e.g., enforce password complexity, implement MFA). If no credentials were found, note that the attack was unsuccessful but the service is exposed to brute-force – recommend rate limiting or account lockout.
In enterprise environments, Hydra is used during internal penetration tests to assess the strength of domain user passwords. For example, a tester may target a domain controller's SMB service with a list of usernames gathered from LDAP enumeration. The command hydra -L users.txt -P rockyou.txt 192.168.1.10 smb -t 1 -vV runs slowly to avoid locking out accounts. The tester might also use password spraying with -p Spring2024! -L users.txt to test a common password. Another scenario is testing web application login forms. For a corporate portal, the tester uses http-post-form module with a custom failure string like "Invalid username or password". They set -t 16 for speed, but if the app has CAPTCHA, Hydra fails – so they first check for CAPTCHA. Misconfigurations often occur when testers forget to specify SSL for HTTPS, causing failures. Also, using too many threads can crash older web servers or trigger WAF blocks. Performance-wise, Hydra can handle thousands of attempts per minute on a local network, but over VPN or with high latency, -w timeout adjustments are needed. Common issues include incorrect failure string detection – if the server returns different error messages for valid vs invalid usernames, the tester must adjust the F= pattern. In cloud environments, source IP rotation via proxies is essential to avoid being blocked by AWS WAF or Azure AD Smart Lockout.
The PT0-002 exam tests Hydra primarily under Objective 5.1 (Tools & Scripts) and indirectly under 3.1 (Credential Attacks) and 3.2 (Exploitation). Expect questions that require you to interpret a Hydra command or choose the correct syntax for a given service. Common wrong answers include:
1. Confusing `-l` and `-L`: Candidates often mix up single username (-l) with username list (-L). The exam will present a scenario with a list of usernames – the correct option uses -L.
2. Forgetting the service module: For HTTP form attacks, the module is http-post-form, not http-get-form or http. The exam tests the exact module name.
3. Incorrect failure string format: The F= parameter must match the exact text from the server response. Candidates may choose an option that uses S= for failure or omits the colon-separated format.
4. Ignoring SSL: When targeting HTTPS, the -S flag is required. A distractor option will omit it.
5. Thread count impact: The exam may ask about account lockout – the correct answer is to reduce threads (-t 1) or add delays (-W).
Key numbers: Default threads = 16, default timeout = 30 seconds. The -s flag specifies port, -o for output file. Edge cases: Hydra does not support NTLM hashes directly (use -m with specific module like smbnt). The exam may ask about resuming sessions with -R. Also, Hydra can use proxy lists with -P (capital P) – careful not to confuse with password list -P. To eliminate wrong answers, understand the underlying mechanism: Hydra sends network packets; it doesn't crack local hashes. If the question involves local password cracking, the answer is likely John the Ripper or Hashcat, not Hydra.
Hydra is an online brute-forcing tool; use it against live services, not local hashes.
Use -l for single username, -L for username list; -p for single password, -P for password list.
Default thread count is 16; reduce to 1 for services with account lockout policies.
For HTTP POST form attacks, use the http-post-form module with format: /path:params:F=fall_string.
Use -S for SSL-enabled services (e.g., HTTPS).
Use -o to save successful credentials to a file.
Hydra can resume an interrupted session with -R flag.
Common wrong answer: confusing -l and -L; always check if the scenario uses a list or single value.
Hydra does not bypass CAPTCHA or MFA; it only tests password strength.
On the exam, know that Hydra is for online attacks, John/Hashcat for offline.
These come up on the exam all the time. Here's how to tell them apart.
Hydra
Supports over 50 modules including SSH, FTP, HTTP, SMB.
Default parallel tasks: 16 (configurable with -t).
Can resume interrupted sessions with -R.
Supports SSL with -S flag.
Output to file with -o.
Medusa
Supports fewer modules (around 20) but includes HTTP, FTP, SSH, etc.
Default threads: 5 (configurable with -t).
Does not have a resume feature.
Supports SSL via -m SSL option.
Output to file with -o.
Hydra
Online brute-forcing against live services.
Works over network protocols.
Requires wordlists and target service.
Can be detected by IDS due to traffic pattern.
Used for credential testing, not hash cracking.
John the Ripper
Offline password cracking of hash files.
Works on local hash dumps (e.g., /etc/shadow).
Uses wordlists, rules, and incremental modes.
No network traffic; runs locally.
Used for cracking hashes obtained from compromised systems.
Mistake
Hydra can crack password hashes offline.
Correct
Hydra is an online brute-forcing tool that attempts authentication against live services. It does not crack hashes locally; that is done by tools like John the Ripper or Hashcat. Hydra sends login requests over the network and interprets responses.
Mistake
Hydra automatically handles rate limiting and account lockouts.
Correct
Hydra does not automatically detect or respect rate limiting or account lockouts. The user must manually configure thread count (`-t`) and delays (`-W`) to avoid triggering lockouts. Without adjustment, Hydra can lock out accounts quickly.
Mistake
The -l option is for a list of usernames.
Correct
The `-l` option is for a single username. To use a list of usernames, you must use `-L`. This is a common confusion point on exams. For example, `hydra -l admin -P pass.txt` uses one username; `hydra -L users.txt -p password` uses a list of usernames.
Mistake
Hydra can brute-force any service without a module.
Correct
Hydra requires a specific module for each protocol. It supports many but not all services. For example, there is no module for RDP by default (though third-party patches exist). Attempting an unsupported service will fail. Use `hydra -U` to list all available modules.
Mistake
The -P option specifies a proxy list.
Correct
The `-P` (capital P) option specifies a password list file. For proxy lists, you use `-P` as well? Actually, Hydra uses `-P` for password list and `-U` for proxy? No, proxy is `-P`? Let's clarify: In Hydra, `-P` is for password list, `-p` for single password. Proxy is specified with `-E` (exit if no proxy) or `-P` is not used for proxies. Actually, Hydra has `-P` for password list and `-U` for user list? No, `-U` lists modules. For proxies, use `-P`? I need to check. Actually, Hydra uses `-P` for password list, and for proxies you use `-P`? That would conflict. The correct is: Hydra does not have a built-in proxy list option in the same sense. You can use `-E` to exit, but proxies are configured via environment variables or command line? This is a misconception: the exam may test that `-P` is for password list, not proxy. So the myth is correct: some think `-P` is proxy, but it's password list.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Use the http-post-form module. The syntax is: `hydra -l username -P pass.txt target.com http-post-form "/login.php:user=^USER^&pass=^PASS^:F=Invalid"`. Replace ^USER^ and ^PASS^ with the actual form field names. The part after the colon is the POST data. The failure string (F=) is a text that appears on failed login. Optionally, add S= for success. Adjust threads with -t. For HTTPS, add -S.
No, Hydra only works with password-based authentication for SSH. If the server only allows key-based authentication, Hydra cannot brute-force it. You would need to obtain the private key file. For password-based SSH, use the `ssh` module.
Increase parallel tasks with -t (e.g., -t 64) but beware of overwhelming the target or triggering rate limiting. Also, use faster wordlists (e.g., smaller lists) or optimize network latency. If the target is remote, consider using a closer VPS. Alternatively, use password spraying instead of brute-forcing.
Use the -R flag to restore the previous session. Hydra saves state in a file (by default `hydra.restore`). Run the same command with -R appended: `hydra -l admin -P rockyou.txt 192.168.1.100 ssh -R`. It will skip already tried combinations.
Yes, use the -6 flag to enable IPv6. Example: `hydra -6 -l admin -P pass.txt [::1] ssh`. The target must be reachable over IPv6.
Both are parallel brute-forcing tools. Hydra has more modules (50+ vs ~20), supports session resume, and is more actively maintained. Medusa is simpler but faster for some protocols. Hydra is more commonly used in pentesting and on the PT0-002 exam.
Hydra does not have a native RDP module. However, there are third-party patches or you can use other tools like Crowbar or ncrack. The exam does not test Hydra for RDP.
You've just covered Hydra for Credential Brute-Forcing — now see how well it sticks with free PT0-002 practice questions. Full explanations included, no account needed.
Done with this chapter?