Order of volatility and live response: what to collect first

Why order matters

When you arrive at a suspect computer that is still switched on, the clock is already running. Running processes, open network connections and encryption keys live in memory and vanish when the power goes off. Files on disk last longer, but normal activity, log rotation and deleted-space reuse slowly overwrite them. Backups and central logs last longest.

The order of volatility is a simple rule: collect the data that will disappear soonest first. RFC 3227, the Internet Engineering Task Force (IETF) guidance on evidence collection, set out this idea and is still the standard reference.

The order in practice

1. Registers and cache: in practice you cannot collect these separately; they are captured, if at all, as part of memory.
2. Memory and system state: a full RAM image, plus running processes, logged-on users, the routing and ARP (Address Resolution Protocol) tables and active network connections.
3. Temporary file systems: swap or page files, temp folders and hibernation files.
4. Disk: a full forensic image of internal storage (see disk imaging).
5. Remote logging and monitoring: firewall, proxy, SIEM and cloud audit logs, which may have short retention so request them early.
6. Physical configuration and archives: network diagrams, backups and offline media.

Item five is often forgotten. A cloud provider or firewall might only keep logs for a few days, so in practice you may ask for them at the same time as capturing memory.

Doing a live response safely

Live response means collecting evidence from a running system. Every action you take changes it slightly: your tool uses memory and creates processes. The aim is to keep those changes small, known and documented.

• Use trusted tools from your own write-protected USB drive or network share, not the suspect machine’s own programs, which might be tampered with.
• Write output to external storage, never to the suspect disk.
• Capture memory first, then gather quick state information.
• Record the system time against a trusted clock so you can correct timestamps later.
• Hash every file you collect and log it on the chain of custody.

A short Windows triage, run from your own toolkit after the memory image, might include:

date /t & time /t
hostname
query user
tasklist /v
netstat -ano
ipconfig /all
arp -a

Making the call and avoiding mistakes

Deciding whether to collect live or power off depends on the case. If full-disk encryption is on, the disk may be unreadable once powered off, so capturing memory and logical files while it is unlocked can be essential. If the system is actively destroying data, isolating it from the network quickly may matter more. Document the reason for your choice.

Common mistakes include rebooting the machine "to see if the problem clears", running antivirus scans that delete or quarantine evidence, copying files with normal tools that update access times, and forgetting to ask for short-lived cloud logs. With modern endpoint detection and response (EDR) tools you can often isolate a host from the network while keeping it powered on, which is a good compromise.

Tip: only perform live response on systems you are authorised to investigate, and practise on your own lab virtual machines first.

Real-world example: a suspicious server at a logistics firm

At a fictional logistics firm, the security team sees a database server making unusual outbound connections at night. The responder does not switch it off. Working from a trusted USB toolkit and taking notes, she first captures memory, then records current network connections and running processes, and only then arranges a disk image during a maintenance window. Firewall and proxy logs are exported last because they are kept centrally for 90 days. Analysis of the memory image finds a malicious process that never wrote itself to disk; powering off first would have destroyed the best evidence.