Detecting Reconnaissance Sweeps in nginx Logs

Why this matters

Almost every targeted attack starts with reconnaissance — an attacker mapping which endpoints exist, which return interesting status codes, and which technology stack you’re running. It’s the quietest, least damaging-looking phase, which is exactly why it’s worth catching: a recon sweep caught early gives you a chance to block the source before the actual exploitation attempt arrives.

Indicators to look for in nginx logs

• A single IP requesting a wide breadth of distinct paths in a short window, especially common scanner targets (/.env, /.git/config, /admin, /wp-admin, /.well-known/)
• Sequential or alphabetic path patterns consistent with a wordlist-based scanner (dirb, gobuster, ffuf)
• A high proportion of 404 responses mixed with occasional 200s — the 200s are what the attacker is actually looking for
• Scanner-associated user-agents, or no user-agent at all
• Requests with unusual HTTP methods (OPTIONS, TRACE, PROPFIND) against ordinary web paths

How LogTriage detects this

The rule-based pattern detector specifically looks for the “wide breadth, low repetition” signature this produces — many distinct endpoints, each touched once or twice, from a single source IP within a session window. This is intentionally a different detection path from credential stuffing (which looks for narrow repetition against one endpoint), because the two attack shapes are inverses of each other and conflating them would blur both signals.

Detection / evidence checklist

• List every distinct path the source IP touched, sorted by response code
• Flag any 200 response buried in a sea of 404s — that’s the endpoint the attacker found
• Check the source IP/ASN against threat intelligence for known scanner infrastructure
• Decide whether to block now (cheap, but tips off the attacker) or monitor (riskier, but preserves intelligence on their next move)
• Review whether any of the discovered endpoints should not have been publicly reachable in the first place