In this section
Collection Order, Preservation, and Workstation Setup
Scenario
You arrive at a compromised workstation. The system is powered on, the user is logged in, and IT wants to shut it down immediately to "stop the attack." The disk evidence (MFT, USN, registry, Prefetch, event logs) survives shutdown. But memory, active network connections, DNS cache, and running processes do not. A hard power-off also loses Shimcache data that would flush to registry during a clean shutdown. The optimal sequence: memory capture, network state, KAPE triage, clean shutdown, then full disk image.
The order of volatility
Figure WF0.7 — Evidence collection priority by volatility. What you lose first, you collect first. Each decision point (power off, reboot, user login, time passage) destroys or degrades specific evidence types.
There is no collection sequence that preserves everything. Running a collection tool creates processes, allocates memory, writes to disk, and generates event log entries. The examiner must choose which evidence categories to prioritize based on investigation type, system state, and legal requirements, and document why they made those choices.
Volatile evidence (Priority 1) is destroyed the moment the system powers off. A memory dump captures running processes with their full command lines, loaded DLLs (including injected malware), active network connections with remote IP addresses, decrypted data that exists only in RAM, and clipboard contents. A process listing with tasklist /v /fo csv and network state with netstat -anob capture the same data in a lighter format. If you can only do one thing before shutdown, take a memory dump. It captures everything else.
Semi-volatile evidence (Priority 2) degrades over time through normal system operation. The USN Journal wraps when it reaches its maximum size (default 32MB), overwriting the oldest entries. The $LogFile wraps in hours. Prefetch files are evicted when the directory exceeds 1024 entries. Event Logs rotate based on configured maximum sizes. Each hour the system runs after an incident, you lose some semi-volatile evidence. For active investigations, collect immediately.
Non-volatile evidence (Priority 3) persists until overwritten. The MFT, registry hives, ShellBags, LNK files, Jump Lists, Amcache, and SRUM database all persist on disk across reboots and shutdowns. They degrade only when the specific records are reallocated (MFT, registry slack) or when SSD TRIM erases deleted file content. These artifacts are what KAPE triage collection targets.
External evidence (Priority 4) exists independently of the endpoint. Cloud audit logs, firewall logs, SIEM data, and EDR telemetry have their own retention windows. Preserve these early because their retention policies may be shorter than the investigation timeline.
KAPE triage vs full disk imaging
Anti-Pattern
Starting every investigation with a full disk image
Full disk imaging was the correct first step when drives were 40GB and imaging took 30 minutes. A modern 1TB NVMe SSD takes 2-6 hours. During those hours, volatile evidence is being destroyed (live system) or has already been lost (powered off). A KAPE triage collection (5-15 minutes) captures the forensic artifacts that answer 95% of investigation questions. Full imaging is appropriate when you need deleted file content recovery from unallocated space, when the investigation may become a legal proceeding, when you don't know what evidence you need, or when a legal hold requires a verified bit-for-bit copy.
KAPE can run silently from a USB drive or network share for covert insider threat investigations. The collection generates disk activity and brief CPU usage but displays no visible interface. Schedule during a period when the subject is away. Document that KAPE's own file operations modify the MFT and generate Event Log entries (process creation). These are examiner artifacts to exclude from analysis.
This is what a KAPE triage collection command looks like. The !SANS_Triage compound target collects the key forensic artifacts in one pass:
Seven minutes, 2.8GB, and you have the MFT, USN Journal, all five registry hives, Prefetch files, LNK files, Jump Lists, Event Logs, SRUM, and browser data. This is the evidence set the student analyzes throughout the course.
EDR and KAPE are complementary, not alternatives. 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, registry hive binaries for offline analysis, Prefetch files, the SRUM database, ShellBag data, or LNK/Jump List files. EDR provides real-time telemetry. KAPE provides historical artifact data.
When IT has already intervened
If IT rebooted the system before forensics was notified, document the reboot time. Volatile evidence is gone. Shimcache may have been preserved (flushed to registry during orderly shutdown). Semi-volatile artifacts are degrading from post-reboot activity. Collect immediately. Note in your report that volatile evidence was unavailable and what conclusions this limitation affects.
Investigation Principle
Collect in order of volatility: what you lose first, you collect first. For active compromise: memory capture, network state, KAPE triage, clean shutdown, full disk image. For historical investigation: KAPE triage first (volatile evidence has no value for past events), then full image if required. For legal proceedings: full disk image with hash verification for chain of custody, after volatile collection if the system is live.
Common analysis issues
"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.
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.
VM platform setup
The forensic analysis VM runs on VMware Workstation Pro (free for personal use since late 2024) or VirtualBox. Create a new VM: 4 vCPU, 8GB RAM (16GB if your host allows), 120GB thin-provisioned disk. Install Windows 11 Enterprise using the free evaluation ISO from Microsoft's Evaluation Center. Create a local account named "Analyst" (not a Microsoft account). After reaching the desktop, take a snapshot named "Clean Install. Pre-Configuration."
The VM approach provides case isolation (snapshots prevent cross-contamination between investigations), portability, and defensibility (you can testify that the analysis environment was clean by showing the snapshot state before evidence was loaded). Windows 11 matches the OS on the majority of evidence systems, reducing version-specific parsing issues.
Disabling interference sources
Windows generates continuous background activity that can contaminate evidence analysis. Disable these before any investigation work:
Scenario
You load a KAPE collection into your analysis VM and start processing with MFTECmd. Windows Defender immediately quarantines three files from the collection: a credential harvesting tool, a webshell, and a suspicious PowerShell script. The quarantine operation modifies the MFT (moving files), creates Event Log entries, and generates its own Prefetch records. Your evidence is now contaminated with analysis artifacts. This is why Defender must be disabled before loading evidence.
Windows Defender real-time protection: Disable via Group Policy for persistence (Computer Configuration → Administrative Templates → Windows Components → Microsoft Defender Antivirus → Turn off → Enabled). Defender will scan and quarantine evidence files including malware samples in KAPE collections.
Windows Update: Pause or disable via Group Policy. Updates modify system files, create Prefetch entries, generate Event Log entries, and may reboot mid-analysis.
OneDrive: Uninstall or sign out. If evidence files are placed in a synced folder, they upload to Microsoft's cloud.
Windows Search indexing: Stop and disable the Windows Search service. Indexing scans file contents and creates database entries, modifying the MFT and generating USN Journal entries.
SysMain (Superfetch): Stop and disable. The service generates its own artifacts that could be confused with evidence artifacts.
Anti-Pattern
Using a daily-use workstation for forensic analysis
A daily-use workstation has thousands of Prefetch files, millions of MFT records, and years of registry history. If the examiner accidentally processes their own system's artifacts alongside evidence, the analysis is contaminated. Windows Defender on an unconfigured system will quarantine malware samples from evidence. Windows Update creates filesystem activity that interleaves with analysis output. A purpose-built forensic VM with interference disabled and case-level snapshots prevents these contamination vectors.
Tool installation
All tools used in this course are free. Create C:\Tools\ and install each suite in its own subdirectory.
KAPE from kape.sh (free account required). Extract to C:\Tools\KAPE\. Update targets and modules with Get-KAPEUpdate.ps1. EZ Tools from ericzimmerman.github.io: MFTECmd, PECmd, AmcacheParser, ShimCacheParser, JLECmd, LECmd, SBECmd, RECmd, EvtxECmd, SrumECmd, Registry Explorer, Timeline Explorer, and more. Arsenal Image Mounter from arsenalrecon.com (free version mounts E01, raw, VMDK as read-only drives). FTK Imager from exterro.com (free registration). HxD from mh-nexus.de (free hex editor for raw artifact examination). Python 3.12 from python.org with forensic libraries: pip install python-registry yara-python pefile construct.
After installing, verify each tool runs. This is the minimum verification:
If any tool fails to run, check that .NET 6 runtime is installed (required for current EZ Tools versions) and that the tools are not blocked by Windows SmartScreen (right-click → Properties → Unblock).
Evidence handling procedures
Evidence integrity depends on consistent handling. Use this structure: C:\Cases\{CaseID}\evidence\ (original evidence, never modified), output\ (tool processing results), notes\ (examination notes, screenshots), report\ (final deliverables). When mounting forensic images, always use Arsenal Image Mounter in read-only mode. Verify the image hash before mounting. Tool output always goes to output\, never to the evidence directory.
Investigation Principle
Before starting each investigation, take a VM snapshot. After the investigation concludes, revert to the snapshot. This prevents cross-contamination between cases and provides a verifiable baseline proving the analysis environment was clean. For practitioners handling multiple concurrent cases, maintain separate snapshots and switch between them.
Common analysis issues
"The Windows 11 evaluation expires after 90 days." You have several options: rearm the evaluation with slmgr /rearm (available 1-2 times, extending by 90 days each), create a new VM from a fresh evaluation ISO, or purchase a Windows 11 Pro license (approximately $30 from authorized resellers). For training purposes, the evaluation is sufficient: you can complete this course well within the evaluation period.
"I don't have enough disk space for a 120GB VM plus evidence files." The 120GB VM disk is thin-provisioned: it only uses actual space as data is written, starting around 25-30GB after OS installation and tools. Evidence files are the larger concern: a single KAPE triage collection is typically 2-10GB, and a full disk image is 100GB+. Store evidence files on an external drive connected to the host, accessible to the VM via a shared folder or USB passthrough. This keeps the VM disk lean while providing abundant evidence storage.
"Should I use a physical forensic workstation instead of a VM?" For production forensic work (real investigations), many practitioners use dedicated physical workstations for performance and to avoid virtualization-related complications. For training and learning, a VM is preferable: snapshots provide case isolation, the environment is disposable and reproducible, and you can run the VM alongside your notes and browser on the host. The artifact analysis techniques are identical regardless of whether you run the tools in a VM or on bare metal.
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.