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
Why Memory Forensics Matters for Incident Response
What this sub establishes
Memory forensics is treated as a specialist tool you reach for when disk analysis fails. That framing is a decade out of date, and acting on it means reaching wrong conclusions on exactly the cases that matter most: the ones that go to legal, to insurance, or to a regulator. This sub replaces the framing.
It teaches no Volatility command yet. It teaches why memory is not niche, the four attack categories where it is the deciding evidence, the operational triggers that make acquisition mandatory rather than optional, and the three capabilities this course builds. Everything taught afterward, every plugin and every structure, lands on this frame.
The first thirty minutes, and what the disk does not tell you
An alert fires on a Northgate Engineering finance workstation: Defender for Endpoint flags anomalous PowerShell reaching an unfamiliar IP. You pull the disk through live response. No suspicious files. No registry persistence. No unusual scheduled tasks. The endpoint team wants the machine reimaged inside the hour, and the controller has a 09:00 board-pack deadline.
A disk-trained instinct reads "nothing on disk" as "nothing happened" and signs off the reimage. That instinct is wrong, and the reason it is wrong is the whole premise of this course: the evidence that answers what the PowerShell actually did is in the machine's RAM, and the reimage destroys it.
Disk and memory are complementary, not interchangeable. Each sees what the other cannot. Any attack engineered to evade disk-based detection is, by definition, visible only in memory, which is precisely why modern tradecraft targets the disk's blind spot.
The disk is one class of evidence, not the evidence
If you collect only the disk, you are making an implicit claim: that everything you need to prove was written to the filesystem by a cooperating attacker. That claim was roughly true in 2010. It is not true now, and the gap is not small.
Modern attackers design tooling to avoid disk writes, because they know the disk is what gets investigated. They run loaders in memory. They inject into legitimate signed processes. They harvest credentials without copying the credential store. They execute through PowerShell reflection, WMI subscriptions, and scheduled tasks that pull their real payload from a remote host at runtime. Collect only the disk and you collect only the evidence the attacker chose to leave.
The shift did not happen overnight; it followed the incentives. As endpoint detection got better at catching disk-based malware, attackers moved up the stack to techniques that leave nothing on disk to catch. Reflective PE injection became a commodity capability around 2014. In-memory credential theft commoditized around 2015. By 2018, living-off-the-land execution through Microsoft-signed binaries was a tradecraft category of its own.
Each step leaves less on disk and more only in memory. An analyst whose methodology stopped at the 2015 picture is investigating a threat that has since moved out from under disk forensics entirely.
Recent intrusion reporting from major IR vendors consistently places in-memory techniques in the large majority of cases that reach a full investigation. An analyst trained on a 2015 mental model is investigating a threat landscape that no longer exists.
Four categories where memory is the decisive evidence
Four families of attacker tradecraft produce investigations where memory is the deciding evidence. The disk shows fragments; memory shows the whole picture. These four are also the vocabulary for scoping an engagement, when leadership asks why memory forensics is needed for this case, you answer from these four.
Each category defeats disk forensics by design. The course is built around them: Modules 2 through 6 take the Windows categories one at a time, Module 7 takes the Linux equivalents, and every analysis you run traces back to one of these four.
Fileless malware. Code that executes without being written to disk. The delivery vehicle, an email attachment, an exploited document, a malicious ad, exists on disk. The payload does not. PowerShell loads a base64-encoded DLL straight into its own address space. A macro resolves a reflective loader and runs it. Shellcode delivered through an Office exploit executes inside the document's process. The disk contains the delivery vehicle; memory contains the payload, its configuration, what it has already done, and the infrastructure it is talking to.
Here is what that means on the Northgate workstation from the start of this sub. The disk tells you an email arrived, an attachment opened, a macro ran, and PowerShell started with an encoded command line. The EDR tells you that process made outbound connections. All true, all useful, and all of it preamble. The question that matters, what is the payload, is one the disk cannot answer. Memory can.
Two commands, two answers the disk could not give. windows.pstree confirms the lineage the event log only implied, and that the process was alive at acquisition. windows.malfind finds the reflective payload: an executable-and-writable region of private memory beginning 4d 5a, the MZ header of a Windows executable that matches no DLL on disk. That region is the thing the disk never saw. Without it the report reads "PowerShell ran something suspicious." With it you have the payload, a pivot to every other host running the same bytes in memory, and the start of an actual finding.
In-memory credential theft. LSASS holds cached credentials, Kerberos tickets, and secrets for running sessions. A Mimikatz-class tool reads them straight from LSASS memory with no file written. The disk tells you a suspicious process existed; memory tells you which credentials were actually exposed at that instant, whether they are still valid, and whether the attacker took them.
Living-off-the-land execution. powershell.exe, wmic.exe, rundll32.exe, regsvr32.exe, mshta.exe: Microsoft-signed, present on every Windows install, all capable of running remote payloads in memory. When an attacker uses them, the disk shows a legitimate binary with a plausible command line. You cannot separate sanctioned administration from abuse on the disk alone. Memory shows what the process actually loaded, injected, and opened.
Kernel-level compromise. A rootkit that hooks the system call table hides its processes from the process list, its files from directory listings, and its connections from the network stack. A user-space EDR sees only what the rootkit permits. Memory analysis, specifically kernel-object enumeration and pool-tag scanning, sees the rootkit's own structures, because it cannot simultaneously hide them from memory and remain functional.
The pedagogy: attack, capture, analyze
Most forensics training hands you a pre-made image and a list of plugins. This course does the opposite, and the reason is the difference between recognizing artifacts and understanding them.
You run the attack from a Kali VM, capture the target's memory before and after, then analyze your own image. Because you put the artifact there, you know what right looks like, which is the only reliable way to build the instinct for finding it when you walk into a case blind.
You run the attack, so you know exactly what should be in memory. You capture before and after, so you understand acquisition and integrity from the inside. You analyze your own image, so you build the pattern recognition that lets you find the same artifact later when no one tells you what the attacker did. By the end of the course you have personally executed every major memory-resident attack category and proven you can find the evidence afterward. That is a different competence from having watched someone narrate a pre-canned image, and it is the competence the rest of this course is built to produce.
When acquisition is mandatory, not optional
Memory is not required for every case. A commodity ransomware variant that wrote its binary to disk, a blocked phishing link, a routine false positive, these resolve on disk and telemetry alone, and acquiring memory for every trivial alert would grind a SOC to a halt. The discipline is knowing the threshold. Memory becomes mandatory when any of four conditions is present.
Credentialed-user compromise is suspected. If the attacker reached a state where they could authenticate as a user, the investigation has to account for which credentials were exposed, where they have been used since, and whether any session tokens are still live. Those answers live in LSASS memory, not on disk.
The disk looks clean but telemetry says otherwise. An EDR fires on process behavior, a SIEM flags unusual traffic, a honey-token trips, and disk investigation finds nothing. That is not a false positive. That is an investigation that has discovered the attack is memory-resident and has not yet acquired the one piece of evidence that confirms it.
Attribution matters beyond "a compromise occurred." Litigation, insurance, regulatory notification, HR proceedings, each needs specific claims about what was accessed, what credentials were taken, what systems were reached. For any attack with memory-resident components, those claims cannot be reconstructed from disk alone, and they will be challenged by someone else's expert.
The incident may recur. Persistence that lives entirely in memory, a WMI consumer that re-injects a payload, a task that reloads from a remote host, survives reimaging unless you address the reinfection vector. Disk shows reinfection happened; only memory explains how.
The operational point hides inside the 03:14 scenario that opened this sub. You cannot make the acquire-or-reimage call well in the moment, half-awake, with a business deadline pressing. The decision has to be pre-encoded in your SOC procedure so that an EDR alert without corresponding disk evidence automatically triggers acquisition before reboot. If preserving the evidence requires a real-time argument with the endpoint team at 03:14, you will lose it, and the case will lose with you.
What this course builds
Three capabilities, each a prerequisite for the next, and every module in the course fits into one of them.
Acquisition discipline. Acquiring memory from Windows and Linux in a way that preserves integrity and survives legal scrutiny. Memory is the most volatile evidence you handle: it exists only while the system runs, changes every cycle, and is gone at shutdown. Tool selection, verification, and chain-of-custody documentation are the foundation, because no amount of analysis skill rescues a capture that will not hold up.
Structure-level interpretation. Reading an image at the operating-system structure level rather than only at the plugin-output level. Volatility is a good tool with edge cases, version-specific behavior, and parser limits. If you understand the underlying structures, the process and thread objects, the VAD tree, the kernel objects, you can validate tool output, catch anomalies the tool misses, and interpret evidence no plugin exists for yet. This is what separates an analyst who runs Volatility from one who knows when Volatility is wrong.
Evidence correlation. Integrating what memory shows with disk, network telemetry, and logs into one defensible timeline. Memory gives you the instant; disk gives you durability; telemetry gives you the external view. None is sufficient alone. The defensible investigation uses all three, with memory as the primary source for anything that happened in-process during the acquisition window. Module 8 is built entirely around this skill, and the capstone in Module 9 tests it against a full multi-stage intrusion with no guidance.
This is the deepest forensic course on the platform, and it assumes you have investigated incidents before. What it adds is the memory layer, the one that closes the cases a disk-only methodology leaves open. The next sub makes the abstraction concrete: exactly what lives in RAM that never reaches the disk, and the taxonomy you will use to classify every artifact you find for the rest of the course.