TR1.12 Module Summary

Module Summary — Evidence Volatility and the Preservation Hierarchy

The order of volatility (TR1.1). Updated RFC 3227 for 2026: five tiers from seconds (registers, active sessions, running processes) to years (archival media). Triage focuses on Tiers 1-3. The collection sequence: Tier 1 native commands (30 seconds), Tier 2 memory dump (2-5 minutes), Tier 3 log collection (5-15 minutes).

Cloud evidence volatility (TR1.2). Cloud evidence is persistent but finite. Time-sensitive during triage: active session tokens (1-hour expiry), OAuth consent grants (revocable by attacker), inbox rules (removable by attacker), MFA registrations. The 5-minute cloud preservation sequence captures all time-sensitive evidence and initiates critical containment.

Windows evidence volatility (TR1.3). Destroyed on reboot: memory, processes, network connections. Overwritten on activity: event logs (rotation), prefetch (1,024 limit). The 5-minute Windows capture: PowerShell Tier 1 commands (30 seconds) → WinPMem memory dump (2-5 minutes) → KAPE volatile collection (3-5 minutes). EvtxECmd for rapid event log parsing during triage.

Linux evidence volatility (TR1.4). Live-only: /proc filesystem, loaded kernel modules, network state. Container-ephemeral: Docker/Kubernetes writable layers destroyed on restart. The /proc capture script preserves per-process state. LiME for memory acquisition (requires pre-staged kernel module). Native commands (ps, ss, last) require no tools.

Preservation decision tree (TR1.5). One question: is the attacker actively causing damage? YES → contain first (stop damage, then preserve). NO → preserve first (capture evidence, then contain). Uncertain + high severity → default to contain first.

Cross-environment correlation (TR1.6). Three methods: timestamps (normalise to UTC, check clock drift), IP addresses (same external IP = same attacker, internal IP in Linux auth.log = lateral movement source), entity mapping (UPN vs SAM vs Linux username). KQL union query for cross-environment timelines.

Key artifacts produced

• Updated volatility hierarchy (5 tiers with time-to-loss)
• Cloud preservation checklist (5-minute sequence)
• Windows triage collection script (PowerShell + KAPE)
• Linux triage collection script (native + LiME)
• Preservation decision tree (one-question framework)
• Entity mapping table template
• Cross-environment KQL union query template

Interactive lab (TR1.7). Four preservation priority scenarios: active data exfiltration from a Linux database server (contain-first — block exfiltration IP at firewall, then preserve), dormant Cobalt Strike beacon on a Windows endpoint (preserve-first — memory dump captures beacon configuration before isolation), historical cloud compromise discovered during audit (preserve-first — snapshot sign-in logs before 30-day retention expires), and cross-environment double extortion with simultaneous encryption and exfiltration (contain exfiltration first — regulatory impact exceeds business disruption from encryption). Each scenario teaches the one-question decision tree from TR1.5: is the attacker actively causing damage RIGHT NOW?

The five evidence hierarchy principles from this module:

1. Collect from most volatile to least volatile — Tier 1 (seconds) before Tier 2 (minutes) before Tier 3 (hours). Never skip a tier to start at a lower one.
2. Cloud evidence is persistent but FINITE — session tokens expire in 1 hour, sign-in logs expire in 30 days, audit logs expire in 30-90 days. Snapshot during triage to ensure the investigation has the data regardless of future retention expiry.
3. Container evidence is ephemeral — Docker/Kubernetes writable layers are destroyed on container restart. Capture docker diff before anything triggers a restart.
4. Memory is irreplaceable — once the system reboots, memory is gone forever. No tool, no technique, no amount of investigation effort can recover memory contents after power loss. Capture memory first.
5. The preservation decision depends on the attacker’s state — active damage = contain first (stop the bleeding), dormant or historical = preserve first (maximise evidence for investigation). Both paths eventually complete both actions — only the sequence differs.

The cross-environment correlation principles from this module:

1. Normalise timestamps to UTC before correlating events across environments.
2. The same external IP in cloud sign-in logs and Linux auth.log confirms the same attacker infrastructure.
3. An internal IP appearing in Linux auth.log as an SSH source identifies the endpoint that was used for lateral movement.
4. Entity mapping (UPN vs SAM vs Linux username) must be pre-built before the incident — building it during triage wastes 5-10 minutes.
5. The KQL union query merges cloud and endpoint events into a single chronological timeline — add Linux events manually if not in Sentinel.

Check My Knowledge (TR1.9). Nine questions covering: volatility order for Windows endpoint triage, OAuth consent grant persistence through containment actions, kernel module rootkit hiding from lsmod, contain-first for active ransomware, timestamp normalisation for cross-environment correlation, Docker container ephemeral evidence urgency, cloud evidence retention calculation (25-day-old incident with 5 days remaining), LD_PRELOAD rootkit detection as definitive compromise indicator, and user pivot query revealing scope expansion from cloud to 3 endpoints.

The module in the course context. TR1 provides the preservation methodology that all subsequent modules depend on. TR2 (Cloud Triage) uses the cloud evidence volatility knowledge from TR1.2 to determine which evidence to capture first during cloud triage. TR3 (Windows Triage) uses the Windows volatility hierarchy from TR1.3 to structure the 10-command triage and KAPE collection. TR4 (Linux Triage) uses the Linux evidence knowledge from TR1.4 — including container evidence, /proc filesystem, and LiME memory acquisition. The preservation decision tree from TR1.5 governs every containment decision in TR2.5 (cloud containment), TR3.6 (Windows containment), and TR4.6 (Linux containment). The cross-environment correlation methodology from TR1.6 is the technique that connects findings across all three environment-specific triage modules.

Key operational artifacts from this module

The updated 5-tier volatility hierarchy (TR1.1) — RFC 3227 modernised for 2026 with cloud tokens, container layers, and distributed authentication state. The hierarchy governs every evidence collection decision in the course.

The cloud preservation checklist (TR1.2) — the 5-minute sequence for capturing time-sensitive M365 and Entra ID evidence: active sessions (minute 0-1), OAuth grants (1-2), inbox rules (2-3), MFA registrations (3-4), sign-in and audit log snapshot (4-5). Save as a printed checklist at the SOC workstation.

The Windows evidence collection script (TR1.3) — the PowerShell script that captures Tier 1 (processes, connections, sessions), Tier 2 (memory via WinPMem, scheduled tasks, autoruns), and Tier 3 (event logs via wevtutil, KAPE collection). Pre-stage on the triage USB drive.

The Linux triage collection script (TR1.4) — the bash script that captures /proc state, network connections, kernel modules, container evidence, auth.log, bash_history, and cron configurations. Pre-stage on USB or NFS mount.

The preservation decision tree (TR1.5) — the one-question framework: “Is the attacker actively causing damage RIGHT NOW?” YES = contain first. NO = preserve first. Post next to the volatility hierarchy on the SOC wall.

The entity mapping table template (TR1.6) — the cross-environment identity reference: cloud UPN, Windows SAM, Linux username, role. Build this for your environment BEFORE the next incident.

The cross-environment KQL union query template — the query that merges cloud and endpoint events into a single chronological timeline. Save in Sentinel as a reusable query.

The preparation checklist from this module. Before your next incident, verify: (1) Triage USB drive built with WinPMem + KAPE + MemProcFS + Sysinternals + triage scripts. (2) LiME pre-compiled for every Linux kernel version in your environment (or AVML staged as an alternative). (3) Entity mapping table created for your top 20 users across cloud/Windows/Linux. (4) Sentinel saved queries deployed: 5-query cloud triage pack, cross-environment union query. (5) Emergency conditional access policy pre-built in Report-only mode. (6) Triage report template added as Sentinel incident comment automation. Each item takes 10-30 minutes to prepare. The total preparation investment is 2-3 hours. This is the minimum viable preparation for evidence-aware triage — the analyst who completes these 6 items can collect, preserve, and correlate evidence across all three environments from the first incident. The items that take longest (LiME compilation, entity mapping) provide the most value because they eliminate the most common evidence collection failures (wrong kernel module, unresolvable entity names).

The continuous preparation cycle. Preparation is not a one-time task. KAPE targets update monthly (run –sync). LiME modules must be recompiled when kernel versions are updated. The entity mapping table must be refreshed when new employees join or roles change. The emergency CA policy must be tested quarterly to ensure it still blocks the intended traffic patterns. Schedule these maintenance tasks as recurring calendar items — the 30 minutes per month invested in maintenance ensures the tools work when the incident occurs. The return: 15-30 minutes saved on every incident for the life of the SOC (TR1.6) — the query that merges cloud and endpoint events into a single chronological timeline. Save in Sentinel as a reusable query with parameterised time range and user identity.

What comes next

TR2 — Cloud Triage. With the preservation methodology established, Module 2 teaches the full cloud triage workflow: the 5-query triage pack, identity alert triage, email alert triage, OAuth alert triage, and cloud containment actions. Every technique uses the evidence categories and preservation priorities from this module.