Brute-Force Detector

The brute-force attack leaves a telltale signature: a burst of failed logins from a single source packed into a short window, not a slow trickle spread across a whole day. Brute-Force Detector reads a log, extracts an IP from every line, classifies each line as a failed login or not, groups failures by IP, and flags any source that has enough failures bunched inside your chosen window — entirely in your browser, nothing uploaded.

Failure detection is pattern-driven, and you pick the signal that matches your logs. In status mode the detector looks for an HTTP 401 or 403 surrounded by whitespace on the line, the way most access logs render a response code. In message mode it matches free-text markers your auth layer actually writes — failed, invalid password, invalid user, authentication failure, or failed login — so it works just as well on application logs that never touch HTTP at all. A configurable timestamp pattern feeds a real sliding-window check: the detector sorts each IP“s failure timestamps and slides your window across them, and if at any point enough failures (your threshold) land inside one window-length span, that IP is flagged. A single stray failure from the same IP hours before or after a genuine burst does not mask the burst — the sliding window finds the tight cluster regardless of what else that IP did earlier in the file. Every flagged IP comes back with its failure count, its within-window verdict, and up to six of the actual offending lines so you can confirm the call at a glance.

• HTTP-status failure mode — count 401/403 responses bounded by whitespace on the line.
• Message-marker failure mode — match common auth-failure wording like invalid password or authentication failure.
• Configurable threshold and time window — set the exact failures-per-minutes rule for your environment.
• True sliding-window detection — finds any dense burst of threshold-count failures inside the window, not just a whole-file span check.
• Per-IP counts with within-window verdicts — see exactly why an IP was or was not flagged.
• Configurable IP extraction regex — adapt to X-Forwarded-For or nonstandard IP fields.
• Flagged + low-risk IP reports — triage the noisy IPs first.
• 100% local — nothing leaves the browser.

1. Paste your log into the text box — access logs, auth logs, or application logs all work.
2. Pick the failure signal — HTTP status codes for web server logs, or message markers for application-level auth logs.
3. Check the IP and timestamp patterns and adjust them if your log format is nonstandard; leave the timestamp pattern empty to skip windowing and just count failures across the whole file.
4. Set the window and threshold — e.g. 5 failures in 10 minutes for a tight rule, or 20 in 60 minutes for a looser one.
5. Detect. Flagged IPs appear with counts, window verdicts, and their exact triggering lines; IPs under the threshold are listed separately as low-risk.
6. Copy the flagged report for the SOC, a ticket, or a blocklist review.

Example 1 — Web app logs. Five 401s from 203.0.113.7 land inside a three-minute span: with the default 5-in-10-minutes rule the detector flags the IP and lists its exact lines, along with the timestamp of the earliest and latest failure in the burst.

Example 2 — App auth messages. A service logs invalid password for user=x; ten of these arrive from one IP inside two minutes and get flagged in message mode even though there is no HTTP status code anywhere in the file.

Example 3 — Noisy IP, no burst. An IP racks up eight failures over six hours — a legitimate user who keeps mistyping a password once or twice a day. With any reasonable window (say, 10 minutes) those eight failures never cluster tightly enough to flag, which is the intended behavior: slow, sporadic failures are not a brute-force pattern.

Example 4 — Threshold triage. Start loose at 10 failures in 15 minutes to see the overall shape of the log, then tighten to 3 in 5 minutes to catch faster, more aggressive attacks on a sensitive admin endpoint.

• Signature-first detection — count failures per source over a real, sliding time window instead of a naive whole-file total.
• Two failure signals — status codes for web logs, message markers for application logs.
• Burst-aware windowing — a tight cluster of failures is found even when the same IP also has unrelated failures elsewhere in the file.
• Actionable report — IPs, counts, exact lines, and window verdicts ready to hand to a SOC or drop into a ticket.
• Adjustable to your logs — IP and timestamp extraction patterns are editable, not hardcoded.
• Private — all processing stays local, nothing is ever uploaded.