Chapter 43

KAPE Deep Dive

KAPE (Kroll Artifact Parser and Extractor) is the fastest path from live system to parsed artifacts. This chapter covers the architecture difference between Targets (collection) and Modules (processing), writing custom Targets, and automating a complete KAPE collection-to-analysis pipeline.

Scenario

You have 30 minutes to collect evidence before the server is restored. KAPE with the !SANS_Triage target runs for 18 minutes and produces 847 MB of compressed artifacts — every forensically relevant file from the system without a full disk image. The remaining 12 minutes are spent running EZ Tools modules over the collected data, producing parsed CSVs ready for analysis. By the time the server is restored, you have actionable forensic data.

KAPE Architecture: Targets vs Modules

  KAPE Two-Phase Architecture
  ═══════════════════════════════════════════════════════════════════

  Phase 1: TARGET COLLECTION
    ├── What: Copy specific files from the source to a collection directory
    ├── Defined by: .tkape files in Targets\
    ├── Source: Live system, mounted image, or forensic image
    └── Output: Raw files in target output directory (e.g., C:\KAPE-OUT\C\)

    Target file structure (.tkape):
      Description: What this target collects
      Category: Category name
      Path: C:\Windows\Prefetch\
      Recursive: true
      FileMask: "*.pf"
      Comment: "Prefetch execution artifacts"

  Phase 2: MODULE PROCESSING
    ├── What: Run tool (EZ Tools, etc.) against collected files
    ├── Defined by: .mkape files in Modules\
    ├── Input: Target output directory
    └── Output: Parsed CSV/JSON files in module output directory

    Module file structure (.mkape):
      Description: What this module does
      Category: Processing category
      FilePath: .\KAPE\Modules\bin\PECmd.exe
      CommandLine: "-d %sourceDirectory%\\C\\Windows\\Prefetch -q --csv %destinationDirectory%"
      ExportFormat: csv
      Processors:
        - Processor: 4   (Windows EventLog Viewer, optional)

Key Target Collections

Target	What it collects	Compressed size (typical)
!SANS_Triage	Comprehensive collection: event logs, registry, prefetch, LNK, shellbags, browser history, SRUM, BAM, scheduled tasks, services, network config	300–900 MB
EventLogs	All .evtx files from System32\winevt\Logs\	50–500 MB depending on log size configuration
RegistryHives	All registry hives: SAM, SYSTEM, SECURITY, SOFTWARE, NTUSER.DAT	50–200 MB
Prefetch	All .pf files from C:\Windows\Prefetch\	5–30 MB
LNKFilesAndJumpLists	Recent items and Jump Lists for all users	2–15 MB
WebBrowsers	Chrome, Edge, Firefox history/cache databases	10–100 MB
SRUM	SRUDB.dat + SRUM-related registry keys	5–50 MB
$MFT	Master File Table (the entire NTFS file system catalog)	50–500 MB (uncompressed)

Batchkape-complete-collection.bat

@echo off
REM Complete KAPE collection + processing pipeline
REM Run on the target system (requires KAPE deployed to target)
REM Output goes to network share or local evidence drive

SET KAPE=\\tools-share\kape\kape.exe
SET TARGET_OUT=\\evidence-nas\CASE-2026-009\FINANCE-SRV01\triage
SET MODULE_OUT=\\evidence-nas\CASE-2026-009\FINANCE-SRV01\parsed
SET FLUSH=%TARGET_OUT%\flush.log

REM Phase 1: Target collection (copy artifacts)
echo Starting target collection...
%KAPE% ^
    --tsource C: ^
    --tdest %TARGET_OUT% ^
    --target !SANS_Triage ^
    --vhdx FINANCE-SRV01-triage ^
    --zv false ^
    --ul true

REM Flush results to network share
echo Flushing to evidence NAS... >> %FLUSH%
robocopy %TARGET_OUT% \\evidence-nas\CASE-2026-009\FINANCE-SRV01\triage /MIR /LOG+:%FLUSH%

REM Phase 2: Module processing (parse artifacts with EZ Tools)
echo Starting module processing...
%KAPE% ^
    --msource %TARGET_OUT% ^
    --mdest %MODULE_OUT% ^
    --module !EZParser ^
    --zm true

echo Collection and processing complete.
echo Parsed output at: %MODULE_OUT%

Writing Custom Targets

YAMLcustom-cobalt-strike.tkape

Description: Cobalt Strike indicator artifacts — named pipes, beacon artifacts
Author: Analyst
Version: 1.0
Id: 12345678-1234-1234-1234-123456789012
RecreateDirectories: true

Targets:
  - Name: WindowsTempExecutables
    Category: MalwareStaging
    Path: C:\Windows\Temp
    Recursive: true
    FileMask: "*.exe,*.dll,*.ps1,*.bat,*.vbs"
    Comment: "Executables in Windows Temp — common staging location"
    IsDirectory: false

  - Name: CobaltStrikeDefaultPaths
    Category: MalwareStaging
    Path: C:\
    Recursive: false
    FileMask: "svchst.exe,svchost32.exe,update.exe,msupdate.exe"
    Comment: "Common CS beacon filenames found in investigations"
    IsDirectory: false

  - Name: ScheduledTaskXML
    Category: Persistence
    Path: C:\Windows\System32\Tasks
    Recursive: true
    FileMask: "*"
    Comment: "Scheduled task XML definitions"
    IsDirectory: false

Q & A

Q: KAPE collects locked files (like the live registry hives). How does it do this without stopping the registry service?

KAPE uses Volume Shadow Copy to access locked files. When you run a KAPE target that includes locked files (registry hives, NTDS.dit, event logs that are being written to), KAPE first creates a VSS snapshot of the volume, then copies the files from the snapshot (where they're not locked — the snapshot is a read-only point-in-time copy). After collection, KAPE deletes the VSS snapshot it created. This is why: (1) KAPE requires running as administrator (VSS creation requires admin privileges), (2) KAPE creates momentary VSS snapshot activity visible in Event Log / registry (document this in chain of custody notes — it's an expected artifact of the collection process, not an anomaly), (3) KAPE works even when the system is under load — it captures a consistent point-in-time state. On systems where VSS isn't available (Server Core with no VSS writers, some hardened environments), KAPE falls back to copying files directly — which works for most files but may fail on actively-written-to databases. In those cases, use raw-mode copy tools or a forensic acquisition approach instead.