LX0.10 Building Your Linux IR Lab

Building Your Lab Environment: Practice Before the Incident

Why You Need a Lab

Every technique in this course is taught with hands-on exercises. You cannot learn to investigate SSH brute force by reading about it — you need to see the auth.log entries, run the grep commands, and trace the attacker’s session through the evidence. You cannot learn memory forensics by studying Volatility 3 documentation — you need a memory dump from a system with running processes, active network connections, and a loaded rootkit module.

The lab provides the environment where you practice these techniques safely, without risk to production systems and without needing a real compromised server. The lab VMs simulate the Northgate Engineering infrastructure described in this course. The scenarios are pre-built — you do not need to compromise the systems yourself (though LX16 includes tabletop exercises where you simulate the attacker’s actions to generate realistic evidence).

Lab Architecture

The minimum lab requires a forensic workstation (your analysis machine) and at least one Linux target VM (the system you investigate). The recommended lab adds additional VMs to simulate the Northgate Engineering infrastructure for multi-system scenarios.

Forensic Workstation: Your primary analysis machine. This can be a dedicated laptop, a desktop, or a VM. It runs the analysis tools (Sleuth Kit, Volatility 3, plaso, Wireshark) and stores the collected evidence. The workstation should not be the same machine as the target — you analyze evidence on the workstation, not on the compromised system.

Requirements: Ubuntu 22.04 LTS or later (the distribution used for tool examples in this course), 16GB RAM minimum (Volatility 3 and plaso are memory-intensive), 200GB free disk space (for disk images, memory dumps, and timeline databases), Python 3.10+ (for Volatility 3 and plaso).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

# Forensic workstation setup — install core analysis tools
sudo apt update && sudo apt install -y \
  sleuthkit \
  dc3dd \
  autopsy \
  wireshark \
  net-tools \
  python3-pip \
  python3-venv \
  git

# Install Volatility 3
python3 -m venv ~/tools/vol3
source ~/tools/vol3/bin/activate
pip install volatility3
deactivate

# Install plaso
python3 -m venv ~/tools/plaso
source ~/tools/plaso/bin/activate
pip install plaso
deactivate

# Clone UAC
git clone https://github.com/tclahr/uac.git ~/tools/uac

# Clone LiME (you will compile for each target kernel)
git clone https://github.com/504ensicsLabs/LiME.git ~/tools/lime

# Verify installations
echo "=== Verification ==="
fls -V          # Sleuth Kit
dc3dd --version # dc3dd
~/tools/vol3/bin/vol -h | head -1   # Volatility 3
~/tools/plaso/bin/log2timeline.py --version # plaso
echo "UAC: $(ls ~/tools/uac/uac)"   # UAC
echo "LiME: $(ls ~/tools/lime/src/lime.h)" # LiME source

Target VMs — Northgate Engineering Infrastructure:

WEBSRV-NGE01 (Web Server): Ubuntu 22.04 LTS. Nginx reverse proxy + PHP-FPM backend. Install a deliberately vulnerable web application for LX5 scenarios (DVWA, bWAPP, or a custom PHP application). Configure Nginx access and error logs in the default locations. Install auditd but do not configure comprehensive rules (to simulate a typical production server that has auditd installed but not fully deployed). This VM is the primary target for LX5 (Web Application Compromise), LX6 (Privilege Escalation), and LX8 (Cryptomining).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

# WEBSRV-NGE01 base setup
sudo apt update && sudo apt install -y nginx php-fpm php-mysql auditd
sudo systemctl enable nginx php8.1-fpm auditd

# Create a basic web application directory
sudo mkdir -p /var/www/app
# (Install DVWA or your chosen vulnerable app here)

# Configure Nginx
sudo tee /etc/nginx/sites-available/app << 'NGINX'
server {
    listen 80;
    server_name websrv-nge01;
    root /var/www/app;
    index index.php;
    access_log /var/log/nginx/app-access.log;
    error_log /var/log/nginx/app-error.log;
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/var/run/php/php8.1-fpm.sock;
    }
}
NGINX
sudo ln -sf /etc/nginx/sites-available/app /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

BASTION-NGE01 (Jump Host): Ubuntu 22.04 LTS. SSH server with both password and key authentication enabled (the misconfiguration that enables the LX4 brute force scenario). Create user accounts matching the Northgate Engineering names (j.morrison, s.chen, a.patel, r.williams, m.thompson). Set a deliberately weak password on one account (the account the attacker will brute force). Configure fail2ban with a high threshold (100 attempts) to simulate a poorly configured brute force protection.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

# BASTION-NGE01 base setup
sudo apt update && sudo apt install -y openssh-server auditd fail2ban

# Enable password authentication (intentional misconfiguration)
sudo sed -i 's/^PasswordAuthentication no/PasswordAuthentication yes/' /etc/ssh/sshd_config
sudo systemctl restart sshd

# Create Northgate Engineering users
for user in j.morrison s.chen a.patel r.williams m.thompson; do
    sudo useradd -m -s /bin/bash $user
    sudo mkdir -p /home/$user/.ssh
    sudo chown $user:$user /home/$user/.ssh
    sudo chmod 700 /home/$user/.ssh
done

# Set a weak password on one account (for brute force scenario)
echo "a.patel:Summer2026!" | sudo chpasswd

DBSRV-NGE01 (Database Server): Ubuntu 22.04 LTS. PostgreSQL 15. Configure with customer sample data. This VM is the lateral movement target in LX11 — the attacker pivots from the bastion or web server to the database server to access customer records.

K8S-NGE (Kubernetes Cluster): For LX9 (Container Compromise) scenarios. The simplest approach: install Minikube or k3s on a single VM to create a single-node Kubernetes cluster. Deploy a vulnerable container (an old Nginx version, a misconfigured Redis instance, or a container with an exposed Docker socket mount). Enable Kubernetes audit logging.

1
2
3
4
5
6
7
8

# Single-node k3s cluster (simplest setup)
curl -sfL https://get.k3s.io | sh -
sudo chmod 644 /etc/rancher/k3s/k3s.yaml
export KUBECONFIG=/etc/rancher/k3s/k3s.yaml

# Deploy a test pod
kubectl run test-web --image=nginx:1.21 --port=80
kubectl expose pod test-web --type=NodePort --port=80

Using Cloud Free Tiers for Lab Infrastructure

If you do not have a machine powerful enough to run multiple VMs locally, cloud free tiers provide sufficient resources for lab exercises:

AWS Free Tier: 750 hours/month of t2.micro EC2 instances (1 vCPU, 1GB RAM) for the first 12 months. Sufficient for BASTION-NGE01 and WEBSRV-NGE01. The t2.micro is too small for memory forensics exercises (LX12 requires a target with at least 2GB RAM) — use a t3.small for those exercises and terminate it when done.

Azure Free Tier: 750 hours/month of B1s VMs (1 vCPU, 1GB RAM) for the first 12 months. Same usage pattern as AWS. Azure also provides $200 credit for the first 30 days — use this for larger VMs during initial lab setup.

GCP Free Tier: e2-micro instances (0.25 vCPU shared, 1GB RAM) are always free. Supplement with the $300 credit for new accounts for larger instances during scenario exercises.

The cloud lab has an additional benefit: it provides the cloud-specific evidence sources (CloudTrail, Activity Log, Cloud Audit Logs) that you need for LX10 (Cloud VM Compromise) exercises. A purely local VM lab does not generate cloud audit trails.

Sample Data and Pre-Built Scenarios

Each scenario module (LX4–LX13) includes a pre-built evidence package that you can download and analyze on your forensic workstation without generating the evidence yourself. The evidence packages contain: UAC triage output from the compromised system, relevant log file excerpts, disk image segments (for filesystem forensics exercises), and memory dumps (for memory forensics exercises). These packages are available to premium subscribers.

For free-tier modules (LX0–LX1), the exercises use your own lab VMs and real-time commands. The lab setup described in this subsection provides everything needed for the free-tier exercises and for the premium scenario exercises where you want to generate evidence yourself rather than using the pre-built packages.

Connecting to the M365 Developer Tenant

If you have completed or are enrolled in the Practical IR: Windows and M365 course, your M365 developer tenant (from developer.microsoft.com) can be connected to the Linux lab to create cross-platform investigation scenarios. Install the Azure Arc agent on BASTION-NGE01 to register it as a hybrid server in Entra ID. Configure the Azure Monitor Agent (AMA) to forward syslog and auditd logs to a Log Analytics workspace. This creates the cross-environment evidence correlation capability described in LX10 and LX14 — Linux investigation findings appearing in the same Sentinel workspace as your M365 investigation data.

1
2
3
4
5
6
7
8
9

# Install Azure Arc agent on a lab VM
wget https://aka.ms/azcmagent -O ~/install_linux_azcmagent.sh
sudo bash ~/install_linux_azcmagent.sh

# Connect to Azure (follow the interactive authentication prompt)
sudo azcmagent connect --resource-group "NorthgateEng-Lab-RG" \
  --tenant-id "YOUR_TENANT_ID" \
  --location "uksouth" \
  --subscription-id "YOUR_SUBSCRIPTION_ID"

This connection is optional. Every exercise in this course can be completed with local tools and local log files. The Azure Arc integration adds the cross-platform dimension for investigators who work in hybrid environments.

Beyond This Investigation

The lab VMs are used throughout the course. LX1 uses the lab for evidence collection practice. LX4 uses BASTION-NGE01 for the SSH brute force scenario. LX5 uses WEBSRV-NGE01 for the web application compromise. LX9 uses K8S-NGE for container forensics. LX12 uses any of the target VMs for memory acquisition and analysis practice. Build the minimum lab now — you will expand it as you progress through the course.

Worked artifact — Lab setup verification checklist:

Run each verification command after setup. Every failure is a gap to fix before the next exercise.

Forensic workstation: ☐ fls -V → Sleuth Kit version displayed ☐ vol -h | head -1 → Volatility 3 help displayed ☐ log2timeline.py --version → plaso version displayed ☐ dc3dd --version → dc3dd version displayed ☐ ls ~/tools/uac/uac → UAC script present ☐ ls ~/tools/lime/src/lime.h → LiME source present

Target VM (BASTION-NGE01): ☐ SSH accessible from workstation ☐ User accounts created (j.morrison, s.chen, a.patel, r.williams, m.thompson) ☐ auth.log generating events ☐ auditd installed (rules optional for now)

Troubleshooting: common lab setup issues

Volatility 3 fails to install. Check Python version — requires 3.8+. Use a virtual environment: python3 -m venv ~/tools/vol3 && source ~/tools/vol3/bin/activate && pip install volatility3.

LiME compilation fails. Kernel headers not installed. Run sudo apt install linux-headers-$(uname -r) on the target system.

Cannot SSH from workstation to target VM. Check: is SSH server running on the target (sudo systemctl status sshd)? Is the firewall blocking port 22 (sudo ufw status)? Are the VMs on the same network?