Challenge 01 • Linux SSH Brute-Force Detection

Understanding Linux Security Logs

Before diving into the investigation, understanding log structure and importance is crucial for effective incident response.

📄 /var/log/auth.log (or /var/log/secure on RHEL/CentOS)

Purpose: Records all authentication-related events including login attempts, sudo usage, SSH sessions, and privilege escalation.

Why It's Critical: This log is your first line of defense for detecting unauthorized access, brute-force attacks, credential abuse, and lateral movement. Without it, you'd be blind to who is accessing your systems and how.

Format: TIMESTAMP HOSTNAME PROCESS[PID]: MESSAGE

Example:
Nov 28 14:13:07 web-prod-03 sshd[8247]: Accepted password for root from 203.0.113.77 port 53120 ssh2

Components:
• Nov 28 14:13:07 = Timestamp (when the event occurred)
• web-prod-03 = Hostname (which server)
• sshd[8247] = Process name and PID (what service)
• Accepted password = Event type (what happened)
• root = Username (who)
• 203.0.113.77 = Source IP (from where)

📄 /var/log/syslog (or /var/log/messages on RHEL/CentOS)

Purpose: General system activity log capturing kernel messages, service starts/stops, hardware events, and daemon activity.

Why It's Critical: Provides context around authentication events. If auth.log shows a successful login, syslog can confirm service restarts, network changes, or system modifications that occurred during that session. Essential for timeline reconstruction and correlation.

What to Look For: Common Attack Patterns

🚨 SSH Brute-Force (This Challenge)

Multiple "Failed password" entries
Same source IP, different usernames
Rapid succession (seconds apart)
Eventual "Accepted password" from same IP
Session opened immediately after

🎯 Credential Stuffing

Failed attempts across many IPs
Same username tried from different sources
Lower frequency than brute-force
May use previously leaked credentials

⚡ Privilege Escalation

Unexpected sudo usage
User switching to root (su command)
Service account running privileged commands
New user creation via useradd

🔄 Lateral Movement

SSH from internal IP to internal IP
Service account logging into workstations
Unusual inter-server connections
Access patterns outside normal hours

Key Log Investigation Commands

# Count failed SSH attempts by IP
grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -nr

# Find successful logins
grep "Accepted password" /var/log/auth.log

# Show sudo usage
grep "sudo:" /var/log/auth.log

# List all SSH sessions for a specific user
grep "session opened for user root" /var/log/auth.log

💡 Pro Tip: Always correlate auth.log findings with network logs (firewall, IDS), application logs, and endpoint detection tools. A successful SSH login might be legitimate, but if followed by suspicious process creation or data exfiltration, it's part of a larger attack chain.

Evidence Review

📄 /var/log/auth.log Click lines to tag as evidence

📄 /var/log/syslog

📌 Evidence Locker

No evidence tagged yet. Click log lines to add them.

Interactive Terminal

Run bash commands to analyze the logs. Available: cat, grep, wc, awk, sort, uniq, clear, help

analyst@blueteam:~$ Terminal ready. Type 'help' for available commands.

analyst@blueteam:~$

Investigation Tasks

Tasks Completed: 0 / 7

Task 1 — Identify the Attacker IP Address

✓ Correct Answer:

203.0.113.77

This IP appears in multiple "Failed password" log entries, followed by an "Accepted password" entry. Use grep "Failed password" auth.log to see all failed attempts and identify the repeating IP address.

Task 2 — Count Failed Login Attempts from Attacker

✓ Correct Answer:

There are 4 failed password attempts from 203.0.113.77 in the auth.log (admin, test, oracle, root). Count them using grep "Failed password" auth.log | grep "203.0.113.77" | wc -l

Task 3 — Compromised User Account

✓ Correct Answer:

root

Look for "Accepted password for root from 203.0.113.77" in the auth.log. This shows the attacker successfully logged in as the root user (superuser with full system privileges).

Task 4 — First Successful Login Timestamp

✓ Correct Answer:

Nov 28 14:13:07

The log line "Nov 28 14:13:07 web-prod-03 sshd[8247]: Accepted password for root from 203.0.113.77..." shows the exact timestamp when the attacker gained access.

Task 5 — SSH Service Process ID (PID) for Successful Login

✓ Correct Answer:

8247

In the format "sshd[8247]", the number in brackets is the Process ID (PID). This unique identifier tracks all actions performed by this SSH session.

Task 6 — Attack Duration (seconds between first failed and first success)

✓ Correct Answer:

First failed attempt: 14:12:58, First success: 14:13:07. Calculation: 14:13:07 - 14:12:58 = 9 seconds. This shows how quickly the attacker found the correct password.

Task 7 — Session Duration (seconds from session opened to closed)

✓ Correct Answer:

135

Session opened: 14:13:07, Session closed: 14:15:22. Calculation: (15×60 + 22) - (13×60 + 7) = 922 - 787 = 135 seconds (2 minutes 15 seconds). This is how long the attacker was logged in.

XP: 0 / 700

Attack Analysis & Incident Summary

This section auto-fills once all tasks are completed correctly.

Decisive Evidence

Complete all tasks to reveal the key log line.

Incident Summary

Attacker IP to blocklist: —
Compromised user account: —
First successful login: —
Total failed attempts: —
Attack duration: — seconds
Session duration: — seconds
Attack vector: SSH password brute-force (dictionary attack)
MITRE ATT&CK: T1110.001 - Password Guessing

Recommended Remediation

Immediate: Block 203.0.113.77 at firewall, terminate active sessions, rotate root password
Short-term: Review sudo logs, check for persistence mechanisms, scan for backdoors
Long-term: Enforce SSH key-only auth, implement fail2ban, enable MFA, monitor auth logs with SIEM

Why This Attack Succeeded

The attacker successfully compromised the root account because:
1. Password authentication was enabled for the root user
2. The password was weak enough to be guessed in a dictionary attack
3. No rate limiting or account lockout was in place
4. SSH was exposed to the public internet without IP whitelisting

🛡️ Challenge 01 • Linux SSH Brute-Force Detection

Mission Brief

Available Artifacts

Interactive Features

Understanding Linux Security Logs

📄 /var/log/auth.log (or /var/log/secure on RHEL/CentOS)

📄 /var/log/syslog (or /var/log/messages on RHEL/CentOS)

What to Look For: Common Attack Patterns

🚨 SSH Brute-Force (This Challenge)

🎯 Credential Stuffing

⚡ Privilege Escalation

🔄 Lateral Movement

Key Log Investigation Commands

Evidence Review

Interactive Terminal

Investigation Tasks

Attack Analysis & Incident Summary

Decisive Evidence

Incident Summary

Recommended Remediation

Why This Attack Succeeded