Volatile Data and the Order of Volatility

A running computer holds data in several storage layers simultaneously. The fastest and most transient are the CPU registers and cache: small, extremely fast memory circuits that hold the values the processor is currently working on. These are overwritten many times per second and their state at any given moment is meaningful only in the context of a specific running process. Below that is main memory (RAM), which holds the full working state of all running processes, the operating system kernel, network buffers, and cached file data. RAM is volatile: its contents are lost when power is removed, typically within milliseconds to seconds depending on chip type, temperature, and whether a remanence attack is being performed.

Beyond RAM, the system maintains several other volatile data stores. The routing table and ARP cache record how the machine communicates with other hosts and which MAC addresses correspond to which IP addresses. These are built dynamically and refreshed continuously; they are gone when the system shuts down or when the network interface is reset. The process table records every running process, its process ID, the user it runs as, and the files and network sockets it has open. A running attacker process appears in the process table; after shutdown it does not.

The system clock is also included in the RFC 3227 ordering, not because clock data disappears on shutdown but because the clock's relationship to accurate time must be recorded at the moment of collection. If the system clock is twelve minutes fast, timestamps on every log entry are twelve minutes off. Recording the clock deviation at collection time allows analysts to correct all timestamps in post-processing.

RFC 3227 lists the order of volatility as a sequence of data categories, each less transient than the previous. The document is concise and the ordering is the foundation of every live-response methodology that followed it. The sequence is not arbitrary: each position reflects how quickly the data changes and how difficult it is to reconstruct after it is gone.

The practical implication is that an investigator arriving at a compromised host should not touch the keyboard until they have decided what to capture. Every command typed on the live system modifies last-access timestamps on files, can overwrite swap space, and may trigger the malware to take an evasive action. The investigator should use a write-protected forensic toolkit run from a USB drive or remote tool to issue commands, and should record every command issued and its output before moving to the next collection step.

Main memory is the single most valuable source of live evidence in most incident investigations. Its contents at the time of acquisition can include: decrypted versions of files that are encrypted on disk; cleartext credentials passed through an authentication process that were never written to a log; the full working memory of a malicious process including its configuration and command-and-control address; active TLS session keys that allow retrospective decryption of captured network traffic if the session was recorded; and injected shellcode that exists nowhere on disk.

Memory-resident malware is a category that specifically exploits the disconnect between RAM and disk. A loader delivered by a phishing email may execute entirely in memory, inject shellcode into a legitimate process such as svchost.exe, and delete the original loader file. On disk there is no malware file to find. In RAM, the injected code is present in the memory space of the host process, the network connections it opened are in the process table, and the strings in its working memory may include the C2 server address. Analysts using tools such as Volatility or Rekall can extract these artefacts from a memory image, but only if the image was captured while the system was running.

RFC 3227 specifies that the act of collection must be documented to a standard that allows another expert to evaluate the integrity of the evidence. The minimum documentation requirements are: the system clock time at the start and end of each collection step, the offset between the system clock and a trusted time source such as an NTP server, every command issued to the system during collection and its output, the identity of the person performing the collection, a cryptographic hash (MD5 and SHA-256 are both common) of every acquired file computed immediately after acquisition, and the hash of any tool or script used to collect evidence.

The clock offset is particularly important and often overlooked. Courts in multiple jurisdictions require that log timestamps be interpreted in context. A log showing a file access at 14:32:07 means nothing unless the investigator also recorded that the system clock was seven minutes ahead of UTC at the time. Without that note, the timestamp cannot be correlated with firewall logs, authentication records, or CCTV footage. Indian courts applying the Bharatiya Sakshya Adhiniyam 2023 require that electronic evidence be accompanied by a certificate of the kind described in Section 63, which includes details of the device and the manner of collection. US courts under FRE 902(13) and (14) allow self-authentication of electronic records if accompanied by a qualified certificate. Both requirements are satisfied by careful RFC 3227 documentation.

The hash requirement serves two purposes. First, it proves that the copy made at collection matches the original at the moment of collection. Second, it allows anyone who later handles the evidence to verify that it has not been altered since acquisition. A RAM image of 16 GB with a documented SHA-256 hash computed at the scene is admissible evidence in a way that an undocumented copy is not, because the hash creates a verifiable link between the original system state and the file presented in court.

Live evidence collection and rapid containment are in tension. Every minute the system stays running while the investigator collects RAM is a minute the attacker can continue operating: exfiltrating data, destroying logs, or moving laterally to other hosts. The investigator must decide how long to run live collection before isolating or shutting down the system.

The decision depends on what is at risk. If the compromised host is actively exfiltrating personally identifiable data, containment takes priority over a complete live collection: isolate the host from the network first, then collect what volatile data remains (RAM is still acquirable from an isolated host, network state data will now reflect the isolation). If the attacker appears to be dormant and the investigation team needs to understand the full scope before containment tips the attacker off, a longer live-collection window is justified.

Most IR playbooks describe a triage collection phase: a short list of high-priority commands that capture the most valuable volatile data in five to ten minutes, followed immediately by network isolation. The triage list typically covers the process table, active network connections, ARP cache, logged-on users, and a memory acquisition if a tool is available. A full disk image can follow after isolation, since disk contents are stable and not time-critical.

The order of volatility as stated in RFC 3227 assumes a physical machine running a conventional operating system. Cloud instances, virtual machines, and containers introduce additional constraints and capabilities that change the practical workflow, though not the underlying principle.

In a virtualised environment, the hypervisor can take a snapshot of the entire VM state, including RAM contents, at a point in time while the VM continues running. This is faster and less invasive than running a user-space memory acquisition tool inside the guest OS, and it captures the CPU register state as well. Major cloud providers including AWS (EC2 instance snapshots and memory capture via SSM), Microsoft Azure (Azure Disk Snapshot and VM memory capture), and Google Cloud Platform (GCP disk snapshots) all provide mechanisms for this. The order of volatility still applies: capture the snapshot before any other action, before stopping the instance, before detaching disks.

Containers present a harder problem. A container shares the kernel with its host and has no separate OS of its own. When a container stops, its writable layer is typically deleted, along with any data that was written inside the container but not mounted to a persistent volume. Container memory is shared with the host kernel memory space and is not separately addressable in the way a VM's memory is. Responders investigating a compromised container should capture the container's running state (docker inspect, kubectl describe), the process tree inside the container, the container's network connections, and environment variables before stopping it. The host's memory image will include container memory, though interpreting it requires additional analysis.

Cloud environments also change the remote logging category. On-premises systems send logs to a remote syslog server, which an attacker could also compromise. In cloud environments, logs are typically written to a managed service (AWS CloudTrail, Azure Monitor Logs, GCP Cloud Logging) that the attacker cannot access through the compromised instance. This makes remote logs more reliable as a secondary evidence source, but they still need to be preserved quickly: log retention windows vary by configuration, and an attacker who has administrative access to the cloud account can delete logs.