In this module
MF1.4 Hypervisor-Based Acquisition
From MF1.2 and MF1.3 you know the in-guest acquisition tools: WinPmem for Windows, LiME and AVML for Linux. Both approaches run inside the guest OS, which means they produce smear, leave a forensic footprint, and face security-architecture constraints (HVCI, Tamper Protection, kernel-version coupling). This sub covers the method that avoids all three: suspend the VM from outside, copy its memory file, resume.
Hypervisor-based acquisition is the gold standard. The VM is suspended from outside the guest — from the hypervisor layer — and its memory is saved to a file on the host's filesystem. The guest OS doesn't know it happened. No driver loads, no kernel module inserts, no process spawns, no disk writes inside the guest. The smear window is effectively zero because the guest's CPUs are halted during the suspension. The forensic footprint on the guest is zero because nothing ran inside it.
This is how you'll capture most of the memory images in this course. Your Target-Win and Target-Linux VMs run on VMware Workstation or VirtualBox on your analysis workstation. When the course says "capture memory," the default path is: suspend the VM, copy the .vmem or equivalent file, resume. Every paid module's attack-capture-analyse loop uses this method because it produces the cleanest possible image of the attack's memory footprint.
The limitation is access. Hypervisor-based acquisition requires hypervisor-level access to the VM. In your lab, you have it — you own the hypervisor. In production, you may not. Physical servers don't have a hypervisor. Cloud VMs run on a provider's hypervisor that tenants can't access at the memory-dump level. Corporate VMware vSphere installations require specific RBAC permissions that the SOC analyst may not hold. When hypervisor access is available, use it. When it's not, fall back to MF1.2 (WinPmem) or MF1.3 (LiME/AVML).
Deliverable: Ability to capture VM memory via VMware Workstation suspension (the course lab method), understanding of the .vmem file format and how Volatility 3 reads it, awareness of the VMware vSphere and VirtualBox equivalents, and the decision criteria for when hypervisor acquisition is available versus when you need to fall back to in-guest tools.
VMware Workstation — the course lab method
This section is the procedure you'll use for every capture in MF2 through MF9. Learn it once here; execute it dozens of times across the course.
VMware Workstation (and VMware Workstation Pro, which became free in late 2024) stores each VM's memory in a .vmem file when the VM is suspended. The suspend operation freezes all guest CPUs, writes the guest's RAM contents to the .vmem file on the host's filesystem, and pauses the VM.
The VM can then be resumed (restoring the exact CPU and memory state from the suspension point) or left suspended while you work with the .vmem file.
The acquisition procedure has three steps.
Suspend the VM — either VM → Suspend from the VMware Workstation UI, or from the command line:
vmrun suspend "C:\path\to\Target-Win.vmx"The guest freezes instantly. Any in-progress operations (network connections, disk I/O, user interactions) halt mid-execution.
Copy the .vmem file — navigate to the VM's directory on the host filesystem and copy the .vmem file to your evidence directory. The file is exactly the size of the VM's configured RAM. Hash it immediately:
certutil -hashfile target-win.vmem SHA256Resume or leave suspended — resume the VM to continue the investigation on a live system, or leave it suspended to preserve the exact state. For the course's attack-capture-analyse loop, you typically resume after copying, because the next step is often to run additional attack stages and capture again.
The .vmem file is a raw physical memory image — the same byte-for-byte format that WinPmem's raw output produces. Volatility 3 reads it natively:
vol -f target-win.vmem windows.infoThis works identically to vol -f target-win.raw windows.info. The only difference is the file extension; the content is structurally identical.
VMware Workstation also creates a .vmss file alongside the .vmem during suspension. The .vmss contains the saved CPU state (register contents, control register values, interrupt descriptor table) that VMware uses to resume the VM.
Volatility 3 can use the .vmss file alongside the .vmem for more accurate analysis — the CPU state helps resolve certain kernel structures that depend on register values. For most analysis, the .vmem alone is sufficient; the .vmss becomes important for advanced kernel analysis in MF6.
# Pause the VM (freezes guest CPUs)
VBoxManage controlvm "Target-Win" pause
# Dump memory to ELF core file
VBoxManage debugvm "Target-Win" dumpvmcore --filename /evidence/target-win.elf
# Resume the VM
VBoxManage controlvm "Target-Win" resumevol -f /evidence/target-win.elf --single-location file:///evidence/target-win.elf windows.infoVMware vSphere — the production-environment path
This section covers the enterprise hypervisor that Northgate Engineering and most corporate environments run. Same principle as Workstation, different access path.
VMware vSphere (ESXi) is the enterprise hypervisor that runs production VMs. The memory acquisition principle is identical to Workstation: suspend the VM, copy the .vmem file, resume. The execution path is different because vSphere VMs are managed through vCenter, not a local Workstation UI.
The vSphere acquisition path uses vim-cmd on the ESXi host or the vSphere API through PowerCLI. Create a memory-inclusive snapshot:
vim-cmd vmsvc/snapshot.create <vmid> "IR-memory-capture" "Memory capture for incident investigation" 1 1The two 1 flags specify "include memory" and "quiesce guest filesystem." The .vmem file appears in the VM's datastore directory. Copy it to your evidence storage via SCP from the ESXi host, or via the vSphere datastore browser.
The RBAC constraint is the practical blocker. Creating snapshots with memory requires the VirtualMachine.State.CreateSnapshot privilege, which is typically assigned to VM administrators but not to SOC analysts.
If your IR runbook doesn't include pre-provisioned vSphere access for the SOC team, the hypervisor acquisition path fails at the permissions gate and you fall back to in-guest tools. This is a policy decision, not a technical one — provision snapshot-with-memory permissions for the IR team before incident day, not during.
When hypervisor acquisition isn't available
This section closes the loop on MF1.1's feasibility axis. Knowing when you can't use the best method is as important as knowing how to use it.
Three scenarios block hypervisor-based acquisition. Physical servers — no hypervisor exists. The server's RAM is accessible only through in-guest tools (WinPmem, LiME, AVML) or physical DMA hardware (PCILeech, Inception). Physical servers in corporate environments are increasingly rare as virtualisation has become standard, but they still exist in manufacturing, legacy infrastructure, and specialised workloads. Northgate Engineering's manufacturing-floor servers are physical — when memory capture is needed from those systems, in-guest tools are the only option.
Cloud VMs without hypervisor access — the hypervisor is the cloud provider's, and they don't expose memory-dump capabilities to tenants. AWS, Azure, and GCP don't offer raw .vmem extraction through their tenant-facing APIs. Azure does offer a "VM memory dump" capability through Azure Support for Tier 3 escalations, but it's not self-service and has a multi-hour turnaround. For cloud incident response, you're back to in-guest tools: WinPmem for Windows, AVML for Linux.
Insufficient RBAC permissions — the hypervisor exists and is accessible, but the SOC analyst doesn't have the permissions to create memory-inclusive snapshots. This is the most frustrating of the three because it's entirely self-inflicted — the capability exists, the infrastructure supports it, but the access model doesn't include the IR team. Fix this before incident day.
This is the method you'll use for every Windows capture in the course. By the end, you have a .vmem file verified in Volatility 3.
The situation. You're investigating a Northgate Engineering server that triggered a Sentinel alert. The server is a VMware vSphere VM. You have vCenter access but your account doesn't have the VirtualMachine.State.CreateSnapshot privilege. The SOC lead is asking for memory. The vSphere admin is in a different timezone and won't be available for four hours. You do have local admin credentials for the VM's guest OS.
The choice. Wait four hours for the vSphere admin to create a memory snapshot (hypervisor acquisition — best fidelity, zero footprint). Or proceed now with WinPmem inside the guest (in-guest acquisition — available immediately, introduces smear and footprint).
The correct call. Proceed with WinPmem now. Four hours on a potentially active compromise is too long — the attacker may exit, the evidence may decay, the business may reimage the system before the vSphere admin responds. In-guest acquisition has lower fidelity than hypervisor, but it produces an image now versus no image for four hours. Document the decision: "Hypervisor acquisition preferred but blocked by insufficient RBAC; WinPmem used for immediate capture; vSphere snapshot requested as supplementary capture when admin access becomes available." If the vSphere admin responds later and the VM is still running, take the hypervisor snapshot too — two captures from different methods provide cross-validation.
The operational lesson. The policy failure isn't the acquisition tool — it's the RBAC model. After the incident, the remediation action is to provision VirtualMachine.State.CreateSnapshot for the IR team's vCenter accounts. The next incident on a vSphere VM should not hit this permissions gate. Fix the access model, not the response playbook.
The myth. Suspending a VM to capture memory kills all active network connections, drops database transactions, and disrupts users. The data loss from the suspension outweighs the forensic value of the memory capture. You should use in-guest tools instead to avoid the disruption.
The reality. VM suspension does freeze the guest — active TCP connections time out, in-flight transactions are interrupted, and users see the system become unresponsive for the duration of the suspension. Those effects are real. But they're temporary and recoverable. When the VM resumes, TCP connections re-establish (or the application reconnects), transactions that were interrupted either replay (if the application handles reconnection) or fail (which the application should handle as a crash-recovery scenario). The "data loss" from a 30-second suspension is equivalent to the "data loss" from a 30-second network outage — which most production systems are designed to tolerate.
The alternative — running WinPmem inside the guest to avoid the suspension — introduces its own disruption: a kernel driver loading, several gigabytes of disk I/O competing with production workload, and a forensic footprint visible to the attacker. On an active-attack investigation, the in-guest disruption may be worse than the suspension disruption because it's visible to the adversary.
The operational judgment is: how critical is the system's uptime during the capture window? For a database server processing financial transactions, a 30-second suspension during business hours is a real cost. For the same server at 03:00 during an active compromise investigation, the cost is negligible. The method choice depends on the operational context, not a blanket "suspending is bad" rule.
Try it — Capture Target-Win via VMware suspension and compare against WinPmem capture
Setup. Your Target-Win VM running in VMware Workstation, in the same clean-baseline state you captured with WinPmem in MF1.2. You'll produce a second baseline image via the hypervisor method and compare the two.
Task. Suspend Target-Win, copy the .vmem file, hash it, resume the VM. On the analysis workstation, run vol -f target-win.vmem windows.pslist and vol -f target-win-baseline.raw windows.pslist (the WinPmem capture from MF1.2). Compare the two process lists. Note which processes appear in both, which appear in only one, and whether the PIDs and create-times match for common processes.
Expected result. Both images show the same core Windows processes (System, smss, csrss, wininit, services, lsass, svchost instances, explorer) with identical PIDs and create-times. Minor differences are expected: the WinPmem capture may show WinPmem's own process (which doesn't appear in the hypervisor capture), and some transient svchost instances may differ if background services cycled between the two captures. The core process tree matches because both captures were from the same clean-baseline VM state.
If your result doesn't match. If the hypervisor capture has significantly fewer processes than the WinPmem capture, the VM may not have been fully booted when you suspended it — let it settle for 2-3 minutes after login before suspending. If PIDs are completely different between the two captures, you captured at different boot sessions — the comparison is only meaningful within the same boot. If windows.pslist fails on the .vmem file, confirm the file is the .vmem not the .vmss.
You should be able to do the following without referring back to this sub. If you can't, the sections to re-read are noted.
You've set up the lab and captured your first clean baselines.
MF0 built the three-VM lab and established the memory forensics landscape. MF1 taught acquisition with WinPmem and LiME, integrity verification, and chain of custody. From here, you execute attacks and investigate what they leave behind.
- 8 attack modules (MF2–MF9) — process injection, credential theft, fileless malware, persistence, kernel drivers, Linux rootkits, timeline construction, and a multi-stage capstone
- You run every attack yourself — from Kali against your target VMs, then capture memory and investigate your own attack's artifacts with Volatility 3
- MF9 Capstone — multi-stage chain (initial access → privilege escalation → credential theft → persistence → data staging), three checkpoint captures, complete investigation report
- The lab pack — PoC kernel driver and LKM rootkit source code, setup scripts, 21 exercises, 7 verification scripts, investigation report templates
- Cross-platform coverage — Windows and Linux memory analysis in one course, with the timeline module integrating evidence from both
Cancel anytime