Collecting volatile evidence from a suspect host

Collecting Volatile Evidence from a Suspect Host

When to Use

• A host is suspected of compromise and you must capture state that disappears on reboot.
• You are performing live response before isolating or imaging the machine.
• You need an ordered, integrity-preserving collection for later analysis.

Do not use this as a substitute for full disk imaging when persistence matters — volatile collection complements, not replaces, a forensic image. And do not reboot before collecting.

Prerequisites

• Trusted, statically linked collection tools run from external media (not host binaries).
• Authorization to collect, and a destination on external/write-once media.

Safety & Handling

• Assume host tools are compromised; use your own trusted binaries to avoid rootkit deception.
• Hash every artifact at collection time and record actions for chain of custody; minimize changes to the host.

Workflow

Step 1: Follow the order of volatility

Collect most-volatile first (RFC 3227): CPU/registers and cache → RAM → network state and connections → running processes → logged-on users/sessions → open files/handles → then disk.

Step 2: Capture memory first

Acquire a full RAM image with a trusted acquisition tool before anything that alters memory; it is the richest and most perishable source.

Step 3: Snapshot network and process state

Record active connections, listening ports, ARP/DNS cache, running processes with command lines and parent links, and loaded modules.

python scripts/analyst.py manifest ./collection --case IR-42 --host WS01

Step 4: Record users and handles

Capture logged-on users, sessions, scheduled tasks, and open handles/files.

Step 5: Hash, log, and hand off

Hash each artifact, write a collection manifest with timestamps, and transfer to the analysis environment preserving integrity.

Validation

• Artifacts are collected in order of volatility, memory first, before any reboot.
• Every artifact has a recorded hash and collection timestamp in the manifest.
• Trusted external tools were used; host changes are documented.

Pitfalls

• Rebooting or shutting down before capturing RAM, destroying the best evidence.
• Using the host's own (possibly trojaned) tools and trusting their output.
• No hashing/manifest, undermining evidentiary integrity.

References

• See references/api-reference.md for the manifest helper.
• RFC 3227 and NIST SP 800-86 (linked in frontmatter).