# Acquisition Order Of Volatility > Acquisition Order of Volatility - Skill: `annatchijova/acquisition-order-of-volatility` (Agent Skill) - Install (CLI): `npx skillmds@latest add annatchijova/acquisition-order-of-volatility` - Raw SKILL.md: https://api.skillmd.com/api/skills/annatchijova/acquisition-order-of-volatility/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: annatchijova (https://skillmd.com/u/annatchijova) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/annatchijova/acquisition-order-of-volatility --- # Acquisition Order of Volatility The evidence you most need is the evidence that disappears fastest. The contents of RAM, the live network connections, the running process list, the routing and ARP tables — all of it is gone the instant someone pulls power or, almost as bad, starts poking at the box to "see what's going on." Disk survives; volatile state does not. So the first law of acquisition is not "make a copy" — it is **collect in order of volatility**, most-perishable first, because the order is the difference between having the evidence and having overwritten it. The second law follows from the first: **the act of collecting alters the scene.** Mounting a filesystem writes access times; running a tool allocates memory over the very RAM you wanted; opening a file changes its metadata. You cannot observe the system without touching it, so the discipline is to *minimize and record* your footprint, not to pretend you left none. The two failure modes that ruin evidence before analysis even begins: - **The "quick look."** An analyst logs in, browses the disk, runs a few commands, reboots to "check something" — and overwrites the memory, the timestamps, and the free space that held the answer. The investigation is now archaeology of the investigator's own footprints. - **Disk-first.** Imaging the drive (slow, non-volatile, patient) while the live connections to the C2, the injected process, and the decryption keys sitting in RAM quietly evaporate. You preserved the part that was in no hurry to leave. Composes with the library: - **finding-custody** — the chain of custody begins at the moment of collection, not later; this skill is where custody starts - **tamper-evident-audit-chain** — hash at the source so a verifier can later prove the image was not altered - **incident-timeline-reconstruction** — the timeline is built from what you collect; collect out of order and the timeline has holes you caused - **honest-degradation** — evidence collected imperfectly is a WARN on that evidence, stated, not a silent gap presented as clean - **containment-under-uncertainty** — the "pull the plug now" containment instinct collides with acquisition; sequence them deliberately --- ## Step 1 — Order the targets by volatility before you touch anything Write the collection order most-perishable to least, and follow it: 1. **CPU state, memory (RAM)** — the most volatile and often the richest: injected code, decryption keys, cleartext credentials, unpacked malware, network buffers. 2. **Live network state** — active connections, listening ports, ARP/routing tables, DNS cache: the map of what the box is talking to *right now*. 3. **Running processes and open handles** — the process tree, loaded modules, open files, which the reboot will erase. 4. **Ephemeral disk state** — temp files, swap/pagefile, unallocated space that the next write may reuse. 5. **Persistent disk** — the full image; non-volatile, patient, collect it after the perishable state is safe. 6. **Archived/remote logs, backups** — least volatile; collect but do not let them jump the queue ahead of RAM. The one non-negotiable ordering error: never reboot or power-cycle *before* memory is captured, unless a containment decision forces it — and if it does, say so (Step 5). --- ## Step 2 — Decide live vs dead acquisition, knowing each destroys something Two paths, and each has a cost you must name: - **Live acquisition** (collect from the running system) — preserves volatile state, but every tool you run alters memory and the running OS could be lying to you (a rootkit hides the very processes you are listing). Use trusted, statically-linked tools from external media; assume the compromised OS's answers are suspect. - **Dead acquisition** (power off, image the disk) — gives a clean, repeatable disk image, but *pulling power destroys all of Step 1's volatile state* and a graceful shutdown runs the attacker's shutdown scripts and changes the disk. Neither power-off option is free. There is no universally correct choice; there is a choice appropriate to *this* incident, made deliberately and recorded. The wrong move is to back into one by habit. --- ## Step 3 — Minimize and record the footprint you cannot avoid You will alter the scene; the discipline is to do it as little as possible and to log exactly what you did, so a later analyst can subtract your footprint from the attacker's: - Prefer read-only / write-blocked access to disk; use a hardware or software write-blocker for imaging. - Run collection tools from external, trusted media, not from the suspect disk. - Record every command you ran, when, as whom, and what it touched — your actions are part of the timeline and must be distinguishable from the adversary's. Unrecorded analyst activity is indistinguishable, later, from attacker activity — and that ambiguity can sink both the investigation and its admissibility. --- ## Step 4 — Hash at the source; custody starts here The integrity claim you will need later — "this image is exactly what was on the disk, unaltered since collection" — can only be made if you anchor it at the moment of collection: - Compute a cryptographic hash of the acquired image (and of memory) *at acquisition*, and record it (`tamper-evident-audit-chain`). - Work from copies; preserve the original acquisition untouched (`finding-custody`). - Note who collected it, when, from what, and how — the chain of custody is a line that starts at your hands, not one you can back-fill from memory later. --- ## Step 5 — When containment forces a bad order, say so honestly Sometimes the incident does not let you follow the order: ransomware is encrypting and you must pull power *now*, or the box was already rebooted before you arrived. That is a legitimate operational reality, and the honest response is not to pretend the evidence is pristine — it is to record the degradation: - "Memory not captured; host was powered off for containment at 14:02 before acquisition" is a WARN attached to the evidence, and it tells every downstream conclusion which questions can no longer be answered. - Evidence collected out of order, or after a reboot, is still evidence — but it is *scoped* evidence, and presenting it as clean is the forensic version of the overclaim this library forbids everywhere. `ABSTAIN` on the questions the lost volatile state would have answered. --- ## The one-line test If your first action on a suspect machine was to log in and look around, you began by overwriting the evidence you came for. Order the targets by how fast they vanish, capture memory before anything reboots it, hash at the source, and log your own footprint — because acquisition is the one phase where a mistake is not a wrong answer, it is the permanent absence of the right one.