Find the Break-In: Reading a Brute-Force Pattern in Auth Logs
Le défi
Voici vos logs d'authentification web. Une IP a martelé le login avec des échecs puis a soudain obtenu un 200 - l'intrusion. Filtrez le bruit (essayez status:401), confirmez que c'est une seule source, et soumettez l'adresse IP de l'attaquant.
Ce que tu vas apprendre
- 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
Compétences testées
Prérequis
- Understanding of HTTP status codes (200 vs 401)
- Familiarity with login flows
Comment ça marche
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.
Erreurs fréquentes
- 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.
Comment s'en protéger
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.