In this section
Check My Knowledge
Scenario 1. You are triaging a compromised Windows endpoint. The suspicious process (rundll32.exe loading a DLL from the user's Temp folder) has been running for 2 hours with an active C2 connection. The attacker is dormant — no commands issued in the last 90 minutes. You have 15 minutes before the user returns from lunch and may shut down the laptop. What is your first action?
Run KAPE to collect event logs, Prefetch, AmCache, and ShimCache. These disk artifacts survive a shutdown, so capturing them first ensures the investigation has something to work with regardless of what happens. a
Disk artifacts survive shutdown — that is exactly why they are not the first priority. The evidence that does NOT survive shutdown is the running process's memory (containing the decrypted beacon configuration), the active network connection (confirming C2 infrastructure), and the loaded DLL modules. KAPE collects valuable evidence, but none of it vanishes on shutdown. The most volatile evidence goes first.
Network-isolate the endpoint via Defender for Endpoint immediately. The 15-minute window is too short to risk — if the attacker issues a destructive command while you are collecting evidence, the damage outweighs the evidence value. b
The attacker is dormant — 90 minutes without commands. Containing now sacrifices the beacon's memory footprint, which contains infrastructure details the investigation team needs. Network isolation keeps the system running but terminates the C2 connection, causing many beacon implementations to enter a self-protective mode or wipe indicators. The dormant state provides a preservation window — use it.
Capture memory immediately using WinPMem. The beacon's decrypted configuration, C2 infrastructure details, and Malleable C2 profile exist only in the running process's memory. A laptop shutdown destroys all of this permanently. Memory acquisition takes 3–5 minutes. After the dump completes, capture the process list and network connections, then execute containment via Defender isolation. c
Correct. Memory is the most volatile evidence that contains the highest-value artifacts for this scenario — the beacon configuration that reveals the attacker's infrastructure. The 15-minute window is tight but sufficient for a memory dump (3–5 minutes) plus Tier 1 volatile capture (30 seconds) plus containment. Disk artifacts survive independently of this sequence and can be collected after isolation via Defender Live Response.
Ask the user's manager to delay the user's return so you have more time. Evidence preservation takes priority over business schedules per Rachel's SOP. d
Coordinating with the manager is a good practice (Section 1.6 covers this), but it is not the first action. Every minute spent coordinating is a minute not spent capturing volatile evidence. Start the memory dump first — it runs unattended — and coordinate with the manager in parallel while WinPMem executes.
Scenario 2. A cloud compromise is detected 6 days after the initial OAuth consent. The attacker used a malicious application with Mail.ReadWrite permissions to access a VP's mailbox 89 times over 6 days. The Entra tenant has P1 licensing (no P2 or E5). Which evidence source is at immediate risk of loss?
The Unified Audit Log entries for mailbox access. UAL Standard retention is 180 days, so the 6-day-old events will persist for months. a
UAL Standard retention is indeed 180 days, so the oldest events have approximately 174 days remaining. This evidence is not at immediate risk. However, the UAL export should still be initiated early because large date-range exports can take up to 24 hours to process — urgency of export is about availability, not retention.
The Entra sign-in logs. With P1 licensing, sign-in log retention is 30 days. The 6-day-old events have 24 days remaining. But the interactive sign-in details — including the IP address, device information, Conditional Access evaluation results, and MFA method for the initial consent event — begin to lose granularity after 7 days in some Entra reporting views. Export the sign-in logs immediately to preserve full detail for the initial compromise window. b
Correct. Sign-in log retention at P1 is 30 days, which sounds comfortable, but the initial consent event at Day 1 is the most critical record for understanding how the attacker gained access. Entra's interactive reporting views may truncate detail after 7 days. Exporting to Log Analytics or downloading as CSV preserves the full record. With no E5 or Audit Premium, MailItemsAccessed events are also unavailable entirely — the analyst cannot determine which specific emails were accessed without this license tier.
The OAuth application's consent record. If the attacker revokes their own application consent to cover their tracks, the evidence of what permissions were granted is lost. c
The consent grant event is recorded in the Entra audit log, which has separate retention from sign-in logs (also 30 days at P1). Even if the attacker revokes the consent, the original grant event persists in the audit log. However, documenting the current application state (permissions, publisher, service principal details) before any revocation is still good practice — it captures the live state alongside the historical log record.
The mailbox content. The attacker may delete emails they accessed to cover their tracks. d
Mail.ReadWrite permissions do allow deletion, and the attacker could delete accessed emails. However, deleted items in Exchange Online are recoverable for 14 days (soft-deleted) and up to 30 days with litigation hold. The mailbox content is at risk but recoverable. The sign-in log detail is not recoverable after retention expiry — once the granular data ages out, it is gone.
Scenario 3. An attacker compromised a Docker host running three containers. You have confirmed that the Nginx container's configuration was modified to proxy C2 traffic. The PostgreSQL container and the Node.js API container show no modifications via docker diff. Should you export all three containers or only the compromised Nginx container?
Export all three containers. Docker diff shows filesystem modifications relative to the base image, but it does not reveal runtime-only changes — environment variables injected at startup, in-memory configuration changes, or processes spawned inside the container that wrote to tmpfs. The PostgreSQL container may have been used for data staging. The Node.js container may have a modified runtime configuration loaded from environment variables. A clean docker diff does not prove a clean container. a
Correct. Docker diff is a useful triage indicator but not a definitive forensic clearance. An attacker who stages data in PostgreSQL's memory (via a SQL query that loads data into a temp table) leaves no filesystem modification. An attacker who injects environment variables into the Node.js container at runtime leaves no diff. Exporting all containers preserves the complete evidence set for the investigation team to examine. The incremental cost of exporting two additional containers is minutes — the cost of missing evidence in a container you did not export is potentially the entire investigation scope.
Export only the Nginx container. The other two containers showed no modifications, and exporting all three wastes time during the triage window. Focus on the confirmed compromise. b
This approach saves time but risks missing evidence. The attacker accessed the Docker host and executed commands inside at least one container. The assumption that they did not interact with the other containers is based solely on docker diff — which only shows filesystem changes. Runtime-only modifications, memory-resident data, and environment variable injections are invisible to diff. During a confirmed compromise of a multi-container host, the safe assumption is that all containers on the host are potentially affected.
Run docker inspect on all three but only export the Nginx container. Docker inspect captures the runtime configuration (environment variables, mounts, network settings) without the overhead of a full filesystem export. c
Docker inspect captures configuration metadata but not filesystem content. If the attacker placed a data staging file inside the PostgreSQL container's writable layer, inspect would not capture it — only export would. Inspect is a useful first step (and should always precede export), but it is not a substitute for export when the host is confirmed compromised.
Do not export any containers. Instead, take a snapshot of the Docker host's entire filesystem, which includes all container writable layers under /var/lib/docker/overlay2/. d
A host filesystem snapshot does capture the container writable layers, and this approach works. However, it requires understanding Docker's storage driver layout to extract individual container filesystems from the overlay2 directory — a skill the investigation team may not have. Docker export produces a clean tar archive per container that any analyst can examine. Both approaches preserve the evidence; export is operationally simpler for the receiving team.
Scenario 4. During evidence collection on a Linux server, you attempt to run AVML for memory acquisition. The command fails with no output. You check the kernel lockdown status and find it is set to "integrity" (Secure Boot enabled). LiME has not been pre-compiled for this kernel version. What is the correct triage action?
Disable Secure Boot in the BIOS and reboot the server. This removes kernel_lockdown and allows AVML to access physical memory. a
Rebooting the server destroys all volatile evidence — running processes, network connections, memory contents, and container writable layers. The reboot defeats the entire purpose of memory acquisition. Disabling Secure Boot to acquire memory is a contradiction: the reboot required to change the BIOS setting destroys the memory you are trying to acquire.
Compile LiME on the target server using the kernel headers. LiME runs as a kernel module and bypasses kernel_lockdown when properly signed. b
Compiling on the target system during an incident is problematic for two reasons. First, it requires installing build tools and kernel headers on the compromised system — modifying the system you are collecting evidence from. Second, on a kernel_lockdown system, unsigned kernel modules will not load. LiME would need to be signed with a key enrolled in the system's UEFI Secure Boot database, which requires advance preparation — not an improvisation during triage.
Skip memory acquisition entirely and focus on /proc and log collection. Memory acquisition is a Tier 2 priority and the Tier 1 evidence (/proc state, network connections) is more urgent anyway. c
The first part is partially correct — /proc and network state are Tier 1 and should be captured. But skipping memory acquisition entirely without documenting the gap is the mistake. Memory may contain decrypted payloads, cached credentials, and injected code that exists nowhere else. The investigation team needs to know that memory was not acquired and why, so they can adjust their analysis approach and factor the gap into their conclusions.
Document the AVML failure and the kernel_lockdown constraint in the evidence manifest. Proceed with /proc state capture, network connections, container evidence, and log collection — all of which remain available despite the memory acquisition failure. Note in the triage report that physical memory was not acquired and the reason, so the investigation team knows what evidence is missing and can request a pre-compiled signed LiME module for future incidents on this kernel version. d
Correct. Memory acquisition failed due to a known platform constraint. The correct response is to document the failure, proceed with all other available evidence sources, and ensure the gap is visible to the investigation team. Documenting what you could not collect is as important as documenting what you did collect. The post-incident action is to pre-compile and sign LiME modules for every kernel version in the environment — closing the readiness gap before the next incident.
Scenario 5. An alert fires at 14:00 showing active ransomware encryption on a file server. Simultaneously, a second alert shows the same attacker exfiltrating data from a different server to an external IP. You are the only analyst on shift. You can contain one server immediately. Which server do you contain first?
The encrypting server. Ransomware encryption destroys data permanently if backups fail. Stop the encryption first, then address the exfiltration. a
Encryption is destructive, but encrypted data is recoverable if backups exist and are uncompromised. Exfiltrated data, once it leaves the network, is permanently outside the organisation's control — it cannot be "un-exfiltrated." However, the answer depends on whether backups are verified. If backup integrity is unknown, the encryption may represent permanent data loss. The regulatory dimension (GDPR notification for exfiltrated PII) also factors into the priority decision.
The exfiltrating server. Exfiltrated data cannot be recovered once it leaves the network — the regulatory and business impact is irreversible. Encrypted data may be recoverable from backups. Block the exfiltration destination IP at the network perimeter (fastest containment with zero evidence destruction), then immediately isolate the encrypting server. The firewall block takes seconds; device isolation takes seconds. Both actions execute within a minute if the analyst has the access. b
Correct. The irreversibility of exfiltration makes it the higher priority. A firewall block of the destination IP stops the data transfer instantly with no evidence impact on either server. After the block, device isolation of the encrypting server stops the encryption with the system still running (memory and process evidence preserved). Both containment actions are fast — the 30-second gap between them is unlikely to change the outcome for either server, but prioritising the irreversible damage vector is the defensible decision.
Neither — with active damage in two locations, escalate to the IR manager and wait for additional analysts. A single analyst cannot effectively contain and preserve across two servers simultaneously. c
Escalation is correct as a parallel action, but waiting for additional analysts while both servers sustain active damage is not. The firewall block and device isolation are both single-command actions that a solo analyst can execute in under a minute. Every minute of waiting adds exfiltrated data volume and encrypted files. Escalate while executing containment, not instead of it.
Block the exfiltration destination at the perimeter AND isolate the encrypting server simultaneously by opening two browser tabs — one for the firewall console and one for the Defender portal. d
The intent is correct — stop both damage vectors as fast as possible. In practice, "simultaneously" via two browser tabs still means one action completes before the other. The analyst should execute the firewall block first (it affects only the exfiltration path) and then isolate the encryption server (which has a broader blast radius). Sequencing matters because if the isolation command fails or requires confirmation, the firewall block is already done.
Scenario 6. You completed evidence collection on a compromised endpoint. Your evidence folder contains a memory dump (8 GB), a KAPE collection (2.1 GB), event log exports (340 MB), and a network connections snapshot (12 KB). You computed SHA256 hashes for all files at collection time. During transfer to the investigation team's evidence share, the network connection dropped midway through copying the memory dump. After reconnecting, you re-copied the memory dump. What must you verify before handing off the evidence?
Verify that all four files exist on the evidence share. The network interruption may have caused a partial copy, and a missing file would leave a gap in the evidence set. a
Checking that all files exist is necessary but insufficient. A file can exist on the share with the correct filename and approximate size but be corrupted by a partial transfer. File existence does not prove file integrity. The SHA256 hash is what proves the file on the share is byte-for-byte identical to the file you captured.
Re-compute SHA256 hashes for the memory dump only, since that was the file affected by the network interruption. The other three files transferred without issue and their hashes from collection time are sufficient. b
Verifying only the memory dump leaves three files unverified on the evidence share. The analyst knows the network dropped during the memory dump transfer, but cannot be certain the other transfers were unaffected — a network issue may have caused silent corruption in any file. Chain of custody requires hash verification at every transition point for every evidence item, not just the items the analyst suspects were affected.
Re-compute SHA256 hashes for ALL four files on the evidence share and compare each against the collection-time hashes. Every file must match. The memory dump is the most likely to have been corrupted by the interrupted transfer, but chain of custody requires verification at every transition point for every item. Document the network interruption and the re-copy in the chain of custody log — the investigation team should know the transfer was not clean on the first attempt. c
Correct. Hash verification at every transition point covers all files, not just the ones you suspect were affected. The chain of custody log documents the interruption because it is a material event during evidence handling — even though the re-copy likely produced an intact file, the log records what happened. If the memory dump hash does not match after the re-copy, the file is corrupted and must be re-transferred from the original collection media.
The SHA256 hashes from collection time are sufficient. As long as the original evidence files on your collection media are intact, the investigation team can always re-copy if the share versions are corrupted. d
Relying on re-copy availability is fragile. The collection media (USB drive, local disk) may not be available days later when the investigation team discovers the corruption. The chain of custody requires that evidence integrity is verified at handoff — the receiving party confirms the hashes match before accepting the evidence. Deferring verification to "we can always re-copy" transfers the integrity risk to the investigation team instead of resolving it at the transition point.
How was this module?
Your feedback helps us improve the course. One click is enough — comments are optional.
Thank you — your feedback has been received.
© 2026 Ridgeline Cyber Defence™ Ltd. Content may not be reproduced or redistributed. Worked artifacts may be adapted for use within your organization.