1. Introduction

Memory forensics with Volatility has become the reference technique for reconstructing security incidents when the attacker has managed to conceal their tracks on disk. Volatile memory holds information that no filesystem preserves: running processes, active network connections, malware fragments loaded in RAM and, very often, cleartext credentials. This article is a complete hands-on guide in which we carry out a real lab of memory forensics with Volatility on an image from a compromised Windows 7 SP1 x64 machine, infected through a Metasploit payload. During the lab we profile the memory dump, identify an injected process, extract NTLM hashes and rebuild the attack timeline for evidentiary purposes. Memory forensics with Volatility does not end when we obtain the data: it ends when we are able to defend every artifact in a rigorous, reproducible technical report.

2. Fundamentals of Memory Forensics with Volatility

The golden rule of incident response states that volatile data is acquired first and analyzed afterward. Memory forensics with Volatility starts from a memory dump that can be obtained in several ways: a virtual machine snapshot, the WinPmem utility, FTK Imager or the Windows debugging toolkit. The artifacts recovered from RAM are highly valuable: the process list with its arguments, open TCP and UDP sockets, loaded drivers, kernel objects and unencrypted passwords. Compared with disk analysis, memory offers two decisive advantages: the data is far harder to tamper with after the fact and it reflects the exact state of the system at the moment of the incident. A competent analyst combines memory forensics with Volatility with disk analysis, correlating every volatile artifact with persistent evidence and with the event logs. Available profiles cover Windows, Linux, macOS and Android, which makes this tool by far the most versatile in its category and a standard inside every DFIR laboratory, and it requires constant practice of memory forensics with Volatility on real cases.

3. Installing Volatility and Capturing the Memory Image

For the lab we used an Ubuntu 22.04 workstation with 16 GB of RAM and the memory.dmp image, 1.2 GB in size, exported from the compromised virtual machine. We started by installing Volatility 2.6.1, which keeps the classic syntax with the --profile parameter, and Volatility 3, the Python 3 rewrite that provides symbolic resolution of Windows structures. Installation is straightforward from the official repository, and correct acquisition is the half of memory forensics with Volatility that nobody can fix afterward:

$ git clone https://github.com/volatilityfoundation/volatility.git
$ cd volatility/
$ pip install distorm3 pycrypto
$ python vol.py --info | grep -i profiles | head -20

Fig. 1 – Verifying the Volatility 2.6.1 installation and listing the available Windows profiles (own lab).

Next, we acquired the memory of the virtual machine without stopping it, preserving the evidence in its original state, and we calculated the SHA-256 hash to maintain the chain of custody. The classic VirtualBox command is the following:

$ vboxmanage debugvm "Win7-Lab" dumpvmcore --filename memory.dmp
$ ls -lh memory.dmp
$ sha256sum memory.dmp | tee memory.dmp.sha256
c4b8e7a2d44f6b51a9c3d2e1f0a8b7c6d5e4f3a2b1c0d9e8  memory.dmp

This dump also contains the CPU registers, which allows recovering suspended kernel structures, a relevant detail for memory forensics with Volatility on virtual machines. We always worked on a copy, never on the original, to preserve the integrity of the evidence.

4. Image Profiling and Initial Reconnaissance

The first step of memory forensics with Volatility consists of determining the profile of the operating system contained in the dump. The imageinfo plugin analyzes kernel structures, such as the global descriptor table and the Directory Table Base space, and proposes the most likely profiles, the most routine phase of memory forensics with Volatility and also the most decisive. Once the profile is confirmed, we launch the first reconnaissance with pslist:

$ python vol.py -f memory.dmp imageinfo
Volatility Foundation Volatility Framework 2.6.1
Suggested Profile(s) : Win7SP1x64, Win7SP1x64_23418
AS Layer1 : WindowsAMD64PagedMemory (Kernel AS)

$ python vol.py -f memory.dmp --profile=Win7SP1x64 pslist
Offset(V)            Name         PID    PPID   Thds
0xfffffa8000bc9060   svchost.exe  2456   1116     12
0xfffffa8001f60400   svch0st.exe  3152   2456     12

Fig. 2 – The injected process svch0st.exe shown in the pslist output during the lab (own lab).

The comparison between pslist and psscan is the foundation of initial reconnaissance: while pslist walks the doubly linked list of EPROCESS blocks, psscan sweeps the memory pools and discovers processes that a rootkit may have unlinked. In our practice, Task Manager and pslist itself showed svch0st.exe as a child of svchost.exe, an obvious anomaly, and this type of discrepancy is precisely what memory forensics with Volatility is built to expose. The cross-check with psxview confirmed the discrepancy between sources, and the pattern was flagged as typical of Metasploit code injection. This orientation led us to the sockets and the injected memory space, detailed next. The double source check is the essence of memory forensics with Volatility.

5. Key Techniques: Network, Credentials and Malware in Memory

The next step of memory forensics with Volatility is correlating the network artifacts, the injected memory space and the stored credentials. Before jumping to the network layer we recommend expanding the reconnaissance with secondary plugins that cost nothing and add context: driverscan lists the loaded kernel drivers, many of which are a telltale symptom of kernel-level implants; svcscan enumerates Windows services and often exposes persistence entries that the process list alone does not reveal; and envars recovers the environment variables of every PID, which frequently include the working directory of the payload and the originating session. These checks complement memory forensics with Volatility by tying the injected process to its persistence mechanism, giving us the full attack chain instead of an isolated anomaly. The netscan plugin recovered an outbound connection toward IP 192.168.1.45 on port 4444, the default port of meterpreter payloads, while malfind located the memory region with the PAGE_EXECUTE_READWRITE flag typical of injection. dlllist also showed modules without a counterpart on disk, confirming the loading of a DLL directly from remote memory. With the scenario characterized, we proceed to extract credentials and the associated evidence:

$ python vol.py -f memory.dmp --profile=Win7SP1x64 netscan
$ python vol.py -f memory.dmp --profile=Win7SP1x64 malfind -p 3152 -D evidence/
$ python vol.py -f memory.dmp --profile=Win7SP1x64 hivelist
$ python vol.py -f memory.dmp --profile=Win7SP1x64 hashdump | tee evidence/hashes.txt
Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::

5.1. Extracting Credentials with Memory Forensics with Volatility

The NTLM hashes can be cracked with John the Ripper and rockyou, and it is worth checking for cleartext credentials via consoles or with memdump and a strings search. The following table summarizes the plugins we consider essential and the context in which each one should be applied:

Plugin	Purpose	When to use it
pslist	Enumerates processes from the EPROCESS list	Initial reconnaissance
psscan	Scans pools to find unlinked processes	When a rootkit is suspected
netscan	Recovers TCP/UDP sockets and active connections	Detecting C2 or exfiltration
malfind	Detects illegitimate injected memory	Confirming code injection
hashdump	Extracts NTLM hashes from the SAM registry	Acquiring and cracking credentials
timeliner	Builds the event timeline	Incident reconstruction

The recommended execution order is always the same: reconnaissance with pslist and psscan, network correlation with netscan, memory analysis with malfind and dlllist, and finally credential extraction with hashdump. This way, each result guides the next one and the coherence of the investigation is preserved. Cracking the NTLM hashes with John the Ripper closes the credential and persistence evidence that a well-executed memory forensics with Volatility must deliver, and demonstrates the real value of memory forensics with Volatility: the tool recovers exactly the secrets that the Metasploit payload steals in memory.

$ john --format=nt --wordlist=/usr/share/wordlists/rockyou.txt evidence/hashes.txt
$ john --format=nt --show evidence/hashes.txt
Administrator:Password1:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::

The memdump of the injected process and the string search over the raw dump also revealed the command and control URL and the persistence command added to the autorun registry key. Our lab thus reproduces every step of a real intrusion exactly as we would behave during a production incident, and it allows us to measure memory forensics with Volatility times as a maturity indicator for the team.

6. Automation with Volatility 3 and Report Writing

Volatility 3 simplifies the lab automation: it removes the manual profile and orders every module by operating system. We repeat the analysis by loading the dump only once:

$ python3 vol.py -f memory.dmp windows.pslist
$ python3 vol.py -f memory.dmp windows.malfind
$ python3 vol.py -f memory.dmp windows.timeliner --output=csv \
    --output-file=evidence/timeliner.csv

Fig. 3 – Automated analysis run with Volatility 3 and generation of the timeline in CSV format (own lab).

The forensic report must combine an executive summary, a technical section with every command executed and an evidence annex with integrity hashes for each file. The project is publicly available in the official Volatility 3 repository on GitHub, and the community maintains full documentation at volatilityfoundation.org. To complement the methodology we also recommend the incident response guides published by CISA on incident response, which include the evidence acquisition order we have applied. Log every command, UTC timestamp and result: reproducibility turns a technical analysis into admissible evidence, sealed by a rigorous, traceable memory forensics with Volatility.

7. Conclusion

In this lab we have verified that memory forensics with Volatility allows us to rebuild the entire intrusion even when the logs and files on disk were tampered with. We have covered the complete cycle, from profiling with imageinfo to the detection of injected processes, socket correlation, NTLM credential extraction and the final automation with Volatility 3. No incident should be closed without a documented memory forensics with Volatility. The methodology we applied fits directly into the workflows of an incident response team, but it demands constant practice: build memory forensics with Volatility into your runbook, repeat the lab with public dumps from DFIR challenges and document the chain of custody from the very first byte. When the first anomaly appears, the GDT, the DTB and the memory pools will speak for us; we simply need to have practiced before. Remember, too, that early RAM acquisition makes the difference between a resolved incident and an unreproducible breach.

Related articles: planning and designing technical audits for security assessments and intrusion footprint elimination and anti-forensics countermeasures.

Need help with Memory forensics with Volatility?

At Jaymon Security, we help organizations protect their systems. From security audits to SIEM/SOC implementation, our expert team designs custom solutions.

Contact us for a free infrastructure assessment.