Find the Break-In: Reading a Brute-Force Pattern in Auth Logs
The challenge
These are your web auth logs. One IP hammered the login with failures and then suddenly got a 200 - the break-in. Filter the noise (try status:401), confirm it is a single source, and submit the attacker's IP address.
What you'll learn
- Filter a noisy log stream by field to isolate relevant events
- Recognise the failures-then-success signature of a successful brute force
- Attribute an intrusion to a single source IP
- Pivot from the login success to the attacker's next action
Skills tested
Prerequisites
- Understanding of HTTP status codes (200 vs 401)
- Familiarity with login flows
How it works
Most security work starts in logs, and the core skill is separating signal from noise. A live web server produces a constant stream of ordinary traffic - GET requests for pages and assets, mostly returning 200 or 304, from many different addresses. An attack hides inside that noise, so you filter the stream down to the events that matter.
A credential brute force or password-spray has an unmistakable shape: many failed authentication attempts (401) against the login endpoint, from a single source, followed by one success (200). Filtering to status:401 collapses the noise and surfaces that run instantly - and here every failure carries the same IP, which is the attribution. The decisive moment is the transition: that same IP finally gets a 200 on /login, and immediately requests an authenticated page (/admin/users). That is the break-in and the first post-compromise action.
The SIEM table supports free-text search and field:value filters, plus quick chips. You do not read every row - you query for the pattern, confirm the single source, and follow it across the success boundary.
Common mistakes
- Reading rows instead of filtering. Scrolling the whole log wastes time; query
status:401and let the pattern appear. - Stopping at the failures. The failures show the attempt; the
200from the same IP shows the actual break-in. - Blaming a benign IP. The noise is GETs from many addresses; the attacker is the one repeating POSTs to /login.
- Submitting a path or status instead of the IP. The question asks who - the source address.
How to defend against it
Defensively, this pattern is exactly what rate limiting, account lockout, and anomaly alerting exist to stop. The same filter you used to find it after the fact can be an automated detection.
- Rate-limit and progressively lock out repeated failed logins per source and per account.
- Alert on a burst of 401s followed by a 200 from the same IP - the brute-force success signature.
- Require MFA so a single guessed password is not enough to break in.