| name | collecting-volatile-evidence-from-a-suspect-host |
| description | Collects volatile evidence from a potentially compromised host in correct order of volatility: memory, network state, running processes, logged-on users, and open handles, while preserving integrity and minimizing footprint. Activates for requests to collect volatile evidence, perform live response, or capture host state before shutdown. |
| domain | cybersecurity |
| subdomain | lab-foundations |
| tags | ["lab-foundations","live-response","volatile-evidence","forensics","incident-response"] |
| version | 1.0.0 |
| author | analyst-ai-pack |
| license | Apache-2.0 |
| mitre_attack | ["T1057","T1049"] |
| d3fend | ["D3-PSA","D3-SFA"] |
| references | ["RFC 3227 Guidelines for Evidence Collection and Archiving — https://www.rfc-editor.org/rfc/rfc3227","NIST SP 800-86 forensic techniques — https://csrc.nist.gov/pubs/sp/800/86/final"] |
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
