Process Memory Capture: Preserving and Analyzing Live-Process Evidence

What Process Memory Capture is

Process Memory Capture is a Malware INFO Enterprise workflow for preserving point-in-time evidence from one exactly identified live process. It helps an analyst collect memory for later examination without pretending that a dump explains everything the process did.

The workflow keeps acquisition and interpretation separate. Malware INFO first identifies the target, checks whether the requested operation is supported, presents a preflight summary, and requires the analyst to start the capture explicitly. The resulting evidence records its status, coverage, identity, artifacts, limitations, and diagnostics for later review.

Critical privacy warning: A process-memory dump can contain credentials, authentication tokens, cryptographic keys, private documents, personal or business data, decrypted content, and unrelated information that happened to be present in the process. Do not share raw memory dumps with other people, post them publicly, or send them through ordinary chat, email, ticketing, or unrestricted collaboration channels. Keep them in protected case storage and use only an authorized secure-transfer process when raw evidence must be transferred.

Unknown or suspicious process capture belongs only in an authorized, disposable, isolated analysis VM with no trusted network, credentials, shared folders, or sensitive data. Process Memory Capture is an observation workflow. Its controls do not turn the analysis machine into a sandbox and do not roll back changes made by a target process.

Why process-memory evidence matters

A file on disk and a running process are different evidence views. During execution, legitimate software or a loader can map images, apply relocations, resolve imports, decompress data, decrypt configuration, generate code, or create private executable regions. A memory capture may therefore preserve bytes that were not available in the original file.

That makes memory valuable, but not self-explanatory. Finding a URL, an API name, executable bytes, high entropy, or an unusual structure in memory does not prove that the program used it maliciously. A dump establishes what bytes were readable within the recorded scope and time. Interpretation still depends on provenance, coverage, process identity, other observations, and analyst judgment.

Supported x86 and x64 boundary

The current Process Memory Capture target boundary is:

• x86 target processes on Windows x64;
• x64 target processes on Windows x64;
• an architecture-matched dedicated capture host;
• one exactly identified process per operation;
• one active Process Memory Capture globally;
• an exact hard limit of 1 GiB (1,073,741,824 bytes) for each primary artifact.

Native ARM64 target capture is not supported. Protected or critical processes, an unstable or incomplete target identity, an unsupported architecture, inaccessible memory, unsafe component mismatch, or a target that has already exited can cause the request to be refused or fail.

Ready for inspection means policy currently permits the analyst to request an operation. It does not mean the process is safe, clean, suspicious, or malicious. Not inspectable is also a safety or availability state, not a detection result.

Choosing among the six capture formats

Process Memory Capture offers six formats. Choose the format that answers the investigation question while collecting no more sensitive data than necessary.

Windows MiniDump

Use Windows MiniDump when you want a conventional, comparatively focused Windows dump for compatible debugging or forensic tooling. It is a complete-only format: a short read, cancellation, identity change, or other failure does not become a successfully published partial MiniDump.

Full User-Mode Dump

Use Full User-Mode Dump when the investigation needs a broader user-mode view and the expected size is acceptable. It can contain substantially more sensitive and unrelated data than a focused region. It is also complete-only.

Raw Process Memory Image

Raw Process Memory Image preserves readable process-memory ranges with a memory map. It can retain meaningful Partial evidence when some ranges are unavailable, but the gaps and limitations must remain explicit. Partial does not mean complete.

Individual Memory Region Dump

Use Individual Memory Region Dump after identifying one exact region that answers a specific question, such as a selected executable-memory candidate. It is complete-only and requires a valid region scope bound to the selected process instance.

PE Image Dump

PE Image Dump preserves a validated mapped PE image from the process. The result represents the mapped memory layout; it is not automatically the original disk file, a repaired executable, a successful unpacking, or runnable output. This format is complete-only.

MalwareInfo Custom Memory Format

MalwareInfo Custom Memory Format preserves typed memory-region and provenance information for Malware INFO analysis. Like the Raw format, it may retain explicitly labeled Partial evidence with meaningful bytes and exact limitations.

The four complete-only formats are Windows MiniDump, Full User-Mode Dump, Individual Memory Region Dump, and PE Image Dump. Only Raw Process Memory Image and MalwareInfo Custom Memory Format may publish Partial capture evidence.

Exact identity, preflight, and explicit consent

Do not choose a target by PID or filename alone. Windows can reuse a PID, and a path or filename can refer to changed content. Malware INFO uses a compound process identity that includes the process instance and executable identity, then revalidates it before capture.

The preflight dialog gives the analyst a final opportunity to check:

• process name and PID;
• compound target identity;
• x86 or x64 architecture;
• selected format and scope;
• estimated artifact size when available;
• the exact 1 GiB limit;
• complete-only or Partial publication rules;
• the sensitive-data warning.

Only choose Start Capture after those facts match the intended target and the case authorization covers memory acquisition. If another capture is active, Malware INFO returns CaptureBusy; it does not queue or automatically retry the request. Refresh the process identity and run preflight again after the active operation finishes.

The current desktop request also has a bounded deadline. A deadline limits the acquisition operation; it does not guarantee that every requested byte will be readable or that the capture will finish successfully.

A controlled benign walkthrough

Use this walkthrough to learn the workflow without introducing malware or private case evidence.

1. Prepare an authorized disposable Windows analysis VM. Remove trusted network access, credentials, shared folders, private documents, and sensitive data.
2. Start a clean benign process such as Notepad. Do not open a real document; leave it empty.
3. Open Advanced Analysis, choose Process Memory Capture, and refresh the process list.
4. Select the exact benign process row. Confirm the process name, PID, start time, executable identity, architecture, user, and inspection state.
5. Begin with the smallest format that answers the question. For training, Windows MiniDump is a reasonable first operation. Use a region-specific format only after selecting the correct region.
6. Read the preflight dialog completely. Confirm format, identity, architecture, scope, estimate, limit, completeness policy, and privacy warning.
7. Choose Start Capture once. Watch the bounded progress dialog and avoid starting another capture in parallel.
8. Read the terminal state and coverage before opening or analyzing evidence.
9. Use the verified handoff to Payload & Memory Analyzer rather than selecting an arbitrary file merely because its name or timestamp looks recent.
10. Confirm that the capture host and any training target have exited when the exercise is complete. Keep raw evidence inside protected case storage.

Repeat a format only when it answers a different evidence question. Collecting every format by default increases storage, privacy exposure, and review burden without guaranteeing better conclusions.

Reading status, coverage, and integrity evidence

Status and coverage answer different questions. A terminal operation state tells you what happened to the request. Coverage tells you how much of the named evidence scope was obtained.

• Status Completed with Complete coverage means the requirements for that named artifact completed within the recorded limits.
• Status Partial means useful evidence was retained but one or more ranges or stages were unavailable. For Process Memory Capture publication, this applies only to Raw and Custom formats.
• Status Cancelled means the operation was stopped. Do not interpret cancellation as no activity.
• Status TimedOut means the deadline was reached.
• Status Failed means the requested operation did not complete successfully.
• Status Unsupported means a required architecture, format, target, or prerequisite is outside the supported boundary.
• A refusal can also occur before capture because identity, protection policy, entitlement, service availability, or another safety prerequisite did not pass.

For published evidence, verify the capture manifest and keep these fields together:

• target compound identity and architecture;
• capture type and time;
• operation status and coverage;
• artifact filename, exact byte length, and SHA-256;
• capture-tool identity;
• coverage limitations and diagnostic code;
• region, raw-map, or PE-image sidecar information when applicable.

A directory, filename, or green-looking message is not enough to establish integrity. If a protected-evidence workflow reports Recovery Required, restrict access to the evidence location and follow the documented recovery process before retrying or exporting. Do not simplify it into an ordinary failure or success.

Handoff to Payload & Memory Analyzer

Payload & Memory Analyzer reads selected artifacts without executing or loading them as code. Verified Process Memory Capture evidence can carry a stronger provenance relationship than an arbitrary standalone file because the handoff can validate the capture manifest, artifact length and SHA-256, and compatible process identity.

The analyzer can report structure, strings, entropy, imports, capabilities, mapped-image information, local enrichment, and other bounded findings. These remain static or mechanically derived evidence unless a separate, verified runtime source satisfies the exact identity and range requirements for attribution.

When analysis is complete, preserve the verified report bundle and its manifest unchanged. The structured handoff can be reviewed by Final Report to CISO without placing the selected raw memory artifact inside the derived report bundle. For a deeper explanation, read From Captured Memory to Defensible Evidence: Understanding Malware INFO Payload & Memory Analyzer.

Static evidence, runtime evidence, and inference

Keep these categories separate throughout the investigation.

Static evidence comes from the captured bytes or their structure. Examples include strings, PE headers, imports, sections, entropy, capabilities, hashes, and local rule matches. It can show content and possible capability, but it does not prove execution.

Observed memory evidence establishes that specific bytes were readable from the identified process within the named capture scope and time. It does not prove how those bytes arrived there or whether a CPU reached them.

Runtime evidence requires a separate sensor observation bound to the same process instance, executable identity, provider, and relevant time or address range. Even an exact observed API call does not automatically prove attacker intent or malware.

Inference is an analyst interpretation supported by cited evidence. For example, encrypted-looking data beside a configuration parser may support a hypothesis, but the hypothesis must retain its uncertainty, contradictions, and missing coverage.

Do not promote one category into another merely because the evidence looks suspicious.

Sparse, incomplete, and unavailable results

A quiet result does not prove inactivity. Sparse or missing evidence may reflect:

• capture timing that missed an earlier state;
• a target that changed or exited;
• inaccessible, unmapped, or changing memory;
• a scope that did not include the relevant bytes;
• unsupported architecture or format prerequisites;
• protected-process policy;
• component mismatch or service availability;
• a limit, timeout, cancellation, or recovery condition;
• behavior that exists only in a child process, service, plug-in host, or another process.

Read the limitation list before interpreting the content. Positive observations remain evidence even when other coverage is missing, and a gap must not be translated into benign activity.

Host-dependent, service, plug-in, and side-loaded behavior

Some DLLs and components do little when examined outside their authentic host. A service DLL may depend on service initialization. A browser or document plug-in may wait for host callbacks. A side-loaded DLL may behave differently only when loaded beside a particular executable and dependency set. A payload may also move work into a child process.

Process Memory Capture does not create that missing context. Select the authentic benign or authorized analysis host process when the investigation question depends on host state, and use a separate controlled runtime-observation workflow when you need to establish operations over time. Never infer complete behavior from one snapshot.

Privacy, storage, and sharing restrictions

Treat every raw dump as sensitive case evidence even when the selected process appears benign. Memory can include information from libraries, caches, document buffers, browser sessions, authentication flows, environment data, and neighboring application state.

Use these handling rules:

• keep raw memory in Malware INFO protected evidence storage or an equivalent access-controlled case location;
• limit access to authorized investigators who need the raw bytes;
• preserve the manifest, length, SHA-256, timestamps, and chain-of-custody information;
• do not upload raw memory to public scanners or cloud services;
• do not attach raw dumps to ordinary email, chat, tickets, shared drives, or public repositories;
• use an approved encrypted transfer and documented recipient authorization when raw evidence must move;
• prefer the minimum sanitized report, metadata, or verified derived bundle needed for analyst or CISO review;
• review exported material for usernames, paths, hostnames, tokens, private strings, case identifiers, and other sensitive content before sharing.

Local capture and protected storage reduce accidental exposure; they do not make an exported dump safe to distribute. See How to Use Malware INFO Safely for the broader analysis boundary.

Practical checklist

Before capture:

• Confirm authorization and use a disposable isolated VM for unknown targets.
• Remove trusted network access, credentials, shares, and sensitive data.
• Select the exact process instance, not just a PID or name.
• Choose the smallest format and scope that answer the question.
• Read the estimate, 1 GiB limit, completeness policy, and privacy warning.

After capture:

• Record status and coverage separately.
• Verify target identity, architecture, artifact length, SHA-256, manifest, and diagnostics.
• Preserve limitations, gaps, cancellations, refusals, and unsupported states.
• Keep raw dumps protected and do not share them casually.
• Use the verified analyzer handoff and preserve the complete derived report bundle.
• Keep static facts, observed memory, runtime observations, and inference separate.
• Treat the result as evidence for analyst review, not a malware verdict or containment authority.

Process Memory Capture is most useful when it preserves not only bytes, but also the identity, integrity, coverage, and limitations needed to explain exactly what those bytes do—and do not—prove.