Memory Forensics with Volatility

Why memory?
Capturing memory on Linux
Profiles: making the dump readable
Core plugins for Linux
A practical workflow
Limitations & caveats

When malware runs, it exists in memory before it ever touches disk — and often never touches disk at all. Fully fileless attacks live and die in RAM. That's why memory forensics can find what disk analysis never will: hidden processes, injected code, decrypted data, in-flight network connections, and the encryption keys protecting everything else. For a Linux examiner, Volatility is the standard tool for the job.

Why memory?

Malware packed to evade antivirus must still unpack somewhere to run — in RAM.
Processes can hide from ps/top (rootkits), but their structures still exist in memory.
Decrypted plaintext, passwords, and keys often remain in the memory of running processes.
Memory gives you the state of the system at capture time — what was running, what was connected.

Capturing memory on Linux

Capture must happen while the system is alive, with root privileges. The recommended method is LiME (Linux Memory Extractor), which produces a self-describing format Volatility reads directly.

# build the right module for the TARGET kernel
git clone https://github.com/504ensicsLabs/lime.git
cd lime/src
make            # run ON the target system

# load it, dumping straight to evidence media
insmod ./lime-$(uname -r).ko "path=/mnt/evidence/ram.lime format=lime"

# confirm
ls -lh /mnt/evidence/ram.lime
sha256sum /mnt/evidence/ram.lime

Capture first Memory capture must be the first action on the live system. Every subsequent command you run overwrites memory. Also make sure your evidence media has enough space — a 4 GB RAM box yields roughly a 4 GB dump.

Profiles: making the dump readable

Volatility needs to know the exact kernel to interpret the dump. With Volatility 2, you pass a --profile; with Volatility 3, detection is automatic. Using Volatility 3:

vol3 -f /evidence/ram.lime linux.pslist

# or explicitly:
vol3 -f /evidence/ram.lime linux.info.PsList

With Volatility 2 (still ubiquitous for Linux), profiles are per-kernel and built on the target system:

# on the target, using volatility's tools/linux module
cd /tools/volatility/tools/linux
make
zip /profiles/$(uname -r).zip module.dwarf System.map

# on the workstation, copy the zip into vol's symbols dir and list
python vol.py --info | grep -i linux

Core plugins for Linux

Plugin	What it gives you
linux.pslist	All processes from the kernel's process list
linux.pstree	Process hierarchy (parents — spot orphaned malware)
linux.psaux	Processes with their full command lines
linux.proc.maps	Memory mappings per process
linux.bash	Recovered bash history from bash process memory
linux.sockets / linux.netstat	Network connections at capture time
linux.check_syscall	Detects syscall table hooking (rootkit indicator)
linux.malfind	Finds executable memory that's not backed by a file
linux.dmesg	Kernel ring buffer contents
linux.lsmod	Loaded kernel modules

A practical workflow

# 1. orient yourself: processes & command lines
vol3 -f ram.lime linux.psaux

# 2. spot weird parent/child relationships
vol3 -f ram.lime linux.pstree

# 3. network connections at the moment of capture
vol3 -f ram.lime linux.netstat

# 4. look for injected / fileless code
vol3 -f ram.lime linux.malfind

# 5. check the syscall table for hooks
vol3 -f ram.lime linux.check_syscall

# 6. recover bash history fragments
vol3 -f ram.lime linux.bash

# 7. dump a suspicious process for offline analysis
vol3 -f ram.lime linux.proc -p 31337 --dump

Cross-check Memory and disk tell different halves of the story. A process listed in memory but absent from auditd/logs, or a socket connecting somewhere unexpected, deserves scrutiny. Correlate memory findings with logs and the timeline.

Limitations & caveats

Missing the right profile makes Linux dumps nearly unreadable — always note the exact kernel version at capture time.
LiME requires the exact target kernel headers to compile; precompile on a clone of the system when possible.
Analysis of a full dump is slow and RAM-hungry; allocate a workstation with 16 GB+ free.
Fileless malware may only exist for the duration of a single execution — memory evidence is timestamp-fragile.

For hands-on plugin examples, see the Volatility tool guide.

← Previous: Log Analysis · Next: Timeline Analysis with The Sleuth Kit →

Memory Forensics with Volatility

Contents

Why memory?

Capturing memory on Linux

Profiles: making the dump readable

Core plugins for Linux

A practical workflow

Limitations & caveats