2011-4-27 Update: The following is for Volatility 1.3. You should be looking at Volatility 1.4. See blog entry on the subject.
Ok. Having read the previous posts, Volatility is now installed, and you have taken a raw memory dump. This post describes how to use Volatility.
Why yet another blog article on Volatility?In doing my research, I found one good summary overview paper available on the Volatility googlecode website http://code.google.com/p/volatility/ Look in the downloads section for “How to use Volatility_V2.pdf:.
I found however that the above paper was slightly dated. Also the various plugin authors each seemed to have their own style of doing things which complicated things when trying to use the plugins effectively.
So I researched each plugin author’s post concerning their plugins, and have tried here to produce a useful summary of this research.
Emphasis is on giving a “how to” recipe; technical details are left aside voluntarily.
AssumptionsTo be specific, this post assumes the following:
- You are not a Windows Guru with intimate knowledge of Windows internals / memory dumps / debuggers.
- Are using a Ubuntu linux OS.
- Volatility SVN ("trunk") version has been downloaded from code.google and installed as documented in accompanying installation recipe.
- All the Volatility plugins have been installed.
- The raw Memory image is from Windows XP SP2 or 3. Win7 support will come in a future version of Volatility now under development at time of writing.
- Volatility V1.3 SVN as of 2010-11-04
- yara 1.4
- vap-0.1 (Volatility Analyst Pack)
PreparationTo prepare, the raw binary memory image should be in its case folder. If this was a hiberfil.sys, or Windows crash dump, it should be converted to raw format using the Moonsol utility.
Identify the dumpHere is the command used:
python volatility ident -f /home/lgsec1/tmp/compta.bin
and here is the result:
Check processesVolatility has a number of plugins to list the executing process modules. One works by looking for the processes by following the chain of control blocks. The others scan the physical memory for process control blocks.
Once the output is obtained, then I used emacs to sort the information by process names. Finally all three listings were compared to search for anomalous (ie “weird” names) / hidden processes (ie not showing up on all listings).
Finally all process names were checked in google to determine if they were legitimate.
Here are the commands used. The first command takes the normal route through the ctl blocks to list the processes. The “scan” plugins scan all through memory looking for things that might be process ctl blocks in an attempt to locate processes that are trying to stealth themselves.
python volatility pslist -f /home/lgsec1/tmp/compta.bin > /home/lgsec1/tmp/out-pslist
python volatility psscan2 -f /home/lgsec1/tmp/compta.bin > /home/lgsec1/tmp/out-psscan2
python volatility psscan3 -f /home/lgsec1/tmp/compta.bin > /home/lgsec1/tmp/out-psscan3
Dump the in-core registry entriesNext, we dump the in-core registry entries and examine the results for unusual / out-of-place values.
Find the hives in memoryFind the hives in memory with this command:
python volatility hivescan -f /home/lgsec1/tmp/compta.bin
Then use the first hive offset as indicated to find the hives in memory:
Here is the command used:
python volatility hivelist -f /home/lgsec1/tmp/compta.bin -o 0x51595d8
with the following result:
These offsets are then used for the modified regripper commands to dump the registry contents.
Each type of hive has a corresponding “macro” command in rrplugins. See the table just below:
So from the above output, the offsets to use would be:
|Type of Hive||Offset|
Format the hives’ content with regripperOne way to have all the output from the regripper commands is to run them inside screen:
mv screenlog.0 my-output-file
Probably it would be best to have a separate file for each type of hive.
Here are the actual perl commands. Note the syntax used to specify the offset for the corresponding hive. (See the above table for the actual offsets.)
perl ./rip.pl -r /home/lgsec1/tmp/compta.bin@0xe1a529f0 -f ntuser
perl ./rip.pl -r /home/lgsec1/tmp/compta.bin@0xe1ef63a8 -f ntuser
perl ./rip.pl -r /home/lgsec1/tmp/compta.bin@0xe1bde008 -f sam
perl ./rip.pl -r /home/lgsec1/tmp/compta.bin@0xe17e6008 -f security
perl ./rip.pl -r /home/lgsec1/tmp/compta.bin@0xe1ac5708 -f software
perl ./rip.pl -r /home/lgsec1/tmp/compta.bin@0xe10195d8 -f system
Analyzing registry dataBasically are looking for anomalous values. Sometimes the regripper plugins indicate what value should normally be present.
Note that there is one NTUSER hive for each user. Content is very rich and shows files accessed, pgms run, etc.
The SOFTWARE hive is useful to see installed software, software execution paths, etc.
There are 2 regripper plugins in the rrplugin directory that are not referenced:
|mountdev2.pl||Is the same as mountdev.pl except that uses perl encode pkg for foreign language encoded strings.|
|sfc.pl||Reports on “system file checker” utility settings. This is a Microsoft “Tripwire”-like utility.|
Network activityNext possible step is to look at connections and sockets.
ConnectionsFirst look at connections.
Here are the commands used:
python volatility connections -f /home/lgsec1/tmp/compta.bin > /home/lgsec1/tmp/out-connections
In my test, I didn’t get any output from connections.
python volatility connscan2 -f /home/lgsec1/tmp/compta.bin > /home/lgsec1/tmp/out-connscan2
SocketsIdem for open sockets.
Here are the commands:
python volatility sockets -f /home/lgsec1/tmp/compta.bin > /home/lgsec1/tmp/out-sockets
python volatility sockscan2 -f /home/lgsec1/tmp/compta.bin > /home/lgsec1/tmp/out-sockscan2
AnalysisEssentially we are looking for a connection to an unusual IP address, or using an unusual port.
Also are looking for connections / sockets that don’t show up on the 1st (normal) list, but are hidden in the system.
Modules and other objects in memory
Executable modulesThis looks at executable modules in memory.
Here are the commands:
python volatility modules -f /home/lgsec1/tmp/compta.bin > /home/lgsec1/tmp/out-modules
python volatility modscan2 -f /home/lgsec1/tmp/compta.bin > /home/lgsec1/tmp/out-modscan2
To compare, I sorted with emacs, then ran ediff-buffer3 to look for unmatched entries (which could be something trying to hide itself).
Files open for each processLook at the files open for each process. Cmds follow:
python volatility files -f /home/lgsec1/tmp/compta.bin > /home/lgsec1/tmp/out-files
Files gives its information by pid.
python volatility fileobjscan -f /home/lgsec1/tmp/compta.bin > /home/lgsec1/tmp/out-fildobjscan
I used emacs to sort the fileobjscan information by filename in order to speed up examination. Even on a small lightly loaded PC, there are a lot of files that are opened.
MutantscanThe document mentioned above (“How to use Volatility_v2.pdf”) has a good writeup on mutexes as well as how to use this plugin.
Here is the command:
python volatility mutantscan -s -f /home/lgsec1/tmp/compta.bin > /home/lgsec1/tmp/out-mutantscan
Note the use of the “-s” switch to turn off output of nameless mutants.
One thing to do is to search for abnormal mutex names. Among other things, malware uses mutexes to ensure that only one copy of an infection runs. Other malware may set a mutex to stop competing malware from infecting the system.
Here is some sample output:
List SIDs for each userThis maps the Window SIDs to executing processes.
“How to use Volatility_v2” explains that to map SIDs to userids, look in the registry – Profile list (Software Hive). Gives user SIDs along with location of profile on disk. Username can be inferred from the profile disk name.
python volatility getsids -f /home/lgsec1/tmp/compta.bin > /home/lgsec1/tmp/out-getsids
List all dlls for each processTo list the dlls for each process:
python volatility dlllist -f /home/lgsec1/tmp/compta.bin > /home/lgsec1/tmp/out-dlllist
Shows the command line used to start the process (including services) as well as all the DLL libraries for the process. Look for strange DLLs that have been injected into legitimate processes, and DLLs with suspicious looking names.
List open registry keys for each processTo list the open registry keys for each process:
python volatility regobjkeys -f /home/lgsec1/tmp/compta.bin > /home/lgsec1/tmp/out-regobjkeys
This is good documentation to have in order to confirm a specific infection vector.
Symbolic link namesSometimes the symbolic link objects can point to the existence of a rootkit or malware.
Here is the command used:
python volatility symlinkobjscan -f /home/lgsec1/tmp/compta.bin > ~/tmp/out-symlinkobjscan
To make the output more readable, I sorted it as follows:
sort -k10 < out-symlinkobjscan > out-symlinkobjscan-tri
This plugin is documented here: http://computer.forensikblog.de/en/2009/04/symbolic_link_objects.html
Again the goal is to spot anomalies. Here is some sample output:
Next timeUp to this point, the emphasis has been on listing items, and looking for anomalies that could indicate possible malware: eg system executable loaded from wrong directory, obscure or encoded values where there shouldn’t be, and so forth.
The article next time will describe the last series of plugins. With these plugins, the strategy shifts to looking for suspicious objects, orphaned objects, objects that have installed hooks that are unusual, and so forth.