Sign In
In this section

LX0.6 Course Structure and Connections

3-4 hours · Module 0 · Free

How This Course Is Organized — and Where It Connects

Navigation Guide
This subsection maps the course structure — three phases, seventeen modules, and the connections between this course and the other Ridgeline Cyber Defence training courses. Use it as a navigation reference to plan your learning path.
Deliverable: Understanding of the course structure, module dependencies, and how this course connects to the Practical IR: Windows and M365 course and the other platform courses.
⏱ Estimated completion: 10 minutes

Three Phases, One Methodology

PRACTICAL LINUX IR — COURSE STRUCTURE Phase 1: Foundation LX0: Linux IR Landscape LX1: Evidence Collection LX2: Filesystem | LX3: Log Analysis Phase 2: Investigation LX4-LX10: Seven attack scenarios LX11: Lateral movement campaign LX12: Memory | LX13: Malware Phase 3: Operations LX14: IR Reporting LX15: Detection Engineering LX16: IR Readiness INVESTIGATION METHODOLOGY (ALL MODULES) Six-Step Pattern: What to look for → Where to find it → How to extract → How to interpret → What it proves → What to do next Same methodology across Windows, Linux, containers, and cloud — different evidence sources, different tools, same approach
Figure LX0.6 — Course structure across three phases. Phase 1 builds foundation skills. Phase 2 applies them in investigation scenarios. Phase 3 converts skills into organizational capability.

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.

# === LEARNING PATH READINESS CHECK ===

# Check 1: Do you have a Linux system for practice?
echo "=== LAB ENVIRONMENT ==="
uname -a       # Should show a Linux kernel (Ubuntu 22.04 recommended)
cat /etc/os-release | head -3

# Check 2: Are core investigation tools available?
echo "=== INVESTIGATION TOOLS ==="
which sleuthkit 2>/dev/null || which fls 2>/dev/null || echo "Sleuth Kit: NOT INSTALLED"
which volatility3 2>/dev/null || python3 -c "import volatility3" 2>/dev/null && echo "Volatility: OK" || echo "Volatility: NOT INSTALLED"
which yara 2>/dev/null || echo "YARA: NOT INSTALLED"

# Check 3: Are log analysis tools available?
echo "=== LOG ANALYSIS TOOLS ==="
which journalctl 2>/dev/null && echo "journalctl: OK"
which ausearch 2>/dev/null && echo "ausearch (auditd): OK" || echo "auditd: NOT INSTALLED"
which jq 2>/dev/null && echo "jq (JSON): OK" || echo "jq: NOT INSTALLED"

# Phase 1 (LX0-LX3): requires basic Linux command line proficiency
# Phase 2 (LX4-LX13): requires tools from Phase 1 + lab environment
# Phase 3 (LX14-LX16): requires understanding from Phase 2 scenarios
Expand for Deeper Context

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 program.

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.

MGMT-NGE01 — Ubuntu 22.04 LTS management server running Ansible for configuration management across the Linux fleet. Has SSH access to all production servers via service account. This server is a high-value target because compromising it provides access to every server it manages. The lateral movement campaign in LX11 traces the attacker's path through this server.

CLOUD-WEB-NGE01 — Ubuntu 22.04 LTS EC2 instance in AWS running a customer-facing microservice. Connected to the on-premises environment via VPN. This server is the investigation target in LX10 (Cloud VM Compromise) and demonstrates the differences between on-premises and cloud-based evidence collection, including AWS-specific sources like CloudTrail, VPC Flow Logs, and IMDS access logs.

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). These deliberate misconfigurations are the gaps that the attacker exploits in the investigation scenarios and that the detection engineering in LX15 addresses. The network uses standard segmentation: a DMZ for the web tier, an internal VLAN for database and application servers, a management VLAN for the bastion and CI/CD runner, and a VPN tunnel to AWS for the cloud-hosted microservice.

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.

Verifying Your Learning Path Readiness

Before starting the investigation scenarios in Phase 2, verify that your lab environment and toolkit are ready.

Compliance Myth: "You must complete every module in exact order — skipping ahead means missing critical context." Reality: Phase 1 (LX0-LX3) should be completed in order because each module builds on the previous. But within Phase 2 (LX4-LX13), the investigation scenarios can be taken in any order based on your immediate priorities. If your organization runs Kubernetes, start with LX9. If you are responding to a web compromise today, start with LX5. The connected investigation thread adds depth if you follow the sequence, but each scenario stands alone as a complete investigation. Phase 3 (LX14-LX16) requires Phase 2 context for the worked examples but the operational procedures are valuable even without completing every scenario.

Try it yourself

Try It — Map Your Learning Path Try It — Map Your Learning Path

Based on your current role and immediate needs, identify your priority modules. If you operate Linux web servers: prioritize LX5, LX6, LX7. If you manage Kubernetes: prioritize LX9. If you are building detection capability: prioritize LX15. Write down your top 3 priority modules and the order you will complete them.

Check your understanding:

1. What are the three phases of this course, and what capability does each phase build? 2. How do the investigation scenarios in Phase 2 connect to each other? 3. Which Northgate Engineering server is the primary target for the SSH brute force scenario, and why is it vulnerable? 4. An incident involves an AiTM phishing attack that leads to SSH access on a Linux server. Which two Ridgeline courses cover the full investigation?

Subsection artifacts: Course structure overview and Northgate Engineering Linux infrastructure reference. The infrastructure names and configurations are consistent across all scenario modules.

Beyond this investigation: Each module in the course builds on the foundation established here. LX4 begins the investigation scenario series, and LX15-LX16 close the course with detection engineering and IR program building.
Decision point

You are investigating a Linux server and discover evidence of both a cryptominer (resource abuse) and an SSH key theft (lateral movement preparation). The cryptominer is consuming 95% CPU and impacting production. Which do you address first?

Address the lateral movement first. The cryptominer is visible, noisy, and contained to this server — it is causing performance impact but not spreading. The SSH key theft is silent, potentially already exploited, and may have given the attacker access to additional servers. Contain the lateral movement risk: rotate the stolen SSH keys, check the target servers for unauthorized access, and apply network restrictions. Then address the cryptominer: kill the process, remove the binary and persistence mechanisms. Prioritizing the noisy but contained threat over the silent but spreading threat is the most common Linux IR prioritization mistake.

© 2026 Ridgeline Cyber Defence™ Ltd. Content may not be reproduced or redistributed. Worked artifacts may be adapted for use within your organization.
Unlock the Full Course See Full Course Agenda
← Previous Next →