Lab: what an attack looks like from the defender's side

Your lab exists. Now you see why it matters. In this lab you will make a small amount of noise against your own Ubuntu machine and then go looking for the evidence — the first time you play defender.

Everything here happens between two machines you built. Nothing leaves your laptop.

1. Snapshot first (2 minutes)

Both VMs running, then snapshot ubuntu-target as before-week-1-attack-lab. Habit, from now on, every lab.

2. Watch a login happen (15 minutes)

On the Ubuntu machine, log in as student and run:

sudo tail -f /var/log/auth.log

tail -f shows the end of a file and keeps following it as new lines arrive. auth.log is where Ubuntu records authentication — who tried to log in, when, and whether they succeeded. Leave this running.

Now open a second window on the same VM (in VirtualBox: View → Full-screen is not needed; just press Alt+F2 for another console) and log in again as student.

Look back at your tail -f window. You should see a new line, something like:

Accepted password for student from 10.0.2.15 port 51234 ssh2

That is what a successful login looks like to a defender. Not a movie interface — a line of text in a file. Read it carefully: it records who, from where, and how.

3. Fail on purpose (15 minutes)

Keep tail -f running. From the Windows machine, open Command Prompt and try to connect to Ubuntu over SSH with a wrong password:

ssh wronguser@<ubuntu-ip>

Type any password when prompted. Do it five or six times, getting it wrong each time.

Now look at the auth.log window. You will see lines like:

Failed password for invalid user wronguser from 10.0.2.20 port 49812 ssh2

Read one line out loud. It tells you: someone from 10.0.2.20 tried to log in as a user that does not exist, and failed.

This is a brute-force attempt, and this is exactly what it looks like in real life — on a real internet-facing server, these arrive by the thousand, every day, from all over the world.

4. Count them like an analyst (15 minutes)

Stop the tail -f with Ctrl+C. Now ask the log some questions:

sudo grep "Failed password" /var/log/auth.log
sudo grep -c "Failed password" /var/log/auth.log
sudo grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn

• The first shows every failure.
• -c counts them instead of printing them.
• The third is the analyst's move: pull the source address out of each line, group them, and count. You get a ranked list of who is attacking you most.

That last command is doing by hand what a SIEM does automatically for millions of lines. Keep it in mind — in Week 8 you will watch Wazuh do exactly this, across every machine at once, in a dashboard.

5. Notice the problem (10 minutes)

Answer these in your notes:

1. How long did it take you to find the failed logins, knowing exactly where to look and having caused them yourself?
2. /var/log/auth.log is one file on one machine. If you had fifty servers, how would you do this?
3. If the attacker had eventually guessed the password correctly, what line would tell you — and would you have been watching at that moment?
4. If an attacker could edit auth.log, what would your evidence be worth?

Question 2 is why SIEMs exist. Question 3 is why alerting exists. Question 4 is why logs get shipped off the machine that produced them. All three are this course.

Extension, if you finish early

• Run sudo last to see login history, and sudo lastb for failed attempts. Different views of the same story.
• Look at /var/log/ and list what else is being recorded: ls -la /var/log/. Open two or three files with sudo less <filename> and get a feel for how much a machine writes down about itself.

Done?

Show your instructor:

1. Your auth.log containing both a successful login and a run of failures.
2. The output of the awk/sort/uniq command, ranking source addresses.
3. Your written answers to the five questions in section 5.

Then restore your snapshot if anything is in a state you dislike — and notice how good that feels.