Credential Stuffing Attacks: A SOC Playbook for Investigation and Response

Credential stuffing is an automated attack where adversaries use username and password pairs stolen from previous data breaches to gain unauthorized access to target accounts. Because those credentials are real somewhere, a stuffing run against your identity provider generates alerts whether or not it works.

What follows is a SOC playbook for triaging and investigating the alert, including how to tell credential stuffing apart from password spray and brute force, the five signals that identify the pattern, and the six steps to run the investigation once one fires.

Most attempts fail because many of the credentials do not exist on the target system, are old, or get stopped by multi-factor authentication, but the high volume can be challenging. A burst can fail thousands of times and succeed once. That success is a distinct event with its own result code, and many detection sources raise a separate alert for it, so a query will find it. From there you must scope the full burst, establishing whether anything succeeded, and analyzing follow-on activity if there was a successful login.

Our guide to alert triage covers the general methodology. This is the identity-specific case.

{{ebook-cta}}

What separates credential stuffing from password spray and brute force

MITRE ATT&CK places credential stuffing at T1110.004. It is one of four sub-techniques under Brute Force (T1110), alongside password guessing (T1110.001), password cracking (T1110.002), and password spraying (T1110.003). MITRE's definition is narrow: adversaries use credentials obtained from breach dumps of unrelated accounts to gain access to target accounts through credential overlap. OWASP has a similar definition, determined by what the attacker is holding when the first attempt goes out.

What separates credential stuffing from other forms of brute forcing is the higher likelihood of the attacker having valid credentials in hands. Password re-use is a common issue and many people use the same password and identificator (their email address, for example) in multiple services. A breach in one of those services can provide attackers with multiple account/password combinations that are valid in many other places, making credential stuffing attacks more dangerous than other simple ways to brute force access.

How to identify a credential stuffing pattern

There are five things to look for that can help identify a credential stuffing attempt.

1. Error-code spread. A stuffing run works from a list assembled somewhere else. A share of the usernames in it will not exist in your directory. In Entra ID sign-in logs that produces 50034 (UserAccountNotFound) interleaved with 50126 (InvalidUserNameOrPassword). A password spray built from a harvested list of your real employees produces 50126 almost exclusively. Counting distinct error codes across the burst is the cheapest discriminator available, and many SIEMs (Elastic, for example) use this count in their detection logic.
2. Source distribution. Attempt volume per IP address stopped being a reliable signal once stuffing tooling moved onto residential proxy networks. OWASP recommends correlating authentication traffic against proxy and hosting-provider IP intelligence alongside counting requests per address, since IP blocking on its own is easy to circumvent. An operation of any sophistication spreads its attempts specifically to stay under per-address thresholds. OWASP also notes that device fingerprinting is client-supplied and can be spoofed, so a clean fingerprint is weak evidence rather than a clearance.
3. MFA outcomes. Entra codes 50076 (UserStrongAuthClientAuthNRequired) and 50079 (UserStrongAuthEnrollmentRequired) mark a sign-in that reached the MFA stage. Microsoft's password spray playbook tells defenders to record successful passwords alongside failed MFA responses, because that pairing indicates the attacker has the password but is not passing MFA. Confirm it in the sign-in's authentication details, where the primary-authentication step is recorded separately, rather than reading the error code alone. A validated password with no session attached justifies a reset regardless of what happened next. MFA use is often inconsistent and not enforced throughout the environment. Triggering a second authentication factor prompt can provide the attacker with a strong indication that those credentials are valid and may be accepted without MFA in another system in the same environment. It is also the precondition for an MFA fatigue escalation, where an attacker holding a working password starts pushing prompts until somebody approves one.
4. Provider-side signals, read with their stated limits. Okta ThreatInsight evaluates sign-in requests against aggregated data on potentially malicious IP addresses, covering credential-based attacks such as credential stuffing, password spray, and brute force. It has three settings: no action, log only, and log and enforce. Enforcement is graduated, so a low threat level may be rate limited rather than blocked outright. Okta states in its own documentation that it cannot guarantee 100% malicious IP address detection or 100% threat detection, so its silence is not evidence that nothing happened. The same caution applies to any provider-side detection, so treat a quiet feed as one input rather than as clearance. Your identity provider's own sign-in log carries more detail than the alert does. Working that log end to end is covered in our guide to investigating Okta sign-in alerts.
5. The single success. Everything above establishes that a pattern exists. One successful authentication inside the burst is the only event that changes the determination. It is also the event most easily lost when a high-volume alert gets closed on the strength of its failure ratio. Scope the burst first, then search for successful outcomes across the same account set and window before deciding anything.

Running the investigation

Many detection systems will look for the activity described above and generate alerts when those actions are detected. The sequence below assumes an authentication-anomaly alert has fired and you have the identity provider's log available.

1. Scope the burst. Pull every authentication event in the alerting window, not only the events for the alerting account. Record distinct accounts attempted, distinct source addresses, distinct error codes, total attempts, and the window's start and end. Then look at which accounts were hit. A run that lands on administrators, service accounts, or recently created accounts is a different problem from one that sprays the general population.
2. Classify the pattern and the infrastructure. Compare the account-to-credential ratio and the error-code spread against the three shapes above. Many accounts with mixed error codes and non-existent usernames points to credential stuffing. Many accounts with one error code points to a password spray. One account with many attempts points to brute force, or to a broken service integration, and the second possibility is common enough to rule out before escalating. Classify the source addresses at the same time: hosting provider, known proxy or VPN, residential, and which networks they sit on. Check whether those addresses or accounts already appear in other alerts from the trailing month.
3. Establish whether anything succeeded. Query for successful authentications across the same account set and window. Include successes from addresses that never produced a failure, since a stuffing operation often validates a pair on one node and uses it from another. Count MFA-blocked outcomes as partial success, because the password was valid.
4. Test any success against that account's own baseline. A successful sign-in inside a stuffing burst is not automatically the attacker. Compare it against the account's trailing history: the hours it normally signs in, the countries and addresses it normally comes from, the user agents and devices on record, and whether a managed endpoint exists at that address. Where the evidence stays ambiguous, ask the user. A one-line confirmation that they were travelling settles more of these than another query will.
5. Follow the session for persistence, not only for access. Where a sign-in succeeded, move from authentication to what the session changed: inbox rule creation, new MFA method registration, OAuth grant consent, refresh-token reuse, and access to file stores. Look specifically for changes that outlive a password reset, which is where these investigations most often stop too early. New accounts created, API tokens or app passwords issued, and any identity provider, federation, or SSO integration added to the tenant all survive the credential you are about to rotate. Check any geographic mismatch against the impossible travel alerts criteria. An inbox-rule change is the point where this becomes a business email compromise investigation rather than an authentication one.
6. Contain, trace the origin, then close the loop. Reset the credential and revoke active sessions and refresh tokens, then confirm that anything found in step 5 is actually gone. Trace where the pair came from, because breach-dump reuse, infostealer logs, and phishing harvesting imply different blast radius. Reuse from an unrelated breach puts every other system sharing that password in scope, and a phishing origin means the user interacted, so a stolen session cookie may be in play alongside it. Ask whether the targeted accounts should have existed at all, since these accounts are structurally harder to protect. CISA notes that service accounts have no human user behind them and so cannot easily be covered by MFA, and that attackers target dormant accounts belonging to people who have left the organization but whose accounts remain on the system. That is what we found while unmasking dormant and orphaned accounts in an acquired subsidiary's infrastructure. Then feed the error-code mix, the source categories, and the account population back into the detection as tuning inputs.

Why credential stuffing alerts get closed without investigation

Security teams often close these alerts without investigating because they have too many alerts and not enough time. A large SOC receives hundreds of alerts daily, and analysts can only investigate a small fraction of them. Since most authentication alerts are benign, they often get closed in bulk without a second look. If an attack fails 4,000 times but succeeds once, the high failure count makes the summary look safe, and that one success gets lost. Tuning the detection down just masks the problem. An account that stays compromised keeps whatever access it had, and the response then has to cover everything that access touched.

Why full investigations matter, and how to scale them

The work of classifying an authentication burst is procedural, tedious, and usually the first thing abandoned when alert volume spikes. Reading through an entire event sequence takes time, and the end result is almost always finding that nothing went wrong.

But skipping these checks is where the danger lies. What decides the outcome of a credential stuffing attack is whether the single successful login gets spotted and investigated. A high failure rate can easily mask a breach, and a team that lacks the capacity to review and connect these bursts carries nearly the same risk as one with no detections at all.

Automation is the only realistic way to close this gap. AI SOC analysts, like Prophet AI, handle this workload by running full, dynamically planned investigations on every alert regardless of severity. They scope the window, calculate error distributions, check for valid logins, and follow post-authentication sessions automatically, recording every piece of evidence along the way.

Request a demo of Prophet AI to see it in action.