VolMemLyzer3 Technical report

Memory forensics · Volatility 3 orchestration · DFIR analysis

From a memory image to reusable evidence — without manually coordinating dozens of plugin runs.

VolMemLyzer3 is an orchestration and analysis layer around Volatility 3. It schedules forensic plugins according to their dependencies, reuses completed artifacts, correlates evidence across plugin outputs, and exposes the same evidence to both analysts and downstream feature pipelines.

Behaviour-Centric Cybersecurity CenterWindows memory forensicsRepositoryCanonical rule specification
2.4×measured wall-clock reduction, 4 workers vs serial
3.15 swarm-cache artifact reuse on the benchmark
56registered plugin definitions
64explicit analyst-facing rule conditions
520features exposed to downstream analysis

Problem

Volatility extracts evidence. A case still has to coordinate it.

One plugin answers one forensic question. A case usually asks many: which processes exist, which views disagree, what they loaded, where they executed from, which handles and privileges they hold, what network state exists, whether private executable memory is present, and what persistence or kernel artifacts deserve review.

Collection cost

Some plugins are fast; pool scans and cross-view operations can dominate a run. Treating every plugin as an independent command turns case setup into manual scheduling.

Dependencies

Some extractors need context produced by others. Starting work too early is incorrect; waiting for unrelated slow work is unnecessary.

Correlation

Volatility outputs are separate artifacts. Investigative hypotheses often require evidence spread across several of them.

System design

Collect once; reuse the evidence in several ways.

Volatility remains the forensic engine. VolMemLyzer controls execution, dependency release, caching and the interpretation layers that consume the resulting artifacts.

Memory imagecaptured Windows memory
Volatility 3forensic plugin execution
Dependency graphcorrect execution order
Artifact cachereusable plugin output
Raw resultsdirect forensic review
Correlated analysisprioritized evidence
Feature extraction520 image-level features
Collection and interpretation are deliberately separate.
Changing an analysis threshold, rerunning a rule, or extracting features should not require another expensive pass over the memory image when the necessary artifacts already exist.

Dependency-aware concurrency

A slow plugin blocks only the work that actually depends on it.

The scheduler does not drain synchronized topological layers. It reaps completions individually and releases a dependent operation the moment its own prerequisites are satisfied.

Layer barrier

Illustration of the older failure mode.

fast A
slow B
depends A

The A-dependent work waits for unrelated B because the whole layer must drain.

VolMemLyzer graph release

A dependent starts when its own prerequisite completes.

fast A
slow B
depends A

The scheduler also commits dependency context before submitting downstream extractors, preserving correctness.

Measured execution

Concurrency reduces collection time; caching changes the cost class entirely.

The committed benchmark runs the same 10-plugin extraction set against a 4.41 GB Windows image. Serial and parallel runs disable the artifact cache. Warm-cache measures reuse, not a faster Volatility engine.

Median wall-clock
Three successful runs per configuration.
172.16 s
Serial · 1 worker
71.12 s
Parallel · 4 workers
3.15 s
Warm cache

Benchmark interpretation

ConfigurationMedianRange
Serial172.16 s166.57–173.79
4 workers71.12 s69.49–73.50
Cache warm3.1517 s3.1483–3.4141

Peak RSS rises from about 305 MB serial to 613 MB at four workers; warm-cache median peak RSS is about 110 MB. The benchmark therefore shows a wall-clock/memory trade-off.

Method and raw benchmark data

Artifact reuse

Completed forensic work becomes input, not disposable terminal output.

Plugin requestedworkflow needs evidence
Exact cache hit?reuse immediately
Convertible artifact?convert without rerun
Otherwise runexecute Volatility
Persist resultavailable to later workflows
A failed or zero-byte artifact is unavailable — never “clean.”
That distinction matters to analysts and to downstream statistical or machine-learning consumers.

Forensic triage

Analysis correlates hypotheses rather than counting every symptom.

The analysis layer spans six surfaces and uses explicit predicates. Observations that represent the same underlying hypothesis share an evidence family; only the strongest member of that family contributes to the object score.

Process census

Cross-view disagreement, hidden/terminated process context, lineage, execution location and related process evidence.

Executable private memory

Review of private executable regions and corroborating loader/payload observations.

Network

Connection and socket evidence when deep collection provides netscan.

Persistence & history

Registry hives, scheduled tasks, UserAssist and related execution/persistence context.

Kernel dispatch

Specialized SSDT-oriented integrity review under deep collection.

Bearings

Image and execution context that supports interpretation of the other surfaces.

Bounded evidence score

object score = min(30, Σ strongest_weight[hypothesis_family])

Low0–8 · context
Medium9–13 · review
High14–19 · corroborated
Critical20–30 · several independent hypotheses

The score is ordinal evidence prioritization, not malware probability, confidence, or a confirmed ATT&CK technique.

Exact rule explorer

Search the canonical rule specification from the repository.

This table is populated directly from docs/ANALYSIS_RULES.md when the page loads. It extracts rule tables containing a Flag and Exact condition column, so the browser presentation does not become a second source of truth.

Loading canonical rules…
SectionFlagExact conditionWeightInvestigative hypothesisATT&CK
Loading…

If browser security blocks the live fetch from a local preview, open the canonical rule specification. On GitHub Pages the explorer can load it normally.

Observed triage snapshot

The analysis view surfaces 31 review indicators across a 118-process census.

This example is taken from the current MemTriage/VolMemLyzer analysis output. The purpose is not to present a synthetic “validation score,” but to show what the correlated evidence model actually produces for an analyst: ranked objects, bounded scores, confidence, evidence explanations, and ATT&CK-aligned context.

118processes in the census
31indicators surfaced
3Critical
1High
6Medium
21Low

Highest-priority object

malware.exe (PID 2580)

FieldObserved value
Parent PID3768
RiskCritical
Score23.6 / 30 (displayed as 24/30 in the compact view)
Confidence94.6%
Signalsmalfind_rwx_private, corr_credential_theft, malfind_peb_walk, token_sedebug

Why it surfaced

EvidenceContributionConfidence
RWX private memory region+8.470%
Corroborated credential access+6.085%
PEB loader-list walk+4.860%
Sensitive privilege enabled+4.455%

The detailed contributions total 23.6. The compact object list rounds the displayed score to 24/30.

Other surfaced process examples

ObjectRiskScoreConfidencePrimary signals
powershell.exe (3768)Critical23.6/3094.6%malfind_rwx_private, corr_credential_theft, lolbin_from_service_host, +1
powershell.exe (5088)Critical23.6/3094.6%malfind_rwx_private, corr_credential_theft, lolbin_from_service_host, +1
winlogon.exe (688)High15.2/3095.5%core_proc_wrong_path, token_sedebug
smss.exe (372)Medium10.8/3090.0%core_proc_wrong_path
SearchHost.exe (5292)Medium8.4/3070.0%malfind_rwx_private

ATT&CK-aligned posture

Alignment is used for triage context, not as a claim of confirmed adversary activity.

TechniqueObserved alignments
T1134 · Access Token Manipulation40×
T1055 · Process Injection10×
T1036 · Masquerading7×
T1003.001 · LSASS Memory3×
T1053.005 · Scheduled Task3×
T1059 · Command and Scripting Interpreter2×
The useful output is the explanation, not just the severity label.
Each surfaced object carries the signals that contributed, their evidence strength, confidence, and framework alignment, so an analyst can inspect why an object moved up the queue instead of trusting an opaque score.

Collection modes

Quick collection avoids the operations most likely to dominate wall-clock.

SurfaceQuick artifactsAdditional deep artifacts
Bearingswindows.info—
Process censuspslist, pstreepsscan, psxview
Executable private memorymalfind—
Networkskippednetscan
Persistence / historyhivelist, scheduled tasks, UserAssisthivescan
Kernel dispatchskippedssdt

Claim boundaries

What the analysis deliberately refuses to infer.

No malware verdict

A surfaced object is a review lead, not a classification.

No missing-data assumption

A failed plugin is unavailable, not clean.

No score inflation

Correlated observations contribute once per hypothesis family.

No filename-to-technique jump

Names and paths can support review; they do not prove adversary behavior.

No raw-RWX verdict

Executable-memory protection alone does not establish maliciousness.

No port-only C2 claim

Network context without protocol or reputation evidence remains supporting context.

Downstream use

The same artifact layer can feed an analyst workspace or a feature pipeline.

MemTriage consumes VolMemLyzer's extraction/artifact layer rather than re-running the memory image for every downstream interaction. The separate feature report documents the quantitative schema used by statistical and model-oriented consumers.