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 ( 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 (

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).


Figure 1: Visualization in Wireshark


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.

figure 3

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 ( 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)

figure 4

figure 4

Using the meterpreter as the payload and a ruby-script (memdump.rb / 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.

figure 5

figure 5

Analyzing the memory image

Next I used a file carving utility called foremost (

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 :-)

figure 7


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

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 ( UK)
GodertJan van Manen (NorthWave, The Netherlands)

Views: 522


You need to be a member of Dissecting The Hack to add comments!

Join Dissecting The Hack

Latest Activity

Anton Vyacheslav is now a member of Dissecting The Hack
Dec 9, 2018
bernardorichard updated their profile
Nov 28, 2018
Sam Mccalla is now a member of Dissecting The Hack
Nov 19, 2018
bernardorichard is now a member of Dissecting The Hack
Oct 24, 2018

Stratagem 13 News Feed

© 2020   Created by Marcus J. Carey.   Powered by

Badges  |  Report an Issue  |  Terms of Service