CSA (312-39) SOC Simulation Lab

Welcome to this hands-on Linux forensics lab. Today, you'll learn how to identify unauthorized access during an incident response investigation by understanding exactly where Linux systems store critical authentication data.

Scenario Context

You are a Tier 2 SOC Analyst at Jake Tech, a financial technology firm. The L1 team escalated an alert regarding anomalous outbound traffic from a critical internal Linux application server (app-server-04, running Ubuntu 22.04). The alert triggered at 03:00 AM UTC.

You suspect lateral movement or unauthorized access. Unfortunately, the attacker seemingly disabled the system's auditd daemon prior to the traffic spike. You must rely on native system log files to reconstruct the timeline and verify who logged into the system.

Security Environment

EDR telemetry indicates sshd spawned a bash shell, but centralized logging for this specific subnet was experiencing a delay. To build the timeline, you jump directly onto the host to review local artifacts.

root@app-server-04:~# ls -la /var/log/ | grep wtmp -rw-rw-r-- 1 root utmp 45312 Oct 24 02:58 wtmp -rw-rw-r-- 1 root utmp 122880 Oct 01 00:00 wtmp.1 root@app-server-04:~# file /var/log/wtmp /var/log/wtmp: data

Note: Attempting to `cat` this file outputs unreadable gibberish because it is a binary data file.

Question

Chloe, a SOC analyst with Jake Tech, is checking Linux systems logs. She is investigating files at /var/log/wtmp. What Chloe is looking at?

SOC Hint: You can't read this file directly with standard text tools like `cat`. You need a specific command (like `last`) to parse it. Think about user authentication history.

Expert Insight & Mentorship

What is happening: As analysts, we often parachute into an environment after a breach. If EDR is bypassed or central logging is misconfigured, native OS logs become our ground truth. In this scenario, Chloe is hunting for evidence of unauthorized access, specifically looking for historical shell sessions.

Why Option D is Correct

The /var/log/wtmp file is a binary log that maintains a history of all successful user logins and logouts, along with system reboots and shutdowns. Because it establishes exact timestamps of when a user authenticated and when their session terminated, it is a critical artifact for incident response timelines.

Why the Other Options are Wrong

A. Error log: Errors are captured by application-specific logs or the syslog daemon (/var/log/syslog or /var/log/messages).
B. System boot log: Handled by the kernel ring buffer (viewed with dmesg) or written to /var/log/boot.log.
C. General messages: Handled by syslog in /var/log/messages (RHEL families) or /var/log/syslog (Debian families).

Real-world SOC Application

If an attacker gains access and clears their ~/.bash_history file to hide command execution, they often forget to clear wtmp. By executing the last command (which parses the wtmp binary file), you can still prove that an external, malicious IP address successfully authenticated to the server at 02:58 AM, giving you the pivot point needed to track the rest of the attack.

MINI LESSON: The Linux Auth Log Triumvirate

To hunt effectively on Linux endpoints, you must memorize the three primary authentication data sources:

/var/log/auth.log (Debian) or /var/log/secure (RHEL): Plaintext logs detailing the process of authentication (e.g., SSH key acceptance, failed passwords, sudo usage). Read with `cat` or `grep`.
/var/log/wtmp: Binary file tracking successful login/logout sessions. Read using the last command.
/var/log/btmp: Binary file tracking failed login attempts. Read using the lastb command. Essential for detecting brute-force attacks.

SOC Pro-Tip: Attackers script the deletion of these files. If you find wtmp is 0 bytes or abruptly truncated without a matching log rotation event, you have a high-fidelity Indicator of Compromise (IoC) for anti-forensics.

Mastered this concept? Keep honing your SOC skills.

Explore more CSA simulations