RAM forensics: tools, techniques, and a 2026 workflow

RAM forensics is the discipline of pulling evidence out of a computer's volatile memory. Unlike disk forensics, where the data sits on a platter, RAM is gone the moment power drops. The artefacts that live there are also the ones adversaries struggle to hide: running processes, injected code, decrypted secrets, in-memory malware, open network sockets, and the actual command lines that were executed.

This guide is the field-level take: what RAM forensics is, the tools that matter in 2026, and a workflow that gets you from "I have a memory image" to "I have a verdict" without standing up a Python environment.

Why RAM forensics keeps mattering

1. In-memory-only malware. Living-off-the-land payloads (PowerShell stagers, reflective DLLs, Cobalt Strike beacons) often never touch disk. RAM is the only place to find them.
2. Credentials and secrets. Cleartext passwords, Kerberos tickets, TLS session keys, bearer tokens. Disk encryption does not protect them — they live decrypted in process memory.
3. State that disk never sees. Rootkit-unlinked processes, hidden network connections, kernel callbacks. Memory forensics is often the only path to them.
4. Anti-forensic resistance. A determined adversary can scrub MFT, Prefetch, EVTX and the USN journal. Scrubbing live memory without crashing the system is harder.

The 2026 toolset

For first-touch triage — confirm a process list, spot a hidden process, read a suspicious command line — you want something fast and friction-free. For deep timeline work, exotic kernels, or expert-only plugins, you want Volatility 3. The two complement each other; see the side-by-side tool comparison for when to reach for each.

A practical RAM forensics workflow

The full pipeline, condensed:

1. Acquire

• Windows. Magnet RAM Capture or DumpIt; write to external media; hash the output (SHA-256).
• Linux. LiME for on-host capture, AVML for cloud / hostile hosts.
• Virtual machines. Pause the VM, grab the .vmem. Already a raw physical image. See memory dump file formats for the formats that parse natively and the ones that need conversion.

Record time, source host, acquisition tool + version, image hash, examiner. The same hash discipline you apply to disk images applies here.

2. Triage

A fast first read before deep analysis:

• A process list, both live (pslist) and pool-scanned (psscan).
• The diff — psxview — to flag DKOM-style hiding.
• Command lines (cmdline) and loaded modules (dlllist) of anything suspicious.
• Network objects (netscan) to surface unexpected outbound connections.

ramparser runs this entire pass automatically on a dropped image. The dump never leaves the device, which matters for regulated environments. The memory analysis workflow covers what to do with the triage output.

3. Deep analysis

When triage flags something, move to Volatility 3:

• Timeline reconstruction (timeliner).
• Memory-mapped file analysis (vadinfo, vaddump).
• Process injection detection (malfind).
• Kernel callbacks and SSDT inspection.
• YARA rule scans over process address space.

4. Carve and corroborate

Run bulk_extractor over the raw image for strings, e-mails, URLs, and key material. Cross-reference with disk and network artefacts: MFT, USN journal, Prefetch, AmCache, Shimcache, EVTX. The strongest findings are confirmed in three places.

5. Report

Document acquisition, hashes, tool versions, and the chain of reasoning. A good memory report explains why a finding is what it is, not just what the plugin printed.

Common pitfalls

• Wrong profile. Old Volatility 2 needed exact profiles. Volatility 3 and ramparser pull symbols from the kernel itself — but you still need the matching kernel symbols for the build that was running.
• Crash dumps and hibernation files. Not flat physical memory. Convert with raw2dmp / hibr2bin first, or you will get garbage.
• Acquiring after reboot. The window closes fast. If you suspect memory evidence, capture before anything else.
• Uploading dumps. A RAM image can contain plaintext credentials and PII. Treat it like the most sensitive evidence in the case.
• Trusting pslist alone. DKOM-hidden processes will not appear. Always cross-check against psscan.

Where ramparser fits

ramparser is the triage stage. It loads the image client-side in a Web Worker, fetches the matching Microsoft PDB to get exact _EPROCESS offsets, and runs every applicable plugin automatically. No Python environment, no symbol pack management, no upload.

It is not a Volatility replacement — it is a frictionless first pass. When triage flags something interesting, switch to Volatility 3 for the deep dive.

Further reading

• pslist vs psscan vs psxview — finding hidden processes
• Memory dump file formats explained
• A browser-based Volatility alternative
• Memory forensics tools compared
• A memory analysis workflow that finds things