Automated memory capture and analysis on Linux with Linux Memory Grabber

A script for dumping Linux memory and creating Volatility profiles


I have already written something about dump of volatile memory on Linux systems.
Recently i have discovered this useful script developed by Hal Pomeranz, that automate all steps required to perform a memory analysis.


A lot of steps!

In order to perform a memory analysis on a Linux system, first need to be able to capture volatile memory, but you need to have a specific module compiled for the kernel of the system where you want to grab RAM.

After, in order to analyze the dump with Volatility, you need to create a profile that matches the system where the memory was captured: to make this, you need to compile a C program on the system and using dwarfdump to get the addresses of important kernel data structures.

This is not easy: there are a number of steps and some low-level Linux commands involved.

The “Linux Memory Grabber” script can automate all this steps.

ON FORENSIC PURITY
==================

If you're a stickler for forensic purity, this is probably not the
tool for you. Let's discuss some of the ways in which my tool interacts
with the target system:

Removable Media -- The tool is designed to be run from a portable USB
device such as a thumb drive. You are going to be plugging a writable
device into your target system, where it could potentially be targeted
by malicious users or malware on the system. The act of plugging the
device into the system is going to change the state of the machine
(e.g., create log entries, mtab entries, etc). If the device is not
auto-mounted by the operating system, the user must manually mount the
device via a root shell.

Compilation -- lmg builds a LiME kernel module for the system.
Creating a Volatility(TM) profile also involves compiling code on
the target machine. So gcc will be executed, header files read,
libraries linked, etc. lmg tries to minimize impact on the file
system of the target machine by setting TMPDIR to a directory on
the USB device lmg runs from. This means that intermediate files
created by the compiler will be written to the thumb drive rather
than the local file system of the target machine.

Dependencies -- In order to compile kernel code on Linux, the target
machine needs a working development environment with gcc, make, etc
and all of the appropriate include files and shared libraries.
And in particular, the kernel header files need to be present on
the local machine. These dependencies may not exist on the target.
In this case, the user is faced with the choice of installing
the appropriate dependencies (if possible) or being unable to
acquire memory from the target.

Malware -- lmg uses /bin/bash, gcc, zip, and a host of other programs from
the target machine. If the system has been compromised, the applications
lmg uses may not be trustworthy. A more complete solution would be
to create a secure execution environment for lmg on the portable USB
device, but was beyond the scope of this initial proof of concept.

Memory -- All of the commands being run will cause the memory of the
target system to change. The act of capturing RAM will always create
artifacts, but in this case there is extensive compilation, file system
access, etc in addition to running a RAM dumper.

All of that being said, lmg is a very convenient tool for allowing
less-skilled agents to capture useful memory analysis data from
target systems.

Note that lmg will look for an already existing LiME module on the
USB device that matches the kernel version and processor architecture
of the target machine. If found, lmg will not bother to recompile.
Similarly, you may choose to not have lmg create the Volatility(TM)
profile for the target in order to minimize the impact on the target system.

lmg uses relative path names when invoking programs like gcc and zip.
So if you wish to run these programs from alternate media, simply update
$PATH as appropriate before running lmg.

The usage is pretty simple:

When you wish to acquire RAM, plug the thumb drive into your target
system. On most Linux systems, new USB devices will get automatically
mounted under /media. Let’s assume yours ends up under /media/LMG.

Now, as root, run “/media/LMG/lmg”. This is interactive mode and
the user will be prompted for confirmation before lmg builds a LiME
module for the system and/or creates a Volatility(TM) profile.
If you don’t want to be prompted, use “/media/LMG/lmg -y”.

Everything else is automated. After the script runs, you will have
a new directory on the thumb drive named 

 “…/capture/<hostname>-YYYY-MM-DD_hh.mm.ss”

lmg supports a -c option for specifying a case ID directory name to be
used instead of the default “<hostname>-YYYY-MM-DD_hh.mm.ss” directory.

Whatever directory name is used, the directory will contain:

 <hostname>-YYYY-MM-DD_hh.mm.ss-memory.lime — the RAM capture
 <hostname>-YYYY-MM-DD_hh.mm.ss-profile.zip — Volatility(TM) profile
 <hostname>-YYYY-MM-DD_hh.mm.ss-bash — copy of target’s /bin/bash
 volatilityrc — prototype Volatility config file

The volatilityrc file defines the appropriate locations for the captured
memory and plugin.

For more technical information, and installation instructions plese refer to github repository:

https://github.com/halpomeranz/lmg

Comments