LX0.6 Course Structure and Connections

How This Course Is Organized — and Where It Connects

Three Phases, One Methodology

This course follows the same investigation methodology as the Practical IR: Windows and M365 course — the six-step pattern (what to look for, where to find it, how to extract it, how to interpret it, what it proves, what to do next) applied to a different operating system with different evidence sources and different tools. An investigator who completes both courses can follow an attacker across any environment: Windows endpoints, M365 cloud services, Linux servers, containers, and cloud VMs.

Phase 1 (Foundation — LX0 through LX3) builds the evidence model. You are here in LX0, learning where evidence lives and why the Linux investigation approach is structurally different from Windows. LX1 teaches the collection toolkit — UAC, live response commands, cloud-specific collection methods. LX2 teaches filesystem forensics — ext4 inodes, timestamps, deleted file recovery, timeline generation with plaso and Sleuth Kit. LX3 teaches log analysis — syslog, journald, auditd, authentication logs, web server logs, and the query techniques that extract investigation answers from each source. These four modules provide the foundational skills for every scenario in Phase 2.

Phase 2 (Investigation Scenarios — LX4 through LX13) applies the foundational skills to ten realistic investigation scenarios. Each scenario follows a single investigation from initial alert through evidence collection, analysis, containment, and detection rule deployment. The scenarios cover the complete Linux attack lifecycle: SSH brute force and credential compromise (LX4), web application compromise (LX5), privilege escalation (LX6), persistence mechanisms (LX7), cryptomining and resource abuse (LX8), container compromise (LX9), cloud VM compromise (LX10), lateral movement (LX11), memory forensics (LX12), and malware analysis for IR (LX13).

The scenarios are not independent — they form a connected investigation thread. The web application compromise in LX5 leads to the privilege escalation in LX6. The persistence mechanisms in LX7 are deployed by the attacker who escalated in LX6. The lateral movement in LX11 originates from the compromised server in LX4. The memory forensics in LX12 reveals the rootkit that was hiding the processes investigated in earlier modules. This connected thread mirrors how real investigations develop: you pull one thread and it leads to three more.

Phase 3 (Operations — LX14 through LX16) converts investigation skills into organizational capability. LX14 covers IR reporting and evidence handling — producing the reports that communicate findings to leadership, legal, and regulators. LX15 covers detection engineering — converting the investigation findings from Phase 2 into auditd rules and SIEM analytics rules that detect the same attack patterns in the future. LX16 covers building Linux IR readiness — the toolkit, the playbook, the tabletop exercises, and the cross-platform integration with your existing Windows and M365 IR programme.

The Northgate Engineering Linux Environment

Every investigation scenario in this course takes place within the Northgate Engineering fictional environment — the same organization used across the Ridgeline curriculum. The Linux infrastructure consists of:

WEBSRV-NGE01 — Ubuntu 22.04 LTS production web server running Nginx reverse proxy with PHP-FPM backend. This server is the primary target in LX5 (Web Application Compromise) and the initial foothold for the connected investigation thread.

DBSRV-NGE01 — Ubuntu 22.04 LTS database server running PostgreSQL 15. Connected to WEBSRV-NGE01 via internal network. Contains the customer database. This server is the lateral movement target in LX11.

BASTION-NGE01 — Ubuntu 22.04 LTS bastion (jump) host. All SSH access to internal servers routes through this host. This server is the primary target in LX4 (SSH Brute Force) and the pivot point for lateral movement.

K8S-NGE — Kubernetes cluster (3 nodes, Ubuntu 22.04 LTS) running the customer-facing API. Uses Docker as the container runtime. This cluster is the investigation environment in LX9 (Container Compromise).

RUNNER-NGE01 — Ubuntu 22.04 LTS CI/CD runner executing GitLab CI pipelines. Has SSH access to deployment targets. This server represents the supply chain attack surface.

All servers use the same base configuration: SSH key-based authentication (with password authentication still enabled on the bastion — the misconfiguration that enables the LX4 scenario), auditd installed but not fully configured (enabling the comparison between systems with and without comprehensive audit rules), and rsyslog forwarding to a central log server (enabling log recovery for servers where local logs were destroyed).

Connection to the Windows IR Course

If you have completed (or plan to complete) the Practical IR: Windows and M365 course, the two courses are designed to complement each other. The investigation methodology is identical — the six-step pattern does not change between operating systems. The evidence sources are different — registry vs /etc, Event Log vs syslog/journald, Prefetch vs auditd, MFT vs ext4 inodes. The tools are different — KAPE vs UAC, EZTools vs Sleuth Kit, KQL vs grep/awk/journalctl.

The most valuable connection: many real incidents span both environments. An AiTM phishing attack against M365 (investigated with Windows IR techniques) may result in a compromised credential that is used to SSH into a Linux server (investigated with Linux IR techniques). A web application compromise on a Linux server (investigated with Linux IR techniques) may exfiltrate data that is stored in SharePoint (investigated with M365 cloud techniques). The investigator who can work across both environments follows the attacker wherever they go — rather than handing off at the environment boundary and hoping the other team finds the same thread.

Connection to Other Ridgeline Courses

Practical Threat Hunting in M365 shares the hypothesis-driven methodology. The threat hunting course teaches you to form hypotheses and test them with KQL. This course teaches you to form hypotheses and test them with Linux commands and log analysis. The detection engineering outcomes are the same — findings that produce new detection rules.

SOC Operations provides the operational framework. The SOC Operations course covers detection rule lifecycle management, triage procedures, and incident response reporting. The detection rules you create in LX15 deploy into the same operational framework.

Practical GRC provides the governance context. The GRC course covers incident response plan requirements, regulatory notification obligations, and evidence handling standards. The reporting and evidence handling procedures in LX14 align with those governance requirements.