2 Live Memory Acquisition and Analysis
2 Live Memory Acquisition and Analysis
In some cases, the forensic investigator will need to grab an image of the
live memory. Remember, RAM is volatile and once the system is turned
off, any information in RAM will be likely lost. This information may include
passwords, processes running, sockets open, clipboard contents, etc. All of
this information must be captured before powering down the system or
transporting it.
In addition, many hard drives are encrypted with such things as TrueCrypt
and the password for these encryption regimes resides in RAM. If the hard
drive is encrypted, then capturing volatile data is even more crucial as the
hard drive information may be unavailable to the forensic investigator
without it.
There are many tools for capturing data from memory, but one company,
Access Data, has been providing their FTK (Forensic Tool Kit) Imager for
years for free and, as a result, it has become the de-facto standard in
image capturing. You can the FTK Imager at Access Data's website.
It will open a window like that below. You will have to select where to store
your memory dump, what to call the file, whether you want to include the
page file (virtual memory), and whether you want to create an AD1 file
(AccessData's proprietary data type).
In my case, I created a directory called "memory dumps", named the file
memdump.mem, included the virtual memory or pagefile, but did not
create an AD1 file. I recommend you do something similar.
When you completed each of these, click the "Capture Memory" button.
This will start a window that will track the progress of your capture. If the
system has a lot of memory, that could take awhile.
Among the most widely used tools for memory analysis is the open-source
tool appropriately named Volatility. It is built into Kali Linux, so there's
no need to download it. Simply transfer the memory image you captured
to your Kali machine and we can begin our analysis.
And plugins.
Before we can do any work on this memory image, we first need to get
the profile of the image. This will retrieve key information from the image.
This profile will then help volatility to determine where in the memory
capture key information resides, as each operating system places
information in different address spaces.
This command will examine the memory file for evidence of the operating
system and other key information.
Now that we have recovered the profile of this memory dump, we can
begin to use some of the other functionality of Volatility. For instance, if we
wanted to list the registry hives including SAM, we could use the hiveinfo
plugin by typing:
Parsing out the image profile is crucial, as each operating system stores
information in different places in RAM. Volatility needs to know the profile
(OS, service pack, and architecture) to know where to look in the memory
image for the necessary information. If you put in the wrong profile
information, Volatility will throw errors telling you it can't parse the
information properly. In that case, try another image profile.
Unfortunately, the profile image that this tool provides is not
always correct.
As our next step, let's see if we can find the processes that the suspect
had running when we captured the RAM image. We can do this by typing:
To view the running DLLs on the system, we simply use the dlllist plugin
like below:
As you can see, Volatility parsed out a list of all the running DLLs.
Step 7: Getting the Contents of the System's Clipboard
Often times, to prove that a suspect actually committed the action they
are accused of, we may need a timeline of events that took place on that
system. We can retrieve this timeline information from the memory image
by using the timeliner plugin like below.
Lastly, let's look for any malware running in the memory of the suspect
system. Volatility has a plugin especially designed for this purpose,
appropriately named malfind. We can use it like any other Volatility
plugin. Simply type the same command as above but replace the name of
the plugin with malfind.