In this section
TR1.10 Interactive Lab: Preservation Priority
Sections 1.1–1.9 built the complete evidence volatility framework: the order of volatility (1.1), environment-specific capture sequences for cloud (1.2), Windows (1.3), and Linux (1.4), memory acquisition tools (1.5), the preservation decision tree (1.6), chain of custody (1.7), cross-environment correlation (1.8), and live response automation (1.9). This lab puts all of it together. Three scenarios present different attacker states across different environments. For each, you determine the sequence, select the evidence, and choose the containment action — then check your reasoning against the reference.
Scenario
Three incidents land in the NE SOC queue within the same week. Each involves a different attacker state, a different combination of environments, and a different set of constraints on what the triage responder can do. For each scenario, answer four questions before opening the reference answer: (1) Preserve first or contain first? (2) What is your first action? (3) What evidence do you capture and in what order? (4) What containment action do you execute, and what is its blast radius?
Figure TR1.10 — Lab scoring framework. Each scenario tests three skills: assessing the attacker's current state, selecting evidence in the correct volatility order, and choosing containment actions that minimize evidence destruction.
How to work this lab
Read each scenario's context carefully — the attacker's current state is described in the details, not stated as a label. You must assess whether the attacker is active or dormant from the evidence provided, the same way you would during a real triage. Write your four answers on paper or in a text file before opening the reference answer. The reference shows one valid approach — your approach may differ if your reasoning accounts for the same factors.
Score yourself on three skills per scenario. Skill 1: did you correctly assess the attacker's state (active vs dormant) from the evidence? Skill 2: did you identify the most volatile evidence specific to this scenario? Skill 3: did you choose a containment action that stops the damage with minimum evidence destruction? Each skill is worth 3 points per scenario. Target: 7+ per scenario.
Scenario 1: Active data exfiltration from Linux database server
Context: Alert fires at 14:22: sustained outbound data transfer from SRV-NGE-BRS-DB01 (RHEL 9.2 database server, bare metal, no containers) to 45.155.205.99 on port 443. The transfer has been active for 12 minutes. Network monitoring shows 2.3 GB transferred so far at a steady 3.2 MB/s. The database contains engineering drawings and customer PII protected under GDPR. The process performing the transfer is curl running as svc-dbadmin with PID 28431.
The svc-dbadmin account authenticated via SSH from 10.50.1.22 (a workstation in the engineering subnet) at 14:08. The server runs kernel 5.14.0-362.24.1.el9_3.x86_64. LiME has not been pre-compiled for this kernel version. AVML is available on the IR USB.
Your task: Answer all four questions before opening the reference.
Reference answer — Scenario 1
Decision: CONTAIN FIRST. The 12-minute active transfer of PII is ongoing damage. Every additional minute increases the GDPR notification scope. The steady 3.2 MB/s rate confirms this is not a completed transfer — the attacker is still exfiltrating.
First action: Block 45.155.205.99 at the network perimeter firewall. This stops the exfiltration instantly without modifying the server's state. The curl process (PID 28431) continues running — it will fail on its next write attempt — preserving the process in memory with its full command line, environment variables, and open file descriptors. If firewall access is unavailable within 60 seconds, fall back to a host-based block: iptables -A OUTPUT -d 45.155.205.99 -j DROP on the server. Document the iptables change as a triage modification.
Evidence capture (after containment):
Tier 1 (immediate): cat /proc/28431/cmdline (the full curl command with URL, headers, and any authentication tokens), cat /proc/28431/environ (environment variables — may contain database credentials or API keys), ss -tnp (connection state after firewall block — expect CLOSE_WAIT), last -i (SSH sessions for svc-dbadmin, confirms 10.50.1.22 as source).
Tier 2 (2–5 minutes): AVML memory acquisition — ./avml --compress /evidence/memory.lime.snappy. Check whether kernel_lockdown is enabled on this RHEL system (cat /sys/kernel/security/lockdown). If AVML fails, document the failure and proceed — LiME is not available for this kernel. Capture /proc state for all processes using the TR1.4 collection script.
Tier 3: auth.log or secure (SSH authentication for svc-dbadmin), bash_history for svc-dbadmin (commands typed in the session), database audit logs (which tables were queried, what data was prepared for export). Hash all evidence files with SHA256 at completion.
Containment complete: Firewall block (exfiltration stopped) + svc-dbadmin account disabled in AD + SSH key for svc-dbadmin revoked + the source workstation 10.50.1.22 queued for investigation as a potential earlier compromise.
Why this sequence: Active exfiltration of GDPR-protected PII demands immediate containment. The firewall block is the optimal first action because it stops the damage with zero evidence destruction on the endpoint. Every other containment option (host firewall, account disable, network isolation) either modifies the server's state or takes longer to execute. The firewall block buys time for complete evidence capture.
Scenario 2: Dormant Cobalt Strike beacon on Windows endpoint
Context: During a proactive threat hunt, the security engineer discovers that DESKTOP-NGE-ENG07 (Windows 11, managed by Defender for Endpoint) has been beaconing to 91.215.85.142 every 60 seconds for 5 days. The beacon process is rundll32.exe loading C:\Users\a.chen\AppData\Local\Temp\msedge_update.dll. DeviceNetworkEvents shows consistent 312-byte payloads for every check-in over the past 120 hours — heartbeat traffic only, no command-and-control tasking. No lateral movement detected from this endpoint. No data exfiltration detected.
The user a.chen is a mechanical engineer with access to CAD file shares and the engineering project management system. The endpoint is powered on and logged in — a.chen is currently at their desk working.
Your task: Answer all four questions before opening the reference.
Reference answer — Scenario 2
Decision: PRESERVE FIRST. Five days of consistent heartbeat-only traffic confirms dormancy. The access broker compromised the endpoint and planted the beacon but has not sold or activated the access. No lateral movement, no exfiltration, no command tasking — the attacker is waiting. This gives the response team a preservation window.
First action: Capture memory. The beacon's decrypted configuration — including the full C2 infrastructure URL, Malleable C2 profile, watermark (team server identifier), and sleep/jitter settings — exists only in the running process's memory. A memory dump is the single most valuable artifact for the investigation team because it reveals the attacker's infrastructure in a way that network traffic analysis cannot (the HTTPS traffic is encrypted). Run WinPMem: winpmem_mini_x64.exe E:\IR\DESKTOP-NGE-ENG07_memory.raw. Duration: 3–5 minutes depending on RAM.
Evidence capture (while memory dumps):
Tier 1 (parallel with memory): Get-Process | Select-Object Id,ProcessName,Path,CommandLine (full process tree — identify rundll32 parent chain), Get-NetTCPConnection | Where-Object {$_.RemoteAddress -eq '91.215.85.142'} (document the beacon connection with owning PID), query user (confirm a.chen is logged in).
Tier 2 (after memory completes): Loaded DLLs for the rundll32 process (Get-Process -Id [PID] | Select-Object -ExpandProperty Modules), scheduled tasks and Run/RunOnce registry keys (persistence mechanisms beyond the DLL), DNS cache (Get-DnsClientCache) — may show resolution history for the C2 domain.
Tier 3: KAPE triage collection — Prefetch (shows when msedge_update.dll first executed, establishing the initial compromise date), AmCache (records the DLL's SHA256), event logs (any authentication anomalies around the initial compromise date 5 days ago). SHA256 hash all evidence files.
Containment (after preservation): Network-isolate DESKTOP-NGE-ENG07 via Defender for Endpoint. Isolation keeps the system powered on with all evidence intact but blocks all network traffic except the Defender management channel. The beacon process continues running (cannot reach C2) and remains available for analysis via Live Response. Do NOT delete msedge_update.dll — it is evidence. Do NOT reboot — memory evidence would be destroyed.
The user communication: Because a.chen is at their desk, the analyst coordinates with a.chen's manager before executing isolation. The analyst does not tell a.chen the endpoint is compromised — the user might panic and shut down the system, destroying volatile evidence. The manager removes a.chen from the workspace on a pretext while the triage team executes evidence capture.
Why this sequence: The 5-day dormancy provides a comfortable preservation window. The beacon's memory footprint is the crown jewel — it gives the investigation team the attacker's infrastructure details, which enable them to search for additional compromised endpoints using the same C2 configuration. Containing before memory capture would terminate the connection and potentially trigger anti-forensic routines in the beacon that wipe the DLL from disk.
Scenario 3: Historical cloud compromise discovered during audit
Context: During a quarterly access review, Elena (GRC analyst) discovers that m.brooks@northgateeng.com (VP of Operations) has an OAuth application called "DocuSync Pro" with Mail.ReadWrite and Files.ReadWrite.All permissions consented 18 days ago. m.brooks does not recognise the application. The application's publisher is a free-tier Azure AD tenant registered to "docusync-pro-corp.onmicrosoft.com". Sign-in logs show the application accessed m.brooks's mailbox 47 times over the past 18 days, most recently 6 hours ago.
No Sentinel alert fired because the OAuth consent was from a user with Global Reader permissions, which is below the anomaly detection threshold. m.brooks's endpoint (LAPTOP-NGE-MB01, macOS Ventura) has not shown any suspicious activity.
Your task: Answer all four questions before opening the reference.
Reference answer — Scenario 3
Decision: PRESERVE FIRST. The attacker is operating through an OAuth application, not an interactive session. The application accessed the mailbox 6 hours ago — it may access again at any time, but there's no evidence of active damage (no email forwarding rule, no bulk download in progress). The 18-day dwell time suggests a patient attacker extracting data incrementally rather than an urgent smash-and-grab.
First action: Export the Unified Audit Log for m.brooks's mailbox activity over the past 30 days. The UAL contains every MailItemsAccessed, FileAccessed, and consent event associated with the compromised account. This is Tier 3 evidence by volatility tier but it's the first action because the attacker's activity pattern over 18 days is the investigation's primary evidence source — and UAL exports take time (up to 24 hours for large date ranges in Purview).
Starting the export first ensures the investigation team has the data when they begin analysis.
Evidence capture sequence:
Cloud (primary): UAL export for m.brooks (30-day range). Sign-in logs filtered to the "DocuSync Pro" application's service principal. OAuth consent grant details from Entra (application permissions, consent timestamp, consenting user). Conditional Access policy evaluation logs — why did the consent succeed? Inbox rules for m.brooks (check for forwarding to external addresses). OneDrive/SharePoint audit logs for Files.ReadWrite.All activity.
Endpoint (secondary): macOS does not show suspicious activity, but the initial OAuth consent may have occurred via a phishing link opened on the endpoint. Check m.brooks's browser history for the consent URL. Safari/Chrome download history for the 18-day-ago date. This is lower priority — the attack vector is cloud-native through the OAuth application, not endpoint-based.
Containment (after preservation): Revoke the "DocuSync Pro" OAuth application consent in Entra: Remove-MgServicePrincipal. Revoke all active sessions for m.brooks: Revoke-MgUserSignInSession. Reset m.brooks's password. Review and revoke any inbox rules or mail flow rules the application may have created. Block the publisher tenant ("docusync-pro-corp.onmicrosoft.com") in Entra's cross-tenant access settings to prevent re-consent.
Why this sequence: No volatile evidence is at risk of imminent destruction. The OAuth token persists until explicitly revoked — unlike a process in memory, it doesn't disappear on reboot. The UAL data persists for 180 days (Standard) or 1 year (E5/Audit Premium). The preservation window is wide. The export starts first because it takes time, not because the evidence is volatile.
Containment executes after the export is queued, not after it completes — revoking the application consent while the export runs in the background is safe because the export captures historical data regardless of the application's current state.
After the lab: bridging to your environment
After completing all three scenarios, apply the framework to your own environment. For each scenario type — active exfiltration, dormant implant, historical cloud compromise — identify: what would the attacker target in your environment? What tools do you currently have pre-staged for evidence collection? What containment actions can you execute right now at 03:00 on a Sunday without calling someone else? Do you have Defender isolation permissions? Firewall rule change access? Entra admin privileges for OAuth revocation?
The answers identify your preparation gaps. A gap discovered during a lab exercise costs nothing. The same gap discovered during a live incident costs evidence, time, and potentially regulatory exposure.
The most common pattern in lab scoring: the analyst who always preserves first (even during active ransomware) or always contains first (even when the attacker has been dormant for days). Both defaults are wrong half the time. The decision tree exists to override the default. If your answers for all three scenarios used the same sequence, review TR1.6 — one of those answers is likely incorrect.
Triage Principle
The preservation decision is a skill that improves with practice, not a rule that's memorised once. Each scenario you work — in labs and in production — refines your ability to assess attacker state from available evidence, select the most volatile evidence for the specific environment, and choose containment actions that preserve what the investigation needs. The scoring framework identifies which of these three skills needs the most attention in your development.
Get weekly detection and investigation techniques
KQL queries, detection rules, and investigation methods — the same depth as this course, delivered every Tuesday.
No spam. Unsubscribe anytime. ~2,000 security practitioners.