Volatility Memory Forensics II–Using Volatility

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.

Assumptions

To 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.

The versions tested for this article are:

• Volatility V1.3 SVN as of 2010-11-04
• yara 1.4
• yara-python-1.4a
• vap-0.1 (Volatility Analyst Pack)

Preparation

To 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 dump

Here is the command used:
python volatility ident -f /home/lgsec1/tmp/compta.bin
and here is the result:

Check processes

Volatility 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.

cd /usr/local/src/volatility/Volatility
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 entries

Next, we dump the in-core registry entries and examine the results for unusual / out-of-place values.

Find the hives in memory

Find 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
ntuser	0xe1a529f0…0xe1ef63a8
sam	0xe1bde008
security	0xe17e6008
software	0xe1ac5708
system	0xe10195d8

Format the hives’ content with regripper

One way to have all the output from the regripper commands is to run them inside screen:
cd /home/lgsec1/tmp
screen –RL
cd /usr/local/src/volatility/Volatility
my-perl-commands
exit
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 data

Basically 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 activity

Next possible step is to look at connections and sockets.

Connections

First 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

Sockets

Idem 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

Analysis

Essentially 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 1^st (normal) list, but are hidden in the system.

Modules and other objects in memory

Executable modules

This 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).

 

Then with google, can check all modules to see if look legitimate.

Files open for each process

Look 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.

Mutantscan

The 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 user

This 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.
Cmd follows:
python volatility getsids -f /home/lgsec1/tmp/compta.bin > /home/lgsec1/tmp/out-getsids

List all dlls for each process

To 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 process

To 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 names

Sometimes 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 time

Up 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.