Dumping a Process and Memory: Windows Processes

What It Shows

When a process looks wrong, capture it before it ends or changes, whether its memory for strings and YARA rules, its executable and DLLs as they sit in memory, or the whole of memory for every memory check on these pages. A file rebuilt from memory is not byte for byte the file on disk, so hash the file on disk too. Some processes refuse to be dumped by design.

Inside Parts It Reads

This check reads these parts, and each page shows what normal looks like.

What to Take

What you capture depends on the question, from one flagged region to the whole of memory, and each has a live route and a memory-image route.

Take	On a Live Machine	From a Memory Image	Good For
The executable	Windows.Memory.PEDump, for one process ID	windows.pslist's dump option, or windows.pedump at the image's base address	Hashing and checking beside the file on disk, which a file rebuilt from memory never matches byte for byte
Its DLLs	Windows.Memory.PEDump for that process ID, with its file name pattern changed from .exe to match DLLs	windows.dlllist's dump option, or windows.pedump at one DLL's base address	A DLL you cannot place, or one loaded from a folder it should not come from
One flagged region	Windows.System.VAD narrowed to that process and protection, with UploadSection on, so it uploads every region that matches	windows.malware.malfind's or windows.vadinfo's dump option	The region a check flagged, for a reverse engineer, without the rest of the process
All of its memory	ProcDump or Windows.Memory.ProcessDump, on a suspect process, agreed with the incident lead first	windows.memmap's dump option	A debugger, YARA rules and a reverse engineer, with everything the process held at that moment
The whole of memory	WinPmem, or Windows.Memory.Acquisition through Velociraptor	The memory image is this capture	Every memory check on these pages, processes that have left the list included
The files it held open	Windows.System.Handles lists them, then copy each file from disk with its hash	windows.dumpfiles for that process ID, the cached copies of the files it has open or mapped	Hashing, signature checks and scanning, though only what was cached comes out, and sometimes only part of it

Read What the Console Showed

Two Volatility 3 plugins read what passed through a console window, so you can recover the commands and their output from a memory image.

Volatility 3 Plugin	What It Reads	What It Is Not
`windows.consoles`	The console host's (conhost.exe) buffers and command history, meaning what was typed into a console window and what it showed	A process's own command line, which is a different record, and only consoles still in memory
`windows.cmdscan`	The command history lists in the console host's memory	The screen text, which windows.consoles reads too

Live and in Memory

Each question has the tools that answer it on a running machine, and in a memory image, a copy of its memory saved to a file.

How do I capture one suspect process?
On a Running Machine
- ProcDump (documentation, opens in a new tab) Writes a full memory dump of one suspect process, for a debugger, a strings search or YARA rules.
- Windows.Memory.ProcessDump (documentation, opens in a new tab) Captures chosen processes as crash dumps or sparse uploads, on one machine or many.
In a Memory Image
- windows.memmap (documentation, opens in a new tab) Its dump option writes out all of one process's addressable memory from the image.
- windows.malware.malfind (documentation, opens in a new tab) Its dump option writes out only the regions it flagged.
How do I get the executable and its DLLs back out?
On a Running Machine
- Windows.Memory.PEDump (documentation, opens in a new tab) Extracts executables from process memory through the VAD, and relocations are not fixed, so the result will not match the file byte for byte.
In a Memory Image
- windows.pslist (documentation, opens in a new tab) Its dump option writes each listed process's executable as rebuilt from memory.
- windows.dlllist (documentation, opens in a new tab) Its dump option writes out the DLLs each process has loaded.
- windows.dumpfiles (documentation, opens in a new tab) Extracts files cached in memory, such as the executable or a DLL behind a process.
How do I capture the whole of memory?
On a Running Machine
- WinPmem (documentation, opens in a new tab) Reads physical memory through its own driver and writes a raw image.
- Windows.Memory.Acquisition (documentation, opens in a new tab) A full image from a client through Velociraptor's built-in WinPmem driver, uploaded to the server.
In a Memory Image
- windows.info (documentation, opens in a new tab) Names the build the image came from, the first thing to confirm before any other plugin.

What It Misses

Every way of looking has gaps, so cover these from another source.

A raw image holds only what was in RAM, so pages in the page file are missing unless it is collected too. Pages Windows compressed sit in the Memory Compression process, so a gap is not proof of absence.
A dump is one moment, so what the process did before, or does after, is not in it.
Defender for Endpoint live response downloads a file with getfile, and the device page collects the investigation package, but neither captures process memory or a full memory image. The capture needs one of the tools above, which a library script started with live response's run command can call on the device.

False Positives

These look odd but are normal, so rule them out before you act.

Your own capture raises the same alerts an intruder's would, such as Sysmon event 10 against lsass.exe where Sysmon is set to record process access, or an attack surface reduction (ASR) block. Record what you ran, where and when, so the alerts can be matched to you.

Before You Start

Agree these with the machine's owner before you begin.

Tell the security team before you capture, because dumping a process can trip endpoint protection, and your work has to be told apart from an intruder's.
Dumping lsass.exe writes credentials to disk and trips credential theft alerts, so agree it first, and keep the file as you would a password.
With added LSA protection on, lsass.exe runs as a protected process, and Microsoft states that no debugger can attach to it, so a protected process refuses a dump by design.
LsaIso.exe runs in isolated user mode, so no tool can attach to it, read its memory or debug a dump of it, even with admin rights or from a driver.

Proves These Red Flags

This check is a step in confirming each sign below.

Red Flags: Renamed, Unsigned or Falsely Signed Binaries Unsigned or Oddly Signed Modules
How Malware Hides in a Process: Process Hollowing DLL Search Order Hijacking and Side-Loading

Check It in the Registry: LSA Protection (RunAsPPL)Clear Pagefile at Shutdown
Read with Active Directory: LSASS Memory Theft What a dump of lsass.exe holds, and the alerts and events that reading it leaves.