IR1.2 KAPE — Collection at Speed

KAPE does not analyze evidence. It does two things: it collects forensic artifacts from a source (a live system or a mounted forensic image), and it processes those artifacts through parsing tools (primarily Eric Zimmerman's EZTools suite). The collection produces a structured folder of raw artifact files. The processing produces parsed CSV, JSON, or TXT files ready for analysis. By itself, KAPE is a pipeline orchestrator — its value comes from the precision of what it collects, the speed at which it operates, and the extensibility of its configuration system.

At a technical level, KAPE works by reading YAML configuration files called Targets (which define what to collect) and Modules (which define how to process). When you run KAPE with a Target, it builds a queue of file specifications from the Target definition, scans the source location for matching files, and copies them to the destination. Files are processed in two passes: the first pass copies unlocked files using standard file operations (preserving timestamps and metadata). The second pass handles locked files — files that the operating system holds open (like registry hives, event logs, and the $MFT) — by reading them at the raw disk level, bypassing OS locks entirely. This two-pass approach is what enables KAPE to collect live system artifacts that cannot be simply copied with xcopy or robocopy.

The two-pass mechanism is worth understanding because it explains why KAPE requires Administrator privileges and why it succeeds where simple file copy fails. The Windows operating system locks certain critical files while the system is running. The SAM and SYSTEM registry hives are locked because they contain active security data. The $MFT is locked because NTFS is actively using it to track file operations. The active event log files (.evtx) are locked because the Event Log service is writing to them. A standard Copy-Item or robocopy command will fail on these files with an "access denied" or "file in use" error. KAPE's second pass reads these files at the raw disk level — accessing the physical disk sectors directly rather than going through the file system API — which bypasses the OS lock mechanism entirely. This is the same technique used by full disk imaging tools, but applied selectively to specific files rather than the entire drive.

---

Why triage collection instead of full disk imaging

The traditional forensic approach is full disk imaging — creating a bit-for-bit copy of the entire drive using tools like FTK Imager, dc3dd, or Guymager. This approach has been the standard since the early days of digital forensics, and it remains necessary for certain investigations: criminal cases requiring complete evidence preservation for court proceedings, investigations requiring deleted file recovery from unallocated disk space, and malware analysis requiring the full binary on disk for reverse engineering. But for the majority of incident response investigations, full disk imaging is slower than the investigation can afford.

The math makes the case. A modern workstation with a 500 GB NVMe SSD takes approximately 45 minutes to image over USB 3.0, or 70 minutes over a 1 Gbps network connection. A server with 2 TB of storage takes 3-5 hours. During that time, the investigation waits for data — and if the attacker is active (encrypting files, exfiltrating data, modifying inbox rules), every minute of delay increases organizational damage.

Now consider what the investigation actually needs. The forensically relevant artifacts on a Windows system — Prefetch files, event logs, registry hives, $MFT, browser history, scheduled tasks, Amcache, Jump Lists, LNK files, and SRUM — total approximately 200 MB to 2 GB depending on the number of user profiles and event log volume. That is 0.04% to 0.4% of the total disk. The remaining 99.6% is operating system binaries, application installations, user documents, page files, and hibernation files that are forensically irrelevant for most IR investigations.

KAPE collects that 0.04-0.4% in 2-5 minutes. The investigation can begin immediately with the artifacts that answer the critical questions: what executed, when, who was logged in, what was accessed, what was changed, and what persisted. If the investigation later determines that a full disk image is needed (because deleted file recovery is required, or because a specific executable binary must be preserved for malware analysis), the full image can be acquired in parallel while analysis of the triage collection is already underway.

This is not a compromise — it is a prioritization. In the first 30 minutes of an investigation, the triage collection provides actionable evidence while the full image is still writing. The first findings from KAPE triage — the attacker's execution timeline, the persistence mechanisms they installed, the accounts they compromised — inform the containment decisions that limit further damage. Waiting 90 minutes for a full disk image before taking any investigative action is a luxury that active incident response cannot afford.

---

Installation and initial configuration

KAPE is distributed as a zip archive containing portable executables — no installer, no system modifications, no dependencies beyond .NET Framework 4.6.2 (which is included with Windows 10 and later). Extract and run. The portability is deliberate: KAPE can run from a USB drive on a compromised system without installing anything on the target, and it can be deployed to remote systems via PowerShell remoting or PsExec without pre-installation.

Licensing clarity. KAPE is free for government agencies (local, state, federal, international), educational institutions, research purposes, and internal company use (investigating incidents on your own organization's systems). An enterprise license is required only when KAPE is used on a third-party network as part of a paid engagement — this applies to consulting firms and managed IR service providers performing investigations for clients. For this course and for investigating your own organization's incidents, the free license applies.

The Modules\bin\ directory. This directory is where the EZTools parser binaries must be placed for KAPE's Module phase to function. When KAPE runs a Module that specifies PECmd.exe as the parser binary, it looks for PECmd.exe in Modules\bin\. If the binary is not there, the Module fails silently — the Target collection completes but the Module processing produces no output. This is the single most common KAPE troubleshooting issue for new users. IR1.3 covers EZTools installation, including copying the binaries to this directory.

---

Updating targets and modules

KAPE ships with built-in targets and modules, but the DFIR community maintains an actively updated GitHub repository (github.com/EricZimmerman/KapeFiles) that receives new artifact definitions regularly. New Windows versions introduce new artifact locations (Windows 11 changed several paths). New attack techniques create new forensic evidence (new persistence mechanisms, new browser artifact formats). New applications store data in new paths. The community updates target definitions to cover these changes — and the updates are critical for comprehensive collection.

Run --sync monthly at minimum. Before any major investigation, run it again to ensure the latest definitions are loaded. A KAPE collection that misses a critical artifact because the target definition was outdated is a collection that produces an incomplete investigation. The sync takes 30 seconds and downloads only the changed files.

---

Understanding targets: what KAPE collects and why it matters

Targets are the heart of KAPE's value. Each .tkape file is a YAML configuration that defines file paths and file masks for a specific forensic artifact or artifact category. Compound targets (prefixed with !) bundle multiple individual targets into a single collection profile. Understanding what the key targets collect — and what investigation questions each artifact category answers — is the difference between running KAPE as a black box and running it as a deliberate investigative tool.

!SANS_Triage — the standard IR collection. This compound target was designed by the SANS DFIR team and is the most commonly used collection profile in incident response. It collects artifacts across six evidence categories, each mapping to specific investigation questions and specific modules in this course:

Evidence of Execution (→ IR3): Prefetch files record which programs ran, when they last ran, how many times they have run, and which files and directories were loaded during execution. Amcache.hve records program execution with SHA1 file hashes — critical for correlating executed programs with known-malware hash databases. ShimCache (in the SYSTEM hive) records application compatibility checks that serve as evidence of execution or presence on disk. BAM/DAM (Background/Desktop Activity Moderator, in the SYSTEM hive) records recent program execution with full path and timestamp. UserAssist (in NTUSER.DAT) records GUI program execution with run counts and focus time. These artifacts collectively answer the most fundamental investigation question: "What executed on this system, when, and how many times?"

Registry Hives (→ IR4): SAM (local account names, SIDs, last logon timestamps, password policy), SYSTEM (services and their executable paths, USB device history with serial numbers and connection timestamps, network profiles with SSIDs and first/last connection times, boot configuration), SOFTWARE (installed programs with install dates, OS version, computer name, time zone), SECURITY (audit policy configuration, LSA secrets), NTUSER.DAT per user (Run/RunOnce persistence keys, typed paths in Explorer, recent documents, MRU lists, UserAssist execution data), UsrClass.dat per user (ShellBags — a complete history of every folder the user navigated to in Explorer, including folders on USB drives and network shares, persisting even after the folder is deleted). These answer: "What is configured on this system, what has the user done, and what persistence mechanisms exist?"

Event Logs (→ IR5): All .evtx files from C:\Windows\System32\winevt\Logs\ — typically 50-200 log files. The critical logs for IR: Security.evtx (logon events 4624/4625, process creation 4688, account management 4720/4726, audit policy changes), System.evtx (service installation 7045, system time changes 4616, unexpected shutdown), Microsoft-Windows-PowerShell%4Operational.evtx (ScriptBlock logging 4104, module logging 4103), Microsoft-Windows-Sysmon%4Operational.evtx (if Sysmon is installed — process creation with hashes, network connections, file creation, registry changes), Microsoft-Windows-TaskScheduler%4Operational.evtx (scheduled task creation and execution), Microsoft-Windows-TerminalServices-*.evtx (RDP connections and sessions). These answer: "What happened on this system chronologically — who logged in, what processes were created, what services were installed, what PowerShell commands were executed, and what remote connections were established?"

NTFS Metadata (→ IR4): $MFT (Master File Table — a record of every file and directory that has ever existed on the volume, with four timestamps per entry: creation, modification, access, and MFT entry modification), $UsnJrnl:$J (the USN Change Journal — a sequential log of every file system operation: creation, deletion, rename, data change, attribute change), $LogFile (the NTFS transaction log). The $MFT and $UsnJrnl together provide a complete filesystem timeline — when files were created, modified, renamed, and deleted. This is how you determine "the attacker created update.exe in C:\Users\jmorrison\AppData\Local\Temp\ at 14:36:07 UTC and deleted it at 14:52:33 UTC." Even after a file is deleted, the $MFT entry persists (marked as free but not overwritten until the space is needed), and the $UsnJrnl records the deletion event.

User Activity: Jump Lists (recent file access per taskbar application), LNK shortcut files (link target path, access timestamps, volume serial numbers — evidence of file access including files on now-disconnected USB drives), browser history (Chrome, Firefox, Edge — URLs visited with timestamps, downloads with source URLs, search terms, form data), PowerShell console history (PSReadLine ConsoleHost_history.txt — a plain text log of every command typed in PowerShell, stored per user), Windows Timeline (ActivitiesCache.db — application usage timeline with timestamps), SRUM (System Resource Usage Monitor — network usage per application per hour, application execution time, energy usage). These answer: "What did the user interact with, which websites were visited, what files were recently opened, and what PowerShell commands were typed?"

System Configuration: Scheduled task XML definitions (C:\Windows\System32\Tasks\ — every scheduled task including the executable, arguments, trigger conditions, and creation metadata), WMI repository (persistent WMI event subscriptions — a common APT persistence mechanism (T1546.003)), the hosts file (attacker modifications redirect DNS resolution), Startup folder contents, Group Policy results. These answer: "What persistence mechanisms are installed and what system-level configuration has been modified?"

A single !SANS_Triage collection captures all of the above in one pass. For the vast majority of incident response investigations — BEC, credential phishing, ransomware pre-encryption analysis, insider threat, malware execution — this provides the evidence base for the complete investigation.

!BasicCollection — a lighter profile for bandwidth-constrained scenarios. Collects event logs, registry hives, and Prefetch only. Approximately 50-200 MB versus 500 MB-2 GB for !SANS_Triage. Use this when collecting over a slow VPN connection from a remote worker's home, when you need a quick answer in 60 seconds before committing to a full triage, or when collecting from dozens of endpoints simultaneously for scope determination and you need to minimize network impact.

!KapeTriage — Kroll's recommended triage profile. Similar to !SANS_Triage with additional targets for cloud-synced directories (OneDrive, Google Drive, Dropbox local caches), Outlook data files (.ost/.pst), and additional application-specific artifacts. The cloud-sync targets are increasingly important: when an attacker exfiltrates data through OneDrive sync, the local OneDrive cache on the endpoint contains evidence of what was synced and when — evidence that may not appear in the M365 audit logs if the sync happened before the investigation began.

---

Your first KAPE collection

Run a test collection on your forensic workstation to validate the installation and internalize the output structure.

After the collection completes, examine the output to understand what was collected and verify completeness.

Typical workstation results: 200-800 Prefetch files, 50-200 event log files, 6-12 registry hives, $MFT captured, 500-2,000 total files, 200 MB-2 GB total. This is the evidence base for a complete investigation — collected in minutes.

---

Running targets and modules together: the production command

In production, you run Targets (collect) and Modules (parse) in a single KAPE command. The Module phase processes collected artifacts through EZTools automatically, producing parsed CSV files categorized by investigation question.

The --mdest output is organized by evidence category, not by parser tool. The EvidenceOfExecution folder contains results from three different parsers (PECmd, AmcacheParser, AppCompatCacheParser) that all answer the same question: "What executed on this system?" The investigator opens one folder to answer one question. This category-based organization — one of KAPE's most important design decisions — means that junior analysts can find relevant evidence without knowing which specific parser produced it.

---

Remote deployment

KAPE is portable and can be deployed to remote systems without pre-installation. Two primary methods:

The PsExec method writes KAPE output directly to a network share, avoiding the need to copy results back from the target system. The -s flag runs KAPE as SYSTEM, providing maximum access to locked files. Both methods require Administrator-equivalent credentials on the target.

---

Creating custom targets

Standard targets cover common Windows artifacts. Your environment may require additional collection: security product logs, custom application data, or investigation-specific files identified during an active case.

Custom targets combine with built-in targets in a single command: --target !SANS_Triage,CrowdStrike collects standard IR artifacts plus your CrowdStrike logs in one pass. Create custom targets for every security product, backup solution, and critical application in your environment — and add them to the jump bag (IR1.8).

---

GKAPE vs command line

KAPE provides a GUI (gkape.exe) and a CLI (kape.exe). The GUI is not a simplified version — it provides identical capabilities and automatically generates the equivalent CLI command as you make selections. This makes GKAPE invaluable for learning (browse all available targets in a filterable list), documentation (the generated CLI command records exactly what was collected), and transparency (review the command before executing).

Use GKAPE when learning, designing collection profiles, or demonstrating the tool to colleagues. Use the CLI when running production collections, deploying remotely, scripting batch operations, or running from the jump bag USB. In practice, experienced responders design their collection profiles in GKAPE, copy the generated CLI command, and use it in production.

---

Troubleshooting

"Access denied" during collection. KAPE must run as Administrator to access raw disk and locked files. Right-click PowerShell → Run as Administrator. For PsExec, use the -s flag.

Module phase produces no output. Check that EZTools binaries are in Modules\bin\. This is the most common issue. Run the bin directory verification script from the Installation section above.

Collection runs but VHDX is empty or very small. Verify the target name is correct and case-sensitive. Compound targets use ! prefix: !SANS_Triage not SANS_Triage. Run kape.exe --tlist to see all available targets.

"Failed to get admin share" with PsExec. The target system must have the default admin share (C$) accessible. This is standard in domain environments but may be disabled on standalone systems. Use PowerShell remoting instead, or access the target locally.

Worked investigation finding — KAPE collection assessment:

Finding: KAPE !SANS_Triage collection from DESKTOP-NGE042 completed in 3 minutes 42 seconds. Collection inventory: 743 Prefetch files, 127 event log files, 8 registry hives (SAM, SYSTEM, SOFTWARE, SECURITY, 2x NTUSER.DAT, 2x UsrClass.dat), $MFT captured (1.2 GB), $UsnJrnl captured (847 MB), 1,847 total files, VHDX size 2.1 GB. SHA256 of VHDX recorded in chain of custody log.

Proves: A forensically complete triage collection was acquired from the target endpoint within 4 minutes of the collection command. All major artifact categories are present for analysis. Does not prove: Whether the evidence was tampered with prior to collection. Whether the collection includes all artifacts specific to this incident (custom application logs may require additional custom targets). Next step: Process the collection with !EZParser to produce parsed CSV output. Run THOR Lite for compromise assessment. Begin analysis in Timeline Explorer.