Tag Archives: malicious code

Mar 16 2015
3 Comments
Digital Forensics and Incident Response, Malware Analysis

Memory Forensics with Volatility on REMnux v5 – Part 1

As threats and technology continue to evolve and malware becomes more sophisticated, the acquisition of volatility data and its forensic analysis is a key step during incident response and digital forensics. This article is about acquiring RAM from a disposable virtual machine before and after malware infection. This data will then be analyzed using the powerful Volatility Framework. The steps described here go hand in hand with the steps described on previous blog posts here and here about dynamic malware analysis.

We will use the methodology stated in previous post. We will start the virtual machine in a known clean state by restoring it from a snapshot or starting a golden copy. Then we will suspend/pause the machine in order to create a checkpoint state file. This operation will create a VMSS file inside the directory where the virtual machine is stored. Then we will use a tool provided by VMware named Vmss2core to convert this VMSS file into a WinDbg file (memory.dmp).  From VMware website: Vmss2core is a tool to convert VMware checkpoint state files into formats that third party debugger tools understand. Last version is available here. It can handle both suspend (.vmss) and snapshot (.vmsn) checkpoint state files as well as both monolithic and non-monolithic (separate .vmem file) encapsulation of checkpoint state data. This tools will allow us to convert the VMware memory file into a format that is readable by the Volatility Framework.

Next, we restore the virtual machine to back where it was and we infect it with malware. After that, we suspend the machine again and repeat the previous steps. This allow us to have two memory dumps that we can compare against each other in order to facilitate the finding of malicious code.

memory-analysis-2To perform the analysis and the memory forensics we will use the powerful Volatility Framework. The Volatility Framework born based on the research that was done by AAron Walters and Nick Petroni on Volatools and FATkit. The first release of the Volatility Framework was released in 2007. In 2008 the volatility team won the DFRWS and added the features used in the challenge to Volatility 1.3.  Seven years have passed and this framework has gained a lot of popularity and attention from the security community. The outcome has been a very powerful, modular and feature rich framework that combines a number of tools to perform memory forensics. The framework is written in Python and allows plugins to be easily added in order to add features. Nowadays it is on version 2.4, it supports a variety of operating systems and is being actively maintained.

Below the  steps needed to acquire the RAM data for a VMware virtual machine:

  • Restore the VMware snapshot to a known clean state.
  • Pause the Virtual Machine
  • Execute vmss2core_win.exe
  • Rename the memory.dmp file to memory-before.dmp
  • Resume the virtual machine
  • Execute the malware
  • Pause the virtual machine
  • Execute vmss2core_win.exe
  • Rename the memory.dmp file to memory-after.dmp

The following picture ilustrates the usage of Vmss2core_win.exe.

memory-analysis-3

After performing this steps we can proceed to the analysis. First we move the memory dumps to REMnux. Then we start the Volatility Framework which comes pre-installed. We start our analysis by listing the process as a tree using the “pstree” module on both the clean and infected memory image. With this we can benchmark the infected machine and easily spot difference on infections performed by commodity malware.  In this case we can easily spot that on the infected machine there a process named explorer.exe (PID 1872) that references a parent process (PPID 1380) that is not listed. In addition we can observe the processes vssadmin.exe (PID 1168) and iexplorer.exe (PID 1224) which were spawned by explorer.exe.  Vsadmin.exe can manage volume shadow copies on the system. This strongly suggests that we are in presence of something suspicious.

memory-analysis-4

 

Next step is to do a deep dive. During the previous dynamic malware analysis articles series were we analyzed the same piece of malware we were able to extract indicators of compromise (IOC). These IOC’s were extracted  from our analysis performed at the network level and system level. We will use this information for our own advantage in order to reduce the effort needed to find Evil. We knew that after the infection the malware will attempt to contact the C&C using a HTTP POST request to the URL topic.php which was hosted in Russia.

Let’s use this pieces of information to search and identify the malicious code. To perform this we will look for ASCII and UNICODE strings that match those artifacts using src_strings utility that is part of The Sleuth Kit from Brian Carrier and is installed on REMnux.

memory-analysis-5

The  parameter “-t d” will tell the tool to print the location of the string in decimal. We save this findings in a text file. The results are  then used by Volatility. Next, we invoke Volatility and use the “strings” plugin that can map physical offsets to virtual addresses – this only works on raw memory images and not on crash dumps – . It works by traversing all the active processes  and is able to determine which ones accessed the specified strings.  In case of a match we will have a good hint on where the malicious code might reside. In this case the plugin is able to match the strings with the process ID 1872 on two different virtual addresses.  This corroborates the fact that on the previous step we saw this process without a parent process which was rather suspicions . Another clue that we might be in good direction.

memory-analysis-6

This can be easily confirmed by listing the process ID 1872 using the “pslist” module.   Given this fact we proceed with the extract of this process from memory to a file using the “procmemdump” plugin. Volatility Framework is so powerful that it can parse PE headers in memory and carve them out. With this plugin we can dump the process executable using its PID.  After extraction we can verify that the file commands correctly identifies the file as a PE32 executable. Then we can verify that the string we found previous is indeed part of this process.

memory-analysis-7

Well, looks like the string “topic.php” is not in the data we just extracted. However, as we could see in the previous analysis steps we determined that the actions performed by the malicious code were in the context of this process. Furthermore, during the basic static analysis performed (see previous post) on the malicious executable we saw that it references very few libraries but two of them were noteworthy. The LoadLibrary and GetProcAddress.  This suggest the malicious executable was either packed or encrypted. In addition those libraries suggest that  malicious code was injected into a process.  There are several techniques used by threat actors to inject malicious code into benign processes. I will expand on this techniques on a different blog post. As conclusion we might be looking at malicious code that was injected in the process explorer.exe (PID 1832) and is somehow concealed. This means we will need to look deeper into the obscure and fascinating world of memory forensics. Part two will follow!

 

Malware sample used in this exercise:

remnux@remnux:~/Desktop$ pehash torrentlocker.exe
file:             torrentlocker.exe
md5:              4cbeb9cd18604fd16d1fa4c4350d8ab0
sha1:             eaa4b62ef92e9413477728325be004a5a43d4c83
ssdeep:           6144:NZ3RRJKEj8Emqh9ijN9MMd30zW73KQgpc837NBH:LhRzwEm7jEjz+/g2o7fH

References:

Ligh, M. H. (2011). Malware analyst’s cookbook and DVD: Tools and techniques for fighting malicious code.
Zeltser, Lenny (2013) SANS FOR610: Reverse-Engineering Malware: Malware Analysis Tools and Techniques

Tagged , , , ,
Feb 27 2014
2 Comments
Malware Analysis

Reverse-Engineering and Malware Analysis

malwareLast year I had the chance to go to SANS Orlando 2013 in Orlando, Florida – thank you Wes! – which is one of the yearly’s biggest SANS conferences only outpaced in size by SANS FIRE in Baltimore, Maryland.  I went there to take the 5 days course – FOR 610 Reverse-Engineering Malware: Malware Analysis Tools and Techniques – with Lenny Zeltser. Apart of the course the main choice was due to the instructor. Lenny is a brilliant fellow and top rated SANS instructed. Awesome writer and fantastic lecturer.

I was very enthusiastic about taking out the most of it. One reason was  because I had read the Malware Fighting  Malicious Code book from Ed Skoudis where Lenny wrote chapter 2 and 4.  This book is 10 years and it’s still a classic, a historical object and definitely a must read to someone who is part of the security community. Other reason was that l wanted to get the skills to be capable of securely analyze, debug, and disassemble malicious programs in order to translate this capability into actionable threat intelligence.

On the first day of the training we got introduced to 2 approaches to examine malicious programs. Behavior analysis and static/code analysis. To perform this we started by setting up a controlled and isolated environment. A simple and inexpensive malware analysis lab running on VMware. Using this lab we used a set of free tools that allowed us to determine what the malicious program does and how it interacted with the file system, network, registry and memory. We also got introduced to REMnux . A lightweight Linux distribution for assisting malware analysts with reverse-engineering malicious software. The distribution is based on Ubuntu and is maintained by Lenny Zeltser.  Using a set of Windows tools, the REMnux distro plus a variety techniques we  got a better understanding how we could analyze malware and determine its capabilities.  Then we got deeper in order to make a detailed analysis of the malware by using reverse engineering tools and different methods. By using techniques to find strings in the executable, run a disassembler (IDA Pro),  load the executable into a debugger (OllyDbg) and execute it and look at the API calls being made we got a glimpse in the world of code analysis. After the lab was set and we got an understanding of the processes we will follow the fun started! With several hand-on labs and different specimens we observed what the malware does and we could document the findings and translate them into indicators of compromise and actionable intelligence that can be used to proactively detect and monitor threats.

Day two started with additional malware analysis approaches. We started to get introduced into packed executable’s and what patching means. Also we unpacked malicious executables using simple packing techniques. Here is where we began the journey on x86 Intel assembly. On the second half of day two we covered browser malware and flash based malware and how to use REMnux to use behaviors and code analysis techniques to analyze web malware. It was impressive to see the amount of ingenious techniques enforced by the bad guys to deliver malicious stuff.

Day three is a deep dive into malicious code analysis. Its starts with core reversing engineering concepts and you spend the rest of the day playing with malicious code at the assembly level. It’s the all day looking at a dissasembler and a debugger. Throughout the material and the exercises you get more and more exposed to x86 assembly stuff. We manage to use the debugger to control malicious program execution (step in, over, breakpoints) and monitor or change its state (registry and memory).   On this day we also covered user mode rootkits, key loggers, sniffers, DLL injection and downloader’s – great stuff!

Day four, even after 10 hours sleep I doubt I had enough processing power on my neurons to absorb all Lenny had to say. As complementary strategy I gave a lot of use to my pencil and wrote as much notes as possible in my courseware material. During the first half of the day we were shown the techniques that the malware writes use to protect their programs. Packing was one. But more complex techniques such as anti-disassembly, anti-debugging and anti-VMware and others were demonstrated. It’s an extraordinary arms race between good and evil. A huge amount of hands on exercises were made so we could reinforce all these concepts and techniques. Was also amazing to see Lenny describing how different malware specimens use mazes of code and junk code to frustrates the analyst and mislead him. By enforcing this techniques, in case the analyst does not have enough resources (time/money) he will soon stop doing his analysis and move on to something else – Evil will win – an interesting trade-off. Apart of the techniques we were taught different techniques to bypass those malware defenses. One example was to infect a system with a piece of malware that was packed/obfuscated. When execute, the malware  loaded its unpacked code into memory which allowed us to examine it. By staying resident in memory because in the file system it was encrypted we used techniques do dump it from memory. To do this we used Chimprec to extract the process from memory and then rebuilding its  PE header import table in order to be executed. Other technique was the usage of a debugger to patch an executable to avoid anti-debugging mechanism. Other tools like LordPE and OllyDump are also used. On the second half of the day, shellcode analysis and Web malware anti-deobfuscation techniques were described and practiced.

Finally on day 5 we spent the first half of the day learning the techniques and tools for analyzing malicious Microsoft Office (Word, Excel, PowerPoint) and Adobe PDF documents. The second half of the day is spent on memory analysis forensics with the help of Volatility Framework and associated plug-ins. The course ends with explanation of the different techniques used by root kit infections and its deceptive techniques and how you could use memory and code analysis to determine and un-hide their capabilities.

The course is extremely technical and deep and very hands-on. I was overwhelmed with the amount of information. After day 3 I was feeling like I was drinking from the fire hose. The course is part of the SANS digital forensics and Incident response curriculum. It is very well structured and the sequential steps it follows are very well thought out.

This particular security field is a very interesting one, it will continue to evolve and it is challenging. Also as the security industry continues to progress from a reactive approach to a more proactive one, the malware analyst type of skills will have an increased demand. More and more companies are funding their own threat intelligence operations with this kind of capability in-house.

If you are an incident handler, sysadmin, researcher or simple want to be the next digital Sherlock Holmes you may also want to look into the Malware Analyst’s Cookbook and DVD: Tools and Techniques for Fighting Malicious Code book and the Practical Malware Analysis. Other relevant and free resources are the Dr. FU’s Security blog on Malware analysis tutorials. Thet Binary Auditing site which contains free IDA Pro training material.  Finally, the malware analysis track  in the Open Security Training site is awesome. It contains several training videos and material for free.

Tagged , , , ,