7. Acquisition
Volatile evidence acquisition
Volatile evidence exists only while the machine is running. On a workstation that is powered on, this is the first acquisition, and on a workstation with disk encryption it is the acquisition that may decide whether anything else is readable.
Why memory comes 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 information about which encrypted containers are currently mounted and where. 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 that runs on the machine.
What to capture
In addition to physical memory, capture or record the following. Each item is an observed fact about the live system:
- System time and time zone, compared against your reference clock.
- Logged-in users and active sessions, local and remote.
- Running processes, with parent process, start time, path and command line where the tool provides it.
- Open files and handles.
- Mounted filesystems and volumes, including their device paths and mount points.
- Encrypted volumes and their state: which 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.
- Active network connections, listening ports and the processes that own them.
- Routing table, ARP cache and DNS cache.
- Mapped network shares and drives.
- Relevant authentication and session state: cached domain credentials, Kerberos tickets, VPN sessions, browser sessions.
- Clipboard contents, where the tool captures them without further interaction.
Much of this can be extracted later from the memory image with a memory analysis framework, which argues for capturing memory first and running 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.
Memory acquisition tools
- WinPmem (open source) captures physical memory on Windows from the command line and can write a raw image. Small footprint, scriptable.
- Magnet RAM Capture (free) captures Windows memory through a simple interface, writing a raw image.
- LiME (Linux Memory Extractor) is a kernel module that captures memory on Linux. It must be built against the exact kernel version of the target, which means preparing it in advance; loading a module is itself a larger footprint than a user-mode tool, so record the module hash and the load. AVML is a user-mode alternative on Linux where the kernel exposes the necessary interfaces.
- Hypervisor-level acquisition is preferred for virtual machines: a VMware snapshot produces memory files, Hyper-V checkpoints produce saved state, and KVM can dump guest memory from the host. The guest's state is untouched, and the capture is complete and consistent. Record the hypervisor, version and the exact operation.
Run tools from your own trusted, write-protected media, never from the target's disk, and write the output to your own destination media, never to the target. Have a tested destination with more free space than the machine has memory.
Acquisition changes memory, and that is acceptable if it is documented
Loading a capture tool allocates memory, overwrites some pages and may cause others to be swapped. The captured image is therefore not the state of memory before you arrived; it is the state during capture, with the tool's footprint in it. This does not invalidate the evidence. Every memory capture ever taken has this property, and courts and examiners understand it. What matters is that you can say what the footprint was: which tool, how large, and that nothing else was run. Minimise it (one tool, run once, no exploring beforehand) and document it. A capture whose footprint cannot be described is the one that will be attacked.
Memory images can also be internally inconsistent because the system keeps running during capture: a process may start or end between the beginning and the end of the read. Note the capture duration; a memory analysis that finds a partially overwritten structure needs that context.
Required documentation for 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 (the machine, identified by asset and serial) and destination media (identified 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).
Secondary sources of memory contents
If live capture was impossible (the machine was found off, or capture failed), the hibernation file, the page file and crash dumps on the disk image can contain earlier memory contents, and on a virtual machine the hypervisor's saved-state and snapshot files can. 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, records its hash from the pre-printed tool sheet, opens a command prompt (recording that this is the first interaction with the user interface), runs the capture to an external SSD at 14:20, and notes that it completes at 14:31 with no errors. The examiner then runs the BitLocker status command, photographs its output showing the system volume unlocked with a TPM protector and no escrowed recovery key, and records that. Only then is power removed. Total live interaction: two commands, both recorded.