RAM Dump Analysis with the Volatility Framework: A Practical Memory Forensics Guide

Disk analysis has its limits. An active attacker lives in memory without ever touching the file system; PowerShell scripts open in RAM, Cobalt Strike beacons inject into other processes via process injection, and a ransomware's encryption key often appears in memory only once. When the device is powered off, this evidence is lost entirely. This is exactly why, in modern digital forensics, memory forensics, that is, the analysis of memory, is just as critical an evidence layer as the disk image.

In this article we take a practical look at how analysis is performed on a RAM dump with the Volatility Framework, which commands extract which evidence, and what to watch out for in terms of reporting and chain of custody. If you have not yet read about the general digital forensics process, we recommend you first take a look at our article on the digital forensics process, KVKK, and the chain of custody.

What Is the Volatility Framework?

Volatility is an open source, Python-based memory analysis framework maintained by the Volatility Foundation. It reads RAM dump files taken from Windows, Linux, and macOS systems and parses dozens of artifact types such as the process list, network connections, registry hives, injected code fragments, and open file handles. It is one of the tools effectively accepted as a standard in academia and law enforcement alike.

The Rekall project, developed at Google, is an alternative forked from Volatility, but active development has largely shifted to the Volatility 3 side. NIST, too, emphasizes in its SP 800-86 Guide to Integrating Forensic Techniques into Incident Response document that volatile data should be collected before disk data, according to the "order of volatility" principle. RAM is always at the top of this list.

The Difference Between Volatility 2 and Volatility 3

There are two main versions of Volatility you will encounter in the field.

Volatility 2 (vol.py) was the de facto standard for many years. It was built on Python 2 and required you to select a separate profile (for example, Win10x64_19041) for each operating system version. Commands were written in the form --profile=... -f memory.raw pslist.

Volatility 3 (vol) was rewritten from the ground up in Python 3. You no longer need to supply a profile; the framework automatically recognizes the kernel symbols in the dump and fetches the relevant symbol package from the internet. The command syntax also changed: vol -f memory.raw windows.pslist. Plugin names come with an OS prefix (windows.netscan, linux.bash, mac.psaux).

In practice, new cases are run with Volatility 3. However, you will still see Volatility 2 in older reports, older examples, and some niche plugins. In this article we will show both syntaxes.

How Is a RAM Dump Taken?

The most critical step before analysis is to take the dump correctly and without altering it. ISO/IEC 27037 is the foundational international standard for the identification, collection, and preservation of digital evidence, and it explicitly states the priority of volatile data. The tools most commonly used in the field:

• FTK Imager (Windows): Free, GUI-based. With the "Capture Memory" option, it produces a .mem file. It also has an option to capture pagefile.sys; be sure to check it, because swapped-out fragments of processes may be there.
• DumpIt (Windows): A small, one-click command-line tool. It writes the system's entire physical memory to the directory it was run from, in .raw format. It is preferred when speed is needed at the scene.
• LiME (Linux): The Linux Memory Extractor, loaded as a kernel module. It is used in the form insmod lime.ko "path=/mnt/usb/memory.lime format=lime". It is the de facto standard on Linux servers.
• macOS: Because of Apple's SIP and kernel restrictions, taking raw memory has become harder in recent years. Generally, the hibernation file, swap, and version-specific tools are combined.

Immediately after the dump is taken, a SHA-256 hash should be computed, and the hash value should be written into the evidence record and the expert report. This is the fundamental way to prove in court that the evidence was not altered afterward.

Supported System Versions

As of Volatility 3:

• Windows: All common versions from XP to Windows 11, and from Server 2003 to Server 2022. While the profile list had to be updated manually in Volatility 2, Volatility 3 downloads symbols automatically.
• Linux: A kernel-specific symbol file (ISF, Intermediate Symbol File) is required. Community shares exist for most modern distributions; for custom kernels, you produce them yourself with dwarf2json.
• macOS: Partial support for Intel and Apple Silicon. Due to version and security policies, it is not always at the same level of maturity.

Core Commands and What They Do

The commands below are the "first half hour" routine of every case. We base this on the Volatility 3 syntax.

windows.pslist: The list of running processes, read from the kernel's EPROCESS chain. It gives the PID, PPID, start time, and thread count. You catch unexpected parent-child relationships here (for example, a powershell.exe spawned from winword.exe).

windows.pstree: The tree view of the same list. It is more useful for spotting parent-child anomalies in process injection and "living off the land" scenarios.

windows.psscan: It also scans for process structures that are allocated in memory but removed (unlinked) from the linked list. It exposes how malware using rootkits or the DKOM technique hides itself.

windows.netscan: Lists open TCP/UDP sockets, remote IPs, and the connected processes. This command catches a beacon talking to a C2 server. To map the IPs you detect to MITRE ATT&CK, the ATT&CK Matrix is very valuable; the techniques under the Command and Control tactic in particular are a good reference.

windows.malfind: Searches for pages that have execute permission but are not backed by the file system (that is, have no corresponding file on disk). It is the classic indicator of techniques such as reflective DLL injection, shellcode injection, and Cobalt Strike beacon placement. You can dump the discovered blocks to a file and submit them for static analysis.

windows.dlllist: Lists the DLLs loaded by each process. Libraries loaded from unexpected paths (%TEMP%, under AppData\Roaming, a DLL in the user profile) are suspicious.

windows.cmdline: The command-line arguments each process received when it was launched. You will see the use of encoded PowerShell (-enc), rundll32 javascript:, mshta http://, and certutil -urlcache style LOLBins here.

windows.handles / windows.filescan / windows.registry.hivelist: Open file handles, file objects in memory, and registry hives. Which Run key the attacker wrote to for persistence, which service they created, all of this you extract with the registry plugins.

On the Linux side, linux.pslist, linux.bash (users' shell history in memory!), linux.netstat, and linux.psaux serve the same functions.

Types of Memory Artifacts

If we categorize the evidence we look for in memory:

• Process and thread structures: EPROCESS, ETHREAD, tokens, integrity level.
• Network artifacts: Open sockets, DNS cache, ARP table, route information.
• Registry: Active hives; persistence keys such as Run, RunOnce, Services, AppInit_DLLs.
• File handles: Which process has opened which file/named pipe/mutex.
• Mutexes: Many pieces of malware use a fixed-name mutex to run as a single instance; these names act as signatures.
• Code loaded in memory: PE images, shellcode, JIT-compiled .NET assemblies.
• User data: Command-line history, clipboard, browser session tokens, passwords.

This diversity of artifacts offers a snapshot of the moment of execution that a disk image can never provide. Even if the attacker leaves no trace on disk and keeps all their code in memory, the mutex names, network connections, and process tokens give them away. This is why, in modern digital forensics training, knowledge of memory artifacts is no less important than knowledge of disk artifacts.

Detecting Mimikatz, lsass Dumps, and Credential Harvesting

The method attackers most frequently resort to for lateral movement on an internal network is extracting passwords, hashes, and Kerberos tickets from the lsass.exe (Local Security Authority Subsystem) process. In the MITRE ATT&CK framework, this behavior is recorded as the technique T1003.001 OS Credential Dumping: LSASS Memory.

With Volatility you can see the traces of this attack in memory from multiple angles:

• In the windows.pslist output, find the PID of lsass.exe. If there is another process opening lsass on the same system (procdump, taskmgr, rundll32 running with comsvcs.dll, Mimikatz's distinctive names), that is a very strong indicator. With windows.handles --pid <lsass_pid> you can see the other processes that have opened a handle to lsass.
• With windows.cmdline, search for rundll32 calls containing the comsvcs.dll, MiniDump argument; this command is the technique of dumping lsass using Microsoft's own DLL.
• In the windows.malfind output, suspicious code fragments injected into the lsass region may be visible.
• If Mimikatz was run, readable strings such as sekurlsa::logonpasswords, kerberos::list, and Mimikatz may be found in the memory region of the process that ran it; you can search for them with windows.strings.

If this detection is made, the incident is no longer a single-machine case. You need to switch to corporate response mode against the possibility of lateral movement; our cyber incident response (IR) playbook article walks through this process step by step within the NIST SP 800-61 framework. The SANS DFIR team's Digital Forensics and Incident Response publications also offer comprehensive references for credential-dumping detection.

Capturing the Ransomware Encryption Key in Memory

Most modern ransomware uses hybrid cryptography: files are encrypted with a symmetric key (AES), and this key is itself encrypted with the attacker's public RSA key and written to the file header. If encryption is still actively in progress after the symmetric key was generated, the key may still be alive in the process's heap or on the stack.

In practice the approach proceeds in this order:

1. The ransomware process is identified (pslist, pstree, malfind, cmdline).
2. With windows.memmap, a map of all the process's pages is produced.
3. With vol -f memory.raw -o ./out windows.dumpfiles --pid <pid> or windows.memmap --pid <pid> --dump, the process memory is exported to disk.
4. With bulk_extractor, yara, custom scripts, or decryptor projects published for known families, candidate AES keys are searched for in memory (high-entropy fixed-size blocks, AES key schedule patterns).

This process is open-ended; every ransomware family is different, and in most cases the key has already been zeroized. However, a RAM dump taken right in the middle of encryption is, in some cases, the only chance for recovery. This is why, in ransomware cases, it is vital to take RAM within the first 24 hours without shutting down the device, after isolating it from the network; we explain the topic in detail in our article the first 24 hours after ransomware.

Hash and Chain of Custody for the Forensic Report

No matter how technical memory forensics gets, discipline is required for the output to hold up in court. Practical notes:

• The moment the RAM dump is taken, SHA-256 (and SHA-1 in addition where possible) is computed; the hash, hardware serial number, the person who took it, and the date and time are written into the record.
• All analysis is performed on a copy of the dump; the original file is kept read-only.
• The full set of Volatility commands, version information, the symbols/profile used, the date run, and the hash information are placed in the report's appendix. This is essential so that another expert can reproduce the result.
• When interpreting the results, the conclusion reached through evidence is separated from expert opinion.

To see why this discipline is so critical, you can look at our article analyzing the patterns in which the Court of Cassation rejected expert reports; a missing hash, a non-reproducible analysis, and methodological ambiguity are among the most frequent reasons for rejection.

The DSET Approach

At DSET, we use Volatility 3 as the primary tool in memory forensics work, and we supplement it with Rekall and custom YARA rule sets when needed. Our typical workflow: standardized RAM dump acquisition (FTK Imager / DumpIt / LiME), stamping with SHA-256, write-blocked duplication, and then cross-analysis by two teams in parallel. We map the output to MITRE ATT&CK technique IDs and compare it against our CTI team's IOC database.

For each case, we extend Volatility's standard plugin set with our own scanners; for example, we run custom YARA rules over the process memory dump for the mutex lists of specific ransomware families, known C2 panel strings, and Cobalt Strike profile signatures. For the reproducibility of results, every command is logged together with version information and the hash value; this way it is always possible for a second expert to produce the same output. For memory-volatile evidence needs on the phone side, we address it together with the mobile DFIR approach in our article detecting the signs of spyware on a phone.

Frequently Asked Questions (FAQ)

1. Is the computer shut down when taking a RAM dump? No. The moment it is shut down, memory is erased. The device is kept on, isolated from the network, and the RAM and then the disk image are acquired.

2. Should I use Volatility 2 or Volatility 3? Volatility 3 is recommended for new cases. If you need to reproduce reports that require an old profile, Volatility 2 is still valid.

3. Is memory analysis meaningful if there is an encrypted disk? Yes, and in fact it is even more critical. The keys of systems such as BitLocker and VeraCrypt are present in memory while running; a dump taken while the device is unlocked can, in some cases, enable the disk encryption to be broken.

4. Can a RAM dump be taken from cloud VMs? Yes. A snapshot can be taken at the hypervisor level and the memory file exported separately; the method varies by cloud provider.

5. Is evidence from RAM analysis accepted in court? When the proper chain is maintained, yes. Compliance with the hash, record, write-block, and reproducibility requirements is essential.

6. Is it possible to take memory from macOS systems? To a limited extent. Apple Silicon and SIP restrictions have made the process harder in recent years; a version-specific tool is chosen.

7. Is Volatility output sufficient on its own? No. It must be cross-verified with disk, log, network, and EDR data; a single-source result has no evidentiary value.

8. How long does memory analysis take? A simple examination of a single machine takes 1-2 days; multi-machine cases in a corporate incident response can extend to weeks.

If You Need Memory Forensics

If you have gone through an active attacker, ransomware, or a suspicion of credential dumping, do not shut down the devices, disconnect them from the network, and reach out to an expert team. The DSET digital forensics team conducts Volatility-based RAM analysis and memory forensics services from its Hacettepe Teknokent, Ankara office.

Contact: +90 536 662 38 09

Even if the disk leaves no trace behind, memory speaks. A RAM dump taken at the right moment, with the right method, is in most cases the only piece of evidence that fully exposes the attacker.