Digital-Forensics Workflow for Memory Dumps: A 4-Phase Investigation Guide

The digital-forensics workflow for memory dumps consists of four phases — Preservation, Memory Extraction, Host Artifacts correlation, and Network Correlation — implemented with Volatility 3, tshark, and strict evidence-handling protocols.

This guide walks through the complete digital-forensics workflow defined in the zhaoxuya520/reverse-skill repository. The methodology, documented in [skills/digital-forensics/SKILL.md](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/digital-forensics/SKILL.md), provides investigators with a repeatable, court-admissible process for analyzing volatile memory captures.

Phase 1: Preservation — Securing Evidence Integrity

Every digital-forensics investigation begins with evidence preservation to prevent alteration and establish chain-of-custody. According to lines 28-32 of SKILL.md, this phase enforces four critical controls:

• Cryptographic hashing: Compute SHA-256 checksums of the original dump
• Metadata recording: Document acquisition timezone and exact commands used
• Read-only operations: Work exclusively on verified copies, never the original
• Chain-of-custody documentation: Timeline entries tracking all access

The repository emphasizes this integrity-first approach because memory dumps are inherently volatile — any write operation, even mounting the image, risks evidence contamination.

#!/usr/bin/env bash
set -euo pipefail

# Preservation workflow from SKILL.md

DUMP="mem.dmp"
HASH=$(sha256sum "$DUMP" | awk '{print $1}')
echo "SHA256: $HASH"
echo "Acquisition time: $(date -u +"%Y-%m-%dT%H:%M:%SZ")"
echo "$HASH  $DUMP" >> evidence.log

Phase 2: Memory Extraction — Volatile Artifact Recovery

With evidence secured, investigators deploy Volatility 3 to extract artifacts from the dump. The reverse-skill repository specifies four essential plugins for Windows memory analysis (lines 36-41):

Plugin	Purpose
windows.info	System configuration and kernel details
windows.pslist	Running process enumeration
windows.netscan	Active network sockets and connections
windows.cmdline	Command-line arguments per process

These plugins reveal live system state at capture time — processes that may no longer exist, network connections that closed, and commands that executed without logging.

VOL="/usr/local/bin/vol"  # Volatility 3 path

# Core extraction commands per SKILL.md

$VOL -f "$DUMP" windows.info   > info.txt
$VOL -f "$DUMP" windows.pslist > pslist.csv
$VOL -f "$DUMP" windows.netscan > netscan.csv
$VOL -f "$DUMP" windows.cmdline > cmdline.csv

Volatility 3's plugin architecture ensures this digital-forensics workflow adapts to new Windows builds without methodology changes.

Phase 3: Host Artifacts — Disk-Based Correlation

Memory analysis alone provides incomplete context. Phase 3 correlates volatile findings with persistent host artifacts (lines 45-49):

Event Log Analysis

• Security logs: authentication events, privilege escalation
• PowerShell logs: script block execution and command history
• Sysmon logs: process creation with hashes and parent/child relationships

Persistence Mechanism Hunting

• Registry Run keys for auto-start programs
• Windows Services with suspicious binaries
• Scheduled Tasks configured for stealth execution
• WMI event subscriptions for fileless persistence

Execution Footprint Identification

• Amcache.hve: program installation and first execution timestamps
• Prefetch files: application launch history and path evidence
• BAM/DAM registry keys: recent executable paths per user

The repository's SKILL.md recommends extracting these via additional Volatility plugins or companion disk forensics tools, creating a unified timeline of attacker activity.

# Example: Security event log extraction from memory dump

$VOL -f "$DUMP" windows.eventlogs -e Security > security_events.csv

Phase 4: Network Correlation — Traffic Integration

The final phase bridges memory-resident network state with packet capture analysis (lines 52-56). When investigators possess contemporaneous PCAP files, tshark enables:

• Session enumeration and protocol distribution statistics
• DNS query extraction for domain pivot identification
• Suspicious flow extraction for deeper protocol-reverse engineering or C2 analysis

PCAP="capture.pcap"

# Session statistics

tshark -r "$PCAP" -q -z io,stat,0,COUNT > network_stats.txt

# DNS-focused extraction for C2 investigation

tshark -r "$PCAP" -Y "dns" -w suspicious_dns.pcap

This network-memory fusion often reveals the full attack chain: a process seen in windows.pslist that connected to an IP found in windows.netscan, now correlated with the actual payload delivered over that connection.

Complete Workflow Implementation

The following bash script implements all four phases as a cohesive digital-forensics pipeline, adapted from the repository's reference implementation:

#!/usr/bin/env bash
set -euo pipefail

DUMP="mem.dmp"
VOL="/usr/local/bin/vol"
PCAP="capture.pcap"

# ---------- Phase 1: Preservation ----------

HASH=$(sha256sum "$DUMP" | awk '{print $1}')
echo "SHA256: $HASH" | tee -a evidence.log
echo "Acquired: $(date -u +"%Y-%m-%dT%H:%M:%SZ")" >> evidence.log

# ---------- Phase 2: Memory Extraction ----------

mkdir -p volatility_output
$VOL -f "$DUMP" windows.info   > volatility_output/info.txt
$VOL -f "$DUMP" windows.pslist > volatility_output/pslist.csv
$VOL -f "$DUMP" windows.netscan > volatility_output/netscan.csv
$VOL -f "$DUMP" windows.cmdline > volatility_output/cmdline.csv

# ---------- Phase 3: Host Artifacts ----------

$VOL -f "$DUMP" windows.eventlogs -e Security > volatility_output/security_events.csv

# ---------- Phase 4: Network Correlation ----------

if [[ -f "$PCAP" ]]; then
    tshark -r "$PCAP" -q -z conv,tcp > volatility_output/tcp_conversations.txt
    tshark -r "$PCAP" -T fields -e dns.qry.name > volatility_output/dns_queries.txt
fi

echo "Digital-forensics workflow complete. Evidence hash: $HASH"

Key Source Files and References

File	Purpose	Location
skills/digital-forensics/SKILL.md	Core workflow definition and command reference	View source
skills/digital-forensics/references/forensics-triage.md	Triage methodology and evidence handling	View source
RULES.md	Authorization requirements and skill invocation rules	View source

Summary

• Integrity first: SHA-256 hashing and read-only operations protect evidence admissibility
• Volatility 3 core: Plugin-based architecture extracts processes, network state, and command history from memory dumps
• Context enrichment: Correlating memory findings with event logs, persistence mechanisms, and execution artifacts builds comprehensive timelines
• Network fusion: tshark integration connects volatile memory state to actual packet captures for end-to-end attack reconstruction
• Repeatable structure: The four-phase workflow in digital-forensics/SKILL.md scales from single-workstation incidents to enterprise investigations

Frequently Asked Questions

What tools are required for this digital-forensics workflow?

The repository specifies Volatility 3 for memory analysis and tshark (or Wireshark) for packet capture examination. Standard Unix utilities (sha256sum, date, awk) handle preservation tasks. All tools are open-source and cross-platform.

Why is Volatility 3 preferred over earlier versions?

Volatility 3 eliminates the need for profile building — it auto-detects Windows kernel structures. This plugin-based architecture means the digital-forensics workflow remains stable despite Windows updates, reducing investigator overhead.

How does this workflow maintain evidence integrity?

Phase 1 mandates cryptographic hashing, metadata logging, read-only original access, and chain-of-custody documentation. These controls satisfy legal requirements for digital evidence handling and enable reproducible analysis.

Can this workflow analyze Linux or macOS memory dumps?

The commands shown target Windows (windows.pslist, windows.netscan). Volatility 3 supports Linux and macOS through alternative plugins (linux.pslist, mac.pslist), but the four-phase digital-forensics structure remains identical regardless of operating system.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}