Brute force, password spraying and credential stuffing

Objective 4.2 in this course covers authentication attacks — CompTIA describes it as executing brute-force attacks, pass-the-hash and credential stuffing. This lesson takes the guessing attacks; lesson 26 takes credential replay. Runs against accounts you created, on the lab from lesson 2.

Why this matters

These three get conflated constantly and are examined as distinct things. They differ in what they vary, what they cost, and what they trip — and picking the wrong one is how a tester locks out a client's staff on the first morning.

The lesson

Why spraying beats brute force against lockout policies

The distinction is what you hold constant:

• Brute force fixes the username and varies the password. Many attempts against one account, which is exactly what lockout detects. Against any account with a lockout policy it locks the account and stops.
• Password spraying fixes the password and varies the username. One attempt per account, then the next password after a delay. Each account sees a single failure, staying under per-account thresholds.
• Credential stuffing varies both, using real username and password pairs from previous breaches, on the basis that people reuse passwords.

Spraying is the one that works against real organisations, and the reason is arithmetic: with a few hundred accounts and a handful of predictable passwords, the chance that somebody uses one is high, while no individual account sees enough failures to lock.

The passwords that work are seasonal, organisational and structural — the ones that satisfy a complexity policy in the most obvious way. That is the finding to write: the policy is being met without producing unpredictable passwords.

Credential stuffing, and the breach corpora that feed it

Stuffing works because password reuse is near-universal. Credentials exposed in someone else's breach are tried against the client, and some proportion work — because the same person used the same password at both places.

What makes it different from the other two:

• Every attempt is plausible, so the failure rate is far lower and the attempt volume needed is far smaller.
• It defeats complexity policies entirely. The password may be long and complex; the problem is that it is already public.
• It is unaffected by the client's own password history, since the reuse happened somewhere they do not control.

For a tester, the material comes from lesson 7's OSINT: which of the organisation's addresses appear in known breaches. Handling it is governed by lesson 4 — this is personal data about real employees, and it stays encrypted, minimal, and deleted on schedule. Naming individuals in the report needs the same restraint lesson 7 asked for.

The remediation that actually works here is not a stronger policy. It is multi-factor authentication, and checking new passwords against known-breached lists.

Rate, lockout and the outage you can cause

This is the professional risk, and it is bigger than most people expect.

• Locking out staff. A brute-force run against a real account list locks every account it touches. On a Monday morning that is an outage you caused, affecting people trying to work.
• Locking out service accounts is worse, because they are often used by applications and the failure surfaces as a broken system rather than a locked user.
• Triggering automated defence that blocks your source address, after which everything you do returns a uniform negative — lesson 19's truncation problem in a new setting.
• Filling authentication logs, with the same disk and platform consequences as lesson 8.

Before any of this runs on a client: know the lockout threshold and the observation window, agree the attempt rate in writing, exclude service and administrative accounts unless the scope names them, and have the client's help desk warned that lockouts may occur and who to call.

Running it against accounts you created, in your own lab

The exercise, on the lab from lesson 2, using a directory and accounts you built.

Set a lockout policy you know, then run each attack and watch what happens:

• Brute force one account. Count the attempts before it locks. That number is the policy, measured rather than read from documentation.
• Spray the same password across every account. Observe that nothing locks, and that one weak account is enough.
• Stuff a pair you planted as if it came from a breach corpus.

Then read the authentication logs for each. They look completely different, and being able to describe that difference is what makes the remediation in your report specific rather than generic.

What each one leaves in the authentication logs

The defender's half, and the reason the exercise ends by reading logs.

• Brute force: many failures on one account in a short window, then a lockout. The easiest of the three to detect, and most systems alert on it.
• Spraying: single failures spread across many accounts, each harmless in isolation. Invisible to per-account rules; visible only to something correlating failures across the whole directory in a time window.
• Stuffing: a low volume of attempts with an unusually high success rate, often from unfamiliar addresses. Detected by looking at successes, not failures.

The pattern worth carrying: the harder an attack is to detect, the more it looks like normal activity spread thin. A client whose monitoring only alerts on per-account thresholds is protected against the loudest attack and blind to the two that work, which is a finding in itself.

What to take into the exam

• Brute force varies the password against one account and trips lockout; spraying varies the account against one password and does not.
• Stuffing uses real breached pairs, defeats complexity policies, and is answered by multi-factor authentication and breached-password checks.
• These attacks cause outages: know the lockout threshold, agree the rate, exclude service accounts, and warn the help desk.
• Detection differs sharply — per-account rules catch brute force, spraying needs correlation across the directory, stuffing is found by looking at successes.