Credential attacks, and the controls that end them

Objective 2.5 asks you to analyse indicators of malicious activity. This lesson takes the attacks on credentials: guessing them, finding out which accounts exist, reusing what has been stolen, and getting past multifactor authentication. Each is presented as what it looks like from the defender's side and which control actually closes it.

Why this matters

Stolen and guessed credentials are the most common way into an organisation that does not involve a software vulnerability at all. An attacker who signs in does not need to break in, and everything they do afterwards looks like a user doing their job. The exam knows this and asks about these attacks repeatedly — here as indicators, and in Domain 4 as authentication controls and as entries in a log.

The reason to learn them together is that each one is closed by a different control, and the favourite question shape is to describe an attack and offer four plausible controls, only one of which addresses it.

The lesson

Spraying versus brute force, and which one your lockout policy stops

Both are guessing. The difference is which axis they iterate on, and it decides everything about detection.

Brute force takes one account and tries many passwords. Traditional lockout policy — a handful of failures and the account locks — stops it, because the attacker exhausts the allowance on the first account. In a log it looks like a burst of failures against a single username.

Password spraying takes one password — a common or seasonal one — and tries it against many accounts. Each account sees one or two failures, under the lockout threshold, so lockout never triggers. In a log it looks like a low rate of single failures spread across hundreds of usernames, often from a small set of sources, often at a steady interval.

That is the point of the technique: it is designed around the control most organisations have. Detecting it means looking at the aggregate — failures per source, or per time window across all accounts — not per account. It is one of the clearest cases where the right answer is a monitoring change rather than a policy change.

Two relatives. A dictionary attack is brute force using a list of likely passwords instead of every combination. Credential stuffing reuses username and password pairs stolen from another breached service. Stuffing shows up as a high proportion of successful logins from unusual sources, because the credentials are real — so nothing that counts failures will catch it.

If an attacker steals the stored password hashes, guessing moves offline, onto their own hardware, where there is no lockout and no alert. That is why storage matters: unique salts defeat precomputed tables, deliberately slow hashing algorithms make each guess expensive, and MFA means a cracked password is not enough on its own.

User enumeration, and the login page that confirms which accounts exist

User enumeration is discovering which usernames are valid. It sounds minor and it is not: it turns a spraying or phishing campaign aimed at guesses into one aimed at real people, and confirms the naming pattern for every other account.

The application leaks the answer in small ways:

• a login page that says "no such user" for one name and "wrong password" for another;
• a password reset form that says "we've sent you an email" only when the account exists;
• a sign-up page that reports an address is "already registered";
• a response that is measurably slower for real accounts, because the system checked a password it would not check for a missing user.

Indicators: many sign-in or reset attempts for different usernames, a high proportion of them for names that do not exist, often in alphabetical or patterned order. Controls: return the same message and the same timing whether or not the account exists ("if that account exists, we've sent an email"); rate-limit sign-in, reset and sign-up endpoints; add a challenge after repeated attempts; and alert on volumes of failures against non-existent accounts, which no legitimate user generates.

Credential replay, and why a stolen hash or token is as good as the password

Replay is reusing a captured authentication artefact rather than the secret behind it. The credential, from the system's point of view, was never the password; it was whatever the protocol accepts.

• Hashes. Some authentication protocols accept a password hash directly, so an attacker who extracts one from a compromised machine can authenticate as that user without ever learning the password. This is pass-the-hash.
• Tickets and tokens. Single sign-on issues tickets and tokens that prove a user already authenticated. Steal one and you are that user until it expires.
• Session cookies. A browser session cookie is issued after MFA, so replaying it skips both the password and the second factor. Information- stealing malware collects them in bulk.
• Captured exchanges. An authentication captured on the network and played back unchanged, if the protocol does not prevent it.

The defence is freshness and binding: nonces, timestamps and sequence numbers so a captured exchange is not valid twice; short token lifetimes; sessions bound to a device; and re-authentication for sensitive actions. Limit where privileged accounts sign in so their hashes and tickets are not left on ordinary workstations, and use operating system protections that isolate stored credentials. Indicators: a session or token appearing from a new address or device while the user is still active elsewhere, and older authentication protocols in use where modern ones are expected.

MFA bypass: fatigue prompts, relayed codes and the fallback that undoes the factor

MFA stops most credential attacks, so attackers have learned to go around it rather than through it:

• MFA fatigue (push bombing) — repeated approval prompts until the user accepts one to make them stop, often combined with a call from "IT" telling them to approve it. Indicator: a burst of denied push requests followed by an approval.
• Relayed codes — a phishing page sits between the user and the real site, passing the password and the one-time code through in real time and keeping the session cookie that results. The user completed MFA; the attacker got the session. Indicator: a successful sign-in, with MFA, from infrastructure the user has never used.
• Weak channels — codes sent by text message can be intercepted by taking over the phone number at the mobile carrier (SIM swapping).
• The fallback — if a user can bypass the strong factor with a text message, security questions or a help desk call, the strong factor is only as strong as that fallback. Enrolment of a new device is the same weak point.

Controls: phishing-resistant MFA — passkeys and hardware security keys whose response is tied to the real site's address, so a relay page receives nothing it can use; number matching and context in push prompts, so a blind approval is impossible; removing or hardening fallbacks; verifying identity properly before resetting or enrolling a factor; and alerting on MFA method changes and on bursts of denied prompts.

The control that answers each: length, phishing-resistant MFA, lockout and monitoring

Two points worth carrying. Length beats complexity: current guidance favours long passphrases and banned-password lists over forced symbol substitution and frequent expiry, which push users toward predictable patterns. And monitoring appears again and again, because several of these attacks succeed by staying under per-account thresholds or by producing successful logins. Domain 4's authentication lesson covers the controls in depth.

What to take into the exam

• Lockout stops brute force and does nothing against spraying; spraying is detected in aggregate.
• Credential stuffing produces successful logins, so failure-counting misses it.
• User enumeration is closed by identical responses and timing for real and unknown accounts.
• A stolen hash, ticket or session cookie is a credential; freshness, short lifetimes and binding are the answers.
• MFA bypass targets the user, the relay or the fallback. Phishing-resistant MFA defeats relays; number matching defeats blind approvals.