Carving malware from live memory November 17, 2009Posted by lvdeijk in Uncategorized.
After spending some time in our laboratory, experimenting with some ruby scripts for the metasploit framework, I conducted a small experiment. I was wondering what if I could carve files out of memory-dump files ?! It could be possible to carve out portable executables/malware as well. This write-up demonstrates what I did.
How to get malware
Getting infected with malware these days is simple. Just put an unpatched home PC online and you are bound to get infected with one ore more pieces of nasty code.
As easy as this is, collecting malware for further analysis in a laboratory environment requires some other type of machine.
Collecting malware, trojans, irc-bots, worms and other type nasties to study their behavior in a safe and controlled environment requires computer systems called honeypots.
A honeypot designed for collecting malware is a machine that emulates different operating systems weaknesses to deliberately convince malware to think that it has a potential target. So, without getting infected, you can “catch” the offered malware for further analysis.
Honeypots are divided into low or high interaction honeypots.
- Real services, OS/s, or applications
- Higher Risk
- Hard to deploy and maintain
- Capture extensive amount of information
- Emulation of TCP/IP stack, vulnerabilities and so on
- Lower risk
- Easy to deploy and maintain
- Capture quantitative information about attacks
There are several honeypots for free available on the Internet.
I have had good results with the Nepenthes honeypot (http://nepenthes.carnivore.it/) which is a low interaction solution.
A great resource about honeypots is “Virtual Honeypots” by Niels Provos and Thorsten Holz (ISBN 978-0-321-33632-3)
As described in this book both type of honeypots have advantages and disadvantages.
Malware, what does it do ?
A quick and simple way to determine what type of malware is caught by the honeypot, is running a antivirus scanner against the detected files. Signature based scanning however, doesn’t show what the malware exactly does (or wants to do).
To gather a view of what actions the executed malware would have performed, one can use a sandbox. A sandbox is best classified as a sort of a high interaction honeypot as it does not just emulate a vulnerable service but it executes and track the executed malware as well.
One publicly available sandbox is Anubis that is maintained by the university of Vienna (http://anubis.iseclab.org).
The analysis eventually results in a downloadable report with an in-depth analysis about the uploaded files which presumable is malware.
Another way to demonstrate the working of malware is to visualize it. The people who designed Anubis also make a pcap file available from the complete communication of the malware during the analysis. This file can be loaded into protocol analyzers such as Wireshark (figure 1) or Etherape (figure 2).
Most malware comes in the form of a PE file (Portable Executable). These type of files have everything on board to do what they are designed to do. So, if such a file is executed on a vulnerable machine, you are basically infecting that machine with live malware.
It is advisable to take some protective measures. An infected machine should never be connected outside the lab environment !
Carving malware out of live memory.
This is precisely what I did:
I picked a file from my honeypot which ClamAV (a open source anti virus solution) had identified as a Blaster-A. Nepenthes stores the found malware using the md5-hash as filename. Once renamed to msblast.exe I ran this file to infect an XP machine in my lab. The task-manager clearly showed that msblast.exe (figure 3)was indeed running in RAM.
The blaster worm outbreak started in 2003 and was based on the vulnerability that was patched by the MS03-026 patch from Microsoft. So, running this on a fully patched system doesn’t work anymore.
Getting the memory image
Next thing I did was to fire up msfconsole from the Metasploit framework (www.metasploit.com) on a Ubuntu machine that was wired to the infected XP machine using a utp-cross cable.
I used the weakness that was used to deploy the Conficker (MS08-069) outbreak in 2008 to remotely take over the (already) infected machine. (figure 4)
Using the meterpreter as the payload and a ruby-script (memdump.rb / http://www.darkoperator.com/meterpreter/) for this payload, I was able to upload mdd.exe (figure 5). This little program basically dumps the entire RAM and its contents into a file (for the POSIX people: it basically makes a coredump). This file is subsequently downloaded to my Ubuntu machine.
Analyzing the memory image
Next I used a file carving utility called foremost (http://foremost.sourceforge.net/).
The following description is from their project page:
“Foremost is a console program to recover files based on their headers, footers, and internal data structures. This process is commonly referred to as data carving. Foremost can work on image files, such as those generated by dd, Safeback, Encase, etc, or directly on a drive. The headers and footers can be specified by a configuration file or you can use command line switches to specify built-in file types. These built-in types look at the data structures of a given file format allowing for a more reliable and faster recovery.“
Foremost automatically carves, identifies and stores files separately into the appropriate folders. Foremost also carves .exe files which is useful for this exercise.
Running ClamAV onto these files I bumped into my good old msblast.exe proving that it is possible to carve out executables out of a snapshot from live memory including malware 🙂
So why using all these different techniques for obtaining malware I already had in my possession in the first place one might ask ?
Well, that’s the entire premise of having a lab to conduct experiments. By deliberately infecting a machine with some malware I have knowledge of, I am able to validate that the results match with my expectations. Therefor I have evidence that my method is a sound one.
This procedure could come in handy in some forensic information gathering situations. The footprint in RAM of mdd.exe is very small. One thing to keep in mind however, is that collecting a memory image this way uses an amount of disk space equal to the amount of internal RAM in the targeted machine.
For this reason, the value of this technique depends on the kind of investigation you are running. In any case, it’s a nice exercise on forensic information gathering. In a penetration test it could come in handy to determine if a machine is infected with a known piece of malware.
In whatever case this technique is used, playing/studying with malware can be fun and highly interesting.
But do realize however that this IS real-live, working, potentially dangerous malware that can do a lot of damage !
Some great sources on a relating techniques:
Collecting memory images by using cold boot attacks
I would like to thank the following people for their advise and positive criticism:
Robert Wesley McGrew (Mississippi State University, USA)
Mikael Keri (Handelsbanke CERT, Finland)
Tiel Notenboom (MoD CERT, The Netherlands)
Dennis Lemckert (MoD CERT, The Netherlands)
Andrew Waite (www.infosanity.co.uk UK)
GodertJan van Manen (NorthWave, The Netherlands)