root@thehacksparrow:~/writeups$ SYSTEM ONLINE
· log in sign up
← back to TryHackMe writeups
root@sparrow:~/writeups$ cat linux-logging-for-soc.md
// Blue Team & SOC

Linux Logging for SOC

15 Jun 2024 · 9 min read
Blue Team & SOCwriteupstryhackmeEasylinux
Overview — Linux Logging for SOC is an Easy TryHackMe room focused on Linux log investigation from a SOC analyst's perspective. It walks through the plain-text logs under /var/log (syslog, authentication, packages, command history) and runtime monitoring with auditd, teaching you to spot suspicious logins, user creation, malicious downloads and network scans.
PlatformTryHackMe
CategoryBlue Team & SOC
DifficultyEasy
RoomLinux Logging for SOC

Task 1 — Introduction

Linux is everywhere: traditional servers, cloud-native containers and workstations. For a SOC analyst, mastering Linux log investigation is key to detecting compromises and suspicious activity. The room targets headless servers, where logs live as plain text under /var/log.

After accessing the VM, we assume the root role so we can read every log:

sudo su

Task 2 — Working With Text Logs

Linux records system events (operations, cron jobs, time synchronization) in /var/log/syslog. We start by reviewing the first lines:

cat /var/log/syslog | head

We can filter for specific events, for example cron jobs:

cat /var/log/syslog | grep CRON

And search recursively by keyword across all of /var/log to locate authentication-related records:

grep -R -E "auth|login|session" /var/log
Tip: many examples use cat file | grep pattern, but grep pattern file does the same without the extra process. The cat | pattern is convenient when chaining filters, though not required.

Questions & answers:

Q: Which time server domain did the VM contact to sync its time?
A: ntp.ubuntu.com

Q: What is the kernel message from Yama in /var/log/syslog?
A: Becoming mindful.

Task 3 — Authentication Logs

/var/log/auth.log captures user logins, sudo commands, SSH events and user management. It is one of the most valuable sources for the SOC.

General knowledge (beyond this room): /var/log/auth.log is the Debian/Ubuntu name for this log. RHEL, CentOS, Fedora and other systems built on rsyslog's traditional config log the same events to /var/log/secure instead — when triaging an unfamiliar Linux host, check both paths before assuming authentication logging is missing.

We list all opened and closed user sessions:

cat /var/log/auth.log | grep -E 'session opened|session closed'

We filter SSH login attempts, both accepted and failed:

cat /var/log/auth.log | grep "sshd" | grep -E 'Accepted|Failed'

And we locate user-management events (additions, deletions, modifications):

cat /var/log/auth.log | grep -E '(passwd|useradd|usermod|userdel)\['
Why it matters: a burst of Failed password entries from a single IP signals a brute-force or password-spraying attack; a useradd line followed by addition to the sudo group may be an attacker establishing persistence.

Questions & answers:

Q: Which IP address failed to log in on multiple users via SSH?
A: 10.14.94.82

Q: Which user was created and added to the "sudo" group?
A: xerxes

Task 4 — Common Linux Logs

Beyond syslog and auth.log, other useful sources exist:

  • /var/log/kern.log → kernel messages.
  • /var/log/dpkg.log → Debian/Ubuntu package installations.
  • Per-user .bash_history files → command history.

For example, to check which version of unzip was installed:

grep unzip /var/log/dpkg.log

And to search for a flag across the users' command histories:

grep -r "flag" /home/*

Or read the history files directly:

cat /home/ubuntu/.bash_history
cat /root/.bash_history

Questions & answers:

Q: Which version of unzip was installed on the system?
A: 6.0-28ubuntu4.1

Q: What is the flag you see in one of the users' bash history?
A: THM{****_**_remember}

Task 5 — Runtime Monitoring

File-based logs tell part of the story, but to understand what the system actually runs you have to look at system calls (syscalls). Every program execution goes through the kernel via a syscall like execve; opening a file or creating a process also requires syscalls. That makes the kernel an ideal vantage point for monitoring.

Knowledge questions:

Q: Which Linux system call is commonly used to execute a program?
A: execve

Q: Can a typical program open a file or create a process bypassing system calls?
A: Nay (no)

Task 6 — Using Auditd

auditd is the Linux audit subsystem: it records runtime events such as process execution and file access, according to rules that tag each matching event with a key. You query it with ausearch, and the -i flag interprets numeric values (UID, syscalls, timestamps) into human-readable form.

General knowledge (beyond this room): ausearch can only return events for actions an audit rule was already watching for. Rules are added with auditctl -w <path> -p rwxa -k <key> (file/directory watches) or -a always,exit -F arch=b64 -S execve -k <key> (syscall rules), and persisted in /etc/audit/rules.d/*.rules. The proc_wget and file_thmsecret keys used below were pre-configured on this VM; on a system you administer, auditd only sees what you told it to watch.

We search for the wget download event by its key:

ausearch -i -k proc_wget

We locate when secret.thm was first opened:

ausearch -i -k file_thmsecret

The scanned network range has no dedicated key, so we filter for scanning tools:

ausearch -i | grep -E "nmap|masscan|scan"

Or extract IP addresses/ranges directly with a regex:

ausearch -i | grep -Eo "([0-9]{1,3}\.){3}[0-9]{1,3}(/[0-9]{1,2})?"
SOC takeaway: auditd records execution even if the attacker wipes their .bash_history. That makes it a more reliable source than shell history for reconstructing an incident timeline.

Questions & answers:

Q: When was the secret.thm file opened for the first time?
A: 08/13/25 18:36:54

Q: What is the original file name downloaded from GitHub via wget?
A: naabu_2.3.5_linux_amd64.zip

Q: Which network range was scanned using the downloaded tool?
A: 192.168.50.0/24

Task 7 — Conclusion

The room reconstructs a small intrusion timeline from the logs: SSH brute-force attempts, creation of a privileged user, download of a scanning tool (naabu) and an internal network scan. Points to remember:

  • Linux logging may seem chaotic but provides critical insight into the system.
  • Logs live in /var/log/ and are mostly plain text.
  • Top sources for the SOC: auth.log, application-specific logs and runtime logs via auditd.
  • .bash_history is unreliable for investigations (it can be cleared or disabled); prefer auditd or alternative tooling.

Key takeaways

  • /var/log/syslog concentrates general system events (cron, time sync, kernel messages).
  • /var/log/auth.log is the primary source for logins, sudo, SSH and user management: ideal for hunting brute-force and persistence.
  • dpkg.log and kern.log add context on installed packages and kernel events.
  • auditd + ausearch -i let you monitor syscalls (execve), file access and executions, surviving history wiping.
  • Bash history is a useful lead but not a trustworthy forensic source.
  • General knowledge, beyond this room: on systemd-based distributions the same events are also collected by the journal and queryable with journalctl (e.g. journalctl -u ssh, journalctl -k for kernel messages, journalctl --since "1 hour ago") — a useful fallback when a distro doesn't keep a plain-text copy of a given source under /var/log.