During incident response triage, how should volatile memory be prioritized and why?

• A. Collect memory last after disk images.
• B. Ignore memory if encryption keys are not found.
• C. Collect memory first because it contains live processes, network connections, and encryption keys and is highly volatile.
• D. Collect only static files and logs.

Answer: (C)

Volatile memory should be collected first because it contains the system’s live state: running processes, active network connections, loaded modules, and ephemeral data such as encryption keys or credentials cached in RAM. This data is highly volatile and can disappear within seconds to minutes if the machine reboots, powers off, or is tampered with, so capturing it early preserves the immediate context of the incident. Having memory during triage allows you to see what the attacker was doing in real time, identify injected processes, credential access, and live communication, and even recover session keys or keys used for decrypting in-memory or live sessions.

Relying on memory last means the evidence is at risk of being lost, and you’d lose critical indicators of compromise that aren’t stored elsewhere. Focusing only on static files and logs misses the live activity and the transient artifacts that memory uniquely holds. Ignoring memory because keys aren’t found is also flawed, since memory can contain other indicators like suspicious processes and network activity that help map the attack, and keys might become usable through other means or remain discoverable later. Collecting memory alongside disk images and logs provides a fuller, more accurate picture of the incident’s current state and evolution.