Definition
Brute force is systematically guessing a password, PIN, or key through repeated attempts, rather than looking it up. It’s the older, simpler sibling of credential stuffing: brute force tries combinations it has never confirmed are real; credential stuffing replays combinations it already knows worked somewhere else. Both end the same way: an authentication system granting access it shouldn’t. But they get there differently, and that difference changes how each is detected and prevented.
What Makes It Work
The attack exploits two things working together: an authentication system that doesn’t sufficiently limit or slow repeated failed attempts, and a credential that falls inside a realistically guessable search space: a short PIN, a common dictionary word, or a vendor-shipped default that was never changed. Neither condition alone is usually enough; a weak password behind strict lockout controls, or unlimited attempts against a genuinely strong, unique password, both resist this attack in practice. What breaks, when both conditions align, is access control on the specific account or device being guessed against.
Where It Actually Shows Up
- Devices and services still running a vendor-shipped default credential that was never changed after deployment: routers, admin panels, IoT devices.
- Dictionary attacks trying common passwords and predictable variations against a standard login form.
- Targeted guessing informed by known personal details about a specific person (sometimes called credential guessing rather than pure brute force).
- API endpoints and secondary admin interfaces that were built without the same rate-limiting and lockout protections applied to the organization’s primary, more visible web login.
Why It Keeps Succeeding
Default credentials on deployed devices and services are extremely common in real environments and are rarely audited as a routine practice. Separately, authentication endpoints outside the obvious main login page (an internal API, a secondary admin panel added later) often don’t inherit the lockout and rate-limiting protections that were carefully built into the primary login, simply because nobody thought to apply the same standard everywhere authentication happens.
How to Detect It
- A high volume of failed authentication attempts against a single account, or from a single source, in a short time window is the clearest signal.
- Sequential or dictionary-pattern attempts (trying alphabetically ordered strings, or a known common-password list) are a distinguishable signature from normal human typos.
- Explicitly check authentication endpoints beyond the obvious main login page: internal APIs, admin panels, device management interfaces, since these are exactly where lockout protections are most often missing.
- Confirm whether a lockout or rate limit actually triggers under a real, controlled test, rather than assuming it does because it’s documented as a feature.
Impact by Scenario
| Scenario | Realistic impact |
|---|---|
| Device or panel still using an unchanged vendor default credential | Near-certain compromise: no guessing required once the default is known |
| Weak, common password with no account lockout | High likelihood of eventual compromise given enough attempts and time |
| Well-chosen, unique password with lockout/exponential backoff enabled | Attack becomes impractically slow; not a realistic path to compromise |
| API endpoint with no rate-limiting, regardless of password strength on the primary web login | The unprotected endpoint is the real exposure; the strong password on the main login is irrelevant if this door was never locked |
Why a Business Should Care
Brute force is one of the cheapest attack classes to prevent almost entirely (account lockout, MFA, and simply not shipping default credentials closes most of it), yet it remains one of the most common findings in real security assessments, precisely because the protection is assumed to already exist everywhere it needs to, and often isn’t checked on the interfaces that aren’t the obvious, primary login. The useful conversation with a client isn’t “do we have strong passwords,” it’s “have we actually verified lockout works, everywhere authentication happens, not just on the login page everyone remembers to secure.”
A Worked Example
(Generalized from common industry patterns. Company and identifiers below are invented.)
During an authorized assessment of Halvorsen Logistics’ internal network, a tester discovers a network-attached device management interface exposed on an internal subnet. The interface presents a standard login form. A quick check against publicly documented default credentials for that class of device succeeds immediately. The device was deployed with its factory-default administrator password still active.
From that interface, the tester confirms read access to device configuration data, including network topology information that would meaningfully aid further lateral movement in a real attack. Testing stops at confirming this access; no further action is taken to change configuration or expand access beyond what’s needed to demonstrate the finding is real.
Severity Calibration
This finding rates Medium, reflecting real but bounded impact: the compromised interface exposed configuration and network information useful for further attack planning, but not direct access to customer data or critical business systems on its own. An identical default-credential finding on an internet-facing system, or one granting direct access to sensitive data, would rate meaningfully higher. The technique (guessing a known default) is trivial either way; the demonstrated reach is what actually sets severity.
Prevention & Response
The real fix is account lockout or exponential backoff after a small number of failed attempts, mandatory MFA, and a hard rule that no device or service ships or stays deployed with a default credential. Current password-length guidance (NIST SP 800-63B) also favors longer, unique passwords over composition-rule complexity.
The common inadequate fix is enforcing complex password composition rules (special characters, mixed case) without an actual lockout mechanism. Composition rules raise the guessing difficulty marginally; an unthrottled login endpoint means an attacker simply has more time, not that they’re stopped.
Related Attacks & Vulnerabilities
- Credential Stuffing: the related technique that replays already-known, real credentials instead of guessing new ones.