2010-11-19

Volatility Mem Forensics III–Using Volatility con’t

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.

This post continues the discussion of how to use Volatility. The strategy now shifts to looking for suspicious objects to obtain executable code samples that can be examined in detail.



Before we were generally 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.

With the next series of plugins, the strategy shifts to looking for suspicious objects, orphaned objects, objects that have installed hooks that are unusual, and so forth.

One of the main goals will be to locate executable code samples that can then be examined in detail:
  • run against Virustotal
  • submitted to your friendly AV vendor
  • reverse engineered.

Drivers

The following commands look specifically at drivers and driver-related hooks:

python volatility driverscan -f /home/lgsec1/tmp/compta.bin > /home/lgsec1/tmp/out-driverscan
python volatility driverirp -f /home/lgsec1/tmp/compta.bin > /home/lgsec1/tmp/out-driverirp

Google suspicious-looking drivers.
Check the driverirp list to verify that a legitimate driver function has not been hooked / hijacked by a malware. See http://mnin.blogspot.com/2009/07/new-and-updated-volatility-plug-ins.html for more information on this.

Kernel hooks, Usermode hooks

According to the plugin author’s blog (see http://mnin.blogspot.com/2009/12/new-and-updated-volatility-plug-ins.html ), the kernel_hooks and usermode_hooks plugins have been replaced by the api_hooks plugin that follows.

API hooks

The following commands look at userland api hooks in an attempt to automate detection of malware executables in memory.

python volatility apihooks -f /home/lgsec1/tmp/compta.bin –d ~/tmp/execs_apihooks > ~/tmp/out-apihooks
egrep –v “Memory Not Accessible” ~/tmp/out-api_hooks > ~/tmp/out-api_hooks-b

The second command scans kernel modules (instead of userland modules).

python volatility apihooks –k -f /home/lgsec1/tmp/compta.bin –d ~/tmp/execs_apihooks-k > ~/tmp/out-apihooks-k
egrep –v “Memory Not Accessible” ~/tmp/out-api_hooks-k > ~/tmp/out-api_hooks-kb

The egrep commands remove extraneous output to make it easier to read the output files.
Suspect executables can be sent to VirusTotal as usual (or reverse engineered with IDA Pro).

Unlinked Loader Modules

The explanation for this plugin is also found in the blog entry mentioned above. (See http://mnin.blogspot.com/2009/12/new-and-updated-volatility-plug-ins.html )

Here is the command:

python volatility ldr_modules -f /home/lgsec1/tmp/compta.bin > ~/tmp/out-ldr_modules

An example of the output follows:
2010-11-19 06-20-02

Here is how to read the above:
  • Counts in nLoad, and nMem should normally be equal
  • Count for nInit should be 1 less than the others.
  • If nMapped count is greater than nLoad / nMem, then there are 1 or more modules trying to hide.
A “-v” option can be used to see full detail for the three lists. Then you can investigate using vadinfo, vaddump plugins to get a dump of the hidden executable.

Threads

Orphan_threads
This plugin detects some specialized rootkits. The write-up is http://mnin.blogspot.com/2009/03/finding-tiggersyzor-infections-and.html

Here is the command:

python volatility orphan_threads -f /home/lgsec1/tmp/compta.bin > ~/tmp/out-orphan_threads

Note that the command needs to know the PID of the system process. However the default value (4) is usually a good choice.

The output lists the PID and TID (Thread ID).
The write-up for the orphan_threads plugin says that a thread is flagged if it doesn’t point back into the “normal” list of loaded drivers (ie plugin “modules”) . A thread (found via “thrdscan2”) that doesn’t point back into a module is flagged.

To find the actual module (/executable) for the thread, you could try the (more complete) lists from plugins “modscan” or “modscan2”.
Thread scans
As mentioned above, there are commands that attempt to enumerate all threads in memory.

python volatility thrdscan -f /home/lgsec1/tmp/compta.bin > ~/tmp/out-thrdscan
python volatility thrdscan2 -f /home/lgsec1/tmp/compta.bin > ~/tmp/out-thrdscan

These give similar output:
2010-11-19 06-24-10

The actual plugin code has the thread start address but doesn’t print it out.
The thread “start address” is contained in the ETHREAD ctl block. Either:
  • The corresponding memory could be manually dumped (to obtain the thread start address), or
  • The relevant code from orphan_threads could be modified to produce a new custom plug-in that prints start addresses for all threads.
Thread message queues
Another possibility for associating threads with executables is the “thread_queues” plugin.

Here is the command:

python volatility thread_queues -f /home/lgsec1/tmp/compta.bin > ~/tmp/out-thread_queues

And there is some sample output:
2010-11-19 06-26-27

Note that the hex values used to identify the threads are the PID / TID (decimal) values from the thread scan plugins.

The plugin author also notes (cf http://moyix.blogspot.com/2008/09/window-messages-as-forensic-resource.html ) that sometimes buggy applications pile up their message queues. This gives an indication of past state for the executable. To find what a given message means, see http://msdn.microsoft.com/en-us/library/ms644927.aspx#types

“suspicious” plugin

This simplistic plugin considers modules suspicious if a) they have the phrase “TrueCrypt” or b) the module name starts with a lowercase drive letter.

The writeup for this plugin is here: http://jessekornblum.livejournal.com/246616.html

Command to execute is:
python volatility suspicious -f /home/lgsec1/tmp/compta.bin > ~/tmp/out-suspicious

malfind2 plugin

Normal operation mode
This plugin scans memory for suspicious executables that might be malware.

Here is the command:

python volatility malfind2 -d ~/tmp/execs-malfind2 -f /home/lgsec1/tmp/compta.bin > ~/tmp/out-malfind2

Here are some sample outputs that are not interesting:
2010-11-19 06-30-24

Here are some more examples of actual malware being detected. This excerpt is taken from the blog article: http://mnin.blogspot.com/2009/07/new-and-updated-volatility-plug-ins.html
2010-11-19 06-32-10
2010-11-19 06-33-22
“Yara” scanning mode
The plugin can also interface with Yara to scan modules. The current problem is that there are very few Yara signatures available anywhere that I could see (2010-11-08). The plugin author explains how to create Yara signatures from ClamAV signatures in his book Malware Analyst’s Cookbook. See http://mnin.blogspot.com/2010_10_01_archive.html

To test this mode, I took the sample Yara signatures from the Yara wiki (http://code.google.com/p/yara-project ).

Here is the command used:

python volatility malfind2 -d ~/tmp/execs-malfind2-y -y ~/tmp/101108-yara-sigs -f /home/lgsec1/tmp/compta.bin > ~/tmp/out-malfind2-y

Note the “-y” parameter which points to the “Yara” signature file.
The current difficulty is to find Yara signatures. The new 

IDT (Interrupt Descriptor Table)

The IDT plugin dumps the IDT.

python volatility idt -f /home/lgsec1/tmp/compta.bin > ~/tmp/out-idt

Here is some sample output:
2010-11-19 06-39-36

The Interrupt 180 points inside some code that cannot be identified. Possibly the memory is not available. An attempt could be made to try to dump the memory at this address.

From the output, we see that interrupt 181 points inside ntoskrnl.exe, 193 points inside hal.dll.
The goal here is to look for hooks that point inside anomalous modules. If there was a rootkit hooked here, then the interrupt would point inside the rootkit code.

Note that:
if the system's KPCR is located at an address other than 0xFFDFF000 (see Brendan Dolan Gavitt's blog or Edgar Barbosa's paper), then you'll need to add the correct address to the script.”

Normally this should not be necessary.

SSDT (System Call Table)

The SSDT plugin helps audit the hooks into the System Call Table. The following blog article describes this plugin: http://moyix.blogspot.com/2008/08/auditing-system-call-table.html

Here is the command:

python volatility ssdt -f /home/lgsec1/tmp/compta.bin > ~/tmp/out-ssdt

The following command was used to eliminate most normal entries:

egrep -v "ntoskrnl.exe|win32k.sys" out-ssdt > out-ssdt-filt

Here is output showing a hook in place:

Entry 0x0035: 0xf87436f0 (NtCreateThread) owned by wpsdrvnt.

In the test I did, there were some entries mentioning ownership by “UNKNOWN”. It is not known at present if this is normal.

Next time

Next time, we wrap up by giving a final summary overview, and mention some odds and ends that can help things to go faster.

1 comment:

sarah lee said...

The suspicious mind believes more than it doubts. It believes in a formidable and ineradicable evil lurking in every person. See the link below for more info.


#suspicious
www.ufgop.org