Analyzing malware in memory with volatility3

Skill meltedinhex/analyst-ai-pack/skills/analyzing-malware-in-memory-with-volatility3

An open agent-skills library for malware analysis, reverse engineering, and threat hunting - 118 curated, runnable skills mapped to MITRE ATT&CK, D3FEND, and CAR.

Install

npx -y skills add meltedinhex/analyst-ai-pack --skill analyzing-malware-in-memory-with-volatility3

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

19 stars19 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Analyzes a memory image with Volatility 3 to find malware: rogue processes, injected code, suspicious network connections, loaded modules, and persistence, then extracts artifacts for further analysis. Activates for requests to do memory forensics, analyze a RAM dump, or hunt malware in memory with Volatility.

The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

3.6 KB, as published. Nobody here has run it

Analyzing Malware in Memory with Volatility 3

When to Use

You have a RAM image from a suspected-infected host and need to find malicious activity.
Disk artifacts are insufficient (fileless/in-memory malware) and you need volatile evidence.
You want to extract injected code, command lines, or network connections for analysis.

Do not use Volatility plugins blindly without an order of investigation — start broad (processes, network) before deep per-process dumps.

Prerequisites

Volatility 3 (pip install volatility3) with appropriate symbol tables.
A memory image acquired with a sound tool (WinPmem, LiME, or hypervisor snapshot).
Knowledge of the source OS/version to select the right symbols.

Safety & Handling

Work on a copy of the image; preserve the original with a recorded hash.
Treat any dumped executable region as a live sample — store and handle it accordingly.

Workflow

Step 1: Enumerate processes and spot anomalies

vol -f memory.raw windows.pslist
vol -f memory.raw windows.pstree

Look for unusual parents (Word spawning cmd/powershell), masquerading names (scvhost.exe), processes with no disk path, and orphaned children.

Step 2: Hunt injected code

vol -f memory.raw windows.malfind

malfind flags private, executable, RWX regions with no backing file — classic injection. Note the PID and base address for dumping.

Step 3: Review network connections

vol -f memory.raw windows.netscan

Correlate listening/established connections with suspicious PIDs and the C2 endpoints from other analysis.

Step 4: Check modules, handles, and persistence

Examine loaded DLLs (windows.dlllist), services, and registry (windows.registry.*) for persistence and unexpected modules.

Step 5: Dump artifacts

Dump the suspicious process or injected region for static/RE analysis:

vol -f memory.raw windows.dumpfiles --pid <pid>

The helper script parses Volatility's JSON renderer output to highlight injection candidates.

vol -f memory.raw -r json windows.malfind | python scripts/analyst.py malfind -

Validation

Injection candidates from malfind correspond to anomalous processes from pstree.
Network connections map to known C2 or the sample's extracted config.
Dumped regions disassemble into meaningful code, not random bytes.

Pitfalls

Wrong symbols/profile producing empty or garbage results — confirm OS build first.
Treating every RWX region as malicious; some legitimate JIT engines use RWX. Corroborate.
Forgetting to hash and preserve the original image before analysis.

References

See references/api-reference.md for the malfind output parser.
Volatility 3 documentation and memory-forensics concepts (linked in frontmatter).