Volatility Memory Dump Analysis Tutorial on Kali Linux

After you capture a RAM image with FTK Imager, Volatility turns that dump into process lists, sockets, and command lines without booting the original machine. This lab uses the public Cridex Windows XP sample—a classic banking trojan training image—so every plugin output below comes from a known malicious baseline.

What is Volatility memory analysis in ethical hacking?

RAM captures volatile evidence that disk forensics misses: active connections, injected code, and command lines that never hit a log file. Volatility parses those dumps offline on your analyst workstation.

A typical investigation chain looks like this:

• Confirm OS version and symbol support
• List processes and parent-child relationships
• Compare process-listing plugins for hidden malware
• Recover network sockets and TCP connections
• Pull command lines and export suspicious executables
• Search process memory for fraud-related strings

The Cridex sample exercises that chain end to end. The suspicious binary reader_sl.exe mimics Adobe Reader while talking to external hosts on port 8080—behavior you would document before deeper malware analysis.

Compare Volatility 2 and Volatility 3

Kali Rolling ships Python 3 by default. Volatility 3 (pip install volatility3) is the maintained framework for modern images. The legacy Volatility 2 tree still matters for Windows XP labs like Cridex.

Volatility 3 windows.netscan does not support Windows XP 5.1 in release 2.28.0, so network and export steps in this walkthrough use Volatility 2 with the WinXPSP2x86 profile.

Kali lab setup

Create a working directory for the half-gigabyte sample and set variables every command will reuse.

Install python2 if it is missing (Volatility 2 requires it):

sudo apt update
sudo apt install -y python2

Download the public Cridex memory image (536 MB):

mkdir -p "$HOME/vol-lab"
curl -fL -o "$HOME/vol-lab/cridex.vmem" 'https://huggingface.co/datasets/jhenning/dfir-validation-data/resolve/main/cridex.vmem'

Point your shell at the dump and the XP profile Volatility 2 expects:

DUMP="$HOME/vol-lab/cridex.vmem"
PROFILE=WinXPSP2x86

The file should be exactly 536870912 bytes when the download completes. A much smaller file usually means an HTML error page instead of the RAM image.

Install Volatility 3 on Kali Linux

Volatility 3 installs cleanly in a virtual environment without touching system Python.

Create the venv and install the package:

python3 -m venv "$HOME/volatility3-venv"
"$HOME/volatility3-venv/bin/pip" install volatility3

Confirm the CLI responds:

"$HOME/volatility3-venv/bin/vol" -h

Sample output:

usage: vol [-h] [-c CONFIG] [--parallelism [{processes,threads,off}]]
           ...
An open-source memory forensics framework

Set a short alias for the rest of the lab:

VOL3="$HOME/volatility3-venv/bin/vol"

Volatility 3 is ready for windows.info and windows.psscan on "$DUMP".

Install Volatility 2 for the Cridex lab

Clone the legacy framework tree and run it with python2 from the repository directory.

git clone https://github.com/volatilityfoundation/volatility.git "$HOME/volatility2"

Check the version string:

cd "$HOME/volatility2" && python2 vol.py --version

Sample output:

Volatility Foundation Volatility Framework 2.6.1

Import warnings about distorm3 or Crypto.Hash may appear on Kali; core Windows plugins used in this guide still run. Install python3-pycryptodome if you need the optional envars plugin later.

Identify the OS with Volatility 3

windows.info replaces Volatility 2 imageinfo for quick kernel metadata. Run it before you trust any process plugin output.

"$VOL3" -f "$DUMP" windows.info 2>&1 | strings | grep -E 'NtMajor|NtMinor|NTBuildLab|SystemTime|Is64Bit'

Sample output:

NTBuildLab	2600.xpsp.080413-2111
SystemTime	2012-07-22 02:45:08+00:00
Is64Bit	False
NtMajorVersion	5
NtMinorVersion	1

NtMajorVersion 5 and NtMinorVersion 1 mean Windows XP. That matches the Cridex training scenario and tells you to pair Volatility 2 plugins with WinXPSP2x86.

Get the Volatility 2 profile with imageinfo

Volatility 2 still needs an explicit profile string for XP plugins.

cd "$HOME/volatility2" && python2 vol.py -f "$DUMP" imageinfo 2>&1 | strings | grep 'Suggested Profile'

Sample output:

Suggested Profile(s) : WinXPSP2x86, WinXPSP3x86 (Instantiated with WinXPSP2x86)

Use WinXPSP2x86 as "$PROFILE" for every Volatility 2 command below.

List processes with psscan and pstree

Start with Volatility 3 psscan, which finds process objects even when linked-list walkers miss them on older images.

"$VOL3" -q -f "$DUMP" windows.psscan 2>/dev/null | grep -E 'reader_sl|explorer'

Sample output:

1640	1484	reader_sl.exe	0x207bda0	...
1484	1464	explorer.exe	0x23dea70	...

reader_sl.exe with parent PID 1484 (explorer.exe) is the first anomaly—legitimate Adobe Reader side-load binaries are rare on a fresh XP lab image.

Build the tree with Volatility 2 pstree for a visual parent-child view:

cd "$HOME/volatility2" && python2 vol.py -f "$DUMP" --profile="$PROFILE" pstree 2>&1 | strings | grep -E 'reader_sl|explorer'

Sample output:

0x821dea70:explorer.exe                             1484   1464     17    415 2012-07-22 02:42:36 UTC+0000
. 0x81e7bda0:reader_sl.exe                           1640   1484      5     39 2012-07-22 02:42:36 UTC+0000

Record PIDs 1484 and 1640 for network, command-line, and export steps.

Check hidden processes with psxview

Malware sometimes unlinks itself from the active process list. psxview compares several enumeration methods side by side.

cd "$HOME/volatility2" && python2 vol.py -f "$DUMP" --profile="$PROFILE" psxview 2>&1 | strings | grep reader_sl

Sample output:

0x0207bda0 reader_sl.exe          1640 True   True   True     True   True  True    True

All True columns mean reader_sl.exe appears consistently across scanners—not a hidden unlink in this sample, but the check is still worth running before you close the process section.

Review network connections with connscan

Volatility 3 windows.netscan does not implement Windows XP 5.1 in 2.28.0. Use Volatility 2 connscan for TCP endpoints tied to PIDs.

cd "$HOME/volatility2" && python2 vol.py -f "$DUMP" --profile="$PROFILE" connscan 2>&1 | strings | grep 1484

Sample output:

0x02087620 172.16.112.128:1038       41.168.5.140:8080         1484
0x023a8008 172.16.112.128:1037       125.19.103.198:8080       1484

Explorer PID 1484 holds outbound connections to two remote addresses on port 8080. That is unusual for a desktop shell process and supports treating reader_sl.exe as malicious infrastructure rather than a benign Adobe component.

List the local listening socket with sockets:

cd "$HOME/volatility2" && python2 vol.py -f "$DUMP" --profile="$PROFILE" sockets 2>&1 | strings | grep 1484

Sample output:

0x82240d08     1484   1038      6 TCP             0.0.0.0         2012-07-22 02:44:45 UTC+0000

Paste the IP addresses, ports, and PIDs into your investigation notes before you export binaries.

Recover command lines with cmdline

cmdline shows the exact path Windows used to start each process—helpful when malware lives under a trusted vendor folder name.

cd "$HOME/volatility2" && python2 vol.py -f "$DUMP" --profile="$PROFILE" cmdline 2>&1 | strings | grep -A1 -E 'reader_sl|explorer.exe pid'

Sample output:

explorer.exe pid:   1484
Command line : C:\WINDOWS\Explorer.EXE
reader_sl.exe pid:   1640
Command line : "C:\Program Files\Adobe\Reader 9.0\Reader\Reader_sl.exe"

The Adobe Reader path is plausible to a user glancing at Task Manager, which is why memory forensics pairs process tree review with network and string analysis.

Export reader_sl.exe with procdump

procdump writes the in-memory PE image for offline hash lookup or sandbox analysis.

mkdir -p "$HOME/vol-lab/export"
cd "$HOME/volatility2" && python2 vol.py -f "$DUMP" --profile="$PROFILE" procdump -p 1640 --dump-dir="$HOME/vol-lab/export" 2>&1 | strings | tail -3

Sample output:

0x81e7bda0 0x00400000 reader_sl.exe        OK: executable.1640.exe

List the extracted file:

ls -lh "$HOME/vol-lab/export/executable.1640.exe"

Volatility names the export executable.1640.exe by default. Hash that file in your lab and compare results to vendor advisories—do not upload live malware to third-party scanners from unauthorized engagements.

Search process memory for banking strings

memdump captures the full address space of PID 1640. strings on that dump surfaces configuration text the trojan embedded for bank portal targeting.

Dump process memory:

cd "$HOME/volatility2" && python2 vol.py -f "$DUMP" --profile="$PROFILE" memdump -p 1640 --dump-dir="$HOME/vol-lab/export" 2>&1 | strings | tail -2

Sample output:

Writing reader_sl.exe [  1640] to 1640.dmp

Grep for financial host names:

strings "$HOME/vol-lab/export/1640.dmp" | grep -E 'chase\.com|tdbank|wellsfargo|bankofamerica' | head -10

Sample output:

*tdbank.com*
*chase.com*
*bankofamerica.com*
*wellsfargo.com*
*businessonline.tdbank.com*
*cashproonline.bankofamerica.com*

Those literals align with Cridex banking-trojan behavior documented in vendor research. They are strong report evidence that the sample targets online banking portals, not just generic spyware.

Troubleshooting

References

• Volatility 3 GitHub repository
• Volatility 2 GitHub repository
• Volatility Foundation memory samples wiki
• Symantec Cridex write-up

Summary

You walked through a full memory forensics lab on Kali using the public Cridex .vmem sample. Volatility 3 windows.info and windows.psscan identified Windows XP and surfaced reader_sl.exe under explorer.exe. Volatility 2 with WinXPSP2x86 carried the XP-specific work—pstree, connscan, cmdline, procdump, and memdump—because Volatility 3 network plugins do not cover this OS version in 2.28.0.

The investigation narrative matches what you would document in a case file: a fake Adobe Reader child process, explorer-owned C2 connections on port 8080, an executable export named executable.1640.exe, and banking host strings inside 1640.dmp. Those artifacts tie the RAM capture to credential-theft malware rather than a benign PDF helper.

For live acquisitions, start with FTK Imager RAM capture on authorized hosts. For broader passive recon before memory work, see the OSINT tools overview. Keep Volatility 3 as your default on modern Windows images, and keep Volatility 2 available when profiles and legacy plugins are still the fastest path through XP-era training dumps.