Quick answer: Volatility is a free and open source framework for analyzing memory (RAM) dumps. Malware that never touches disk, encryption keys, running processes and open network connections exist only in memory, which makes memory analysis indispensable in modern examinations. The learning path: download a training dump, list processes (pslist and psscan), inspect network connections (netscan), hunt injected code (malfind), dump the suspicious process (dumpfiles, procdump) and tie it into a timeline. The critical rule: a memory dump must be taken before the device is powered off, because the moment you shut it down that evidence is gone.

The most common mistake in incident response is powering the machine off. It is done with good intentions, the plug is pulled "to stop the spread", and at that instant the most valuable evidence in the investigation disappears. The ransomware encryption key, malicious code running in memory that was never written to disk, the attacker's open session, all of it lives in RAM. This article explains why memory analysis matters and how to learn it with Volatility.

What is in memory that is not on disk

Disk is persistent, memory is volatile. That simple distinction has consequences:

  • Fileless malware. A significant share of modern attacks writes no file to disk and runs directly in memory through PowerShell or WMI. Disk examination cannot see it.
  • Encryption keys. BitLocker, VeraCrypt and ransomware keys are held in memory while running. A dump taken while the device is on may be the only way into a locked disk.
  • Running processes and injection. Code injected into a legitimate process is visible only in memory.
  • Network connections. The attacker's open connection to a command server exists in memory at that moment.
  • Clipboard data, decrypted passwords, open documents. Whatever the user has on screen is in memory.

Order of volatility: why memory comes first

International guidance defines an order of volatility. The evidence that disappears fastest is collected first:

  1. CPU registers and cache
  2. Memory (RAM)
  3. Network state and running processes
  4. Temporary files
  5. Disk
  6. Backups and archives

In practice: if the device is on and you have lawful authority, capture memory before shutting down. The disk image can wait, memory cannot.

How a memory dump is taken

Volatility does not capture dumps, it analyzes them. Capture is done with separate tools:

Platform Common tools
Windows FTK Imager (Capture Memory), WinPmem, Belkasoft RAM Capturer, DumpIt
Linux LiME (Linux Memory Extractor), AVML
macOS osxpmem and version dependent solutions
Virtual machine Snapshot or hypervisor memory file, the cleanest method

Virtual machines carry a subtlety: a memory file taken from the hypervisor is the least intrusive method because the guest operating system is never touched.

Volatility 2 or 3

There are two major versions and the difference confuses newcomers.

Volatility 2 is Python 2 based and uses profiles: you specify the operating system build manually, such as --profile=Win7SP1x64. Many older plugins and tutorials target this version.

Volatility 3 is Python 3 based and uses symbol tables instead of profiles, largely detecting the operating system itself. Command names changed too, adopting a namespace form such as windows.pslist.

If you are starting now, start with Volatility 3. Just be aware that much of the material you find online uses Volatility 2 syntax and commands will not map one to one.

Core plugins and what they are for

These form the backbone of an examination.

Plugin What it does Why it matters
windows.info Reports dump and system details Confirms you are working with the right dump
windows.pslist Lists processes from the linked list Gives the normal picture
windows.psscan Scans memory for process structures Finds hidden processes, a difference from pslist is a red flag
windows.pstree Shows processes as a parent child tree Anomalies such as Word launching PowerShell appear here
windows.cmdline Shows process command lines Catches encoded PowerShell commands
windows.netscan Extracts connections and listening ports Command server connections
windows.malfind Hunts suspicious memory regions and injection Catches fileless malware
windows.dlllist Lists loaded DLLs Detects sideloading
windows.handles Shows open handles Which files and keys were accessed
windows.filescan Scans file objects in memory Traces of files deleted from disk
windows.dumpfiles Extracts files from memory Recovering a malware sample for analysis
windows.registry.hivelist Registry hives in memory Persistence mechanisms

The logic of an examination

Rather than memorizing plugins, follow the question:

  1. What was running? Check pslist, then compare with psscan. The difference is a hidden process.
  2. Who launched what? Check pstree. An office application launching a shell is a classic warning.
  3. What commands ran? Check cmdline. Base64 encoded PowerShell surfaces here.
  4. Where was it connecting? Check netscan. A connection to an unknown address may be a command channel.
  5. Is there injection? Check malfind. Anonymous memory regions marked executable are suspicious.
  6. Extract the sample. Use dumpfiles, hash it and compare against threat intelligence.

Practice data and learning path

Memory analysis is learned only on real dumps. Lawful and free sources:

  • The Volatility Foundation list of sample memory images
  • NIST CFReDS reference data sets
  • DFRWS challenge files
  • Scenario based memory dumps published by Ali Hadi
  • Your own lab: run a harmless test tool on a virtual machine, capture the dump, then try to find it

Month one: learn what a normal system looks like with info, pslist, pstree, cmdline. To recognize the abnormal you must first know the normal. Month two: move to concealment techniques with psscan, malfind, netscan. Month three: merge your findings with disk and network evidence into a single timeline.

Common mistakes

  • Powering the device off. The most expensive mistake. Volatile evidence does not come back.
  • Writing the dump to the suspect machine's own disk. You contaminate the evidence. Write to clean external media.
  • Not hashing. The dump is evidence too and its integrity must be recorded with a hash.
  • Wrong version or profile. Running Volatility 2 commands on version 3 is the most common beginner obstacle.
  • Trusting a single plugin. A clean pslist does not mean a clean system, compare it with psscan.
  • Reporting findings without context. "This process existed" says nothing on its own, when and alongside what matters.

Frequently asked questions

Can Volatility capture a memory dump? No, it only analyzes. Use WinPmem, FTK Imager or LiME to capture.

Can memory be recovered from a powered off computer? No. However the hibernation file and swap space on disk may hold memory remnants, which are extracted through disk examination.

Can an encrypted disk's key be recovered from memory? A dump taken while the device is running and the volume unlocked may contain the key. This is one of the most concrete reasons to capture memory before shutdown.

Is Volatility 2 dead? Not dead, but development weight moved to 3. Unless you need older plugins, proceed with 3.

Does it support Linux and macOS? Yes, though setup is more involved than Windows because of the symbol table requirement.

Is memory analysis sufficient on its own? No. Memory is a single snapshot. It gains meaning when combined with disk, network and log evidence.

Sources

The first hours of an incident decide the outcome, and memory is the evidence that disappears fastest. For support or to plan hands on memory forensics training for your team, contact DSET. We provide 24/7 incident response from our Ankara Hacettepe Teknokent laboratory.