2010-11-18

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:

    1ident-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.

    2 processes

    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

    3hives

    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:

    4hivelist

    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 1st (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).

     

    5modules

    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:

    2010-11-18 13-29-18

    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:

    2010-11-18 13-32-25

    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.

    1 comment:

    lee woo said...

    Forgiving does not erase the bitter past. A healed memory is not a deleted memory. Instead, forgiving what we cannot forget creates a new way to remember. We change the memory of our past into a hope for our future. See the link below for more info.


    #memory
    www.matreyastudios.com