GETTING PROCESS INFORMATION

The syntax for running a command in Volatility is vol.py –profile=<profile> -f <command>, i.e. vol.py –profile=LinuxUbuntu14_04-3_16_0-30x64 -f ~/cases/pfe1/ram.lime linux_pslist. If you plan on using scripts to look at process information (or anything for that matter) using Volatility, you can store this obnoxiously long command, with profile and path to your RAM image, in a variable.

If you plan on running more than one volatility command on the command line, you might consider using the alias utility to spare yourself the pain of repeatedly typing all of this (and likely fat-fingering it at least a few times). The general syntax for the alias command is alias shortcut=”really long command that you don’t want to type”. If you put this command in your .bashrc file (located in your home directory) or other startup file, it will be available to you each time you log in. If you want to use the alias without logging out after editing .bashrc, you must source the .bashrc file by typing . ~/.bashrc. The appropriate line that has been added toward the end of the .bashrc file (which is highlighted) and the sourcing of .bashrc are shown in Figure 8.3.

FIGURE 8.3

Creating an alias to more easily run Volatility. The highlighted line near the end of the .bashrc file creates the appropriate alias.

All of the supported Linux commands begin with “linux”. Typing vol.py –info | grep linux should produce a complete list of available Linux commands. Partial output from running this command is shown in Figure 8.4. As of Volatility 2.4 there are 66 of these commands. It is important to keep in mind that memory analysis is a somewhat new field. As a result, it is not uncommon for some of these Volatility commands to fail.

FIGURE 8.4

Some of the available Volatility Linux commands.

Volatility provides a number of process commands for Linux systems. One of the simplest is linux_pslist which produces a list of tasks by walking the task list. This command outputs the process name, process ID, user ID, and group ID (along with a couple other fields that you likely don’t need). Partial output from running this command against our PFE subject system is shown in Figure 8.5. The highlighted row shows a shell associated with the Xing Yi Quan rootkit running with root privileges in process 3027.

FIGURE 8.5

Partial output of the Volatility linux_pslist command. The highlighted row shows a rootkit shell running with administrative privileges.

Another command for listing processes is linux_psaux. This command is named after ps -aux, which is a favorite command for people who want to get a listing of all processes complete with command lines. Partial output from this command is shown in Figure 8.6. The highlighted lines show how a root shell was created with sudo -s (process 3034); which caused bash to run as root (process 3035); and then the LiME module was installed (process 3073) in order to dump the RAM.

FIGURE 8.6

Partial output from running the Volatility linux_psaux command against the PFE subject system.

The two process commands presented thus far only show the processes in isolation. To get information on the relationship of processes to each other, the linux_pstree command can be used. This command will show processes with any subprocesses listed underneath and preceded by a period. Nested processes will have multiple periods prepended to their names. Not surprisingly, almost everything is a subprocess of init, which has a process ID of 1 as it is the first thing executed at boot time. Partial output from running this command against the PFE subject system is shown in Figure 8.7. The highlighted portion clearly shows the creation of the root shell by the user with ID 1000 which was then used to dump the RAM with LiME.

FIGURE 8.7

Partial results from running the Volatility linux_pstree command against the PFE subject system. The highlighted output shows the relationships of processes highlighted in Figure 8.6.

While the linux_psaux command is nice and provides a lot of information, there is another command that can provide even more information. That command is linux_psenv. This command lists the full process environment for every displayed process. Because this command will generate a lot of output, you may wish to use the -p option, which allows you to provide a comma delimited set of process identity numbers. For help on this, or any other Volatility command, run vol.py <command> -h for a brief help screen. The last part of this help screen for linux_psenv as well as the results of running linux_psenv on the process associated with the rootkit are shown in Figure 8.8.

FIGURE 8.8

Partial results of running vol.py linux_psenv -h and results of running this command on the process associated with a rootkit.

The -p option from the help screen is highlighted in Figure 8.8. Looking at the bottom of the figure we see that this process was executed by the john user with user ID 1000, and that sudo was used. This does not necessarily mean that John was involved in the compromise. Rather, this tells us that his account was used. There are a number of reasons that his account may have been used. He might have been targeted by someone that knew he had administrative privileges. It is also quite possible that he has a weak password that the attacker was able to crack.

Volatility provides a cross-reference command for processes called linux_psxview. Why would you want such a command? Some malware will attempt to hide its processes from view by altering internal kernel structures. By comparing (cross-referencing) the various structures, inconsistencies related to malware are more easily identified. Partial results of running this command against the PFE subject system are shown in Figure 8.9. In this case nothing unusual was noted.

FIGURE 8.9

Partial results from running linux_psxview against the PFE subject system.