From Captured Memory to Defensible Evidence: Understanding Malware INFO Payload & Memory Analyzer

What Payload & Memory Analyzer is

A file on disk is only one view of a program. During execution, a loader may apply relocations, resolve imports, unpack or decrypt content, generate code, or map data that was not directly readable in the original file. A retained memory artifact can therefore contain investigative evidence that is absent from the disk image.

That evidence is easy to overstate. A URL in memory does not prove that a connection occurred. An API name does not prove that the function was called. Executable bytes do not prove that a CPU reached them. A changed page does not automatically prove unpacking, injection, or malicious self-modification.

Malware INFO Payload & Memory Analyzer is an Enterprise workspace for bounded, local, non-executing inspection of supported artifacts. It establishes what bytes and structures are present, records how the artifact was acquired, preserves identity and coverage, and keeps static capability evidence separate from exact runtime observations and analyst inferences.

The central rule remains simple: the analyzer reads the selected artifact but does not execute it or load it as a library.

Start with Preflight, not the findings

The current workflow uses a format-aware Preflight before analysis. Preflight identifies the producer and format, checks available manifests or sidecars, records provenance, and distinguishes the file the analyst selected from any inner artifact that will actually be analyzed.

This distinction matters for containers and producer outputs. The selected or outer file may be an envelope, while the analyzed or inner file may be a PE image or a logical memory view. The report preserves both identities rather than silently replacing one with the other.

The current acquisition route covers:

• ordinary files, including EXE, DLL, and SYS files, without requiring a manifest;
• Automated Unpacker Dump, Candidate, and Fixed artifacts when their generation chain can be verified;
• six Process Memory Capture kinds: Windows MiniDump, Full User-Mode Dump, Raw Process Memory Image, Individual Memory Region, PE Image, and MalwareInfo Custom .mimem;
• retained Deep API Trace memory or PE artifacts through their verified session and snapshot evidence; and
• API Hook-derived or Deep-derived Analyzer evidence packages where the corresponding source contract is present and valid.

A manifest can strengthen identity, range mapping, acquisition provenance, and runtime relationships. It does not make an artifact safe, change the file-size limit, prove execution, or create a malware verdict. A safe recognized standalone artifact may continue with Partial coverage, while a corrupt recognized container or conflicting identity is blocked instead of falling back to an untyped raw-byte interpretation.

One file-size policy, two coverage boundaries

Every selected Payload Analyzer file now uses the same exact admission limit: 1 GiB (1,073,741,824 bytes). A file larger than that is refused.

For an admitted file, the analyzer streams the complete byte count and SHA-256. PE parsing, entropy, strings, preview, and capability inspection retain at most the first 16 MiB. If the complete artifact is larger, the full-file identity remains exact while affected static-analysis families are reported as Partial.

The 16 MiB value is therefore an internal retained-analysis boundary. It is not the input-file limit and it is not a total report-size limit.

The current safety contract can be summarized as:

StaticOnly;NeverExecuteArtifact;NeverLoadLibraryArtifact;ReadOnlyInput;Bounded1GiB;RetainedAnalysis16MiB;CorrelationIsEvidenceNotVerdict;NoCloudSubmission

Memory evidence is sensitive

Important: A memory dump can contain credentials, tokens, private keys, document fragments, personal data, internal paths, commands, decrypted configuration, and other sensitive material from the captured process. Do not send a raw dump, Analyzer package, or report bundle to another person or external service unless the sharing is explicitly authorized and the destination, access controls, retention period, and redaction requirements have been reviewed.

Payload & Memory Analyzer works locally and does not silently submit artifacts or recovered content to a Malware INFO analysis cloud. Shareable output redacts common credential-shaped values and local-user paths where supported, but redaction is not a guarantee that every sensitive value has been removed. Treat both the source evidence and exported package as controlled case material.

Static analysis also does not make the original collection environment safe. Capturing or tracing an unknown program belongs only in an authorized, disposable, isolated analysis VM with no trusted network, credentials, shares, or sensitive data.

Runtime collection and artifact analysis answer different questions

Guided API Trace, Deep API Trace, API Hook Trace, Process Memory Capture, and Payload & Memory Analyzer can contribute to one investigation, but they do not have the same authority.

Payload & Memory Analyzer starts with existing bytes and asks:

• What structures and values are present?
• Which facts were read directly from the artifact?
• Which values were derived mechanically?
• Which interpretations remain hypotheses?
• Which evidence families were unavailable or limited?
• Does a separately verified runtime package bind an exact event to this artifact and process instance?

An imported API, API-looking string, endpoint, high-entropy region, YARA match, or executable page is static or contextual evidence. Exact runtime use requires a supported runtime observation and a verified compound relationship. Even an exact API observation does not by itself establish attacker intent, malware family, successful exfiltration, or authority to contain the endpoint.

A controlled folder-analysis example

The captured example used for this article began with a previously retained Deep API Trace evidence folder. Payload & Memory Analyzer examined the folder as a bounded local source and generated a folder index plus detailed artifact reports.

The captured report shows 76 accepted artifacts and 76 detailed analyses. That count means the bounded artifact work completed. It does not mean 76 malicious payloads were confirmed, and it does not mean every artifact achieved runtime attribution.

A practical end-to-end workflow is:

1. Preserve the source package, manifests, checksum inventory, timestamps, and case context.
2. Select the exact artifact or supported evidence folder.
3. Review Preflight producer, format, selected/outer identity, analyzed/inner identity, coverage, limitations, and blocking diagnostics.
4. Continue only when the displayed source is the one intended for analysis.
5. Review static structure, strings, enrichment, memory comparison, and source correlation as separate evidence families.
6. Read gaps, contradictions, omitted counts, and resource limits before drawing conclusions.
7. Export the completed local report package into controlled case storage.
8. When the source family is eligible, let Final Report to CISO independently verify the package on analyst request.

The Evidence Spine preserves what happened to the evidence

The current Analyzer uses a versioned Evidence Spine to connect the analysis without flattening different evidence types into one result. It preserves bounded identities for:

• processes and compound process identity;
• captures and artifacts;
• logical or virtual ranges;
• root observations and runtime references;
• derived relationships;
• gaps and contradictions;
• coverage and resource bounds; and
• privacy and response limitations.

This is especially important when the evidence moves between producers. An exact Deep API Trace event keeps its original API evidence identity and authority. Showing the same event inside a Payload report does not turn it into an independent second observation. Guided, Guard, ETW, Sysmon, and other contextual rows remain Context / NotApiCall; the Analyzer does not relabel them as exact API calls.

Verify identity before interpreting correlation

PID, filename, path, and hash each help, but none is a complete process-to-artifact relationship by itself. Windows can reuse a PID. A path can be replaced. Two files can share a basename, and the same bytes can appear under different paths.

Attributable runtime binding therefore requires the available contract to agree on the relevant compound identity, including session, PID and process-start time, executable path and SHA-256, architecture, artifact SHA-256, source integrity, capture time, and artifact range.

The captured provenance view intentionally shows separate states for artifact identity, source binding, runtime binding, checksum inventory, and retained-analysis bounds. One valid field cannot silently replace a missing or conflicting field.

The runtime-binding vocabulary is deliberately conservative:

• Attributable means the required compound identity and source integrity are verified;
• ContextOnly means useful related evidence exists but the identity contract is incomplete;
• Mismatch means a mandatory binding conflicts; and
• Unavailable means no eligible correlation source was supplied.

Establish static facts without creating runtime claims

Depending on format and retained coverage, the Analyzer can report:

• complete-file size and SHA-256, bounded entropy, ASCII and UTF-16 strings, and a read-only HEX/ASCII preview;
• PE32 or PE32+ headers, sections, directories, hashes, imports, delay imports, resources, TLS callbacks, load configuration, CFG, version data, and offline Authenticode state;
• CLR metadata, assemblies, types, methods, fields, resources, P/Invoke declarations, CorFlags, and strong-name information;
• metadata for possible embedded PE, ZIP, or GZIP content without exporting carved bytes;
• bounded constants and sanitized configuration candidates;
• local YARA, hash-database, and PE-signature enrichment with independent coverage states; and
• optional disk-versus-memory and consecutive-snapshot comparisons when the required identities and ranges verify.

In the captured case, the representative artifact was a retained private executable-region binary. The static pass established its complete-file identity and retained bounded structural and string evidence. It did not label native-code patterns as proof that the region was shellcode or that it executed.

StaticOnly describes how the artifact was analyzed. It does not say that the original process never ran. ContextOnly describes the strength of the available relationship to runtime evidence.

A truthful incomplete-correlation result

The source for the captured example contained session and process context, but the representative artifact did not satisfy every prerequisite for a unique runtime join. Verified executable identity and per-artifact source binding were incomplete.

The Analyzer therefore preserved related rows as context while reporting ContextOnly runtime binding and Partial incident-correlation coverage. That is not failed static analysis. It is successful enforcement of the attribution boundary.

In this captured view, 366 timeline rows were available, 160 were retained as context, and zero satisfied attributable artifact binding or the artifact-range join. Those zeros do not prove that the process performed no API activity. They mean the stronger identity and range requirements were not met for this artifact.

When the complete contract is available, the Analyzer can preserve bounded derived relationships such as an exact typed API parameter mapped to a string offset, a verified caller address mapped to an artifact RVA or section, or observed runtime imports grouped by canonical module!function identity. These are cited relationships, not reconstructed source code or a complete behavior history.

Compare memory states conservatively

Multi-snapshot analysis can record changed bytes, pages, ranges, offsets, RVAs, sections, and before/after hashes between verified consecutive observations. A changed executable page proves only that the retained bytes differed.

Disk-versus-memory comparison also requires an analyst-selected original or a verified source that supplies an exact path and hash. Relocations and IAT changes require separate interpretation because legitimate loader activity can modify them. If the required mapped image, original file, identity, or range is unavailable, the report says the comparison was unavailable; it does not say disk and memory were identical.

Local enrichment reports failure as a coverage gap

Each enrichment source has its own state. A YARA worker failure must not become NoMatch, and a completed hash lookup must not conceal that another source failed.

In the captured example, YARA enrichment failed safely while PE-signature and hash sources reported their own completed states. The warning remained visible instead of turning the overall result into Clean.

A local match remains evidence under the named source, rule, version, and provenance. It does not automatically prove execution, confirm malware, identify an actor, or authorize containment.

Current report publication is streamed and verifiable

The current report format is the streamed MalwareInfo.PayloadAnalysisPackage. Its manifest binds bounded JSONL chunks and other package members by identity, path, size, SHA-256, count, evidence-family metadata, and operation state. Record ordinals are checked for uniqueness and continuity.

The report has no aggregate report-size ceiling, but that is not a no-limit claim. Individual entries, chunks, records, counts, text fields, paths, memory use, cancellation, and transactional publication remain bounded. If publication begins but its committed result cannot be verified, the operation can remain RecoveryRequired rather than being reported as an ordinary success.

The complete Analyzer report is for human review. Final CISO consumes verified structured evidence, not claims reconstructed from HTML, CSV, STIX, screenshots, or report prose. Historical payload-analysis-handoff.json and fixed six-file/schema-v1 bundles describe an older compatibility path; they are not requirements of the current workflow.

Final Report to CISO is on-demand and source-aware

Payload & Memory Analyzer never pushes a report automatically into Final CISO. The analyst selects a source folder, and Final CISO independently verifies eligible packages while isolating corrupt, unsupported, unrecognized, or ineligible neighbors.

Current API Hook Trace, Deep API Trace, API Hook-derived Analyzer, and Deep-derived Analyzer packages can be eligible inputs. Process Memory Capture, Automated Unpacker, Manual File, and Unknown-derived Analyzer packages remain valuable local technical reports, but they are not Final CISO evidence inputs in the current policy.

Final CISO preserves static capability, exact runtime observations, and Context / NotApiCall evidence as different families. It also preserves identity, parent relationships, observation intervals, coverage, gaps, contradictions, producer omissions, and CISO policy omissions. The maximum response remains AlertOnly, and AutomaticContainmentAuthorized remains false.

Final CISO does not open adjacent raw .dmp, .bin, .memimg, or .mimem artifacts as part of package intake. Analysts must still protect those raw files separately because they can contain sensitive data.

How the related tools fit together

Guided API Trace

Guided API Trace provides lower-impact, identity-bound Guard and Windows telemetry correlation. Its rows can contribute process, image, file, Registry, and network context, but they remain contextual and are not exact API calls.

Deep API Trace

Deep API Trace uses a matching-architecture worker to observe supported native API boundaries. It can retain bounded parameters, outcomes, threads, timing, caller attribution, diagnostics, and memory artifacts. Its collection can alter timing and belongs in a controlled analysis environment.

API Hook Trace

Where the Enterprise feature is enabled and the required authorization is present, API Hook Trace produces a separately verified runtime package with its own visibility, coverage, recovery, and protected-evidence boundaries. Its observations keep their original source authority when represented in an Analyzer report.

Process Memory Capture

Process Memory Capture preserves supported x86 or x64 process-memory evidence and its capture metadata. Payload & Memory Analyzer statically interprets supported output; it does not retroactively observe how the bytes were created or whether they executed.

Payload & Memory Analyzer

Payload & Memory Analyzer performs no new execution. It validates the selected source, inspects bounded bytes, builds provenance-preserving evidence, and publishes a verified local technical report.

No source is universally stronger. The right source depends on the question, and the same root observation must not be counted twice merely because it appears in multiple views.

How to interpret sparse or incomplete results

A quiet result does not prove inactivity. Few findings can mean that the artifact contained few qualifying facts, but they can also reflect an unsupported format, a missing manifest or range, a failed provider, incomplete identity, policy limits, omitted records, the wrong capture window, or behavior that occurred in another process.

By itself, Payload & Memory Analyzer cannot prove:

• that an artifact belongs to a particular malware family or actor;
• that an import, string, endpoint, or capability was used;
• that executable-looking bytes were reached by a CPU;
• that a changed page represents unpacking, injection, or malicious modification;
• that a network connection succeeded or data was transferred;
• that all relevant bytes, processes, threads, children, APIs, and time windows were covered;
• that unobserved behavior did not occur;
• that a local match is a final malware verdict; or
• that quarantine, termination, blocking, deletion, or another response is authorized.

Practical analyst checklist

• Work on a preserved copy and keep the source manifest, sidecars, hashes, timestamps, and case context.
• Use an authorized disposable isolated VM for any collection that executes or attaches to an unknown program.
• Verify Preflight producer, format, selected/outer identity, analyzed/inner identity, and coverage before continuing.
• Read complete-file identity separately from the 16 MiB retained static-analysis coverage.
• Keep Observed, Derived, Inferred, exact runtime, and Context / NotApiCall evidence separate.
• Review gaps, contradictions, omitted counts, resource limits, rejected sources, and typed operation state.
• Treat enrichment matches as rule-scoped evidence, not automatic malware confirmation.
• Protect raw dumps and report packages as sensitive case evidence; do not share them without explicit authorization.
• Use Final CISO only with eligible, independently verified packages selected by the analyst.
• When the result remains Partial, ContextOnly, Unavailable, or RecoveryRequired, collect the missing evidence instead of strengthening the wording.

The practical lesson

Forensic tooling earns trust not only by what it reveals, but also by what it refuses to claim.

Payload & Memory Analyzer can turn supported files and memory artifacts into structured, reviewable evidence while preserving acquisition source, complete-file identity, bounded analysis coverage, runtime authority, gaps, contradictions, and privacy limits. It does not turn a static clue into proof of execution, a runtime event into attacker intent, or an Analyzer report into automatic response authority.

Captured bytes become defensible evidence only when identity, integrity, provenance, coverage, and interpretation travel with them.