Brute Force: The Least Clever Attack That Still Wins

A practical look at why brute force attacks still work in 2026, and where most of the real risk comes from.

Disclaimer: Educational content only. Brute forcing accounts you don't own is illegal and can DoS services. Test only on systems you own or have written authorization for. Be aware that most production systems have account lockout, you can lock out real users by accident.

Brute force is the attack everyone dismisses and nobody actually tests properly.

The logic goes: "modern passwords are long, rate limits exist, brute force is dead." And then a company gets owned because admin:admin was still set on an internal dashboard.

The truth is boring: brute force is not clever, but it's persistent. And most of the value doesn't come from guessing hard, it comes from the things people skip:

• Not checking default credentials
• Not reading the password policy
• Not building a target-specific wordlist
• Not checking whether a rate limit actually exists

This isn't a tool reference, the actual command syntax for hydra, medusa, ncrack, and legba for forty services is a click away on any cheat sheet. This is about how to think about credential attacks so you don't waste a week running rockyou.txt against a login page that was never going to work.

Step one: stop guessing and look up defaults

Before you brute force anything, check if the target shipped with default credentials.

Every appliance has them. Routers, NAS devices, CMS installers, CI/CD servers, monitoring dashboards, printers, IoT cameras. Developers install them for setup and then forget to change them.

Look up the product name and version in one of these:

• DefaultCreds-cheat-sheet (GitHub, ihebski)
• SecLists/Passwords/Default-Credentials/default-passwords.csv
• cirt.net/passwords
• many-passwords.github.io

I've seen internal admin panels on admin/admin in production environments, the app was "internal only" and the team assumed nobody could reach it. Internal networks leak. Default credentials are the cheapest win in the engagement.

Do this first. Before you write a single script.

Wordlists are the whole game

Here's the thing about brute force: rockyou.txt is a starting point, not a strategy. It's a leaked collection of passwords from 2009. Every rate-limited, correctly-configured target is immune to it. Every well-designed password policy defeats it.

What actually works is a target-specific wordlist.

Harvesting words from the target

cewl scrapes the target site and extracts words:

The -m 5 means minimum word length of 5. Shorter words are usually noise. Then mutate the output with leetspeak, case variations, and append years.

If the site has a lot of JavaScript, run tok over the JS URLs to pull identifiers, function names, and string constants:

And getjswords.py does the same thing for JS-specific content:

You'd be surprised how many password reset questions, internal project names, and API keys leak through JS comments.

Building from what you know about the victim

CUPP generates passwords from personal information — names, dates, pets, teams, cities:

python3 cupp.py -i

If the target's main page says "Founded by Jane Doe in Madrid, 2018, big fan of Real Madrid," you now have material. If there's an HR page with employee names, cross-reference with LinkedIn for personal details.

This is OSINT feeding a wordlist. It's boring, it's manual, and it works.

Combining and mutating

Wister takes a set of seed words and generates all reasonable combinations:

The -c 1 2 3 4 5 controls combination depth. Ten seed words can produce tens of thousands of candidates, but they're all plausible candidates.

crunch generates patterns from a charset:

The -t flag uses placeholders:

• @ — lowercase alpha
• , — uppercase alpha
• % — numeric
• ^ — special characters

So, @@^^%% generates candidates that match a specific structure (capital letter, two lowercase, two specials, two digits). That's useful when you know a password policy and want to stay inside the accepted rules without generating 2^20 candidates.

Pre-built lists

Start from rockyou. Then layer in:

• SecLists (danielmiessler) - the canonical collection
• Kaonashi - modern password collection
• WordList - Compendium
• weakpass.com
• wordlists.assetnote.io - actually good for web content discovery, also has passwords
• hashkiller.io/listmanager

Don't use all of them together. Pick a set based on the target's apparent era and complexity. An old internal PHP app installed in 2015 is different from a modern SaaS product.

Spraying vs. brute force

This is where people get fired.

Brute forcing means trying many passwords against one account. Almost every login form has a lockout after 5 or 10 attempts. You will lock out real users. You will probably get caught.

Password spraying means trying one password against many accounts. It's designed to stay under lockout thresholds. The math:

• 5 attempts per user, 500 users
• Try Summer2024! against all 500
• Wait for the lockout window to reset
• Try Welcome1! against all 500

If even one user has a common password, you win. And you never tripped any single account's lockout.

Always spray, don't brute. The exception is when you're testing a single high-value account (like the admin) with a small, carefully-chosen password list, and you should confirm the lockout threshold before you do, ideally on a test account you control.

Does the rate limit actually exist?

Before you write a wordlist, test the rate limit.

Create a test account. Submit wrong credentials ten times. Then a hundred. Then a thousand.

Watch for:

• HTTP 429 - there's a rate limit. Note how many requests per window.
• CAPTCHA appears - you'll need to solve it, or wait.
• Account lockout - you can't spray this account anymore.
• Silent throttling - the server keeps returning "wrong password" but response times balloon. Check timing.
• No change at all - jackpot. The rate limit is client-side or nonexistent.

The last case is more common than you'd think on internal applications. Dev teams add a "forgot password" page and assume rate limiting is a default of the framework. It's usually not.

If there is a rate limit, look for bypasses:

• Different IPs - only if authorized. Rotating IPs to bypass third-party controls is abuse, not testing.
• Different sessions - does the limit reset when you get a new session ID? If the session is clientcontrolled and unsigned, yes.
• Different user agents - sometimes the limit is per (IP, user-agent). Rotate the UA.
• Case variations - try Admin instead of admin. Some rate limiters key on exact username.
• HTTP method swaps - POST vs PUT, Content-Type: application/json vs form-encoded. Sometimes the limit is on one code path and not another.
• Timing windows - if the limit is per minute, spread attempts across the window.

The mass scanner playbook

This is the part I find genuinely interesting — how the industrial-scale brute forcers actually work.

A 2024 era piece of malware called GoBruteforcer was caught running an internet-wide scanning workflow. It's a good model for how automated credential attacks operate, because it's not clever — it's systematic.

Worker pools

It maintains a fleet of concurrent workers sized to the target architecture:

• 95 workers on x86_64 and arm64
• 85 on i686
• 35 on armv5tel
• 50 by default on anything else

Every second it checks the active worker count and spawns replacements to maintain the target. Each worker handles one target IP and then exits — no reuse of connections, no patterns for defenders to spot.

Target selection

It generates random public IPv4 addresses and filters them:

• Drops RFC1918 private ranges (10/8, 172.16/12, 192.168/16)
• Drops loopback (127/8), link-local (169.254/16), CGNAT (100.64/10)
• Drops benchmarking ranges (198.18/15)
• Drops multicast (>=224/4)
• Avoids cloud-heavy /8s (3, 15, 16, 56) — too noisy, too much detection
• Avoids DoD-associated /8s (6, 7, 11, 21, 22, 26, 28, 29, 30, 33, 55, 214, 215)

The logic is: avoid infrastructure that's likely monitored. Hitting AWS us-east-1 with thousands of login attempts gets you blocked in seconds. Hitting random residential ranges in smaller countries gets you a longer run.

Service probing before attacking

Before it tries to log in, it probes the service port with a short timeout (~2 seconds):

• FTP on port 21
• MySQL on port 3306
• PostgreSQL on port 5432
• phpMyAdmin over HTTP/80

If the port doesn't respond, it moves on. If it does, it starts cleartext login attempts.

If it can't fetch its credential list from the C2 server, it falls back to a small built-in list. Even malware has a fallback wordlist.

Exfiltration

Every successful hit fires an HTTP GET beacon to the C2:

Service codes are simple: 1 = phpMyAdmin, 2 = MySQL, 3 = FTP, 4 = PostgreSQL. The browser User-Agent is standard Chrome, so the traffic blends into normal web noise.

The phpMyAdmin spray is particularly sophisticated:

1. It tries about 80 common paths with GET /index.php?lang=en.
2. It detects PMA markers: pmahomme theme references, phpmyadmin.css, navigation.php.
3. It parses codemirror.css?v=X.Y.Z to figure out the version.
4. Versions < 4.9 accept GET params pma_username / pma_password.
5. Versions >= 4.9 use POST with server=1, a CSRF token, and the same credentials.

This matters because most brute-force scripts assume one auth pattern. The good ones fingerprint the version and adapt.

What this tells you as a tester

If you're on the defensive side:

• Ports don't stay hidden. Random scanning finds you eventually.
• Rate limits on login endpoints are table stakes. Without them, you're in the pool.
• phpMyAdmin at a guessable path with no rate limit is a target. Either move it, or rate-limit it, or both.
• Short timeouts on connections matter less than you think. A 2-second probe is enough to fingerprint a service.

If you're on the offensive side (in an authorized engagement):

• Fingerprint the version before you script the spray. The auth flow is different across versions.
• Probe before you spray. No point in exhausting a rate limit against a closed port.
• Understand the detection surface. If you're doing it right, you should be able to explain why a defender might see you and what they'd see.

Service-specific notes

The full command for every service is in any cheat sheet. Thematically, here's what actually matters:

• SSH / FTP / RDP / Telnet - same logic. Hydra, medusa, ncrack, legba all work. The differences are in lockout behavior, which varies wildly by config. Test one account at a time to find the threshold.
• MySQL / PostgreSQL / MSSQL - lockout is less common than you'd hope. MSSQL sometimes locks domain accounts; local accounts often don't. Be careful with ms-sql-brute against domain-joined hosts.
• SMB - try Administrator with a small password list first. legba smb or hydra -l Administrator … smb — t 1 (the -t 1 is important, parallel SMB auth triggers account lockouts).
• SNMP - this is community-string guessing, not password guessing. Common strings: public, private, manager, plus anything in the target's environment. onesixtyone with the default community list, or hydra — P community-strings.txt … snmp.
• JWT - not really brute force, but people lump it in. hashcat -m 16500 -a 0 jwt.txt wordlist.txt cracks weak JWT HMAC secrets. If the JWT secret is secret or password, you can forge any token.
• VNC - usually no lockout. hydra -s … vnc or nmap — script vnc-brute.
• Redis / MongoDB / Elasticsearch - these often have no authentication at all. Before you brute force, just try to connect. nmap -sV — script redis-info -p 6379 is faster than running hydra against a service that never asked for a password.
• ZIP / PDF / Office files - offline cracking is different. zip2john + john or hashcat -m 13600 for ZIP, and similar for the others. Rockyou still works here, these are usually files from before password managers became standard.

The thing about online hash cracking

For every hash you can't crack locally, there's a website that's already tried.

• crackstation.net - free, huge rainbow tables
• hashkiller.io - MD5, NTLM, SHA1, MySQL5, SHA256, SHA512
• md5decrypt.net , cmd5.org , md5online.org - smaller but fast
• hashes.org - searchable database
• gpuhash.me - for longer cracks
• onlinehashcrack.com - also does WPA2 captures and Office files

Before you spin up a GPU cluster, paste the hash. Fifty percent of the time, it's already cracked.

For NTLM/NetNTLMv1 with custom challenge-response, shuck.sh handles the ESS/SSP variations that break most tools.

The checklist

Order I go in:

1. Look up default credentials for the target product/version. Always first.
2. Check for unauthenticated access. Redis, Mongo, Elastic, phpMyAdmin without password, often no brute force needed.
3. Probe the rate limit. Create a test account, submit 10/100/1000 failures, watch for 429, CAPTCHA, lockout, or nothing.
4. Look for rate-limit bypasses. New sessions, different user agents, different verbs, different content types.
5. Build a target-specific wordlist. cewl , JS harvesting, CUPP, Wister.
6. Spray, don't brute. One password, many accounts, stay under lockout.
7. Pick the right service flow. Fingerprint the version first (phpMyAdmin = 4.9 is the classic example).
8. Cache what the service returns. CSRF tokens, nonces, session IDs — reuse them properly.
9. Document the lockout threshold so you don't brick the account.
10. Move on if there's a real rate limit and no bypass. Brute force without a bypass is just denial of service.

The thing to remember

Brute force is not a technical attack. It's a discipline attack.

The value isn't in a clever payload or a fast GPU. It's in the operations that most testers skip:

• Checking defaults first
• Reading the password policy
• Building a target-specific list instead of running rockyou
• Understanding the lockout threshold before you trip it
• Spraying instead of brute-forcing
• Fingerprinting the version before you automate

The industrial scanners do all of this. That's why they work. They're not smarter than you, they just don't skip steps.

And on the defensive side: if a login endpoint has no rate limit, no lockout, and default credentials, no amount of "we're internal" changes the outcome. Someone with a VPS and a wordlist will find it.

Test on your own systems. Be aware of lockout risk. Never run internet-wide scans — that's abuse, not research. And when you find weak credentials, report them as critical, because that's what they are.

Thanks for reading. If this was useful, Raksharoot has more where this came from.