Memory Dumps (Volatility)
Big dump of the RAM on a system. Use tools like volatility to analyze the dumps and get information about what happened
Last updated
Big dump of the RAM on a system. Use tools like volatility to analyze the dumps and get information about what happened
Last updated
When you get a big file (>1 GB) and its file type is just data, you might have your hands on a memory dump.
You can often find a lot of interesting strings with the strings tool, but there are often way too many strings to find anything useful. That's why we use tools like Volatility to analyze the data in these dumps and find interesting information like open processes, caches, and much more.
You can find an example challenge where the goal was to find 3 pieces of information about some malware that had run in the memory dump:
There are 2 versions of volatility. The first is the original volatility which is made for Python 2. In the rest of this page, I'll refer to it as volatility2. The second version is volatility3, made for Python 3. It is an improved version of the original, but some features/modules are missing. That's why you often work with both tools combined.
You should clone both Github repositories and then run the vol.py Python files to use the tools.
Both tools have a detailed help page with -h that shows all the available modules, and what they do. This page will also cover a few of the most important ones.
Tip: You can create a symlink to the vol.py script to easily access the tools from any directory with the vol2 and vol3 commands:
Volatility2 needs a profile to do its scans. This just tells the tool what operating system and version the dump was made in, so it can change the way it searches based on that. To find this profile there is a simple imageinfo module that analyzes the dump and tells what profile it thinks you should use.
If it can find a profile, it will show after Suggested Profile(s), and you need to use one of these in all future commands using the --profile argument.
Note: You can also use the kdbgscan module instead of the imageinfo module. This module is useful for the --kdbg argument that can help some modules function better. It finds KDBG address instead of just a profile, giving even more information to the modules. If you're having trouble with a module like pslist you can try running this scan and adding the argument (see this post)
By default both volatility Github repositories only contain Windows profiles. But you might get a memory dump from some Linux or Mac system. Luckily there are extra profiles you can download for these operating systems. Download the profiles below for volatility2 or 3:
The Linux profiles need to be placed into the volatility/plugins/overlays/linux source directory, and the Mac profiles to volatility/plugins/overlays/mac.
Do not copy all the ZIP files into these directories. It will try to load every single one and make volatility extremely slow. They suggest making educated guesses about what operating system the dump could have come from, and then only importing that individual ZIP file.
A good quick thing to do is to look at the running processes. From there you can often spot something suspicious to investigate further.
If you find a process that you haven't seen before or looks custom, you can extract the executable from memory and analyze it further as a file. Just provide the --pid you find in the process list and dump it into the current directory:
If you found any cmd.exe or powershell.exe processes, it might be worth checking what arguments they have to see what they are executing:
You might see a PowerShell process with the -EncodedCommand or /e argument, and a big random string. This is actually a Base64 and UTF16 encoded command that is executed in PowerShell, and you can use a CyberChef recipe for example to decode the command.
Environment variables sometimes contain secrets or other interesting information, so generally, it's a good idea to look at them. It will give a lot of results for all processes though, so you can filter them to a single process by providing a --pid.
Very often programs and malware need to communicate with some remote endpoint, and these network connections can also appear in the memory dump:
The Windows registry is a big list of keys and values. Some programs or malware use it to store settings/data that might be interesting to look at. You can extract the registry hives and specific keys from a memory dump:
Tip: Use the -o argument in any of these commands to get the information from a specific hive from hivelist. It needs the virtual address of the hive like -o 0x9aad6148. Otherwise, it will use all hives
Files often contain lots of information, especially on Linux where everything is a file. Memory dumps may contain interesting files that you can extract and take a look at. The idea is that you first list files to find interesting ones, and then extract some specific ones you find.
There are some specific things you can take a look at in-memory dumps that don't fit into a specific category. Here are some of them:
Surprisingly enough, you can even generate a screenshot of the system from only a memory dump. It can help give an idea of what applications are running in the foreground, and quite literally give a clearer picture of the system.
In Linux, it's possible to read the .bash_history file, but often this is disabled. With this module you can still recover the bash history from memory:
Similarly to a tool like Mimikatz, volatility can extract hashes and passwords from the memory dump:
Then after you get these hashes, you might be able to do some Pass-The-Hash attack or crack the password (see Cracking Hashes). Hashes you get from hashdump are NTLM hashes, where the 4th column is the actual hash. You can get the hashes formatted in a file like this:
