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
First Commands in Volatility 3 and MemProcFS
Hands on the tools, on a clean image first
You have the toolkit and the lab. This sub puts your hands on Volatility 3 and MemProcFS for the first time, deliberately against a clean capture of NE-ENG-031, before MF1 has you acquiring an image under acquisition discipline. Working a known-good image first is the right order: when you reach a compromised capture, you need to already know what normal output looks like, because every finding in this course is an anomaly measured against normal, and you cannot see the anomaly if the baseline is unfamiliar.
The commands here map onto the first phases of the workflow from MF0.3. You will Identify the image, then Enumerate it two independent ways and reconcile, then browse the same image as a filesystem in MemProcFS, reading each result through the taxonomy from MF0.2 and the address model from MF0.4. Nothing here is an attack; it is orientation, the equivalent of learning where the controls are before you drive under pressure.
The orientation is not a separate skill from the workflow; it is the workflow's first phases run on an easy image, so the moves are automatic before the image is hard.
Identify the image
Start where every analysis starts: confirm what the image is and that symbols loaded. You captured this image from the clean NE-ENG-031 snapshot by suspending the VM and pointing Volatility at the resulting .vmem file, the hypervisor acquisition from MF0.9, so you already expect a Windows 11 build.
Read it through MF0.4: the kernel base sits in the 0xfffff... range, which is kernel space, exactly where the kernel base should be, your first free sanity check that the translation is working and the symbols match. If this came back with a zero kernel base or an absurd timestamp, you would stop and fix the profile before anything else, because every later command trusts this one. On a clean image it confirms in seconds, and you move on. Spend a moment on what the fields are telling you, because you will read this output on every image for the rest of the course. The build number is what Volatility matched symbols against, and a build you do not recognize is worth confirming against the system you believe you captured, a mismatch here is the cheapest possible place to catch a swapped or mislabeled image, the Identify-phase failure from MF0.3. The system time is the clock every later timestamp is read against; note it now, because correlation in MF8 depends on knowing what "now" meant for this capture. The 64-bit flag and the kernel base together confirm you are reading a modern x86-64 Windows image the way the tool expects, and on a clean capture all of it should be unremarkable, which is exactly the point of looking.
Enumerate two ways and reconcile
Now list processes, and do it the way phase 3 demands, with more than one method, so reconciliation is a habit you build on the easy image rather than discover on the hard one.
On this clean image the two counts match, and that agreement is itself the finding: no process is hidden from the active list, which is what you expect on an uncompromised system. That matters because it teaches you the shape of a normal reconciliation. When you run the same comparison on a compromised image in MF2 and beyond and the counts disagree, you will recognize the disagreement immediately as the DKOM signal from MF0.3, precisely because you have seen what agreement looks like here. Reading the process list itself, you also learn normal: System at PID 4, the expected svchost.exe instances, Defender's MsMpEng.exe, explorer.exe parented sensibly. Knowing this benign baseline is what later lets a single out-of-place process or a bad parent-child lineage jump out. Look specifically at the parent-child relationships while everything is clean. explorer.exe is parented by the user's session, svchost.exe instances descend from services.exe, and the browser's child processes hang off the browser, all of it the ordinary shape of a running Windows system. The reason to study this now is that the most reliable injection and living-off-the-land signals are lineage anomalies: a powershell.exe whose parent is a Word process, an svchost.exe that does not descend from services.exe. You cannot see a wrong lineage if you have never looked at a right one, so the clean image is where that recognition is built, quietly, before it matters. It is worth understanding why the two counts can ever differ, because the reason is the whole basis of the reconciliation. The active list is a linked list the kernel walks to schedule and manage running processes, so a process can be unlinked from it, by an attacker manipulating the structures directly, while the process itself keeps running. The scanning method does not trust that list; it sweeps the memory pool for the signatures of process structures regardless of whether anything still points to them, so it finds processes that were unlinked and processes that have exited but not yet been overwritten. On a clean image nothing is hidden and the two agree, as here, and the value of seeing them agree now is that the disagreement later has a precise meaning: the scan found a process the list denied, which is structural manipulation, not noise. You are learning the normal case so the abnormal one reads as a specific technique rather than a mystery.
Browse the same image as a filesystem
Now meet the other tool. Mount the same .vmem in MemProcFS and explore it as a directory tree, the filesystem view from MF0.5, so you feel the difference in ergonomics directly.
The same processes you enumerated with pslist are here as folders, and a process's details, its command line, modules, handles, are files you read rather than plugins you run. Notice the ergonomics: to answer "what was explorer's command line" you navigated to a file, where in Volatility you would compose windows.cmdline --pid 3120. Neither is more correct; this is the triage-versus-report distinction from MF0.5 made tangible. For orienting on an unfamiliar image, browsing is faster; for the documented, reproducible analysis that goes in a report, the recorded Volatility command wins. Practicing both on a clean image means that on a real one you reach for the right one without thinking about it. A caution about the browse view belongs here while you are forming habits. The filesystem MemProcFS presents is a live, reconstructed interpretation of the image, generated on demand, so it is ideal for fast orientation, but the thing you cite in a report is the underlying analysis, run and recorded reproducibly, not a path you happened to browse to. Treat the mount as a way to find what is interesting quickly, then confirm and document the finding with a recorded query whose exact form a reviewer could re-run against the same image and get the same result. The two tools are complementary along precisely this line: one is for the analyst's eyes moving fast over an unfamiliar image, the other is for the record that has to stand up later, and keeping that distinction from the first clean image is what stops a real investigation resting a conclusion on an unrecorded click.
See normal before abnormal: the connection list
One more orientation move pays off later more than almost any other: look at the network connections on the clean image. Enumerate them and read what an uncompromised NE-ENG-031 talks to, the handful of expected Windows and Defender endpoints, update and telemetry destinations, nothing user-driven on an idle box. The point is not the specific addresses, which vary, but the shape: a clean workstation has few connections and they go to recognizable places. When a later module finds an explorer.exe holding an outbound connection to an unfamiliar address, that finding lands because you have seen how short and how mundane the normal connection list is. Calibrating normal connections now is what turns a single anomalous connection later into an obvious flag rather than one line lost among many you cannot characterize.
svchost.exe processes, unfamiliar service names, and legitimate JIT regions that look exactly as alarming as injected code, because they have no baseline to compare against. Every one of those is normal, and not knowing that turns a triage into a panic. The fix is the discipline this sub models: learn what a clean Windows image looks like first, so that on the real one your attention goes to the genuine anomaly instead of to ordinary system behavior you have never seen before.What this sets up
You have now run the opening moves of the workflow on a real image: identified it, enumerated it two ways and reconciled, and browsed it in both tools. None of it found anything, which is the point, you have calibrated normal, and normal is the reference every later anomaly is measured against. The commands were few and the image was easy, deliberately, because the skill being built here is recognition, not command memorization.
From MF1 onward the loop changes character. You will acquire your own image under proper discipline, then run an attack and capture again, and the same windows.info, windows.pslist versus windows.psscan, and MemProcFS browse will start returning the anomalies this clean run did not. The final sub of this module is where you first reason across all of it: an interactive triage that drops you into the opening minutes of an incident and asks you to make the calls, using everything MF0 has built.