A brute force attack is when software automatically tries password after password, username after username, or key after key. It keeps guessing against a login or an encrypted file until one combination succeeds. It’s not clever. It doesn’t need to be. Automation and cheap computing power mean an attacker can burn through millions of guesses without ever exploiting a single bug.
Why does such a simple technique still work?
Because the weak point isn’t the software, it’s the password. As long as people choose short, predictable or reused passwords, guessing at scale keeps paying off. Dictionary attacks prove the point: they test real words and previously breached passwords before anything random. They succeed as often as they do because human-chosen passwords are far less random than we like to think.
The other reason it persists is access to tooling. Hydra and Medusa automate guessing against live services like SSH, RDP and web logins. Hashcat and John the Ripper do the same job offline against stolen password hashes. They use GPU power to test candidates at a rate no human attacker ever could. Burp Suite’s Intruder module runs the same kind of attack against web applications during authorised testing. None of these require custom development. They’re free, documented, and, used with permission, legitimate parts of a penetration tester’s kit. Several appear in our roundup of popular penetration testing tools in Kali Linux.
Online versus offline: why speed changes everything
An online brute force attack guesses against a live login page. Network latency and any rate limiting the target has in place slow it down. An offline attack is a different game entirely. Once an attacker has a copy of a password hash, cracking happens on their own hardware with no target-side limits at all. That’s why an eight-character, lowercase-only password, roughly 209 billion possible combinations, can fall in hours offline. The same password would take a login form with basic lockout protections far longer to yield online.
Length closes that gap faster than complexity does. Every additional character multiplies the search space. Adding symbols and capitals only multiplies it by a small, fixed factor. NIST’s digital identity guidelines reflect this directly. They set an eight-character minimum for user-chosen passwords. They also recommend against forcing complexity rules or routine expiry, since those requirements tend to produce weaker, more guessable passwords in practice.
The variants worth knowing by name
Not every brute force attack looks the same, and the variants matter because they evade different defences:
- Dictionary attacks test known words and leaked passwords before random combinations.
- Hybrid attacks bolt predictable variations onto dictionary words, like turning “welcome” into “Welcome2026!”.
- Password spraying (sometimes called reverse brute force) tries one or two common passwords across thousands of usernames. It deliberately stays beneath any single account’s lockout threshold rather than hammering one account repeatedly.
- Credential stuffing skips guessing entirely and replays real username and password pairs stolen in an unrelated breach. It’s covered in more depth in our guide to detecting credential stuffing attacks, since spotting it takes different signals than spotting classic guessing.
What it looks like when it actually happens
Two incidents show how far brute forcing scales in practice. In 2021, the NSA, CISA, the FBI and the UK’s NCSC jointly attributed a sustained, global brute force campaign to Russia’s GRU military intelligence. The operation ran through a Kubernetes cluster, which let it distribute and anonymise password-guessing attempts against hundreds of government, defence, energy and education-sector targets. From there it pivoted into networks using stolen credentials and known Microsoft Exchange flaws.
T-Mobile’s case was smaller but very public. CEO Mike Sievert confirmed in 2021 that an attacker who had reached the company’s servers then used “brute force attacks to access the databases.” The breach ultimately exposed data on 54.6 million customers. Our report on the T-Mobile incident has the full timeline. Neither case needed a novel exploit. Both needed only patience, automation and a weak point in credential hygiene.
A practical checklist for defenders
- Cap failed login attempts and add progressive delays or CAPTCHAs after repeated failures, following NIST’s throttling guidance. Don’t lock out legitimate users on a single mistyped password.
- Enable multi-factor authentication everywhere it’s supported. Microsoft’s own security data shows MFA blocks over 99.9% of automated account compromise attempts. It’s the single biggest lever most organisations can pull.
- Push for length over complexity in password policy, and support a password manager so “long and unique” doesn’t mean “unmemorable.”
- Monitor across accounts, not just per account. A spraying campaign spreads thin across your user base and can slip past individual lockout thresholds unnoticed.
- Reduce exposed surface. Close or restrict internet-facing SSH and RDP, disable unused authentication endpoints, and patch the services that remain. Our Linux server hardening guide sets out where to start.
Two myths that make brute force attacks worse
The first myth is that a “complex enough” password with a symbol and a capital letter is automatically safe. It isn’t, if it’s short. Complexity rules multiply the search space by a small factor. Length multiplies it exponentially, which is exactly why current guidance leans so hard on long passphrases over short, symbol-stuffed ones.
The second myth is that account lockouts are a complete defence. They stop naive attacks against one account well. But they were never designed to catch password spraying, which spreads a small number of guesses across thousands of accounts specifically to stay under that threshold. Treating “we have a lockout policy” as the end of the conversation is how spraying campaigns go unnoticed for months.
Frequently asked questions
What’s the difference between a brute force attack and a dictionary attack?
A dictionary attack is one type of brute force attack. Pure brute forcing tries every possible combination. A dictionary attack narrows the search to real words and previously breached passwords first, which usually finds a working password much faster.
Can rate limiting alone stop a brute force attack?
It slows online attacks significantly. But it won’t stop an offline attack against a stolen password hash, and it doesn’t reliably catch password spraying, which is designed to stay under per-account thresholds. It’s one layer among several, not a complete fix.
Is it illegal to run brute force tools?
Owning tools like Hydra, Hashcat or Burp Suite is not illegal. They’re standard penetration testing software. Using them against a system without the owner’s explicit authorisation is.
How would I know if my organisation is being targeted?
Look for spikes in failed logins, or authentication attempts spread across unusually many usernames from one source. Watch too for successful logins right after a run of failures from an unfamiliar location. Centralised log monitoring catches patterns individual account lockouts miss.
Does a password manager actually help against this?
Yes, in two ways. It makes long, unique passwords practical to use everywhere, and it removes the temptation to reuse a password across sites. That reuse is precisely what makes credential stuffing effective after any one site gets breached.
Do CAPTCHAs actually stop automated guessing?
They raise the cost of an attack rather than blocking it outright. Basic CAPTCHAs can be solved by cheap human-solving services or increasingly capable automated solvers. They work best as one layer alongside rate limiting and MFA, not as a standalone defence.