Windows Acquisition and Triage with KAPE and Velociraptor

This guide walks through acquiring evidence from a Windows system in an order that preserves the most volatile data first, then imaging or triaging the disk without losing what you just protected. By the end you will be able to choose between live and dead-box acquisition, capture memory, image a disk (BitLocker included), run KAPE and Velociraptor triage collections, handle cloud VMs, and document everything so the evidence holds up.

Order of volatility on Windows

RFC 3227 formalised the idea that you collect the most short-lived evidence first. Applied to a running Windows host, the order of volatility looks like this:

The table is a guide, not a law. If you have one shot at a laptop that is about to be handed back, a triage collection of the right files may matter more than a perfect memory image. What matters is that you choose consciously and write down why.

Live response versus dead-box

A dead-box acquisition means the system is powered off and you image the disk through a write blocker. It is the cleanest option for integrity, but you lose memory and, on encrypted disks, possibly access to the data.

A live acquisition means you run tools on the running system. Every action changes something: your tool creates Prefetch entries, registry keys, event log records and memory allocations. That is acceptable as long as you minimise the footprint (run from external media, write output to external media or a network share) and record what you ran and when, so an analyst can later separate your activity from the attacker's.

In incident response, live acquisition is the norm: servers cannot always be shut down, BitLocker is increasingly common, and memory often holds the only trace of fileless malware. Dead-box remains standard for seized devices in criminal or HR cases where the machine is already off.

A practical rule: if it is on, leave it on until memory is captured; if it is off, leave it off and image it dead-box.

Memory capture first

Memory holds running processes, network connections, loaded drivers, command history, decrypted content and, often, encryption keys. It is also the first thing lost. Capture it before anything that might trigger a reboot or change system state significantly.

Common tools:

• WinPmem (Velocidex, open source): command-line, writes a raw image. The project has moved between a C version (winpmem_mini) and a newer Go rewrite, and the syntax differs between releases, so check the README of the build you carry.
• DumpIt (now distributed by Magnet Forensics): single executable, minimal interaction, good for handing to a non-specialist on site.
• Magnet RAM Capture: free GUI tool, produces a raw image.

# WinPmem (winpmem_mini release): write a raw image to external media
E:\tools\winpmem_mini_x64_rc2.exe E:\case\HOST01\mem.raw

# Hash the result immediately and record it
Get-FileHash E:\case\HOST01\mem.raw -Algorithm SHA256 | Format-List

Practical points:

• Write the image to external or network storage, never to the suspect system disk: you would overwrite unallocated space that may hold deleted evidence.
• Expect the image to be roughly the size of installed RAM. Check free space before you start.
• Acquisition drivers need administrator rights. Older drivers may fail to load, or destabilise the system, when memory integrity (HVCI) or other virtualization-based security features are on. Test your toolkit on current Windows builds before an incident, not during it.
• After memory, collect hiberfil.sys and pagefile.sys from disk: they contain older memory pages that complement the live image.

Analysis of the image is covered in Windows memory forensics with Volatility.

Disk imaging

Tools and formats

FTK Imager (Exterro) is the usual choice on Windows: it images physical disks, logical volumes and even memory, and verifies the result. On Linux, ewfacquire (libewf) and dc3dd or dd do the same job.

# Linux: image a write-blocked disk to E01 with case metadata prompts
ewfacquire -t /cases/HOST01/disk -f encase6 /dev/sdb

# Verify the stored hash against the image content
ewfverify /cases/HOST01/disk.E01

# Raw alternative with dc3dd, hashing on the fly
dc3dd if=/dev/sdb of=/cases/HOST01/disk.raw hash=sha256 log=/cases/HOST01/dc3dd.log

Hashing and write blockers

Hash the source and the image and record both. MD5 and SHA-1 are still common in forensic tooling for compatibility; add SHA-256 where the tool supports it. Hashing proves integrity from acquisition onward: it does not prove the source was not modified before you arrived, which is why your notes matter.

For dead-box work, connect the drive through a hardware write blocker. Software write blocking exists, but it depends on the operating system behaving as expected; on Linux, mounting read-only alone is not enough because some filesystems replay journals on mount, so use blockdev --setro and do not mount the source at all while imaging.

Soldered storage, unusual NVMe form factors and hardware-bound encryption make removing the disk impractical on many modern laptops. In those cases a live image from the running system, or a boot into a forensic environment, may be the only route.

BitLocker considerations

BitLocker changes the acquisition plan more than any other factor. On Windows 11, Device Encryption is enabled automatically on many consumer and business devices, often with the recovery key escrowed to a Microsoft account, Active Directory or Entra ID. Assume encryption until proven otherwise.

Check the state on a live system before doing anything irreversible:

manage-bde -status
# Recovery password and other protectors for the system volume
manage-bde -protectors -get C:

Your options, in order of preference:

1. The system is running and unlocked: capture memory, then take a logical image of the volume (FTK Imager "Logical Drive") or a triage collection. Windows decrypts transparently, so you get plaintext. A physical image of the same disk will contain ciphertext.
2. You have the recovery password: from manage-bde output, AD (msFVE-RecoveryInformation objects), Entra ID, Intune or the user's Microsoft account. Record it in your notes and image dead-box. Tools such as bdemount (libbde) or Arsenal Image Mounter can then unlock the image.
3. No key and the system is off: you have ciphertext. Do not power it on hoping for the best without a plan; TPM-only protectors will unlock at boot, but booting changes the system.

# Mount a BitLocker-encrypted image with its recovery password (libbde)
bdemount -r 123456-123456-123456-123456-123456-123456-123456-123456 disk.raw /mnt/bde

The same logic applies to third-party encryption: if it is unlocked now, that is your window.

Triage collection with KAPE

A triage collection copies the files that answer most questions (registry, event logs, NTFS metadata, execution and user-activity artifacts) in minutes instead of hours. KAPE (Kroll Artifact Parser and Extractor, by Eric Zimmerman) is the reference tool on Windows. Check its license terms if you use it on paid engagements.

KAPE works in two stages:

• Targets (.tkape) describe what to collect: paths, file masks, recursion. Compound targets bundle others; names starting with ! are conventions for curated collections such as !SANS_Triage and !BasicCollection. KapeTriage is another widely used compound target.
• Modules (.mkape) describe what to run on the collected data, typically Eric Zimmerman's parsers through the !EZParser compound module.

# Collect from the live C: volume, including shadow copies, into a VHDX container
kape.exe --tsource C: --tdest E:\case\HOST01\tout --target !SANS_Triage --vss --vhdx HOST01

# Parse a collection afterwards on the analysis workstation
kape.exe --msource E:\case\HOST01\tout --mdest E:\case\HOST01\mout --module !EZParser

Notes on the options:

• --vss tells KAPE to also collect from every volume shadow copy on the source volume, deduplicating identical files. This often recovers older registry hives and event logs; it also makes the collection slower and larger. See volume shadow copies.
• --vhdx or --zip packages the output into a single container, which is easier to hash and move.
• --tsource can point at a mounted image as well as a live volume, so the same targets work for dead-box images.
• Locked files: registry hives, $MFT, event logs and the USN journal are in use on a live system. KAPE detects locked files and reads them from the raw NTFS volume instead, so you get a usable copy without stopping services.

Run kape.exe --sync on your analysis machine (with internet access) to refresh targets and modules from the KapeFiles repository before you build your field kit.

Triage collection with Velociraptor

Velociraptor is an open-source endpoint agent and collection framework. It is the better choice when you need to collect from many hosts, hunt across the fleet, or run collection logic that goes beyond copying files.

The equivalent of KAPE targets is the Windows.KapeFiles.Targets artifact, which reuses the KapeFiles target definitions. In recent releases it has been superseded by Windows.Triage.Targets, and parameter names have changed between versions, so inspect the artifact on the version you run:

# Show the artifact definition and its parameters for this build
velociraptor.exe artifacts show Windows.KapeFiles.Targets

# Collect locally without a server (parameter names vary by version)
velociraptor.exe artifacts collect Windows.KapeFiles.Targets --args _SANS_Triage=Y --output E:\case\HOST01.zip

Velociraptor reads locked files through its ntfs accessor, which parses the volume directly. That is also how it collects $MFT, $UsnJrnl:$J and alternate data streams.

Offline collector

When you cannot deploy an agent (no network path, a third party's machine, a disconnected site), build an offline collector from the server GUI: pick the artifacts and parameters, choose an output (local ZIP, or upload to S3, Azure blob, SFTP), and Velociraptor produces a single preconfigured executable. Anyone can run it as administrator; it writes a Collection-<host>-<timestamp>.zip containing the files and a log of what it did. You can later import that ZIP into a server for analysis. Consider encrypting the output container with a certificate, since triage collections contain credentials material (SAM, SECURITY, browser data).

KAPE or Velociraptor?

Many teams use both: Velociraptor for fleet-wide scoping, KAPE for deep single-host collections, and the same parsed outputs feeding a super timeline.

Cloud virtual machines

For Windows VMs in AWS, Azure or Google Cloud you rarely touch hardware. The equivalent of disk imaging is a snapshot of the virtual disk:

# AWS: snapshot the EBS volume and tag it with the case number
aws ec2 create-snapshot --volume-id vol-0abc123 --description "CASE-2026-041 HOST01 C:" \
  --tag-specifications 'ResourceType=snapshot,Tags=[{Key=case,Value=CASE-2026-041}]'

# Azure: snapshot a managed disk, then get a time-limited SAS URL to export the VHD
az snapshot create --resource-group rg-ir --name host01-os-snap --source /subscriptions/<sub>/resourceGroups/rg-prod/providers/Microsoft.Compute/disks/host01-os
az snapshot grant-access --resource-group rg-ir --name host01-os-snap --duration-in-seconds 3600

Points to plan for:

• Memory first, still: providers do not generally give you a hypervisor-level memory dump. Run WinPmem or a Velociraptor memory artifact inside the guest before snapshotting or isolating in ways that stop the VM.
• Isolate without stopping: restrict the security group or network security group instead of shutting the instance down.
• Crash consistency: a snapshot of a running VM is crash-consistent, like pulling the plug. Expect dirty registry hives and replayable NTFS logs.
• Encryption and sharing: AWS snapshots encrypted with the default AWS-managed key cannot be shared with another account; copy them with a customer-managed KMS key first. Azure Disk Encryption on Windows is BitLocker inside the guest, with keys in Key Vault: retrieve them before you need them.
• Hashing: you cannot hash a snapshot object directly. Create a volume from it in an isolated forensic account, attach it to a forensic instance, image it and hash that image.
• Cloud logs: CloudTrail, Azure Activity Log and similar sources are evidence too, and they record your own snapshot actions, which helps the timeline.

Chain of custody and documentation

Evidence you cannot account for is evidence someone can challenge. Keep a chain of custody record and contemporaneous notes that cover:

• Who collected what, from which system (hostname, serial number, asset tag, cloud instance ID), where and when, with times in UTC and the system clock offset you observed (see UTC and local time).
• The exact commands and tool versions you ran, in order. Your actions will appear in the evidence; your notes explain them.
• Hashes of every image and container at acquisition, and every time the evidence changes hands.
• Storage: where the evidence lives, who can access it, and each transfer with signatures or ticket references.
• Decisions and deviations: why you did not capture memory, why you chose triage over a full image, why a step failed.

Common mistakes

• Shutting down to "preserve" evidence: you lose memory and possibly access to BitLocker-protected data.
• Writing output to the suspect disk: it overwrites unallocated space and pollutes the $MFT.
• Physical image of an unlocked BitLocker volume without a key: you walk away with ciphertext.
• Copying hives without their .LOG1/.LOG2 files: recent changes may exist only in the transaction logs. See Windows registry forensics.
• Trusting a stale toolkit: outdated KAPE targets miss new artifact paths; old memory drivers fail on current builds.
• No hash, no notes: the collection may still be useful for investigation but is weak as evidence.

Acquisition workflow checklist

1. Record the scene: system state, screen, network connections, time and clock offset. Photograph physical devices.
2. Decide live or dead-box; write down the reason.
3. If live: capture memory to external media and hash it.
4. Check BitLocker with manage-bde -status; retrieve the recovery password from the host or the directory.
5. Collect volatile state (processes, network, sessions) with Velociraptor or approved commands.
6. Run a triage collection (KAPE !SANS_Triage or Velociraptor) with shadow copies; hash the container.
7. If warranted, take a full image (logical if encrypted and unlocked, physical otherwise) and verify it.
8. For cloud VMs: in-guest memory, isolate by network rules, snapshot, copy to a forensic account, image and hash.
9. Complete the chain of custody record and store evidence on access-controlled media.
10. Start analysis from copies, never the originals: for example with the evidence of execution artifacts and a super timeline.

For the bigger picture of where these collections fit in an investigation, see Getting started with Windows forensics.