Malware Memory Analysis - Volatility

In the Acquiring Memory blog a list of tools that could be used to acquire the memory of a live system was listed. Once you have successfully acquire the memory of the system, a tool like volatility can be used to analyze the memory for data. In this assessment I will be evaluating the memory sample as a person that has no formal training in memory analysis or on how to use the tool to see if I can still use the tool to identify malicious code contain within the memory image. For this test the Zeus memory sample acquired from the Google Code – Volatility Memory Sample page will be used.

I will use practical troubleshooting steps to established my approach of analyzing the memory sample.

• Look for strange processes
• Look for strange network connections
• Check registry for strange entries added by the malicious code.
• Analyze suspicious code

Volatility

Here is the official description of the tool from the developer page:

“The Volatility Framework is a completely open collection of tools, implemented in Python under the GNU General Public License, for the extraction of digital artifacts from volatile memory (RAM) samples. The extraction techniques are performed completely independent of the system being investigated but offer unprecedented visibility into the runtime state of the system. The framework is intended to introduce people to the techniques and complexities associated with extracting digital artifacts from volatile memory samples and provide a platform for further work into this exciting area of research. “

http://code.google.com/p/volatility/

Installation

Installation of volatility is very simple. If you are using Windows, it just a matter of downloading the version you want and running the installer. For UNIX base systems, the hardest part of the installation may be determining where you want to extract the the source code after you download it. Once the source code has been extracted, your ready to use volatility. No compiling needed.
Note: There is one main requirement when it comes to using Volatility – python. You must have a working version of python installed on your system. If you are using an up to date UNIX base system to include OS X, you already have a working version of python installed on your system. Windows users may want to download and install the volatility standalone version. It comes with everything you need to use volatility including a runtime version of python. Check the download page on the volatility main website for more detail.

Using Volatility

Basic usage

Basic usage of volatility is as follows:


$ python vol.py [plugin] -f [image] –profile=[PROFILE]

The options after the “vol.py” command can be in any order as long as all like options are together. During my evaluation, I discovered that it was best to use the following order when running volatility from the command line. It allowed me to edit the last command ran from the command line easier.

$ python vol.py –profile=[PROFILE] -f [image] [plugin]

 

Volatility Commands

During this test I essentially reference the volatility command reference page which listed all the commands along with sample output of each commands. All similar commands are group together under the below section on the CommandReference page :

• Image Identification
  
• Processes and DLLs
  
• Process Memory
  
• Kernal Memory and Objects
  
• Networking
  
• Registry
  
• Crash Dumps, Hibernation, and Conversion
  
• Malware and Rootkits
  
• Miscellaneous
  

Command Reference Page: http://code.google.com/p/volatility/wiki/CommandReference
 

Step 1 - Image Identification

Having not capture the memory sample myself, it seem logical to run the plugin command “imageinfo” against the Zeus memory image to see what information the plugin can provide about the memory image.

python vol.py imageinfo -f zeus.vmem

The “imageinfo” plugin provided some valuable information such as the date and time of the image and local date and time of the system the memory was acquired. It also suggested which profile should be used when using the “--profile” option with volatility. The WinXPSP2x86 profile was the profile suggested to be used for this Zeus memory sample.

Step 2 - Looking for strange processes

Using the CommandReference page, I identify the plugin command to list the processes that were running in the memory sample when the memory was acquired.

python vol.py --profile=WinXPSP2x86 pslist -f zeus.vmem

At 1^st glance, there appears to be no strange processes running.

Step 3 - Looking for Strange Network Connections

The next step in my hunt for malware was to check the memory for any strange connections. Once again I used the CommandReference page to identify the plugin command to use to list all current network connections:

python vol.py –profile=WinXPSP2x86 connections -f zeus.vmem

Just my luck, no current connections were found. Well right under the “connection” plugin command on the CommandReference page was the command to scan for previous connections found in the memory - “connscan”. I tried that plugin command next.

python vol.py --profile=WinXPSP2x86 connscan -f zeus.vmem

Ahhh Yea, two connections found and now I just to learn more about the Remote Address. Using freegeoip.net website I enter the remote IP Address to learn the geolocaton of the IP.

Freegeoip.net http://freegeoip.net/static/index.html

Yes I agree that I could have just used ARIN to do a simple whois on the remote address, but I'm a visual person and I tell you that I love seeing that little green arrow pointing the possible geolocation of the Remote Address which in this case is in the Replublic of Moldova. It's so much cooler to look at then looking at the following:

Now we know where the Remote Address is located but this is not the only valuable piece of data we can acquire from “connscan” output. The “connscan” output also displays the process ID (PID) of the process that was associated with the connection to the Remote Address which happens to be PID 856.

Referring back to the output we got from the “pslist” plugin, we identify that “scvhost.exe” is the process that was associated with the connection to the Remote Address. According to the “plist” output we also see that the parent process ID (PPID) was 676 (services.exe) which in turn was started by PID 632 (winlogon.exe)

PID 632 winlogon.exe

       PID 676 services.exe

              PID 856 (svchost.exe)

                     Remote address: 193.104.41.75

Step 4 - Dump process

So from my previous outputs I have identified at least two processes that I want to take a closer look at “svchost.exe” and the process that started it “services.exe”. Using the volatility plugin command for dumping a process from the memory image - “procexedump” I proceeded to dump each process.

python vol.py --profile=WinXPSP2x86 -f ../zeus/zeus.vmem -p 856 procexedump -D ../zeus/

python vol.py --profile=WinXPSP2x86 -f ../zeus/zeus.vmem -p 676 procexedump -D ../zeus/

I submitted both processes that was dump by volatility to VirusTotals.com for analysis and received the following results:

svchost.exe analysis

The “svchost.exe” process had 1 detection by Emsisoft for Packed.Win32.Krap.g!A2 out of the 42 antivirus scanners that scanned the process.

Services.exe analysis

The “service.exe” process had no detection out of the 42 antivirus scanners that scanned the process.

Volatility also offers an additional plugin for dumping the process and it's slack space by using the plugin command “procmemdump”. I decided to dump the processes again using this option to see if my results would change.

Note: unless you specify a different output location or rename any previous PID process output, volatility will overwrite any process dumps with the same PID. I found this out the hard way LOL

Dumping the processes including slack space from memory

python vol.py --profile=WinXPSP2x86 -f ../zeus/zeus.vmem -p 856 procmemdump -u -D ../zeus/

python vol.py --profile=WinXPSP2x86 -f ../zeus/zeus.vmem -p 676 procmemdump -u -D ../zeus/

As before, I submitted the dumped processes to VirusTotal.com and this time the results were more interesting.

svchost.exe with slack space analysis

The “svchost.exe” process had 6 detection out of the 42 antivirus scanners that scanned the process.

Antivirus	Results
AntiVir	TR/Crypt.XPACK.Gen
CAT-QuickHeal	(Suspicious) – DNAScan
Comodo	UnclassifiedMalware
Emsisoft	Trojan.Crypt!IK
Esafe	Win32.TRCrypt.XPACK
Ikarus	Trojan.Crypt

Services.exe with slack space analysis

The “service.exe” process had 2 detection out of the 42 antivirus scanners that scanned the process.

AntiVirus	Results
CAT-QuickHeal	(Suspicious) – DNAScan
Symantec	WS.Reputation.1

So it appears that if you are going dump a process out of memory that it's best to use the “procmemdump” plugin as compare to “procexedump” plugin. Now I'm pretty satisfied that I was able to find some malicious code in the memory image but I don't really know how it got there. Maybe the registry can provide me with that answers.

STEP 5 – Search the Registry for signs of Malware

Now it time to search the registry for suspicious entries. I know of the normal places to search the in the registry for signs of malware such as “Run” keys but I decided to do a search on the Internet to see if there may actually be a list of the most used registry keys by malware and not to be disappointed, there was a list of the top 10 registry keys to look for signs of malware by F-Secure.

Top 10 Launch points

http://www.f-secure.com/weblog/archives/00001207.html

With list in hand now it time to use volatility to search the registry hives contained within the memory. Referring back to the Volatility CommandReference page, I identify the plugin command that would list the current registry hives in memory - “hivelist”. I used this plugin command to list the registry hives in my memory sample:

python vol.py --profile=WinXPSP2x86 -f ../zeus/zeus.vmem hivelist

From the output of the “hivelist” plugin, I see that the following registry hives are available:

• Software
• SAM
• System
• NTUSER.DAT

This is great because the hives that I need to review according to the F-Secure top 10 list are present.

Displaying values in the registry

I review all the registry key as suggested by the F-Secure list using the “printkey” plugin in the following convention:

python vol.py --profile=WinXPSP2x86 -f ../zeus/zeus.vmem printkey -o {virtual address} -K {regestry key}

• {virtual address} is the address acquired from the “hivelist” plugin.
• {registry key} is the path of the registry key you want to display the data value

After searching all the keys in the F-Secure top 10 list, only one actually had something suspicious. The “Microsoft\Windows NT\CurrentVersion\Winlogon” key.

python vol.py --profile=WinXPSP2x86 -f ../zeus/zeus.vmem printkey -o 0xe153ab60 -K "Microsoft\Windows NT\CurrentVersion\Winlogon"

The “Userinit” key seems to have an additional value added which will start at login - “sdra64.exe”. Since we do not have the actual system at hand that the memory sample was acquired to upload the sdra64.exe file to VirusTotal.com to be examine I performed a Google search on “sdra64.exe” to see what I could find. The Google Search returned over 56,400 results in just .25 seconds which many referred to the files as being the Zbot. I think I found the origin of the Zeus infection.