Insufficient Logging & Monitoring — Brute-Force Log Analysis

If you have never thought about server logs or security monitoring before, you are in exactly the right place. This step builds the foundation you need before the hands-on investigation begins.

What is a server access log?

Every time a browser or program sends a request to a web server — loading a page, submitting a login form, calling an API — the server writes one line to a file called an access log. That line records:

• Who sent the request (their IP address)
• When it arrived (a timestamp, usually in UTC)
• What they asked for (the HTTP method and path, e.g., POST /api/login)
• What the server answered (an HTTP status code — 200 means success, 401 means wrong credentials)
• How much data the server sent back (the response size in bytes)

A typical log line looks like this:

203.0.113.99 - - [15/Mar/2024:14:22:03 +0000] "POST /api/login HTTP/1.1" 401 128

In plain English: "On 15 March 2024 at 14:22:03 UTC, the IP address 203.0.113.99 sent a POST request to /api/login. The server replied with status 401 (Unauthorised) and sent back 128 bytes."

What HTTP status codes tell you

A status code is the server's one-number answer to every request. Three are critical to this lesson:

A single 401 is normal — anyone mistyping their password gets one. What is not normal is the same IP address sending dozens of POST /api/login requests and receiving 401 responses over and over within a few minutes. That is the fingerprint of a brute-force attack.

What is a brute-force attack?

A brute-force attack against a login form is when an automated tool systematically tries many passwords for one account until one works. The attacker does not need to exploit a code vulnerability — they simply automate guessing, often using leaked password lists from previous data breaches.

What it looks like in the logs:

• One IP address sending a relentless stream of POST /api/login requests
• Every request returns 401 — the password was wrong
• The requests arrive with machine-like regularity: every 3–5 seconds, like clockwork
• No other activity from that IP — no page loads, no browsing — just hammering the login endpoint

Why logging and monitoring matter

Here is the uncomfortable truth: the brute-force attack itself is not the worst part — the worst part is not knowing it happened.

The application you are about to investigate had perfectly readable access logs. Every one of the 47 failed login attempts was recorded. The information was there. But without real-time monitoring and alerting, nobody looked at the logs until long after the attack began.

This is exactly what OWASP A09:2021 — Security Logging and Monitoring Failures describes. According to the Verizon Data Breach Investigations Report, the median time from initial intrusion to discovery is measured in months. In that window an attacker can steal data, escalate privileges, and move through an entire network undetected.

What you will do in this lesson

You will take on the role of a SOC analyst. SOC stands for Security Operations Centre: the team and tooling responsible for watching security alerts, investigating suspicious activity, and coordinating incident response. In this lesson, you are reviewing the access logs of a fictional company called LogShield Analytics. An automated threat detection system has flagged an incident: unusual login activity. No alert fired at the time, so nobody intervened.

Your job:

• Review the access log table and understand the normal traffic patterns.
• Spot the attack — find the IP address that is behaving like a brute-force tool.
• Submit the attacker's IP address as your incident analysis finding.
• Capture the challenge flag from the incident report confirmation.

Everything happens in your browser. No tools to install, no terminal to open.