Sign In
In this module

Collection Order and Evidence Preservation

Module 0 · Free
Operational Objective
Evidence collection is a destructive operation. The act of collecting evidence modifies the system — running a collection tool creates processes, allocates memory, writes to disk, and generates event log entries. Collecting volatile evidence first preserves data that would be lost at shutdown, but the collection tool itself alters the volatile state. Imaging a live disk preserves the filesystem, but the imaging process modifies the last access timestamps (if enabled), creates temporary files, and may trigger antivirus scans that modify quarantine artifacts. Powering off the system preserves the disk state from further modification, but destroys all volatile evidence — running processes, active network connections, decrypted memory contents, and in-memory registry state. There is no collection sequence that preserves everything. The examiner must choose which evidence categories to prioritize based on the investigation type, the system state, and the legal requirements — and document why they made those choices. This subsection provides the collection priority framework that maximizes evidence preservation for each investigation scenario, the specific artifacts lost at each collection stage, and the documentation requirements that make the collection methodology defensible.
Deliverable: The evidence collection priority hierarchy (volatile → non-volatile → network → cloud), the specific artifacts at risk at each decision point (power off, reboot, user login, time passage), KAPE collection profiles for triage vs standard vs comprehensive collection, and the collection documentation template that records methodology decisions for legal defensibility.
Estimated completion: 35 minutes
EVIDENCE COLLECTION PRIORITY — ORDER OF VOLATILITY PRIORITY 1 — VOLATILE Lost at power off Running processes + cmdline Active network connections Memory (RAM dump) DNS cache · ARP cache PRIORITY 2 — SEMI-VOLATILE Degrades over hours/days USN Journal (wraps on size) $LogFile (wraps in hours) Prefetch (1024 entry limit) Event Logs (size limits) PRIORITY 3 — NON-VOLATILE Persists until overwritten $MFT (persists until realloc) Registry hives ShellBags · LNK · Jump Lists Amcache · SRUM · Browser data PRIORITY 4 — EXTERNAL Independent of endpoint Cloud audit logs (Entra, M365) Firewall / proxy logs SIEM / EDR telemetry Email gateway logs DECISION POINTS — EVIDENCE LOST AT EACH STAGE POWER OFF Lost: all volatile evidence Preserved: disk state frozen REBOOT Lost: volatile + Shimcache flush Changed: registry hive flush USER LOGIN Changed: NTUSER.DAT loaded Modified: ShellBags, MRU, UserAssist TIME PASSAGE Lost: USN wraps, $LogFile wraps Lost: SSD TRIM on deleted files

Figure WF0.7 — Evidence collection priority hierarchy and decision points. Each stage (power off, reboot, user login, time passage) destroys or modifies specific evidence categories. The collection sequence must be chosen based on the investigation type and the evidence most critical to the investigation objectives.

The order of volatility

RFC 3227 (Guidelines for Evidence Collection and Archiving) established the order of volatility principle in 2002: collect the most volatile evidence first because it has the shortest lifespan. The hierarchy runs from registers and cache (seconds) through memory (minutes to hours) through disk (days to months) through network logs (varies) through archival media (years). Twenty-four years later, the principle holds, but the specifics have changed.

On a modern Windows endpoint, the practical volatility hierarchy for forensic artifacts is: volatile system state (processes, connections, memory) degrades at power off. Semi-volatile artifacts (USN Journal, $LogFile, Prefetch, Event Logs) degrade through normal system operation — the journal wraps, the log rotates, the Prefetch directory fills. Non-volatile artifacts (MFT, registry, ShellBags, Amcache, SRUM) persist until explicitly overwritten or reallocated. External logs (cloud, SIEM, proxy) have their own retention policies independent of the endpoint.

The collection decision is not "collect everything in volatility order" — it is "given this investigation type and this system state, which evidence categories are most critical and at greatest risk of loss?" An active compromise investigation prioritizes volatile evidence (what is the attacker doing right now?) because volatile evidence is destroyed at power off and the attacker may be actively destroying disk artifacts. A historical insider threat investigation prioritizes non-volatile evidence (what did the user do over the past 6 weeks?) because the volatile evidence from 6 weeks ago is already gone, and the risk is that ongoing system activity overwrites semi-volatile artifacts like the USN Journal.

Expand for Deeper Context

The "pull the plug vs orderly shutdown" debate has a nuanced answer that depends on the specific evidence at risk. Pulling the power cord (or holding the power button for 5 seconds for a hard shutdown) preserves the disk state exactly as it was — no shutdown writes, no registry flush, no Shimcache update. But it destroys all volatile evidence and may leave registry hives in an inconsistent state (recoverable via transaction logs but requiring additional processing). An orderly shutdown flushes dirty registry pages to disk (preserving the most current state), writes the Shimcache to the SYSTEM hive (preserving execution evidence that only exists in memory until shutdown), and closes Event Log files cleanly — but the shutdown process itself generates new Event Log entries, modifies the MFT, and may trigger cleanup operations.

The modern best practice for most investigations: collect volatile evidence first (memory dump + process listing + network connections), then perform a KAPE triage collection from the live system (which captures locked files like registry hives and the $MFT), then image the disk or perform an orderly shutdown. This sequence captures volatile evidence before it is lost, captures the current registry and MFT state while the system is live, and preserves the disk for later full imaging. The trade-off is that the live KAPE collection modifies the system (creating files, allocating memory, generating Event Log entries), but the modifications are documented and the evidence gained (locked files, memory) outweighs the evidence modified (a few MFT records for the KAPE tool itself).

What you lose at each decision point

Power off (immediate). All volatile evidence is destroyed: running processes (PIDs, command lines, parent processes, loaded DLLs, injected threads), active network connections (local/remote addresses, ports, associated processes), memory contents (decrypted data, credentials, in-memory-only malware, clipboard), DNS cache (recent name resolutions), ARP cache (recent MAC-to-IP mappings), and the in-memory registry state (including any modifications not yet flushed to disk). If Shimcache has not been flushed to the SYSTEM hive (it flushes at orderly shutdown, not continuously), the most recent Shimcache entries are lost. On systems where the attacker is operating in memory only (fileless malware, reflective DLL injection), powering off may destroy the only evidence of the compromise.

Reboot. Same volatile evidence loss as power off, plus: the Shimcache is flushed to the SYSTEM hive during orderly shutdown (preserving it), but the new boot generates new process creation events, loads new drivers, and starts new services that overwrite Event Log entries. If Event Logs are near their maximum size, the reboot-generated entries may push out entries from the investigation timeframe. Registry hives are flushed during shutdown and reloaded at boot — any dirty pages in memory are committed to disk.

User login. The user's NTUSER.DAT and UsrClass.dat hives are loaded into memory. Any MRU lists, UserAssist counters, and ShellBag entries are accessible and may be modified by the user's activity during the login session. If the investigation involves user activity artifacts, logging in as the target user modifies the evidence. If you must access the system, log in as a different administrative account — this loads a different NTUSER.DAT and does not modify the target user's registry artifacts.

Time passage. Every hour the system runs, semi-volatile artifacts degrade. The USN Journal wraps, discarding the oldest entries. The $LogFile wraps, losing NTFS transaction history. Prefetch files for the 1025th unique executable overwrite the oldest entry. Event Logs that reach their maximum size overwrite the oldest records (if set to "Overwrite events as needed," which is the default). SSD TRIM operations erase the flash cells underlying deleted files, reducing recovery potential. SRUM entries older than 30-60 days age out. The degradation rate varies by system activity level — a heavily used workstation degrades faster than a lightly used server — but the direction is always toward evidence loss.

KAPE collection profiles

KAPE (Kroll Artifact Parser and Extractor) is the standard tool for forensic artifact collection on Windows. It operates at three collection levels, each balancing speed, completeness, and evidence modification.

Triage collection (5-15 minutes): Collects the minimum artifact set for rapid assessment. Targets: $MFT, $UsnJrnl, registry hives (SYSTEM, SOFTWARE, SAM, NTUSER.DAT, UsrClass.dat, Amcache.hve) with transaction logs, Prefetch files, Event Logs (Security, System, Application, PowerShell, Sysmon), SRUM database. This collection answers: was this system compromised, what was the initial access vector, what ran, what persisted. It does not collect browser data, LNK files, Jump Lists, ShellBags (these are in the registry hives but require separate parsing), or file content.

Standard collection (15-45 minutes): Adds browser artifacts (Chrome/Edge/Firefox history, downloads, cache), LNK files and Jump Lists from all user profiles, Scheduled Tasks XML files, startup folder contents, WMI repository, PowerShell console history files, RDP bitmap cache, and the $Recycle.Bin metadata. This collection supports full investigation analysis including user activity reconstruction and browser-based exfiltration detection.

Comprehensive collection (45 minutes to several hours): Full disk image or targeted file collection including all files from user profile directories, all files from Windows\Temp, all files from recently created or modified directories, Volume Shadow Copy metadata, and pagefile.sys / swapfile.sys (for memory artifact recovery). This level is used for legal proceedings where completeness is required, or for investigations where the examiner doesn't yet know which artifacts are relevant.

Decision point

You arrive at a compromised workstation. The system is powered on and the user is logged in. IT wants to shut it down immediately to "stop the attack." You need to preserve evidence. What is your collection priority?

Your options: (A) Agree to shut down — the disk evidence (MFT, USN, registry, Prefetch, event logs) survives shutdown. Collect from the powered-off disk image. (B) Collect volatile evidence FIRST before shutdown: memory (for running processes, network connections, decrypted data), then network state (netstat, DNS cache), then trigger a KAPE triage collection of key artifacts. THEN allow a clean shutdown (which writes Shimcache to registry). A hard power-off loses both volatile evidence AND Shimcache data. A clean shutdown preserves Shimcache but loses memory and network state. The optimal sequence: memory capture → network state → KAPE triage → clean shutdown → full disk image.

The correct approach is B. The collection order matters: volatile evidence (memory, network state) is destroyed at shutdown. Non-volatile evidence (disk artifacts) survives. Always collect in order of volatility — what you lose first, you collect first.

Try It — Build a Collection Decision for Each NE Scenario

For each Northgate Engineering investigation scenario, determine the optimal collection sequence and KAPE profile:

INC-NE-2026-0915 (Insider threat, departing engineer): The engineer is still employed for two more weeks. The investigation is covert — the engineer must not know they are being investigated. The evidence is historical (6 weeks of past activity).

Key questions: Can you collect from the live system without the user noticing? Which collection profile captures the user activity artifacts you need? Is volatile evidence valuable for a historical investigation?

INC-NE-2026-1022 (Ransomware, active incident): Ransomware deployed 4 hours ago. 12 hosts are encrypted. The attacker may still have access to unencrypted systems. Containment is in progress.

Key questions: Should you collect volatile evidence from the 12 encrypted hosts (the attacker's tools may still be in memory on some)? How do you prioritize collection across 12 hosts? What about the unencrypted hosts the attacker may be pivoting through?

INC-NE-2026-1130 (Access dispute, HR proceeding): The employee has been placed on administrative leave. Their workstation is powered on but logged out. IT has secured the workstation but not imaged it. The HR proceeding is in 3 weeks.

Key questions: What is the first thing you do before anyone else touches the workstation? Which collection profile provides the evidence for the access dispute? Do you need volatile evidence?

Document your collection decisions and compare them against the methodology discussed in WF0.12.

Compliance Myth: "The first step in any forensic investigation is to image the hard drive"

The myth: Forensic investigation always begins with a bit-for-bit disk image. This preserves all evidence in its original state and provides a working copy for analysis. The image is the foundation of every investigation.

The reality: Full disk imaging was the correct first step when hard drives were 40GB and imaging took 30 minutes. A modern 1TB NVMe SSD takes 2-6 hours to image depending on the interface and imaging tool. During those hours, volatile evidence is being destroyed (if you image from a live system) or has already been destroyed (if you powered off first). Semi-volatile evidence continues to degrade on live systems. For most investigations, a KAPE triage collection (5-15 minutes) captures the forensic artifacts that answer 95% of investigation questions — without the delay of full imaging. Full disk imaging is appropriate when: (a) you need deleted file content recovery from unallocated space, (b) the investigation may become a legal proceeding requiring complete evidence preservation, (c) you don't know what evidence you need (imaging captures everything), or (d) the legal hold requires a verified bit-for-bit copy. For all other investigations, KAPE triage collection followed by targeted analysis is faster, more efficient, and captures the same artifact data that a full image provides.

Troubleshooting

"IT already rebooted the system before we were notified." Document the reboot in your collection notes with the approximate time. Volatile evidence is gone. Shimcache may have been preserved (flushed to registry during the orderly shutdown before reboot). Semi-volatile artifacts from before the reboot are still present but are now degrading from post-reboot system activity. Collect immediately — every hour of delay loses more semi-volatile evidence. Note in your report that volatile evidence was not available due to the reboot and what forensic conclusions this limitation affects.

"The user is still working on the system — can I collect without them noticing?" KAPE can run silently from a USB drive or network share with output written to a network destination. The collection generates disk activity and brief CPU usage but does not display a visible interface. The user may notice a brief slowdown. For covert insider threat investigations, schedule the KAPE run during a period when the user is away (lunch, meeting) or run it overnight during an after-hours maintenance window. The collection modifies the MFT (KAPE's own file operations) and generates Event Log entries (process creation) — document these as examiner artifacts that should be excluded from analysis.

"We have EDR on every endpoint — why do I need KAPE?" EDR captures process telemetry, file operations, network connections, and registry modifications in real time. It does not capture: the full $MFT (historical file metadata including deleted files), the full USN Journal (historical file operations), registry hive binaries (for offline analysis, deleted key recovery, transaction log replay), Prefetch files (execution counts, referenced files), SRUM database (historical network transfer volumes), ShellBag data (folder navigation history), or LNK/Jump List files (file access history). EDR and KAPE are complementary — EDR provides real-time telemetry, KAPE provides historical artifact data. Use both.

Operational Artifact — Collection Decision Framework

Step 1: Assess system state. Is the system running? Powered off? Rebooted? User logged in? Document the state. Step 2: Assess investigation type. Active compromise → prioritize volatile evidence. Historical investigation → prioritize semi-volatile and non-volatile. Legal proceeding → prioritize completeness (full image). Step 3: Collect volatile (if system is running). Memory dump (WinPMem, DumpIt, Magnet RAM Capture). Process listing with command lines (tasklist /v /fo csv). Network connections (netstat -anob). DNS cache (ipconfig /displaydns). Logged-in users (qwinsta). Estimated time: 5-15 minutes. Step 4: KAPE triage collection. Use compound target for investigation type. Output to external media or network share. Document KAPE version, targets used, and output location. Estimated time: 5-15 minutes. Step 5: Full disk image (if required). FTK Imager or Arsenal Image Mounter for E01 format with hash verification. Document source drive serial number, imaging tool version, and verification hashes. Estimated time: 2-6 hours depending on drive size and interface. Step 6: Secure external/cloud evidence. Preserve cloud audit logs (retention windows vary). Export EDR telemetry. Export SIEM data for the investigation timeframe. These sources have independent retention and should be preserved early. Document everything. For every collection step: who performed it, when (UTC), what tool and version, what was collected, what was the output hash, where was the output stored. This documentation is your chain of custody.

You arrive at a Northgate Engineering workstation that was involved in a suspected data exfiltration incident. The system is currently powered on with the suspect user logged in. The user has been asked to step away from the workstation but the session is still active. Your investigation requires evidence of file access patterns over the past 30 days, USB device usage, and quantification of data transferred externally. What is the correct collection sequence?
Immediately power off the workstation by pulling the power cord to freeze the disk state. Then connect the drive to a write-blocker and create a full forensic image. Analyze the image for MFT, registry, SRUM, and ShellBag evidence. This preserves the disk in its most pristine state.
Log the user off first to prevent any further evidence modification. Then run KAPE from a USB drive with the comprehensive target to collect everything. Power off after KAPE completes and create a full disk image for legal preservation.
Do not log the user off or power off — both actions modify evidence. First, collect volatile evidence (memory dump, process list, network connections) since the system is live. Then run a KAPE standard collection while the system is running — this captures locked files ($MFT, registry hives including the user's loaded NTUSER.DAT and UsrClass.dat, SRUM, Event Logs, Prefetch) and user activity artifacts (LNK files, Jump Lists, browser data). The KAPE collection captures the user's loaded registry hives with current ShellBag and MRU data. After KAPE completes, assess whether a full disk image is required for the legal proceeding. Document the system state, collection tools, and collection sequence.
This is a 30-day historical investigation, so volatile evidence is not relevant — the data you need is on disk. Skip the memory dump and go straight to KAPE triage collection for speed. Collect MFT, registry hives, SRUM, and Event Logs. Full disk image is unnecessary because KAPE captures all the artifacts you need.
© 2026 Ridgeline Cyber Defence™ Ltd. Content may not be reproduced or redistributed. Worked artifacts may be adapted for use within your organization.

You've built the foundations of artifact-level forensic analysis.

WF0 gave you the taxonomy, NTFS architecture, and the five-step methodology. WF1 took you inside the MFT at the binary level — every attribute, every timestamp, every edge case. From here, every artifact category gets the same raw-first treatment.

  • WF2–WF10: every major Windows artifact decoded at binary level — USN Journal, Prefetch, Amcache, Shimcache, ShellBags, LNK, Jump Lists, SRUM, Event Logs, and the Registry hives
  • INC-NE-2026-0915 (WF13) — Insider data exfiltration capstone. Work the complete investigation from USB history to OneDrive exfiltration evidence
  • INC-NE-2026-1022 (WF14) — Ransomware capstone. Three-host triage (FIN01 → IT03 → FS01) across the 72-hour attack chain
  • The lab pack — 25+ realistic evidence files in 10 formats, simulated KAPE triage pre-populated, both capstones deployable to your own VM
  • Anti-forensic detection methodology — defeat timestomping, log clearing, and Prefetch deletion with cross-artifact correlation
Unlock with Specialist — £25/mo See Full Syllabus

Cancel anytime

← Previous Next →