Threats

T1110

Credential Stuffing

How credential stuffing differs from brute force attacks, where attackers source billions of credentials, and how analysts detect and stop automated login floods.

View on Graph

What It Is and How It Differs From Brute Force

  • Credential stuffing is the automated injection of stolen username and password pairs into login forms to gain unauthorized access to user accounts.
  • MITRE ATT&CK maps credential brute forcing and stuffing to T1110 (Brute Force) with sub-techniques: T1110.001 (Password Guessing), T1110.003 (Password Spraying), and T1110.004 (Credential Stuffing).
  • The critical distinction: brute force (T1110.001) tries many passwords against one account.
  • Password spraying (T1110.003) tries one or two passwords against many accounts.
  • Credential stuffing (T1110.004) tries known-valid credential pairs across many accounts — the attacker already has the right username and password, they just need to find where it works.

Detection Workflow — Credential Stuffing Triage

Step 1: Identify the Attack Signature

Credential stuffing produces a distinctive pattern in authentication logs. Unlike brute force (many passwords, one user) or password spraying (few passwords, many users), stuffing generates:

  • High volume of authentication attempts per second from a distributed IP range
  • Each attempt uses a unique credential pair — username:password combinations that are not obviously related
  • Success rate is low but non-zero — usually 0.1% to 2% of attempts succeed
  • Failed attempts are “valid credentials but wrong target” — Windows Event ID 4625 with Sub Status 0xC000006D (bad username or password) or 0xC0000064 (user name does not exist) — the system rejects the pair not the password
  • Successes are immediately followed by resource enumeration — a successful credential stuffing login is often followed by checking the mailbox, accessing cloud storage, or probing what else the account can reach

Step 2: Collect and Correlate Log Sources

QuestionWhich Source to Check
Who is logging in and failing?Windows Event ID 4625 (failed logon), CloudTrail ConsoleLoginFailure, SaaS app audit logs
Who is logging in successfully?Windows Event ID 4624 (successful logon), CloudTrail ConsoleLogin, SignInLogs in Azure AD
How many attempts per source IP?Firewall logs, WAF logs, reverse proxy access logs
Is this distributed across accounts?Application logs — look for invalid_grant or invalid_username across many usernames in a short window
Are successful logins followed by anomalous behavior?EDR telemetry, CloudTrail subsequent events, OAuth token issuance
Is the traffic coming from known proxy/botnet IPs?Threat intelligence feeds, Tor exit node lists, datacenter ASNs

SPL query — identify credential stuffing from authentication logs:

index=auth sourcetype=windows_security EventCode=4625
| stats count by AccountName, Source_Network_Address, Logon_Process, Authentication_Package
| where count > 5
| sort - count
| eval stuffing_pattern = if(count > 50, "Suspicious", "Normal")

SPL query — find successful logins from unusual IPs after stuffing wave:

index=auth sourcetype=windows_security EventCode=4624
| search Source_Network_Address IN (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
| lookup geoip Source_Network_Address OUTPUT Country
| where Country != "US" AND Country != "CA"
| stats values(Country) as Countries, count by AccountName
| where count > 1

Step 3: Analyze Traffic Patterns

The attack infrastructure behind credential stuffing is distinctive:

  • TOR exit nodes — a significant portion of credential stuffing traffic routes through Tor. Block Tor exit nodes at the WAF level for login endpoints.
  • Datacenter IPs — legitimate users do not log in from AWS us-east-1 or DigitalOcean droplets. Residential proxies (Luminati, SOAX, BrightData) are harder to distinguish but their traffic is still automated.
  • Repeated User-Agent strings — stuffing bots often use a single User-Agent across thousands of requests. Grouping by User-Agent reveals the campaign.
  • Timing patterns — automated tools hit the login endpoint at precise intervals (e.g., exactly 500ms between attempts). Human timing has variation. Standard deviation of inter-request timing < 100ms is a strong bot indicator.

SPL query — detect automated timing patterns:

index=web sourcetype=iis
| search cs_uri_stem="/login"
| sort _time
| streamstats time_window=5m count by ClientIP, cs(User-Agent)
| where count > 20
| eval request_rate = count / 300
| where request_rate > 0.5
| table _time, ClientIP, cs(User-Agent), count, request_rate

Step 4: Investigate Successful Compromises

For each successful stuffing login, determine if it was a legitimate user or an attacker:

IndicatorSuspiciousAction
Login from new IP / geolocationHigh riskForce password reset + MFA re-enrollment
Login outside normal hoursMedium riskCheck for other anomalies
Multiple successful logins to same account from different IPsCritical — credential shared or session hijackedForce logout all sessions, reset password
Login followed by MFA prompt to userUser may approve without readingBlock if user says no — better yet, enforce number-matching MFA
Login followed by resource enumeration (mailbox access, file downloads)Confirmed compromise — attacker is exploringIsolate account, review accessed resources

Step 5: Determine Disposition

SeverityCriteriaAction
CriticalSuccessful stuffing login + evidence of resource access + attacker enumerationIsolate account (revoke tokens, force password reset, revoke MFA sessions). Check accessed resources. Notify user. Begin incident response.
HighSuccessful stuffing login from unusual IP but no post-login activity yetDisable account, force password reset. Monitor for 48 hours for any pre-existing sessions. Review credential source — was the password in HaveIBeenPwned?
MediumFailed stuffing wave detected, no successesRate-limit authentication for affected endpoint. Block attack IP ranges. Add CAPTCHA to login. Monitor for 24 hours.
LowLow-volume failed attempts from single IPBlock IP. No further investigation needed. Add to watchlist.

Preventative Controls

ControlWhat It PreventsImplementation
Rate limitingStops high-volume automated attemptsWAF rules: max 10 login attempts per IP per minute
CAPTCHA / challengeDifferentiates human from bot trafficAdd reCAPTCHA v3 to login pages when rate threshold is exceeded
MFA enforcementRenders stolen credentials uselessRequire MFA for all users, especially on first login from new device
Password breach monitoringDetects when user credentials appear in known breachesAzure AD Password Protection, HaveIBeenPwned API
Block known proxy / Tor IPsRemoves common attack infrastructureGeo-block high-risk regions. Block Tor exit nodes. Implement proxy detection at WAF level.
Device-based conditional accessRequires known device in addition to credentialsAzure AD Conditional Access requiring compliant device
Passwordless authenticationEliminates passwords as attack surfaceWindows Hello, FIDO2 security keys, passkeys

Sources