SSH is the most commonly tested Hydra target on the CEH practical exam. The exam expects students to know the basic syntax and understand that SSH rate-limits by default — keeping thread count low (-t 4) prevents connection errors and false negatives caused by overwhelming the daemon.

# Single username, password wordlist:
hydra -l admin -P /usr/share/wordlists/rockyou.txt ssh://192.168.1.100 -t 4
[22][ssh] host: 192.168.1.100  login: admin  password: password123

# Username list + password list (tests all combinations):
hydra -L users.txt -P passwords.txt ssh://192.168.1.100 -t 4 -f
# -f stops immediately after first valid pair — saves time in exams

SSH is designed to slow down repeated failed attempts through exponential backoff — each successive failure from the same source takes longer to respond. This is why thread count matters: too many parallel threads overwhelm the service and produce unreliable results. Four threads is a conservative and reliable setting for SSH.

FTP brute forcing tests knowledge of the protocol flag syntax. FTP typically tolerates higher thread counts than SSH because it has simpler connection handling. The CEH exam may present FTP services running on non-standard ports, so knowing the -s port flag is useful.

# Standard FTP (port 21):
hydra -L users.txt -P passwords.txt ftp://192.168.1.100 -t 8
[21][ftp] host: 192.168.1.100  login: deploy  password: dep2024!

# Non-standard port:
hydra -l admin -P rockyou.txt ftp://192.168.1.100 -s 2121

Web login forms require Hydra to understand the form structure: the URL path, the parameter names, and crucially — what a failed login looks like (the failure string). Hydra classifies each attempt as a failure if the response contains that string. If it's absent, the attempt is a success. Getting the failure string right is the most common source of false positives in HTTP form testing.

The failure string concept: Think of it like watching for a specific rejection letter. If every failed login says "Invalid credentials" and a successful login shows the dashboard, Hydra watches for the absence of "Invalid credentials" to know it found the right password. If you specify the wrong failure string, Hydra may report false positives or miss valid credentials entirely.

# Syntax: http-post-form "path:params:failure_string"
hydra -l admin -P rockyou.txt 192.168.1.100 \
  http-post-form "/login:username=^USER^&password=^PASS^:Invalid credentials"

# ^USER^ is replaced with each username attempt
# ^PASS^ is replaced with each password attempt
# "Invalid credentials" = the string that appears on failed login

# HTTP GET form (less common, same concept):
hydra -l admin -P rockyou.txt 192.168.1.100 \
  http-get-form "/login:user=^USER^&pass=^PASS^:Wrong password"

Both CEH and PenTest+ test knowledge of standard wordlists and when to use each. The exam expects familiarity with rockyou.txt as the primary starting point and SecLists as a curated collection for different scenarios. Understanding why rockyou.txt is effective — it comes from a real data breach and reflects actual human password choices — is as important as knowing the file path.

# RockYou — 14.3 million passwords from a real 2009 breach
# Most effective general-purpose starting point
/usr/share/wordlists/rockyou.txt

# SecLists — curated collection, context-specific lists
/usr/share/seclists/Passwords/Common-Credentials/10k-most-common.txt
/usr/share/seclists/Passwords/Default-Credentials/default-passwords.txt

# For known target patterns, a small targeted list outperforms large generic ones:
# Company2024!  companyname123  Company@1  [company]admin

The rockyou.txt wordlist's effectiveness comes from a key insight: it contains passwords real people actually chose. Human password selection is not random — it clusters around familiar words, names, dates, and simple character substitutions. A wordlist built from real breach data captures this human behaviour far more efficiently than a theoretically comprehensive character-space enumeration.

The CEH practical exam environment includes Windows services. RDP (Remote Desktop Protocol, port 3389) and SMB (port 445) are common targets. RDP brute forcing requires careful thread management — Windows will temporarily block sources that generate too many failed RDP attempts.

# RDP — keep threads very low, Windows rate-limits aggressively:
hydra -l administrator -P passwords.txt rdp://192.168.1.10 -t 1 -f

# SMB — Windows file sharing authentication:
hydra -l administrator -P passwords.txt smb://192.168.1.10

# View all supported service modules:
hydra -U smb  # service-specific help
hydra -h     # full help

Account lockout disables an account after a configurable number of consecutive failed login attempts (commonly 5-10). This is the most direct brute force countermeasure and is effective against targeted attacks on a specific account. However, it creates a secondary risk: an attacker who knows an organisation's lockout threshold can deliberately trigger lockouts on all accounts, creating a denial-of-service condition for legitimate users without ever finding a valid credential.

This tradeoff — lockout stops brute force but enables DoS — is a classic security design tension, and understanding it is CEH exam content. The partial solution is "soft lockout" (temporary lockout with automatic unlock after a period) rather than permanent lockout requiring admin intervention.

Rate limiting restricts how many login attempts can be made within a time window from a single IP address. Rather than locking accounts, it limits the attacker's throughput — making a brute force attack take months instead of hours. At 1 attempt per second per IP against a 14-million-entry wordlist, completion would take 162 days. Against even a small 1,000-password targeted list, rate limiting to 1 attempt per 30 seconds makes the attack take 8.5 hours — still manageable, but far slower.

CAPTCHA breaks the automation assumption: it requires demonstrating human cognition, which automated tools cannot do reliably. When combined with rate limiting, these controls make online brute force impractical against most web applications.

MFA renders online brute force attacks pointless against services where it is enforced. Even if an attacker successfully identifies a valid username and password, a second factor — TOTP code, push notification, hardware key — cannot be enumerated via Hydra. The attack finds a correct credential but cannot use it.

This is why MFA is the single most impactful authentication security control. It doesn't prevent the credential from being guessed — it prevents that credential from being sufficient for authentication. From a threat modelling perspective, MFA changes the attack from "find the right password" to "find the right password AND intercept the second factor simultaneously" — a dramatically harder problem.

Intrusion Detection Systems can identify brute force attacks by their characteristic signature: many failed authentication attempts from a single source IP in a short time window, targeting the same account or cycling through many accounts. Hydra's default behaviour — 16 threads generating dozens of attempts per second — is highly visible in logs and to network monitoring tools.

The thread count flag (-t) directly affects detectability. Reducing threads slows the attack but makes it less distinguishable from legitimate failed login patterns. This tradeoff between speed and stealth is a recurring theme in penetration testing methodology and appears in both CEH and PenTest+ exam content.

Consider a hypothetical where a company exposes SSH directly to the internet on port 22 with no IP allowlisting. Their account lockout policy locks accounts after 5 failed attempts, requiring admin reset. An attacker discovers the server and begins a brute force attempt targeting the admin account.

Before finding the password, the attacker triggers the lockout threshold. The admin account is locked. The legitimate administrator — working from home — cannot SSH into the server to respond to an unrelated production issue. The lockout policy intended to prevent compromise has inadvertently created an availability incident. The attacker didn't gain access, but they disrupted operations effectively.

This scenario illustrates the DoS-via-lockout attack vector and explains why security architects often prefer rate limiting over hard lockout for externally-facing services. It also demonstrates why SSH should not be exposed to the internet without IP allowlisting or fail2ban-style auto-blocking.

A network engineer at a growing company deploys twenty new managed switches and configures them for their environment, but forgets to change the default Telnet management credentials on six of them. These switches are accessible from the management VLAN, which is reachable from the corporate network.

During a penetration test, the assessor scans the management VLAN, identifies the Telnet services, and tests a small list of common default credentials. All six switches authenticate with documented default credentials within seconds — no wordlist required. The assessor gains full management access to core network infrastructure without triggering any lockout or alert, because the "attack" was indistinguishable from legitimate management traffic.

This scenario explains why default credential testing is always the first step before a full wordlist attack, and why it appears on both CEH and PenTest+ exam objectives. Default credentials represent the least technical, highest-yield finding in network assessments — requiring no cracking, no wordlists, and no sophistication.

A small e-commerce company builds a customer portal with a login form. The developer implements no rate limiting and no lockout policy — they're concerned that lockouts might frustrate legitimate customers who mistype their passwords. The login form simply accepts unlimited attempts.

From a theoretical standpoint, this means the authentication surface accepts any number of credential guesses per unit time, limited only by network bandwidth. The application essentially provides no resistance to automated credential testing beyond the time required to process each attempt. Any account whose password appears in a common wordlist is therefore testable without any technical bypass — the absence of controls is itself the vulnerability.

The security implication is a reminder that authentication controls are not a single feature — they're a layered system. Password strength, rate limiting, lockout policy, MFA, and monitoring each address a different dimension of the threat. An application that implements only one of these layers has meaningful gaps in its security posture.