7. Acquisition
Volatile evidence acquisition
In short: on a powered-on workstation this is the first acquisition, and with disk encryption it may decide whether anything else is readable.
Capture memory first when encryption is suspected
While an encrypted volume is unlocked, its key is in memory:
- BitLocker's full volume encryption key.
- A VeraCrypt master key.
- A LUKS master key held by the kernel.
Memory may also hold cached credentials, authentication tokens, session cookies, the plaintext of recently opened documents, and which encrypted containers are mounted and where.
Stop and think
All of it is gone at power-off. If there is any indication of encryption (section 3), or any doubt, capture memory before anything else runs on the machine.
Capture or record the live state
As well as physical memory, capture or record the following. Each item is an observed fact about the live system:
- Time: system time and time zone, compared against your reference clock.
- Users: logged-in users and active sessions, local and remote.
- Processes: running processes, with parent process, start time, path and command line where the tool provides it.
- Files: open files and handles.
- Volumes: mounted filesystems and volumes, with device paths and mount points.
- Encryption state: which volumes are unlocked, which protectors or key slots are in use, whether recovery keys are escrowed. On Windows the BitLocker status command reports this; on Linux the LUKS status and device-mapper tools do.
- Network: active connections, listening ports and the processes that own them.
- Caches: routing table, ARP cache and DNS cache.
- Shares: mapped network shares and drives.
- Authentication: cached domain credentials, Kerberos tickets, VPN sessions, browser sessions.
- Clipboard: contents, where the tool captures them without further interaction.
Why memory first, commands second
Much of this can be extracted later from the memory image with a memory analysis framework. So capture memory first and run as few live commands as possible. Live commands are still worth running for state the memory tools may not reliably reconstruct (encryption status is the usual example) and as a cross-check.
Pick the capture tool
| Tool | Platform | Notes |
|---|---|---|
| WinPmem (open source) | Windows | Command line, can write a raw image. Small footprint, scriptable. |
| Magnet RAM Capture (free) | Windows | Simple interface, writes a raw image. |
| LiME (Linux Memory Extractor) | Linux | Kernel module. Must be built against the exact kernel version of the target, so prepare it in advance. Loading a module is a larger footprint than a user-mode tool: record the module hash and the load. |
| AVML | Linux | User-mode alternative where the kernel exposes the necessary interfaces. |
| Hypervisor-level acquisition | Virtual machines (preferred) | A VMware snapshot produces memory files, Hyper-V checkpoints produce saved state, KVM can dump guest memory from the host. Guest state untouched; capture complete and consistent. Record the hypervisor, version and exact operation. |
- Run tools from your own trusted, write-protected media, never from the target's disk.
- Write output to your own destination media, never to the target.
- Have a tested destination with more free space than the machine has memory.
Accept the footprint, then document it
Loading a capture tool allocates memory, overwrites some pages and may cause others to be swapped. The image is therefore the state of memory during capture, with the tool's footprint in it, not the state before you arrived.
- This does not invalidate the evidence. Every memory capture ever taken has this property, and courts and examiners understand it.
- Be able to describe the footprint: which tool, how large, and that nothing else was run.
- Minimise it: one tool, run once, no exploring beforehand. Then document it.
- Note the capture duration. The system keeps running during capture, so a process may start or end between the beginning and the end of the read. A partially overwritten structure found later needs that context.
Stop and think
A capture whose footprint cannot be described is the one that will be attacked.
Document every volatile capture
- Tool name and version.
- SHA-256 hash of the executable or module actually run, recorded before use.
- The exact command line or interface options used.
- Start and finish times from your reference clock.
- Source and destination: the machine by asset and serial, the destination media by your evidence reference.
- Size of the resulting image and its SHA-256 hash, calculated immediately.
- Every error, warning or unexpected message, verbatim, including ones that looked harmless.
- What the machine was doing during capture, if observable (a dialogue appeared, a screen saver started).
Fall back on secondary sources
If live capture was impossible (the machine was found off, or capture failed), earlier memory contents may survive in:
- The disk image: the hibernation file, the page file and crash dumps.
- A virtual machine's host: the hypervisor's saved-state and snapshot files.
These are recovered evidence from an earlier moment, not a substitute for live capture, and should be described as such.
Example
The examiner inserts a write-protected USB stick containing WinPmem and records its hash from the pre-printed tool sheet. They open a command prompt (recording that this is the first interaction with the user interface), run the capture to an external SSD at 14:20, and note that it completes at 14:31 with no errors. They then run the BitLocker status command, photograph its output showing the system volume unlocked with a TPM protector and no escrowed recovery key, and record that. Only then is power removed. Total live interaction: two commands, both recorded.
Before you move on
- Memory captured before any other live command.
- Tool run from your own media, output on your own destination.
- Encryption status recorded with a live command and photographed.
- Capture record complete: tool, hashes, command, times, source, destination, errors.
- Image hashed immediately after capture.