Lesson 6 of 6·14 min read·Includes quiz

Linux Internals for Defenders

Process model, file system, authentication, logging, persistence mechanisms

What You'll Learn

  • Explain the Linux process model including init/systemd, process trees, and the /proc virtual filesystem
  • Navigate the Linux filesystem from a defender's perspective, identifying security-critical directories and permission models
  • Describe how Linux authentication works through /etc/passwd, /etc/shadow, PAM, and SSH keys
  • Identify the key log sources on a Linux system (rsyslog, journald, auditd) and where each stores its data
  • Enumerate common Linux persistence mechanisms used by attackers and map them to detection strategies
  • Use command-line tools (last, lsof, ss, find) to investigate a potentially compromised Linux server

Why Linux Internals Matter for Blue Team

Every SOC will encounter Linux. Web servers, DNS servers, mail relays, Docker hosts, cloud instances, CI/CD runners — the internet runs on Linux. When an attacker compromises a Linux box, the artifacts they leave behind are fundamentally different from Windows. There is no registry. There are no Event Logs. There is no Task Manager.

If you only know Windows forensics, a compromised Linux server is a blind spot. This lesson gives you the internal knowledge to investigate Linux systems with the same confidence you bring to Windows.

ConceptWindowsLinux
Process tree rootSystem (PID 4) → smss.execsrss.exeinit/systemd (PID 1)
Service managementServices (SCM), services.mscsystemd units, systemctl
Configuration storageRegistry (HKLM, HKCU)Text files in /etc/
Event loggingEvent Logs (.evtx)syslog, journald, auditd
PersistenceRegistry Run keys, Scheduled Tasks, Servicescron, systemd, init.d, .bashrc, authorized_keys
Process inspectionTask Manager, Process Explorerps, top, htop, /proc/

The Linux Process Model

PID 1: The Root of Everything

On every Linux system, the first process started by the kernel is PID 1. On modern distributions, this is systemd. On older systems, it was init (SysVinit). Every other process on the system is a descendant of PID 1.

# View the process tree rooted at PID 1
pstree -p 1 | head -30

# Alternative: full process listing with parent PIDs
ps auxf

Understanding the expected process tree is critical for defenders. If you see /bin/bash spawned directly from apache2 or nginx, that is a web shell — the web server should never spawn interactive shells.

The /proc Filesystem

Linux exposes process information through the /proc virtual filesystem. Every running process has a directory at /proc/[PID]/ containing everything about it:

PathWhat It Contains
/proc/[PID]/cmdlineFull command line that started the process
/proc/[PID]/exeSymlink to the actual binary on disk
/proc/[PID]/cwdCurrent working directory
/proc/[PID]/fd/Open file descriptors (files, sockets, pipes)
/proc/[PID]/environEnvironment variables at process start
/proc/[PID]/mapsMemory-mapped regions (shared libraries loaded)
/proc/[PID]/statusProcess state, UID, GID, memory usage
/proc/[PID]/net/tcpNetwork connections for the process namespace
# Investigate a suspicious process (PID 4821)
cat /proc/4821/cmdline | tr '\0' ' '
ls -la /proc/4821/exe
ls -la /proc/4821/cwd
ls -la /proc/4821/fd/
cat /proc/4821/environ | tr '\0' '\n'

Attackers delete their binaries after execution. If /proc/[PID]/exe shows (deleted), the binary was removed from disk while the process is still running. This is a classic indicator of malicious activity. The kernel keeps the binary in memory, and you can recover it: cp /proc/[PID]/exe /tmp/recovered_binary.

Process Signals

Signals are the IPC mechanism for process control. Defenders need to know the important ones:

SignalNumberEffectForensic Note
SIGHUP1Hangup / reload configAttackers send to daemons to reload modified configs
SIGKILL9Immediate terminationCannot be caught; used to kill logging/monitoring processes
SIGTERM15Graceful terminationDefault kill signal
SIGSTOP19Pause processCan suspend security tools

Linux Filesystem for Defenders

Linux filesystem hierarchy and security-critical directories for SOC investigation

Security-Critical Directories

DirectoryWhat a Defender Looks For
/etc/Modified config files — passwd, shadow, sudoers, ssh/sshd_config, crontab
/var/log/All log files — auth.log, syslog, kern.log, audit/audit.log
/tmp/ and /dev/shm/World-writable directories attackers use for staging payloads
/var/spool/cron/Per-user crontabs (persistence)
/root/ and /home/*/User home dirs — check .bashrc, .profile, .ssh/authorized_keys
/usr/local/bin/Legitimate admin installs — but also where attackers hide renamed binaries
/var/www/Web roots — look for web shells

File Permissions and Special Bits

Linux permissions use the classic rwxrwxrwx model (owner/group/other), but three special permission bits are critical for security investigations:

BitSymbolMeaningWhy Attackers Care
SUID-rwsr-xr-xRuns as file owner (usually root)SUID binaries are privilege escalation vectors
SGID-rwxr-sr-xRuns with group permissions of the fileCan escalate group-level access
StickydrwxrwxrwtOnly owner can delete files in directorySet on /tmp — prevents users from deleting each other's files
# Find all SUID binaries on the system
find / -perm -4000 -type f 2>/dev/null

# Find all SGID binaries
find / -perm -2000 -type f 2>/dev/null

# Find world-writable files (excluding /proc and /sys)
find / -perm -o+w -type f ! -path "/proc/*" ! -path "/sys/*" 2>/dev/null
🚨

SUID binaries are a top privilege escalation vector. An attacker who gains low-privilege access will immediately search for SUID binaries they can abuse. Resources like GTFOBins (https://gtfobins.github.io/) document hundreds of binaries that can be exploited when SUID is set. In Lab 3.6, you will baseline SUID binaries on a clean system so you can detect new ones added by an attacker.

Linux Authentication

The passwd and shadow Files

Linux stores user information across two files:

# /etc/passwd — readable by all users
# Format: username:x:UID:GID:comment:home:shell
root:x:0:0:root:/root:/bin/bash
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
analyst:x:1001:1001:SOC Analyst:/home/analyst:/bin/bash

# /etc/shadow — readable only by root
# Format: username:password_hash:last_change:min:max:warn:inactive:expire
root:$6$rounds=5000$salt$hash...:19500:0:99999:7:::
analyst:$6$rounds=5000$salt$hash...:19500:0:99999:7:::
Investigation CheckWhat to Look For
New accountsUIDs that appeared recently, especially UID 0 (root-equivalent)
Shell changesAccounts with /bin/bash that should have /usr/sbin/nologin
Password hash type$6$ = SHA-512, $1$ = MD5 (weak), ! or * = disabled
Accounts with no passwordEmpty second field in /etc/shadow — immediate compromise vector

PAM (Pluggable Authentication Modules)

PAM provides a modular framework for authentication. Configuration lives in /etc/pam.d/. Attackers can backdoor PAM modules to accept any password:

# Check PAM configuration for SSH
cat /etc/pam.d/sshd

# Look for unexpected PAM modules
find /lib/security/ -name "*.so" -newer /lib/security/pam_unix.so

SSH Keys and authorized_keys

SSH key-based authentication bypasses passwords entirely. Attackers who gain access frequently plant their own public key:

# Check all authorized_keys files on the system
find / -name "authorized_keys" -type f 2>/dev/null

# Review root's authorized keys
cat /root/.ssh/authorized_keys

# Check for keys with command restrictions or unusual options
grep -r "command=" /home/*/.ssh/authorized_keys 2>/dev/null
💡

The authorized_keys file supports forced commands. An entry like command="/usr/bin/rsync" ssh-rsa AAAA... restricts that key to only running rsync. Attackers sometimes modify this to command="/bin/bash" or remove the restriction entirely. Always compare authorized_keys entries against expected access patterns.

Linux Logging

Linux logging is fragmented across multiple subsystems. Understanding which log captures what is essential for investigation.

Log Subsystems

SubsystemConfigurationStorageWhat It Captures
rsyslog/etc/rsyslog.conf/var/log/ (text files)System events, application logs, kernel messages
journald/etc/systemd/journald.conf/var/log/journal/ (binary)All systemd unit output, structured metadata
auditd/etc/audit/auditd.conf, /etc/audit/rules.d//var/log/audit/audit.logKernel-level syscall auditing, file access, process execution

Critical Log Files

Log FileWhat It ContainsKey Events
/var/log/auth.logAuthentication eventsSSH logins, sudo usage, su commands, failed logins
/var/log/syslogGeneral system messagesService starts/stops, cron execution, kernel events
/var/log/kern.logKernel messagesModule loading, hardware errors, firewall drops
/var/log/audit/audit.logAudit daemon eventsSyscalls, file access, user commands (if rules configured)
/var/log/wtmpLogin records (binary)Read with last command — all login sessions
/var/log/btmpFailed logins (binary)Read with lastb command — brute force evidence
/var/log/lastlogLast login per user (binary)Read with lastlog command
/var/log/cron.logCron job executionScheduled task runs — verify against expected cron jobs
# View recent authentication events
tail -100 /var/log/auth.log

# Search for failed SSH logins
grep "Failed password" /var/log/auth.log

# Search for successful SSH logins from unusual sources
grep "Accepted" /var/log/auth.log | grep -v "10.0."

# Query journald for SSH-related events
journalctl -u sshd --since "2 hours ago" --no-pager

# View login history
last -20

# View failed login attempts
lastb -20

# View last login for all users
lastlog

# Search audit log for executed commands
ausearch -m EXECVE --start recent

auditd is the most powerful Linux logging tool — but it is often not enabled by default. The audit daemon can log every syscall, every file access, and every command executed on the system. If you are responsible for hardening Linux servers, enabling auditd with appropriate rules is one of the highest-value actions you can take. Wazuh integrates natively with auditd logs.

Linux Persistence Mechanisms

When an attacker gains access to a Linux system, they want to ensure they can return even after a reboot or password change. These are the most common persistence techniques:

Common Linux persistence mechanisms — cron, systemd, SSH keys, init scripts, and LD_PRELOAD

Cron Jobs

Cron is the built-in task scheduler. Attackers add reverse shells or beacon scripts to cron:

# System-wide crontab
cat /etc/crontab

# Per-user crontabs
ls -la /var/spool/cron/crontabs/

# Cron directories (scripts here run automatically)
ls -la /etc/cron.d/
ls -la /etc/cron.daily/
ls -la /etc/cron.hourly/

# List all cron jobs for all users
for user in $(cut -f1 -d: /etc/passwd); do echo "--- $user ---"; crontab -u $user -l 2>/dev/null; done

Attackers use cron for callbacks. A typical persistence entry looks like: */5 * * * * /dev/shm/.x 2>/dev/null — runs every 5 minutes from a hidden file in shared memory. The file starts with a dot (hidden), lives in a tmpfs that disappears on reboot (anti-forensics), and stderr is suppressed. In Lab 3.6, you will identify planted cron entries like this.

Systemd Services

Modern Linux uses systemd for service management. Attackers create malicious unit files:

# Check for recently created service files
find /etc/systemd/system/ -name "*.service" -mtime -7

# Check for services in user directories
find /home -path "*/.config/systemd/user/*.service" 2>/dev/null

# List all enabled services
systemctl list-unit-files --state=enabled

# Check for suspicious service properties
systemctl cat suspicious-service.service

A malicious systemd service might look like:

[Unit]
Description=System Health Monitor

[Service]
ExecStart=/usr/local/bin/.health-check
Restart=always
RestartSec=30

[Install]
WantedBy=multi-user.target

init.d Scripts and rc.local

Legacy systems (and some modern ones) still support SysVinit scripts:

# Check init.d scripts modified recently
find /etc/init.d/ -mtime -7

# Check rc.local (runs at boot)
cat /etc/rc.local

Shell Profile Backdoors

Attackers add commands to shell configuration files that execute on every login:

# Files that execute on user login
cat /home/*/.bashrc
cat /home/*/.bash_profile
cat /home/*/.profile
cat /root/.bashrc

# Look for unusual commands (reverse shells, downloaders)
grep -r "curl\|wget\|nc\|/dev/tcp\|python.*import.*socket" /home/*/.*rc /home/*/.*profile /root/.*rc 2>/dev/null

SSH authorized_keys

As discussed in the authentication section, planting a public key in ~/.ssh/authorized_keys provides passwordless persistence.

LD_PRELOAD

The LD_PRELOAD environment variable forces the dynamic linker to load a shared library before all others. Attackers use this to hook system calls:

# Check for system-wide LD_PRELOAD
cat /etc/ld.so.preload

# Check for LD_PRELOAD in environment files
grep -r "LD_PRELOAD" /etc/environment /etc/profile.d/ /home/*/.*rc 2>/dev/null

at Jobs

The at command schedules one-time tasks. Unlike cron, at jobs run once and are sometimes overlooked:

# List pending at jobs
atq

# View the contents of a specific at job
at -c [job_number]

Investigating a Compromised Linux Server

When you suspect a Linux server has been compromised, use this investigation workflow:

Step 1: Volatile Data Collection

Collect data that will be lost on reboot or process termination first:

# Current network connections
ss -tulnp

# All running processes with full command lines
ps auxww

# Open files and network connections per process
lsof -i -n -P

# Currently logged-in users
who
w

# Login history
last -25

Step 2: User and Access Review

# Check for new or modified user accounts
awk -F: '($3 == 0) {print $1}' /etc/passwd

# Users with login shells
grep -v "nologin\|false" /etc/passwd

# Sudo group members
getent group sudo
getent group wheel

# All authorized_keys files
find / -name "authorized_keys" 2>/dev/null

# Recent sudoers changes
stat /etc/sudoers
ls -la /etc/sudoers.d/

Step 3: Persistence Hunt

# All cron jobs
for u in $(cut -f1 -d: /etc/passwd); do echo "=== $u ==="; crontab -u $u -l 2>/dev/null; done
ls -la /etc/cron.d/ /etc/cron.daily/ /etc/cron.hourly/

# Recently created systemd services
find /etc/systemd/ /lib/systemd/ -name "*.service" -mtime -30

# init.d and rc.local
ls -la /etc/init.d/
cat /etc/rc.local 2>/dev/null

# Shell profile backdoors
grep -rn "curl\|wget\|nc \|ncat\|/dev/tcp" /home/*/.*rc /home/*/.*profile /root/.*rc 2>/dev/null

# LD_PRELOAD
cat /etc/ld.so.preload 2>/dev/null

# at jobs
atq

Step 4: File System Analysis

# Files modified in the last 7 days in critical directories
find /etc /usr/local/bin /usr/bin -mtime -7 -type f

# SUID/SGID binaries (compare against baseline)
find / -perm -4000 -o -perm -2000 -type f 2>/dev/null | sort

# Hidden files in /tmp and /dev/shm
ls -la /tmp/.*  2>/dev/null
ls -la /dev/shm/.* 2>/dev/null

# Files with unusual names (spaces, dots, unicode)
find /tmp /var/tmp /dev/shm -name ".*" -o -name "* *" 2>/dev/null

# World-writable executables
find / -perm -o+w -type f -executable 2>/dev/null

Step 5: Log Analysis

# Failed authentication attempts
grep "Failed\|failure\|FAILED" /var/log/auth.log | tail -50

# Successful SSH logins
grep "Accepted" /var/log/auth.log | tail -50

# Sudo usage
grep "sudo:" /var/log/auth.log | tail -50

# Check for log gaps (attacker may have cleared logs)
ls -la /var/log/auth.log*
stat /var/log/auth.log
🚨

Check for log tampering. If /var/log/auth.log was modified recently or has an unexpectedly small file size, the attacker may have cleared it. Compare timestamps of log files with stat and check for gaps in log sequence numbers. Binary logs (wtmp, btmp) can also be truncated — compare the output of last against expected timeframes.

Key Takeaways

  • Linux processes form a tree rooted at PID 1 (systemd); unexpected parent-child relationships (e.g., nginx spawning bash) signal compromise
  • The /proc filesystem exposes live process data — command lines, open files, network connections, and loaded libraries — without needing special tools
  • SUID binaries are a top privilege escalation vector; baseline them on clean systems so you can detect new ones immediately
  • Linux authentication chains through /etc/passwd, /etc/shadow, PAM, and SSH authorized_keys — all must be reviewed during an investigation
  • Key log files are auth.log (SSH/sudo), syslog (general), audit.log (syscall-level), and wtmp/btmp (login records); auditd provides the deepest visibility when enabled
  • Attackers persist on Linux via cron, systemd services, .bashrc, authorized_keys, LD_PRELOAD, and at jobs — each must be checked during incident response
  • The investigation workflow follows a strict order: volatile data first (processes, connections), then user review, persistence hunt, filesystem analysis, and finally log analysis

What's Next

You now have the internal knowledge to investigate both Windows and Linux systems. In Module 4: Phishing Analysis & Email Security, you will shift from endpoint and OS internals to the most common initial access vector in real-world attacks — phishing emails. You will learn how to analyze email headers, trace message routing, extract and detonate suspicious attachments, identify credential harvesting pages, and build detection rules for malicious email patterns.

Knowledge Check: Linux Internals for Defenders

10 questions · 70% to pass

1

What is PID 1 on a modern Linux system, and why is it significant for defenders?

2

An investigator finds that /proc/4821/exe shows '(deleted)'. What does this indicate?

3

Which special file permission bit allows a program to execute with the privileges of the file owner (typically root)?

4

In Lab 3.6, you will baseline SUID binaries on a clean system. Which command finds all SUID binaries on a Linux system?

5

Which Linux log file records SSH logins, sudo usage, and failed authentication attempts?

6

An attacker adds the entry '*/5 * * * * /dev/shm/.x 2>/dev/null' to a crontab. What does this achieve?

7

In Lab 3.6, you investigate a compromised Linux server. Which command should you run FIRST during an investigation?

8

What is LD_PRELOAD and why is it a persistence concern on Linux systems?

9

In Lab 3.6, you compare a compromised server against its baseline. Which Linux logging subsystem provides the deepest visibility by auditing kernel-level syscalls?

10

How does Linux configuration storage differ from Windows, and where do defenders find configuration files on Linux?

0/10 answered