Detecting Credential Stuffing in nginx Access Logs

Why this matters

Credential stuffing is the most common attack against any API or web login endpoint that’s reachable from the public internet. Attackers replay username/password pairs leaked from unrelated breaches against your login form, betting on password reuse. A single nginx access log line for a failed login looks completely unremarkable — the pattern only becomes visible when you look at volume, timing, and source concentration across thousands of lines at once, which is exactly what’s tedious to do by hand and easy to automate.

Indicators to look for in nginx logs

• A high ratio of 401/403 responses to a single authentication endpoint (e.g. /api/v1/login, /wp-login.php) from one IP or a small IP cluster
• Requests with no Referer header and a generic or scripted User-Agent (python-requests, curl, headless browser strings)
• Very low variance in request timing — human login attempts are irregular; scripted attempts often land in tight, regular intervals
• A late 200 response in the sequence, after many 401s — this is the line that matters most, since it represents a credential pair that worked
• The same IP or ASN appearing across unrelated customer accounts in a short window

How LogTriage detects this

LogTriage’s nginx parser (parser_nginx.py) extracts IP, user-agent, path, method, and status code from every line. The session grouper clusters requests by source IP within a time window, and the rule-based pattern detector specifically looks for the failed-then-successful login signature this attack produces. Independently, the user-agent classifier flags known scripted/attack-tool user agents with a risk floor, and IP enrichment checks the source against AbuseIPDB, OTX, GreyNoise, and ThreatFox — a single confirmed-malicious verdict from any one of those sources is enough to push the event’s risk score into HIGH/CRITICAL territory regardless of what the additive base score would have been.

Detection / evidence checklist

• Identify the authentication endpoint(s) being targeted
• Count failed-auth attempts per source IP within a rolling window
• Flag any IP that transitions from repeated failures to a success
• Cross-reference source IPs against threat intelligence (reputation, known botnet C2, scanner classification)
• Check whether the account that succeeded has MFA enabled — if not, treat as a confirmed compromise, not just a suspicious login