The Linux IR Landscape

What this course is

This is a practical incident response course for Linux systems — bare-metal servers, cloud VMs, and containers. Seventeen modules take you from the Linux evidence landscape through complete investigation scenarios covering every attack type you'll encounter on production Linux infrastructure.

The alert fires at 03:17 on a Thursday. Your monitoring system reports a CPU spike on WEBSRV-NGE01 — a production web server running Ubuntu 22.04 behind an Nginx reverse proxy. CPU utilization has jumped from its normal 12% to 98%. You SSH in, run top, and see a process called [kworker/2:1+] consuming 94% of CPU. The square brackets look like a kernel thread — but kernel threads don't consume 94% of CPU for 40 minutes. You run ps auxf and the process appears under a PHP-FPM worker, not the kernel. A kernel thread spawned by PHP is not a kernel thread. It's a cryptominer named to look like one.

Now the investigation begins. How did the attacker get in? What vulnerability? How long have they been present? Did they establish persistence? Did they move laterally? Did they access the database? The answers exist somewhere on this server — in the filesystem, in the logs, in memory. But they exist in different places than you're used to looking. There is no Windows Event Log. No registry. No Prefetch. No NTFS MFT. The evidence model is fundamentally different from Windows, and if you apply Windows investigation instincts to a Linux server, you will miss artifacts, misinterpret timestamps, and draw incorrect conclusions.

This course teaches the systematic investigation methodology for Linux systems — where evidence lives, how to collect it without destroying it, how to analyze it, and how to follow the attacker across the three deployment environments that define modern Linux infrastructure: bare-metal servers, cloud VMs, and containers. Every investigation scenario uses Northgate Engineering's Linux infrastructure — the same organization you know from the Windows IR and M365 courses, investigated from the Linux side.

What this course teaches

Seventeen modules across three phases. LX0 and LX1 are free — no account required.

Phase 1 — Foundation (LX0, LX1). You are here now. LX0 maps the Linux evidence landscape — where artifacts live, why they differ from Windows, the three investigation environments, the attacker's perspective on Linux targets, and the volatility problem. LX1 covers evidence collection and triage — acquisition methodology, live response commands, disk imaging, memory capture with LiME, volatile data collection order, and the triage framework that gets you from alert to initial findings in 30 minutes.

Phase 2 — Investigation Scenarios (LX2–LX13). Twelve modules covering the full investigation skill set. Linux filesystem forensics — ext4 internals, timestamps (MAC/CRTIME), deleted file recovery, timeline construction with plaso (LX2). Linux log analysis — journald, syslog, auth.log, application logs, log correlation and timeline building (LX3). SSH brute force and credential compromise (LX4). Web application compromise — Apache/Nginx analysis, PHP/Python exploitation, web shell investigation (LX5). Privilege escalation — sudo abuse, SUID/capability exploitation, kernel exploits (LX6). Persistence mechanisms — cron, systemd, shell profiles, SSH authorized_keys, library injection (LX7). Cryptomining and resource abuse (LX8). Container compromise — Docker escape, Kubernetes pod compromise, container forensics (LX9). Cloud VM compromise — AWS/Azure metadata abuse, cloud-native attack patterns (LX10). Lateral movement — SSH pivoting, credential reuse, internal network movement (LX11). Linux memory forensics with Volatility 3 — process analysis, rootkit detection, credential extraction from memory (LX12). Linux malware analysis for IR — static and dynamic triage, ELF analysis, reverse shell identification (LX13).

Phase 3 — Operations (LX14–LX16). Three modules building the operational capability. IR reporting and evidence handling — technical reports, executive summaries, chain of custody for Linux evidence (LX14). Linux detection engineering and hardening — auditd rules, Sysmon for Linux, YARA rules, and the detection coverage that prevents the next incident (LX15). Building Linux IR readiness — the tools, the procedures, the monitoring, and the organizational preparation that means your team is ready before the next Linux incident (LX16).

You can study the course linearly (LX0 → LX16) or selectively once Phase 1 is complete. Phase 2 modules can be reordered based on your environment — if web servers are your primary concern, start with LX5; if containers dominate, start with LX9. LX2 (filesystem forensics) and LX3 (log analysis) are foundational skills used in every subsequent module — complete those two before jumping to specific scenarios. Phase 3 requires Phase 2 concepts.

Who this course is for

Anyone who investigates security incidents on Linux systems — whether that's your primary role or something you handle alongside Windows and cloud work.

SOC analyst expanding into Linux. You triage alerts and investigate incidents in Windows and M365. But your organization runs Linux servers — web servers, jump boxes, CI/CD runners, database hosts. When one is compromised, you need the investigation skills to follow the attacker through filesystem artifacts, log files, and memory. This course provides the systematic methodology.

IR practitioner in mixed environments. You handle incidents across Windows, M365, and Linux. Your Windows forensics is strong. Your Linux investigation is ad hoc — you know some commands but not the systematic methodology. This course provides the structure that makes Linux investigation as rigorous as your Windows work.

Cloud security analyst. Your environment is cloud-native — EC2 instances, Azure VMs, GKE nodes, containers. The VMs run Linux. The containers run Linux. When a cloud workload is compromised, the investigation starts at the Linux layer. LX9 (containers), LX10 (cloud VMs), and LX12 (memory forensics) are the core modules for you.

Detection engineer building Linux coverage. You write detection rules for Windows and M365. Your Linux detection coverage is minimal — maybe some basic auditd rules. LX15 (detection engineering and hardening) teaches auditd rule writing, Sysmon for Linux deployment, and YARA rule integration for Linux endpoints.

Anyone who completed the Practical IR (Windows) course. You investigated NE incidents from the Windows and M365 side. This course investigates NE incidents from the Linux side — the same organization, sometimes the same attack chains, viewed through a different evidence source. The lateral movement that the Windows investigation traced to a Linux jump box? This course picks up where that investigation left off.

Prerequisites

Two required, one recommended.

Linux command line comfort. You should be able to navigate the filesystem with cd, ls, find, and grep. You should understand file permissions (rwx), process management (ps, kill), and basic text processing (cat, less, head, tail, awk). You do not need to be a Linux administrator — the course teaches the investigation-specific commands. If the Linux command line is entirely unfamiliar, spend a week with a Linux VM and a beginner's guide before starting Phase 2.

Basic investigation concepts. You should understand what evidence preservation means, why timestamps matter, and the difference between volatile and non-volatile evidence. If you've completed the Incident Triage course or the Practical IR (Windows) course, you have this. If you're coming directly to Linux IR, LX0 and LX1 cover the Linux-specific evidence model from the ground up — prior IR experience accelerates but isn't strictly required.

Recommended: Windows IR experience. Many real-world investigations span both Windows and Linux. Understanding how Windows artifacts work makes the comparison points in LX0 more meaningful and helps you build cross-platform investigation timelines. The Practical IR course provides this. Not required — the course teaches Linux IR as a standalone discipline.

Nothing else is required. No programming, no kernel development, no forensic certifications. The course teaches the forensic methodology using free, open-source tools.

Lab setup

A single Ubuntu VM and free open-source tools. No cloud subscription, no commercial forensic software.

Ubuntu 22.04 LTS VM. The primary investigation environment. 4 GB RAM, 40 GB disk, 2 CPU cores. Runs on VMware Workstation Pro (free), VirtualBox, or Hyper-V. Can also be a cloud instance (AWS free tier, Azure free tier) if you prefer. LX0 provides complete setup instructions.

Investigation toolkit (free, installed per module). Sleuth Kit for filesystem forensics. Volatility 3 for memory analysis. plaso/log2timeline for super-timeline construction. LiME for memory acquisition. YARA for malware detection. Each tool is installed when the relevant module requires it — not all at once.

Lab pack (downloadable). Realistic Linux evidence from Northgate Engineering incidents: auth.log files, syslog extracts, filesystem timeline exports, memory images, container artifacts, and web server logs with planted attack indicators. Downloaded per module.

Docker (for LX9). Container investigation requires Docker installed on your lab VM. Free, installed when you reach LX9.

What you can skip: you don't need to install anything before starting LX0. The first module is the evidence landscape — concepts and methodology. Set up your Ubuntu VM when you reach LX1. Install tools and download lab packs as each module requires them.

How the course is structured

Every module from LX2 onward follows the same pattern.

Objective header. The investigation problem the subsection solves, the finding it produces, and the time estimate.

Diagram. Every subsection has an SVG diagram — the evidence location map, the attack flow, the filesystem structure, or the investigation decision tree.

Worked investigations. Complete investigation walkthroughs with real Linux evidence — the raw log entries, the actual commands and their output, the analysis reasoning, and the finding. 176 investigation walkthroughs across the course.

Decision Point. Investigation judgment calls — is this process malicious or legitimate, does this log entry indicate compromise or misconfiguration, has the attacker established persistence or just achieved initial access.

Try-it. Investigate the evidence yourself. Four components: Setup (the evidence files), Task (find the specific artifact), Expected Result (the correct finding), and Debugging Branch (what to check if your analysis differs).

Compliance Myth. Linux investigation misconceptions — "Linux doesn't get hacked," "containers are ephemeral so there's no evidence," "if the attacker has root it's game over for the investigation."

Artifact footer. The operational artifact — a command reference, an investigation checklist, a detection rule, a collection script.

Module completion pattern. Each module has content subsections (eight to fourteen), an interactive lab or structured investigation exercise, a module summary, and a Check My Knowledge subsection with scenario-based questions. Investigation scenario modules (Phase 2) are the most intensive.

Time per phase

The course is self-paced. No cohorts, no deadlines, no streaks.

Phase 1 (LX0, LX1): One to two evenings. LX0 is the evidence landscape (3–4 hours). LX1 is collection and triage methodology (4–5 hours).

Phase 2 (LX2–LX13): Seven to ten weeks at five to eight hours per week. Twelve modules covering every investigation scenario. LX5 (web application compromise) and LX9 (container compromise) are the longest modules.

Phase 3 (LX14–LX16): Two to three weeks. Three modules covering reporting, detection engineering, and readiness. LX15 (detection and hardening) is the most intensive in this phase.

Full course at five to eight hours per week: ten to eighteen weeks. This course pairs naturally with the Windows IR course — investigating the same NE environment from both sides builds complete cross-platform investigation capability.

Start here

Go to LX0.1 next. It establishes why Linux evidence is fundamentally different from Windows — where things live, what's volatile, what survives a reboot, and what disappears the moment you run the wrong command. Understanding the evidence model is the foundation for every investigation that follows.

After LX0.1, the remaining LX0 subsections cover the three investigation environments (bare-metal, cloud VM, container), the attacker's perspective on Linux targets, the volatility problem and collection order, the NE Linux infrastructure, the investigation toolchain, and a scenario-based knowledge check.

Work through LX0 in order. The evidence model and volatility hierarchy from LX0 are the foundation every subsequent module applies.