How is a recon sweep different from ordinary 404 traffic?

Ordinary 404 traffic is sporadic and usually follows human-typed URL patterns. A recon sweep produces a high-volume, low-repetition pattern of 404s — the same IP requesting many distinct paths in a short window, often targeting well-known scanner targets like /.env, /.git/config, and /admin. The breadth and deliberateness of the path set is the signal, not the 404 count alone.

Should I block the source IP immediately when a recon sweep is detected?

It depends. Blocking immediately is lower risk but tips off the attacker that they've been detected. Monitoring instead preserves intelligence about their next move. LogTriage surfaces the full detected path set and IP/ASN reputation, giving you the information to make that call.

Does LogTriage detect distributed scans split across multiple IPs?

LogTriage's pattern detection groups by source IP within a session window. Scans distributed across a large number of distinct IPs look like many individual low-volume requests rather than one coordinated sweep. IP-level threat intelligence enrichment can still flag the individual IPs if they're known scanner infrastructure.

What log volume can LogTriage handle?

Up to 100 MB per file. For nginx logs at typical production request rates, that's usually millions of log lines — more than enough to capture a full incident window including the reconnaissance phase.

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

Frequently Asked Questions

How is a recon sweep different from ordinary 404 traffic?: Ordinary 404 traffic is sporadic and usually follows human-typed URL patterns. A recon sweep produces a high-volume, low-repetition pattern of 404s — the same IP requesting many distinct paths in a short window, often targeting well-known scanner targets like /.env, /.git/config, and /admin. The breadth and deliberateness of the path set is the signal, not the 404 count alone.
Should I block the source IP immediately when a recon sweep is detected?: It depends. Blocking immediately is lower risk but tips off the attacker that they've been detected. Monitoring instead preserves intelligence about their next move. LogTriage surfaces the full detected path set and IP/ASN reputation, giving you the information to make that call.
Does LogTriage detect distributed scans split across multiple IPs?: LogTriage's pattern detection groups by source IP within a session window. Scans distributed across a large number of distinct IPs look like many individual low-volume requests rather than one coordinated sweep. IP-level threat intelligence enrichment can still flag the individual IPs if they're known scanner infrastructure.
What log volume can LogTriage handle?: Up to 100 MB per file. For nginx logs at typical production request rates, that's usually millions of log lines — more than enough to capture a full incident window including the reconnaissance phase.

See this detection run on a real report

Try the live demo with a pre-loaded malicious log set — no signup required — or upload your own log file and get a full AI-reviewed threat report in minutes.

Try Live Demo → Analyze Your Own Logs