Metasploitable/Volatile Data Investigation

Volatile Data System Investigation

These commands are forUnix and Linux systems.

Volatile data like memory, network ports, and processes will change over time, so be careful to make these backups as soon as possible after the incident. And be careful how you gather data! You can potentially flush valuable cached network interface data in the process of trying to recover it.

More info on tools here: http://www.forensicswiki.org/wiki/Tools:Memory_Imaging

Toolz

In order to perform volatile data investigation, you'll need (at least) 2 things:

1) jump drive number 1 - this will contain the memory dump, so it needs more capacity than the memory of the machine you're analyzing

2) jump drive number 2 - this will contain trusted binaries of tools, compiled for the architecture of the machine you're analyzing

Prepare Environment

Make available a trusted source of Linux tools in /media (a CD or USB drive).

Make a USB mount drive for volatile data collection at /mount.

You'll use removable storage, and your own tools, to make these backups.

Prepare

Invoke a trusted shell: this should be shellshock-patched and statically linked (making it invulnerable to attacks on shared libraries).

Begin Logging

Go to your working directory, and run the script command to begin logging activity on the machine. Once you exit the shell, an output file will be created.

Dump Memory

Document the date and time, for the output file:

$ date

Linux 2.4 kernel

Capture memory for Linux 2.4 kernel using memdump.

$ /media/../dc3dd if=/dev/mem > /mount/../physical_mem_out

$ /media/../memdump > /mount/../physical_mem_out

$ /media/../dc3dd if=/proc/kcore of=/mount/../kcore_mem_out

Linux 2.6 kernel

Capture memory for Linux 2.6 kernel. This method will use fmem, but will need to be configured to keep from modifying the system.

Alternative tools?

Remote dump memory

To remotely dump memory, you can use fmem and pipe the output to netcat.

NOTE: This will generate lots of network traffic, and will therefore flush any saved buffer information in the network device being used. Make sure and recover that information first, if needed.

Start a netcat listener on the command-and-control server,

$ nc -l 4444 > phys_mem

In another window on the command-and-control server, monitor the size of the file. It should start to grow, and continue growing steadily, until it reaches the size of the memory on the machine. Monitor the size via:

$ watch -lahg /opt/data/phys_mem

Now, on the victim, get fmem on-board (using techniques shown above). Then pipe the memory dump to netcat.

$ dd if=/dev/fmem | nc 10.0.0.32 4444

Use control-C to stop the process once the file size has stopped growing.

Collect system state

Network

We'll want to capture network activity.

$ netstat -naovp

$ netstat -inet -naov

System

Run a few essential commands to list system status:

$ ifconfig
$ hostname
$ printenv
$ whoami
$ id
$ logname
$ uptime
$ uname -a
$ cat /proc/version
$ cat /proc/cpuinfo

$ # Record kernel boot:
$ cat /proc/cmdline

$ # Dump the routing table:
$ netstat -nr

$ # Dump the ARP cache:
$ arp -a

$ # Logged-on users:
$ who
$ w 
$ users

$ # Process data:
$ lsof -l
$ ps -e
$ ps -ef # Simple list
$ ps aux # Temporal
$ top -n 1 -b
$ pstree -a
$ pmap -d PID
$ ps -eafww
$ ps auxww
$ pmap -x PID # proc mem map

$ # Service config:
$ # (This will change based on OS)
$
$ # RedHat:
$ chkconfig -list
$ # General:
$ service -status-all # Shows status
$ service -status-all 2&>1 | grep \+
$
$ # Solaris:
$ ls /etc/rc*.d
$ # Solaris 10+:
$ smf 

$ # Check loaded kernel modules:
$ lsmod
$ cat /proc/modules
$ modinfo MODULE_NAME # from lsmod
$ xclip -o

$ iptables -t nat -nL
$ iptables -t mangle -nL
$ iptables -t filter -nL
$ iptables -t raw -nL
$ for type in nat mangle filter raw; do iptables -t $type -nL; done