Labs · Cyber Security

Lab: Read a Login Log Like a SOC Analyst: Find Brute-Force and Spraying Patterns and Write a Short Incident Note

By Ravindra Bagale Last updated: 8 October 2026

Beginner40 minTerminal (Linux, Mac, WSL or Git Bash) or Windows PowerShell · Sample file sample_auth.log

Course: Cyber Security · Chapter 31: SOC, SIEM and Incident Response

Chapter 31 explains SOC, SIEM and incident response; this lab does by hand what a SIEM rule does automatically.

Chala mitrano! A SIEM is powerful, but behind every alert is a simple question: who tried, how many times, and did anyone get in? Today we answer that with four small commands on a sample login log. Count, sort, look for the success after many failures, and write it up. SOC analyst cha pahila divas!

Suppose we are…

Suppose we are a Level 1 analyst in the 24×7 SOC at Tata Consultancy Services (TCS), monitoring a retail client's web server web01. The night shift exported one day of the server's SSH log. Our task: find suspicious patterns, decide whether there was a break-in, and hand a short incident note to Level 2. (The file is sample data with reserved IP addresses.)

Goal of this lab

By the end you will be able to:

Count failed logins per IP and per username with grep, sort and uniq -c.
Tell brute force (many tries from one IP, fast) from password spraying (one try per user, slow).
Find a successful login after many failures, follow what happened next, and write an incident note.

What you need (all free)

A terminal: Linux, Mac, WSL or Git Bash on Windows. PowerShell alternatives are given for the key step.
The sample file below. About 40 minutes.

Download sample_auth.log

Safety and ethics

Practise on this sample file or on logs of servers you manage. Real logs contain usernames and IP addresses, which are personal data: share them only inside your team and never post them publicly.

Steps

Open a terminal in the download folder and look at the file size and first lines:
```
wc -l sample_auth.log
head -n 5 sample_auth.log
```
What you should see: 83 sample_auth.log and lines like Oct 6 01:52:07 web01 sshd[3105]: Accepted publickey for priya from 198.51.100.20 ....

Count failed logins per source IP:

grep "Failed password" sample_auth.log | grep -oE "from [0-9.]+" | awk '{print $2}' | sort | uniq -c | sort -rn

PowerShell:

Select-String "Failed password" .\sample_auth.log | ForEach-Object { if ($_.Line -match "from ([0-9.]+)") { $matches[1] } } | Group-Object | Sort-Object Count -Descending | Select-Object Count, Name

What you should see: 59 203.0.113.77, 8 192.0.2.15, 1 198.51.100.20.

Look at which usernames 203.0.113.77 tried:
```
grep "203.0.113.77" sample_auth.log | grep -oE "invalid user [a-z-]+" | awk '{print $3}' | sort | uniq -c | sort -rn
```
What you should see: generic names that do not exist on the server: ubuntu 10, postgres 9, oracle 9, admin 8, user 8, git 5, test 4. A typical automated brute-force list.
Find how fast it was: the first and last failure from that IP.
```
grep "Failed password.*203.0.113.77" sample_auth.log | sed -n '1p;$p'
```
What you should see: 02:10:00 and 02:15:04: 59 attempts in about 5 minutes, one every few seconds. That is brute force.
Now the most important check: did anyone get in?
```
grep "Accepted" sample_auth.log
```
What you should see: 7 successful logins. Six are from the office IP 198.51.100.20 (mostly publickey). One stands out: 02:15:13 Accepted password for deploy from 203.0.113.77, nine seconds after the last failure from the same IP.
Follow what happened after the break-in:
```
grep -E "useradd|usermod|203.0.113.77" sample_auth.log | tail -n 5
```
What you should see: 02:18:13 useradd ... name=support2 and 02:18:33 usermod ... add 'support2' to group 'sudo', then the session ends at 02:24:13. The attacker created a backdoor admin account.
Look at the second IP:
```
grep "192.0.2.15" sample_auth.log
```
Eight attempts, each for a different user, about 2 minutes apart, none successful. That is password spraying: slow on purpose to avoid lockouts.
Check the lone failure from the office IP: ravi mistyped once at 16:02:11 and logged in 9 seconds later. Normal user behaviour, not an incident.

Write the incident note (copy this template into a text file):

INCIDENT NOTE  (SOC L1, <your name>, <date time IST>)
Summary: SSH brute force from 203.0.113.77 succeeded for user 'deploy' at 02:15:13 IST on 06 Oct; attacker created sudo user 'support2'.
Timeline (IST): 02:10:00-02:15:04 59 failed logins | 02:15:13 password login 'deploy' | 02:18:13 useradd support2 | 02:18:33 support2 -> sudo | 02:24:13 logout
Also seen: password spraying from 192.0.2.15, 03:30-03:45, 8 users, no success.
Indicators: 203.0.113.77, 192.0.2.15, user support2
Severity: HIGH (confirmed compromise, admin persistence)
Recommended: isolate/snapshot web01; lock support2 and remove from sudo; reset 'deploy' and switch SSH to keys only; block both IPs; check other servers for 203.0.113.77; escalate to L2.

Common mistakes

Mistake	What happens	Fix
Stopping after counting failures	You miss the one successful break-in	Always run `grep "Accepted"` next
Using `awk '{print $11}'` for the IP	Field numbers change between "invalid user" and normal lines	Extract with `grep -oE "from [0-9.]+"`
Treating one typo as an attack	False alarms waste L2's time	Look at count, speed and what followed
Forgetting the actions after login	Persistence (new users, keys) stays	Search for useradd, usermod, sudo after the success
Writing a long story	L2 cannot act quickly	Summary, timeline, indicators, severity, actions

Self-check checklist

I counted failures per IP (59, 8, 1).
I can explain brute force vs password spraying with this log.
I found the successful login from the attacking IP and the time.
I found the new sudo user.
I wrote a short incident note with indicators and actions.

0 of 5 done

Try-at-home challenge

Write one command that prints only the IPs that have both a failed and an accepted login in this file. Which IPs appear, and which one matters?

Check your answer

comm -12 <(grep "Failed password" sample_auth.log | grep -oE "from [0-9.]+" | awk '{print $2}' | sort -u) <(grep "Accepted" sample_auth.log | grep -oE "from [0-9.]+" | awk '{print $2}' | sort -u) prints 198.51.100.20 and 203.0.113.77. The office IP had one typo (normal); 203.0.113.77 had 59 failures then a success: that is the compromise. A SIEM rule "N failures then success from the same IP" automates exactly this.

Samjla ka? Count, sort, look for the success after failures, follow it, write it up. Aata pudhe jaauya: Chapter 32 hardens the server so this cannot happen.