KAPE and Triage Collection Guide: Fast Forensic Collection for Windows Incidents

Full disk images take hours to acquire and longer to process, while most early incident questions can be answered from a few gigabytes of well-chosen files. Triage collection grabs those files, such as registry hives, event logs, the $MFT and evidence of execution, in minutes, and KAPE (Kroll Artifact Parser and Extractor) is one of the most widely used tools for doing it on Windows. This guide explains how KAPE's targets and modules work, the triage workflow, safe deployment, the licensing terms as the project currently states them, and the alternatives. It is written for incident responders, SOC analysts who perform first response, and DFIR leads who must choose a collection approach. Evidence handling and the meaning of each artefact are covered in linked guides rather than repeated here.

Key takeaways

• Targets collect, modules process. Targets are YAML lists of file and directory paths to copy; modules are YAML definitions that run one program each against collected files or a live system.
• Logs are built in. Every run writes a console log and a copy log with the source path, destination and SHA-1 of each file, which supports your chain of custody.
• Licensing changed on 1 January 2026. The KAPE documentation states it is free for government, educational, research and internal company use, and no longer available for commercial use such as paid engagements on third-party networks.
• Prepare the kit before the incident. KAPE needs Administrator rights, synced target and module files, and module binaries you download yourself.
• Know your alternative. A Velociraptor offline collector or another triage collector can fill the gap where KAPE's licence or Windows focus does not fit.

What the tool does

KAPE was created by Eric Zimmerman and released through Kroll in 2019. Its documentation describes it as a triage program that targets a device or storage location, finds the most forensically useful artefacts and parses them quickly, so investigators can prioritise critical systems and collect key evidence before imaging finishes. It does nothing on its own: it reads configuration files and acts on them, which is what makes it extensible. It is a standalone program that needs no installation, but it requires Administrator rights. A graphical front end, gkape, builds the same command lines.

Targets

A target (a .tkape file) is a collection of file and directory specifications with required fields Description, Author, Version, Id (a GUID) and RecreateDirectories, followed by a list of entries each with Name, Category and Path. Paths are written as if on the C drive and KAPE substitutes the real source at run time; wildcards are supported. KAPE expands the target into files that exist on the source and copies them to the destination. Locked files, such as live registry hives, are read through raw disk access, original timestamps are reapplied and metadata is logged. Compound targets reference other targets. The best known is KapeTriage, which its description says pulls file system files, registry hives, event logs, scheduled tasks, evidence of execution, SRUM and SUM data, cloud storage metadata, browser history, LNK files and jump lists, third-party remote access and antivirus logs, and $I Recycle Bin files.

Modules

A module (a .mkape file) runs exactly one command, so you need one module per executable. Fields include Category (for example ProgramExecution, Registry or FileFolderOpening), BinaryUrl, ExportFormat, an optional WaitTimeout in minutes and an optional FileMask. Output from modules in the same category lands in the same folder, so Amcache and ShimCache results both appear under ProgramExecution. Modules can also run live response commands such as netstat or ipconfig. KAPE does not download module binaries automatically: you place them in .\KAPE\Modules\bin, and the documentation says this is deliberate, for your protection.

Defender use cases

• First-hour triage of a suspected compromise: run KapeTriage against the system drive into a VHDX, move it to an analysis host, and process it there. This keeps execution on the suspect host short.
• Collect and process in one pass: run targets and modules together (for example registry and event log parsers) when speed matters more than minimising activity on the host, and review the CSV output for leads.
• Mounted images and offline drives: point --tsource at a mounted image or a write-blocked drive letter to triage evidence that has already been acquired.
• Remote or scaled collection: push a prepared KAPE folder through existing management tooling and upload the container to an SFTP server or cloud bucket, or use batch mode (_kape.cli) for repeatable runs.
• Machine credential scoping: triage output often reveals which service accounts ran, which scheduled tasks executed and which remote access tools were present, which helps decide which non-human credentials to rotate. See the Service Account Security Guide.

Interpreting the collected artefacts is covered in the Windows Forensic Artefacts Guide. KAPE copies files; it does not capture RAM, so acquire memory first where it matters, using the approach in the Memory Forensics Guide.

Deployment and safe use

Check the licence first

The KAPE documentation FAQ, under "Can I use KAPE in client engagements?", states: "KAPE is free for any local, state, federal or international government agency. KAPE is also free for educational, research, and internal company use." It then states: "As of January 1, 2026 KAPE IS NO LONGER AVAILABLE for commercial use (i.e. when used on a third-party network and/or as part of a paid engagement)." Kroll's original 2019 announcement referred to an enterprise licence for commercial use; the current FAQ does not mention one, so treat the FAQ as the governing statement and confirm with Kroll if in doubt. In practice an internal security team responding on its own network falls within the free uses described, while an incident response provider or consultant working on a client's network does not. Note that the community target and module files on GitHub are a separate repository from the KAPE program itself.

Build and use the kit

1. Build a trusted kit on a clean workstation. Download KAPE from Kroll, run --sync to fetch current targets and modules, download the module binaries you need into Modules\bin from their stated BinaryUrl, and record hashes of the whole folder.
2. Test on a representative host. Run your chosen targets against a lab machine and check the copy log for gaps and run time. Use --tlist and --mdetail to confirm what will run and which binaries are missing.
3. Decide where execution happens. Prefer targets only on the suspect host, with modules run later on an analysis workstation. Running modules on the suspect host changes more of its state.
4. Collect. Run from removable media or a network share as an administrator, with output to external media or a share rather than the suspect disk where possible, for example: kape.exe --tsource C: --target KapeTriage --tdest E:\%m\tout --vhdx %m.
5. Verify and seal. Keep the console log, copy log and skip log with the container, hash the container, and log it into your evidence process. See the Evidence Handling and Chain of Custody Guide.
6. Clean up. Remove the KAPE folder from the host if it was copied there and note in the case record what was run, by whom and when.

Credentials in the command line

Upload options take secrets as switches: an SFTP password, S3 access key and secret (--s3k, --s3s, optionally a session token), or an Azure SAS URI. The documentation notes that the SFTP password is redacted from the console log, but command lines are often captured elsewhere, for example by EDR, Sysmon event ID 1 or Windows event 4688 with command line auditing, and an attacker on the host may see them. Treat these as short-lived non-human credentials: use a presigned S3 PUT URL (--s3url) or a SAS URI limited to write on one container with a short expiry, use a dedicated bucket, never reuse a long-lived access key, and revoke it after the collection. See the API Key Management Guide and the Cloud Forensics Guide.

Which approach when

Smaller organisations benefit most from a prepared, tested kit and a written runbook, because the person running it during an incident may not be a forensic specialist. Larger organisations typically combine a fleet tool for scoping with per-host triage for confirmed systems.

Detection and hardening value

Triage collection is a detection aid as much as a response tool: parsed output quickly shows persistence, execution and lateral movement that live tooling missed. It also reveals logging gaps, for example event logs that roll over within hours or PowerShell logging that was never enabled. Feed those gaps back into logging policy. See the Sysmon Guide and the Logging and Monitoring Policy Template.

Because KAPE runs with administrator rights and reads raw disk, its use should itself be visible. Expect EDR alerts on raw volume access and shadow copy mounting, agree with the SOC how responders announce collections, and alert on KAPE executions that do not match an open case.

Copy log fields that support evidence integrity

Metrics

• Time to triage: minutes from the decision to collect to a container on the analysis host.
• Kit currency: days since the kit was last synced, tested and re-hashed (target: quarterly or less).
• Collection completeness: share of collections where the copy log shows all expected artefact categories.
• Credential exposure: number of upload credentials still valid more than 24 hours after a collection (target: zero).
• Evidence integrity: share of containers with hash, logs and custody record complete.

Framework mapping

Alternatives

Tool selection criteria are covered in the Digital Forensics Tools Buyer's Guide.

Common failure patterns

• Assuming the licence still allows paid engagements: the current FAQ says commercial use ended on 1 January 2026.
• Building the kit during the incident: syncing and downloading binaries from a compromised host wastes time and trusts the wrong machine.
• Writing output to the suspect disk: it overwrites unallocated space that might hold deleted evidence.
• Running modules on the suspect host by default: more processes and file writes on the system you are investigating.
• Long-lived cloud keys on the command line: they end up in process creation logs and can be reused by the attacker.
• Discarding the logs: without the copy log and console log you lose the record of what was taken and how.

Practitioner checklist

• Confirm your use is within the KAPE licence terms stated in the documentation FAQ; choose an alternative for paid client work.
• Build the kit on a clean machine, sync targets and modules, add binaries and record hashes.
• Test KapeTriage and your custom targets in a lab and record expected run times.
• Acquire memory first where it matters, then collect targets to external media or a share.
• Package into VHDX or zip, hash it and keep the console, copy and skip logs with it.
• Run modules on an analysis workstation, not the suspect host, unless speed requires otherwise.
• Use presigned or short-lived, write-only upload credentials and revoke them after use.
• Agree with the SOC how collections are announced so EDR alerts can be closed quickly.
• Review the kit quarterly and after every incident.

Standards and references

• Eric Zimmerman: KAPE Documentation
• KAPE Documentation: Frequently Asked Questions (licensing)
• Kroll: Kroll Artifact Parser and Extractor (KAPE)
• GitHub: KapeFiles community targets and modules
• NIST: SP 800-86 Guide to Integrating Forensic Techniques into Incident Response
• Velociraptor: Offline Collections
• GitHub: CyLR live response collection tool

Related NHI Mgmt Group resources: Digital Forensics (DFIR) Guide · Windows Forensic Artefacts Guide · Memory Forensics Guide · Incident Response Guide