The attacks that reach legal review now run in memory by design: fileless execution, reflective injection, in-memory credential theft, kernel rootkits that never write a file. Collect only the disk and you collect only the evidence the attacker chose to leave. This course teaches you to capture and analyze volatile memory across Windows and Linux, and it teaches it by having you run each attack, capture the memory it produces, and analyze your own evidence. This module shows you what you'll be able to do, the model you'll work in, and how the course gets you there.
10 modules
across 4 phases
Windows + Linux
memory analysis on both
You cause it
run the attack, then find it
All tools free
Volatility 3, MemProcFS, WinDbg
Why this course exists
A disk image holds what was written down. It does not hold the reflective loader that ran entirely in RAM, the credentials lifted from LSASS, the PowerShell payload that decoded itself in memory and left no file, or the kernel rootkit that hooked the system without touching storage. Modern intrusions are built precisely to live in that gap, so an investigation that collects only the disk collects only the evidence the attacker was willing to leave behind. The decisive evidence, the payload, its configuration, its command channel, is in volatile memory, and it is gone the moment the machine powers off.
Memory forensics is how you collect and read that evidence, and it has moved from specialism to baseline because the cases that reach an insurer, a regulator, or a court now turn on it. This course builds that capability through a specific model: you run each attack yourself, capture the memory it produced, and analyze your own evidence. You are never handed a canned image and a list of plugins to recognize. You know exactly what should be in the capture because you caused it, which is a deeper and more durable competence than narrating someone else's sample, and it builds the acquisition and integrity discipline a real case demands from the inside.
What you will be able to do
This course is built around what you can prove from a memory image, not the plugins you can run. Every module stages an attack, has you capture it, and makes you find and defend the evidence.
Acquire memory cleanly
Capture volatile memory from Windows and Linux, verify capture integrity, and hold the chain-of-custody discipline every finding depends on.
Expose process injection
Identify reflective DLL injection, process hollowing, and APC injection through the VAD tree and injected-code analysis, telling injection from legitimate memory.
Recover credentials from RAM
Analyze LSASS memory and Mimikatz-class artifacts, and prove which credentials were exposed and whether they were taken.
Catch fileless malware
Find in-memory PowerShell, .NET assembly loading, and WMI subscriptions, and recover the decoded payload the disk never saw.
Detect kernel compromise
Uncover rootkits, direct kernel object manipulation, and hooks through structural verification, including WinDbg validation a plugin alone would miss, on Windows and Linux.
Time it and report it
Build a timeline from memory, correlate it with disk, logs, and network, and report at honest confidence tiers that hold up to review.
You also leave with things you keep: a repeatable memory-forensics workflow, report templates, the multi-VM lab you build, and a full capstone investigation of a multi-stage attack chain analyzed from memory with no guidance.
The model you will work in
You learn this by causing it. In each module you run the attack, capture the volatile memory it produced, and analyze your own evidence, so you always know what should be in the image and what its absence means. A captured memory image becomes the single source you interrogate for process injection, credentials, fileless malware, kernel rootkits, and live network activity, and you do it across both Windows and Linux.
You work this with a free, professional toolkit, Volatility 3, MemProcFS, WinDbg, and YARA, in a multi-VM lab you build in Module 0 and reuse for the rest of the course. There is nothing to license. The discipline is what carries: the acquisition rigor, the artifact taxonomy, and the confidence-tier reporting you build here are how memory is investigated on any platform, and memory stays the primary source for what truly happened in-process, whatever tool you reach for next.
How the course is built
Ten modules move through four phases. You build the foundations and a clean acquisition pipeline, go deep on Windows memory across the major attack categories, carry the same discipline onto Linux, then integrate and prove it in a full capstone.
What you need and who this is for
This is a Specialist-tier course, the deepest forensic course on the platform, and it is honest about that: it assumes you have investigated incidents before. It does not re-teach incident response from scratch. What it adds is the memory layer, the evidence and techniques that sit underneath everything you already do. The memory-specific concepts are all built up from first principles, so you do not need prior memory-forensics experience, only the investigative grounding to apply it.
Who it is for
DFIR analysts, incident responders, threat hunters, and SOC investigators who already work cases and want the memory layer that the disk-only investigation keeps missing.
Free tools and lab
Every tool is free and Module 0 walks you through building the multi-VM lab. Study linearly: each module's attack builds on the last, and the analysis skills compound.
How to get the most
Run every attack and capture your own image before you analyze it, and predict the artifact before you find it. When the capture surprises you, that gap is the lesson.
Do I already know this material?
Six quick scenarios across the full range of this course, from why memory matters to finding a hidden process in a kernel-rootkit case. Answer them to find out where you sit, and whether this course fits or it will sharpen knowledge you already have.
Why is memory forensics often essential, beyond disk forensics?
Memory is just a faster copy of the disk.
Memory holds state that never touches disk: running and injected code, live network connections, decrypted data, and credentials in use, which disk analysis cannot recover.
Much of what matters in an intrusion exists only in RAM, injected code, decrypted secrets, the credentials and connections in active use. None of it is on disk, so without memory you simply never see it.
Memory is only useful for performance tuning.
Disk forensics already captures everything.
What is the most important constraint when acquiring memory from a live system?
Acquire it before powering off, using a method that minimises changes to memory, because shutting down destroys it and heavy tooling can overwrite the very evidence you want.
Memory is both perishable and fragile: a shutdown erases it, and a clumsy capture overwrites parts of it as it runs. You acquire while the system is live with the lightest sound method available.
Acquire it whenever is convenient.
Reboot first to get a clean capture.
Only capture memory if the disk is encrypted.
You suspect code was injected into a legitimate process. Which memory characteristic most signals this?
The process has a normal-looking name.
The process uses a lot of CPU.
Executable memory regions that are not backed by a file on disk, or memory marked both writable and executable, inside an otherwise legitimate process.
Normal code is mapped from a file and is not writable and executable at once. Injected code shows up as executable memory with no backing file, or as writable-and-executable regions, sitting inside a process that otherwise looks legitimate.
The process was started recently.
An attack ran entirely in memory and left nothing on disk. Why does this defeat disk-only forensics, and what is the implication?
It does not; everything reaches disk eventually.
Fileless code lives only in memory, so a disk image shows nothing; if memory was not captured while the system was live, the evidence is simply gone, which is why memory acquisition matters.
Fileless attacks never write the payload to disk, so an image taken after the fact is blank. The only chance to capture them is in memory, while the system still runs, which is the whole case for memory acquisition.
It means the attack must have failed.
Antivirus would have caught it regardless.
A process is active in memory but does not appear in the operating system's own process list. What does this suggest, and how do you find it?
The process does not really exist.
The memory image is corrupt.
It is a normal system process.
Likely a rootkit hiding the process by manipulating kernel structures; you find it by scanning memory for process objects directly rather than trusting the operating system's list, then comparing the two.
A process that runs but is missing from the OS list is the signature of a kernel rootkit unlinking it. Scanning memory for the process objects themselves, then comparing against the official list, reveals what was hidden.
You have strong findings from a memory image alone. What most strengthens the investigation's conclusions?
Nothing; the memory image is sufficient by itself.
Re-capturing the same memory image again.
Correlating the memory findings with other sources, disk artifacts, logs, and a timeline, so each conclusion is supported across independent evidence rather than a single snapshot.
A memory image is one moment in time. Tying its findings to disk artifacts, logs, and a timeline turns a snapshot into a corroborated sequence, which is far harder to dispute than a single source.
Reporting only the most certain finding and dropping the rest.
This course is for you.
You will build memory forensics from acquisition through process injection, in-memory credential theft, fileless malware, kernel-level compromise, and full attack-chain investigation.
You have the fundamentals. The value here is the harder half.
You understand why memory matters and how to acquire it, so the payoff is the back half: process injection, credential theft, fileless malware, persistence, kernel-level compromise, Linux memory analysis, and timeline correlation.
You handled acquisition, injection signals, fileless analysis, hidden-process detection, and multi-source correlation, the senior end of the discipline. Take the course to sharpen what you have, close the gaps you did not expect, and turn strong instincts into full attack-chain investigations.
You are a student of this course now, so start by deciding what you want from it. Are you here to close the disk-only blind spot in your investigations, to handle fileless and in-memory intrusions you currently cannot prove, or to build a court-ready memory-forensics capability across Windows and Linux? Name that outcome, then turn it into a study plan: which attack categories matter most to your work, how much time you will give it each week, and what you want to be able to prove by the time you finish.
The rest of Module 0 sets you up to do exactly that. Work through it to see why memory is decisive, what lives in memory and how to classify it, the workflow and confidence standard that make a finding defensible, the physical and virtual memory model under every tool, the toolkit, and the lab you will build. Then begin Module 1.
Stuck on this lesson?
Your question goes straight to the team and we'll reply by email. Sign in to ask.
