Read server logs like an analyst and find the attack
This is the blue team side of the track: the work of the defender who reads what a server wrote down and spots the attack inside it. You build a tiny log lab on your own machine (no root, no Docker), run a real OpenSSH server on localhost, then knock on it with failed logins the way a brute-force bot would, so the logs fill with real attack entries you created yourself. Then you do the analyst's job on them: read the SSH auth log with journalctl, find the failed logins and the address they came from, count the attempts per source with a grep and awk pipeline until the one noisy attacker stands out from the quiet, read a web server access log for the scanners sweeping for vulnerable pages, and finally turn detection on with fail2ban and summarise the web log with GoAccess. Every log line you analyse is one your own activity produced, against your own box. It pairs with Harden a server (the defence you apply once you can see the attack) and Build a hacking lab (which sets the one rule everything here obeys).
- A Linux-style terminal. On Windows that is WSL2 (the slim Linux built into Windows), which has journalctl, apt and systemd; on Linux your normal terminal. The exact lab uses journalctl and the Ubuntu package archive, so it is Linux and WSL2 only, not macOS
- The lab-only mindset from Build a hacking lab: you generate attack traffic only against software you run yourself, never against anyone else's machine. This mission stays inside that rule from the first command to the last
- It pairs with Harden a server. That lesson shuts the doors; this one teaches you to see the attacker testing them. Doing either first is fine. Nothing here depends on Docker, so you can do this one even if you skipped that setup
- About 60MB of disk for the unpacked tools, a working internet connection the first time (to fetch them from the Ubuntu archive), and Python 3, which Ubuntu already has
Why logs, and the analyst's one habit
Understand what a log is, why the defender lives in it, and the single mental habit that turns a wall of text into a finding. Fix in your mind that this only happens on your own box.
Almost every program on a server keeps a diary. A log is that diary: an append-only record of events, one line each, written as they happen, with the time, what happened and often who it involved. When someone logs in over SSH, a line is written. When a web server answers a request, a line is written. When a login fails, that is written too. The attacker cannot easily stop these lines being recorded, which is exactly why they are the defender's best evidence. An attack is not invisible; it is usually sitting in a log, waiting for someone to read it.
Reading logs is the first skill of blue team work (defence) and of DFIR, digital forensics and incident response: the job of working out, from what a machine recorded, what happened to it. You do not need special tools to start. The logs are plain text, and the standard terminal commands, read in the right order, answer the questions that matter: who connected, what did they try, how often, and from where.
The one habit that separates an analyst from someone staring at scrolling text is this: baseline first, then anomalies. Learn what normal looks like, so the abnormal announces itself. A quiet server has a handful of SSH logins a day, from addresses you recognise. One failed login is a typo. The anomaly is volume and shape: two hundred failed logins in a minute, from one address, trying username after username. You are not reading every line. You are learning the shape of calm, then looking for the spike that breaks it.
This whole lesson is defensive. You will generate attack traffic, but only so there is something real to find, and only against a server you run on your own machine. The skill you build is recognising the signs of an attack in what a system recorded, so that on a real server you own you can tell the difference between a normal Tuesday and someone trying to break in.
CarefulYou will create failed logins and scanner requests in this mission. Generate them only against your own lab server, which listens on your own machine's loopback address and nowhere else. Sending failed logins or vulnerability scans at a server you do not own or have written permission to test is an offence in the UK (the Computer Misuse Act 1990) and almost everywhere else, even if nothing breaks. Every attack in this mission is aimed at a box you built, on the address 127.0.0.1, which is your own machine talking to itself.TipThe same line the attack track opened with, read from the defender's chair. In the attack lessons you only attacked software built to be attacked. Here you only read the logs of a server you own. Before any command, the question is the same: is this my machine? For the whole of this mission, yes.