Reading width
Wide uses the full column for everything — text, diagrams, code, and exercises. Narrow keeps the standard reading width.
Text size
Scales the body text. Headings and code blocks keep their size.
In this section
What Lives in Memory: The Forensic Artifact Taxonomy
Why "it's all just RAM" is a career-limiting idea
A memory image looks like an undifferentiated blob: a few gigabytes of bytes with no obvious structure. Treat it that way and three things go wrong. You cannot prioritize acquisition when an incident is time-critical and the capture is slow. You cannot defend what you chose to analyze first when the image is 32 GB and the report is due in 48 hours. And you cannot explain to legal counsel why a specific finding required memory rather than disk.
Memory is not a blob. It is a structured collection of artifact categories, each with different volatility, reliability, acquisition sensitivity, and forensic use. This sub gives you the three-category taxonomy that organizes every analysis you run for the rest of the course: volatile structures, ephemeral data, and transient artifacts. Once you can place any finding into one of the three, you know how to acquire it, how hard it is to find, and how strong a claim it supports in a report.
Every finding you make in a memory report classifies into one of these three. The category is not academic: it tells you the discovery method to use, the reliability to assign, and the claim language your report can defend.
Volatile structures: the kernel's own bookkeeping
The first category is the kernel-maintained record of everything happening on the system: processes, threads, network connections, open files, loaded drivers, and the kernel's internal state. The kernel keeps these because it must, without them it cannot schedule work, route packets, or service a system call. When you read a memory image, you read the same structures the kernel was reading at the instant of acquisition.
Three properties make volatile structures the backbone of most investigations. They are high-reliability, because the kernel depends on them: a process in the active list existed, a TCP connection in the table was negotiated. They offer multiple discovery methods, because the toolkit provides independent verification paths, you can enumerate processes by walking the active list, scanning the pool for process signatures, following thread back-references, or cross-referencing handles. When two methods disagree, the disagreement is itself the evidence. And they are a named target for sophisticated attackers: Direct Kernel Object Manipulation unlinks a process from the active list while leaving its threads scheduled, and kernel hooks filter attacker processes out of the results an API returns. Defeating those manipulations is the spine of the course's kernel modules.
The structures the course teaches in this category each get a dedicated treatment later: 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. What unites them is that the kernel cannot corrupt all of them at once and keep running. To hide a process from the active list an attacker unlinks its EPROCESS, but the threads inside it are still scheduled, so a thread-based enumeration still finds it. That redundancy works for you: the more independent paths reach the same object, the harder it is to erase from all of them, and the disagreement between paths becomes the loudest signal you have.
Here is the pattern in practice. A memory image from the Northgate finance workstation NE-FIN-014 is captured after a suspicious-process alert, and you enumerate network connections to learn what the flagged PowerShell was talking to.
The connection table is populated by the kernel as part of normal operation; PID 4872 could not have communicated over TCP without an entry. The table links each connection to its owning process and timestamps it. Here it proves the suspicious PowerShell (PID 4872, the same process the lineage in MF0.1 flagged) opened two sessions to 203.0.113.47:443, one still present at acquisition. The firewall log would show the same connections, but the memory evidence independently proves the internal process that made them. That is the volatile-structure pattern: the kernel populates the evidence as a side effect of running, the link to process context is direct, and reliability is high.
Ephemeral data: the applications' working state
The second category is the working state running applications hold in their own memory: cached credentials inside LSASS, Kerberos tickets in the client cache, command-line history in a shell's buffer, the clipboard in Explorer, decrypted documents inside the application that opened them, session tokens in browser processes, environment variables in every process. Unlike volatile structures, this data is not kernel-maintained. It lives in user-mode process memory under whatever management the application chooses, and that difference changes its forensic profile.
Reliability is context-dependent. A value's meaning depends on application state and configuration: a plaintext password in LSASS is decisive if WDigest was enabled, and the same region is empty on a modern Windows build where WDigest is off by default. A shell history entry proves a command was typed in that session, not that it completed, succeeded, or reached what it appeared to target. Discovery is usually single-path: most ephemeral data has one correct extraction, the application-specific structure that holds it, with no pool-scan fallback if you miss it. That single-path property has a sharp consequence for acquisition: if the process holding the data exits between the moment the attack runs and the moment you capture, the evidence is simply gone, with no second structure to recover it from. A shell that closes takes its in-memory history with it; a browser tab that is closed takes its decrypted session material. Volatile structures tolerate a slow acquisition because the kernel keeps maintaining them; ephemeral data does not forgive one. And it is an intermittent anti-forensic target, LSASS credentials and session keys are routinely hunted, the clipboard and DNS cache rarely are.
Ephemeral data is where memory most often produces evidence that exists nowhere else. A disk timeline can prove a shell opened at 14:23 and closed at 14:47; it cannot prove what was typed in those 24 minutes unless something logged it. The shell history buffer in memory holds the literal text of every command from that session, including commands typed, run, and never flushed to the history file because the session ended first.
The command-line arguments live in the process environment block and remain for the process's lifetime. Decoding the -enc value reveals the real command: a download from the same C2 IP windows.netscan surfaced. Disk Script Block Logging captured the encoded string; the decoded command is application-held state that exists only in the process's memory until it exits. That is ephemeral data, evidence that is application-held, context-dependent, and extracted per-application.
Transient artifacts: the attack's footprints
The third category is the memory introduced by attacker activity: code injected into a legitimate process, reflectively-loaded DLLs absent from the module list, process hollowing where an image section no longer matches its mapped contents, kernel hooks in function-pointer tables, shellcode in the heap of a normally benign application. Transient artifacts exist because an attack occurred and vanish when the payload unloads, the process exits, or the system reboots. They have no legitimate analogue on a clean system, and they carry the most aggressive forensic properties of the three.
Discovery is pattern-based, not list-walking. Because attackers designed these artifacts to evade detection, there is no authoritative list to enumerate. Finding injected code means scanning every memory region for the anomaly pattern, executable and writable and private, holding an MZ or PE header, backed by no file on disk. Reliability varies with technique: classical reflective injection leaves a clear signature any modern plugin catches, while module stomping or a technique that preserves every integrity invariant may not surface in first-pass output. And transient artifacts are always an anti-forensic target, every one was placed by an attacker who wanted it to work unseen.
The plugin walked every process's memory map and returned every region matching the executable-writable-private pattern. Three hits. Two are benign, the Chrome JIT region (expected) and a small Explorer region that needs a second look. The third, in PID 4872, shows the pattern plus an MZ header: a reflectively-loaded PE with no entry in the module list and no file on disk. You found it by asking a pattern-based question, "show me regions that look like injected code", not by walking a list the kernel maintains. That is the defining property of transient artifacts: hostile to investigation by design, found by scanning for anomalies rather than enumerating known objects.
Reliability inside this category is not uniform, and treating it as uniform is how analysts both over-claim and miss things. Classical techniques, basic reflective injection, a straightforward SSDT hook, leave signatures any current plugin catches, and a hit there is high-confidence. Modern techniques, module stomping that overwrites a legitimately-loaded DLL in place, eBPF-based hooking on Linux, manipulation that preserves every structural invariant the kernel checks, may not appear in first-pass output at all. The practical rule the course builds toward: a clean transient-artifact scan is evidence of nothing until you have also checked the structures by hand, because the absence of a flagged anomaly and the absence of an attack are not the same statement.
How the taxonomy drives real decisions
The three categories are operational, not a filing system. They decide three things under pressure.
Acquisition order, when capture is time-constrained. If the tool is slow, the attacker may be watching, or the live-response window is short, volatility sets the sequence. Transient artifacts disappear if the payload unloads mid-capture; ephemeral data is lost to ordinary process churn like clipboard overwrites and buffer recycling; volatile structures are captured by any image. The priority is transient, then ephemeral, then volatile. In practice this argues for full acquisition, and when it must be partial, the category sets the order.
Analysis order, when triaging a fresh image. Asked "was this system compromised," the transient category is where the answer most often lives. Scanning for injected code, anomalous module loads, and kernel-hook anomalies reaches the compromise signal faster than enumerating the full process list first. Once compromise is found, volatile structures supply the context, what processes, what connections, and ephemeral data supplies the specifics, what commands, what credentials.
Claim strength, when writing the report. Each category supports a different grade of claim. Volatile findings support strong claims: "at acquisition this process was running, owned by this user, with these handles." Ephemeral findings support specific but context-qualified claims: "at acquisition this credential was cached in LSASS, which implies a logon at or after boot." Transient findings support claims that need correlation: "at acquisition this process contained an injected PE; injection occurred between process start at 14:22 and acquisition at 21:47." The category is the grammar of confident reporting, and Module 8 builds the correlation skill that turns three category-tagged findings into one defensible timeline.
The taxonomy is the frame every later module hangs on. When MF2 dissects process injection, you are working in the transient category; when MF3 pulls credentials from LSASS, ephemeral; when MF6 hunts a kernel rootkit, volatile structures the attacker tried to corrupt. The next sub turns the frame into procedure: the six-phase workflow and the documentation standard that makes a memory investigation repeatable and defensible.