In this module
MF1.2 Windows Acquisition with WinPmem
From MF1.1 you know acquisition is a tradeoff between fidelity, footprint, and feasibility. You know about smear and why it's unavoidable in live capture. This sub puts a specific tool in your hands: WinPmem, the open-source Windows memory acquisition tool the rest of this course uses for every in-guest Windows capture.
WinPmem is the open-source standard for Windows memory acquisition. It loads a signed kernel driver, reads physical memory page by page, and writes a raw image to disk. The tool is a single executable, requires no installation, and runs from a USB drive or network share — which is exactly why it's the default IR acquisition tool in environments that don't have commercial forensic suites deployed.
The problem isn't running WinPmem. The problem is running it correctly under the conditions you'll actually face: Defender blocking the driver load, Tamper Protection intercepting kernel access, HVCI preventing unsigned driver execution, disk space running out mid-capture on a production workstation, and the output format question (raw vs crashdump vs ELF) that determines which analysis tools can read what you captured. Practitioners who test WinPmem once in a lab and assume it works everywhere discover these failures at 02:00 during an active incident.
This sub covers WinPmem end-to-end: where to get the correct binary, what the driver does and why it needs kernel access, how to execute a capture, how to verify the output, and the five failure modes you'll hit in production along with the specific fix for each.
Deliverable: Ability to execute a WinPmem capture on any Windows 10/11 or Server 2019/2022 system, verify the output is structurally sound, troubleshoot the five common failure modes, and document the acquisition to the standard MF0.8 established.
What WinPmem does at the kernel level
This section explains why WinPmem needs administrator rights and a signed driver. Without understanding the kernel access requirement, every production failure looks like a permissions bug instead of a security-architecture constraint.
WinPmem ships as a single portable executable that embeds a signed kernel driver. When you run it, the executable extracts the driver to a temporary location, calls CreateService and StartService to load it into the kernel, then uses the driver's device interface to read physical memory page by page.
The driver maps each physical page into the process's address space, the userland component copies the bytes to the output file, and the process repeats for every page in the physical address range. When capture completes, the driver is unloaded and the temporary file is deleted.
The driver signature matters. Windows 10 and 11 enforce driver signature verification by default — unsigned drivers don't load unless you disable it with:
bcdedit /set testsigning onThis is not acceptable on production systems. The WinPmem releases from the Volatility Foundation are signed with a cross-signing certificate that satisfies the default policy. If you downloaded a WinPmem binary from a random GitHub fork rather than the official release, the driver may be unsigned and will fail silently on production systems. Always verify the source.
HVCI (Hypervisor-protected Code Integrity) adds another layer. Systems with HVCI enabled — most Windows 11 installations with Secured-core hardware — restrict which signed drivers can load based on a blocklist and a strict signature policy.
WinPmem's cross-signed certificate may not satisfy HVCI's stricter requirements on some hardware configurations. When this happens, the driver load fails with a generic error that doesn't mention HVCI. The diagnostic is checking msinfo32 → System Summary → Virtualization-based security — if it shows "Running," HVCI is active and WinPmem's driver may be blocked.
MF1.4's hypervisor-based acquisition bypasses this entirely because it doesn't load a guest-side driver.
Running WinPmem — the correct execution sequence
This section is the operational procedure. Follow it exactly on your Target-Win VM and you'll have a raw memory image ready for Volatility 3 by the end.
The execution sequence has four steps, and the order matters. Skipping step 1 (verify admin) produces a cryptic driver-load failure. Skipping step 3 (verify size) leaves you with a partial capture you won't discover until analysis fails in MF2. Skipping step 4 (hash) breaks chain of custody for any investigation that reaches legal review.
Step 1 — Verify administrator rights. Open a Command Prompt as Administrator (right-click → Run as administrator). Confirm elevation:
whoami /groups | findstr S-1-16-12288This checks for the high-integrity SID. If the output contains S-1-16-12288, you're elevated. If it returns nothing, the shell isn't elevated and WinPmem will fail at driver load with "access denied."
Step 2 — Execute the capture. The -o flag specifies the output path. The tool writes the entire physical address space to a raw file:
winpmem_mini_x64_rc2.exe -o C:\evidence\target-win.rawWinPmem prints a progress bar showing pages captured. On a 4 GB VM with an SSD-backed virtual disk, capture takes 30-90 seconds. On a 128 GB production server with spinning disk, expect 12-15 minutes.
The output file is exactly the size of the system's physical RAM — not the used RAM, the total physical RAM. A 4 GB VM produces a 4 GB file regardless of how much memory Windows is actually using.
Step 3 — Verify file size. Confirm the file size matches the target's physical RAM:
dir C:\evidence\target-win.rawFor a 4 GB VM, the file should be 4,294,967,296 bytes. A smaller file means the capture was interrupted — disk full, process killed, or driver error mid-capture.
A file that's smaller by exactly one page (4,096 bytes) usually means the last page wasn't flushed before the process exited — re-run the capture. A file that's significantly smaller (gigabytes missing) means the capture failed partway through and the image is torn at the truncation point. Re-acquire.
Step 4 — Hash immediately. Calculate the SHA-256 hash before doing anything else with the file:
certutil -hashfile C:\evidence\target-win.raw SHA256Record the hash in your investigation log. This is the integrity anchor for the entire chain of custody. Every subsequent transfer, every copy, every analysis session re-verifies against this hash.
If you hash after transfer rather than before, you've lost the ability to prove the image wasn't modified during transfer.
The five production failure modes
This section covers what goes wrong when WinPmem runs outside the lab. Every failure mode has a specific diagnostic and a specific fix — not general troubleshooting advice.
Failure 1 — "Access denied" at driver load. The command prompt isn't elevated. Close the window, right-click Command Prompt, "Run as administrator," retry. This accounts for roughly half of all WinPmem support questions.
Failure 2 — Driver loads but capture reports zero pages. Defender's Tamper Protection is intercepting the kernel memory read. WinPmem's driver loaded (it passed signature verification) but Tamper Protection blocked its attempt to read physical memory pages.
Fix: temporarily disable Tamper Protection in Windows Security → Virus & threat protection → Tamper Protection toggle. Re-enable after capture. On managed endpoints where Tamper Protection is policy-enforced, you may need to disable it via Intune or your EDR console before the capture.
Failure 3 — "Driver load failed" with no further detail. HVCI is blocking the driver. Check VBS status:
msinfo32 → System Summary → Virtualization-based securityIf it shows "Running" with "Hypervisor enforced Code Integrity," WinPmem's cross-signed driver is being rejected.
Fix on lab VMs: disable VBS in VM settings or via the following command (requires reboot):
bcdedit /set hypervisorlaunchtype offOn production systems where you can't disable VBS, use hypervisor-based acquisition (MF1.4) instead — it bypasses the guest entirely.
Failure 4 — Capture stops partway with "write failure." The output drive ran out of space. WinPmem writes the full physical RAM size to disk, so free space must exceed RAM by a margin. A 64 GB server needs 64+ GB free on the output drive.
Fix: write to an external USB drive with sufficient space, or to a network share:
winpmem_mini_x64_rc2.exe -o \\fileserver\evidence\target.rawNetwork writes are slower but eliminate the local-space constraint.
Failure 5 — Capture completes but Volatility 3 can't parse the image. Format mismatch. WinPmem defaults to raw format, which Volatility 3 reads natively. If someone passed --format elf or --format crashdump, the output needs a different Volatility 3 layer specification.
Fix: re-capture with the default raw format (no --format flag). If you're stuck with an ELF-format capture, Volatility 3 can read it with:
vol -f image.elf --single-location file://path/to/image.elf windows.infoRaw is the standard for this course.
This procedure runs against your MF0.9 Target-Win VM. By the end, you have a raw memory image verified by hash. If you completed MF0.10's lab, this is a repeat with more rigour — the MF0.10 capture was a smoke test; this one produces the documented baseline image.
The situation. You're responding to a Northgate Engineering endpoint that triggered a Defender alert for suspicious PowerShell execution. The endpoint is a finance workstation running Windows 11 with HVCI enabled, managed by Intune, with Tamper Protection enforced by policy. You have local admin credentials. You need memory before the SOC lead authorises reimaging.
The choice. Attempt WinPmem on the endpoint knowing HVCI may block it, or skip straight to hypervisor-based acquisition via vSphere (the endpoint is a VMware VM).
The correct call. Go straight to hypervisor-based acquisition. You already know HVCI is enabled (standard Northgate Engineering build) and Tamper Protection is policy-enforced (can't toggle it locally without Intune). WinPmem will almost certainly fail at driver load. Attempting it anyway wastes 5-10 minutes of incident response time and — worse — the failed driver load attempt appears in the endpoint's event log, which adds noise to the forensic timeline. The hypervisor path produces a higher-fidelity image with zero guest footprint. Document in the acquisition record: "WinPmem not attempted due to HVCI + enforced Tamper Protection on managed endpoint; hypervisor-based acquisition selected per MF1.1 feasibility-dominates analysis."
The operational lesson. Know your environment's security posture before incident day. If your standard build has HVCI and enforced Tamper Protection, WinPmem isn't your Windows acquisition tool for managed endpoints — hypervisor acquisition is. WinPmem remains the right tool for unmanaged systems, lab VMs, and environments where the security configuration permits driver loading. The tool choice is an output of the environment's constraints, not a default you attempt and fall back from.
The myth. Running any acquisition tool on a live system modifies the system's state, which means the evidence is contaminated. Memory acquisition is inherently destructive. A purist would argue you should never run software on a system you're investigating because you're altering the evidence you're trying to collect.
The reality. WinPmem does modify the system — it loads a driver, allocates memory for its own process, and writes to disk. Those changes are real. But "modifies the system" is not the same as "contaminates the evidence." Contamination implies the changes are indistinguishable from the evidence and therefore undermine the findings. WinPmem's footprint is distinguishable: its driver appears with a known name, its process appears with a known PID, and its disk writes go to the output path the operator specified. An examiner reviewing the image can identify and exclude WinPmem's own artifacts because they're predictable and documented.
The legal standard isn't "zero modification" — it's "documented, controlled, minimised modification." ACPO Principle 1 acknowledges that accessing evidence may change it and requires documentation of the change, not avoidance of all change. The CPR 35 methodology section should note that acquisition was performed using WinPmem, that the tool's own footprint is present in the image, and that this footprint has been accounted for in the analysis. That documentation is what makes the acquisition defensible, not the fiction that nothing was modified.
The only acquisition method with truly zero guest modification is hypervisor-based suspension (MF1.4). If zero-modification is a genuine requirement — rare, but possible in specific legal contexts — use the hypervisor method. For everything else, WinPmem's documented footprint is standard practice.
Try it — Capture Target-Win memory and verify against expected output
Setup. Your MF0.9 Target-Win VM running with WinPmem available (downloaded in MF0.9 or MF0.10). The VM should be in a clean state — no attack payloads running, no unusual processes. This produces the clean baseline image that MF2 onward compares against.
Task. Execute the full Guided Procedure above: elevate, capture, verify size, hash, transfer, re-hash. Then run vol -f target-win-baseline.raw windows.info on your analysis workstation and confirm the four readiness fields from MF0.10: Kernel Base starts with 0xfffff8, KernelFileVersion matches your Windows 11 build, SystemTime is within seconds of your capture timestamp, KeNumberProcessors matches your VM's vCPU count.
Expected result. A 4 GB .raw file with matching SHA-256 hashes on both Target-Win and the analysis workstation. windows.info output showing a valid Windows 11 profile with all four readiness fields correct. This is your Windows baseline image — keep it.
If your result doesn't match. If WinPmem fails at driver load, work through the five failure modes in order: admin elevation, Tamper Protection, HVCI, disk space, format. If the capture completes but windows.info shows wrong values, the image is structurally damaged — most commonly a partial capture (check file size against RAM). If hashes don't match after transfer, the transfer method corrupted the file — try a different transfer path (SCP vs shared folder vs USB).
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