Week 3 Lab Exercises A

Linux Process Analysis

Introduction
In this week’s workshop we looked at the ways in which processes can be enumerated, in
particular linux_pslist and linux_pstree. In this weeks lab you will use these as starting points
to look at some of these processes in more detail and how to extract pieces of the process
memory that enable more detailed analysis. In addition to this you will see how additional
information such as commands entered at the shell are used to deepen our understanding
and further our analysis. You will notice that this week we do not need to create a profile as
the correct ones for this weeks Lab Exercises are already included in the Kali VM. This is also
probably a good time to remind you that you should be practising Wk2 Lab Exercises A in
preparation for your Lab Test in Learning Week 6.

Lab Goals
During this Lab you will learn a number of skills that will be vital for your first assessment
which takes place in the lab during week 6.

1. Understand how to analyse processes and their specific characteristics.

2. Learn about other related plugins such as bash history and the additional context it
can provide.

Tools and Resources

For today’s Lab you will require the following tools and software;

• Learning slides for reference– LS7

• debian.dump & debianNet.dump
o Can be found under Week 3 Lab materials on MyLearning
o Need to unzip them before use.
• MemoryAnalysis.ova
o Kali VM can be found on Lab machine at C:\CST3510\VM
• VirtualBox Application

Virtual Machine Username Password

Kali-Linux kali MDXK4l1

CST3510 Week 3 Lab Exercises A 1 ©2024 [email protected]

Exercises

Before we start looking at processes one final rememinder of how to setup your analysis
environment for the Labs on this module;

1. Download and unzip the two memory dumps from Week 3 MyLearning resource and
place them into a shared folder for this Lab in your Windows host.
2. Open up VirtualBox and import the MemoryAnalysis.ova
3. Go to settings and check display, network and edit the shared folder to a folder in your
Windows host machine.
4. Power up and login with the credentials provided above, then open a terminal.

You will also need to get a copy of the correct profile to use with these dumps and this is
already present in the VM so there is no need to create one as we did in last weeks labs. As a
reminder the command to list them is:

$> volatility -–info | grep Linux

Figure 1. Listing Volatility Linux profiles

As you can see there are already a number of profiles added in this VM and the correct one
for this Lab is circled in red. Copy and pasting this value is much faster and avoids errors.

Process listing

Navigate to the shared folder location in Kali /media/testShare. Firstly check that the memory
sample we will analyse is present (debian.dump) using ls and enter the following command.

$> volatility -f debian.dump --profile=LinuxDebian_4_9_0-12-

amd64_profilex64 linux_pslist

Figure 2. Enumerating the list of processes

CST3510 Week 3 Lab Exercises A 2 ©2024 [email protected]

This will produce a list of processes that were running on the system at the time off its
memory capture with various other fields containing relevant information. Each process is
assigned a unique identifier in the form of a process Id - Pid. As you learnt in the workshop
there are two main types of process to consider, Userland processes and Kernel processes. In
the example we can see that some processes do not have a Directory Table Base - DTB. These
processes are kernel threads and use kernel memory. Those that do have a DTB are userland
processes, each with its own memory space.

The next field of interest to us is the ppid field as this indicates the process which launched
this process. This is referred to as the parent child relationship between them. To investigate
the relationships between the processes and to understand which ones were created by
which process we can use linux_pstree as it provides an easier viewpoint.

$> volatility -f debian.dump --profile=LinuxDebian_4_9_0-12-

amd64_profilex64 linux_pstree

Figure 3. linux_pstree plugin to view process hierarchy

For instance, in this example we can see a sleep process running in a bash shell. We can also
see that systemd is the first process (PID 1). In old machines, this should be init. If we have a
look to the kernel threads section we find the following:

Figure 4. k-threads

None of the processes has a Uid, and their name is in square brackets. We can also investigate
the maps for specific processes, to identify their original path. To do that with the systemd
(process or p 1) process we can run the proc_maps plugin which shows the

$> volatility -f debian.dump --profile=LinuxDebian_4_9_0-12-

amd64_profilex64 linux_proc_maps -p 1

CST3510 Week 3 Lab Exercises A 3 ©2024 [email protected]

Figure 5. Listing memory maps for a process using linux_proc_maps plugin

You can see in the example that the process is mapped to /lib/systemd/systemd and all the
libraries it uses, among them libuuid.so. Under the flags column for the first entry, we can see
that it has ‘x’ indicating that it is executable. This can be used to validate where a process has
executed from as it is possible for userland malware to manipulate the mappings that ps
reports. These sections of the process memory can be extracted for analysis and we can see
that the file is in the memory section 0x0000560f8f4e3000 (circled red in Fig. 5).

We can also check the file handlers of the process by using:

$> volatility -f debian.dump --profile=LinuxDebian_4_9_0-12-

amd64_profilex64 linux_lsof -p 1

Figure 6. File descriptors with linux_lsof plugin

The File Descriptors FD 0, 1 and 2 correspond with stdin, stdout and stderr respectively. In
this example, all of them are going to /dev/null which is to be expected for this process as
seen abovre in Fig 6.

Exercise 1: Find the maps and the file handlers of the sleep process, where are
the handlers pointing to?

CST3510 Week 3 Lab Exercises A 4 ©2024 [email protected]

Recovering Memory

Our next interest is to recover specific information from the memory, for instance, some files
associated to memory. Before we do this we need to create an output directory where some
of our results will output to. From the terminal use mkdir to create a new directory called
maps. From our previous example, we are going to recover the executable section of systemd.
As we saw above in Figure 5, it starts in 0x0000560f8f4e3000, therefore we specify the pid
number (-p), where it starts (-s) and the directory where we want to dump it (-D)
(in this case, the current directory):

$> volatility -f debian.dump --profile=LinuxDebian_4_9_0-12-

amd64_profilex64 linux_dump_map -p 1 -s 0x0000560f8f4e3000 -D maps/

Figure 7. Extracintg executable section using linux_dump_map plugin

Exercise 2: Recover the executable of the sleep process.

Analysing Command Line Arguments

You can also check which arguments were used to call every command which will give further
clues about the users intent. For that you can use the linux_psaux plugin:

$> volatility -f debian.dump --profile=LinuxDebian_4_9_0-12-

amd64_profilex64 linux_psaux

Figure 8. Command line arguments using linux_psaux

We can see that systemd was called as "/sbin/init" and sleep as "sleep 100". If we were to
find some network calls including ports or IPs, that could indicate a backdoor. Sometimes it is
possible for a process to hide its call ffrom psaux, but we can inspect other places to try and
determine this, such as the environment variables for a process.

CST3510 Week 3 Lab Exercises A 5 ©2024 [email protected]

Process Enviroment Variables

You have seen from the learning slides why the environmental variables are of value to
investigation due to some the data that can be extracted here. To view the variables for all of
the processes we can run the linux_psenv plugin.

$> volatility -f debian.dump --profile=LinuxDebian_4_9_0-12-

amd64_profilex64 linux_psenv

Figure 9. Output for all processes environemnt variables using linux_psenv

In this example, we can see the whole path of each process. If, for example, we have a process
hiding its call to psaux, we can check where the user called it from using the (PWD)variable.
You may also sometimes see an OLDPWD variable which indicates a previous location. If we
would have a bash with an SSH connection, we would also be able to see details of the
connection, such as, IPs and ports. The USER variable may help to identify credentials of
potential attacker.However it is important to remember that there can often be good reasons
for a user carrying out certain activities and so needs to be taken in context.

It is quite easy to find processes with specific variables through use of grep to filter, but for
this example we have a specific process we are interested in and so will filter to just the
process we are looking at.

$> volatility -f debian.dump --profile=LinuxDebian_4_9_0-12-

amd64_profilex64 linux_psenv -p 685

Figure 10.Enviroment varaibles for process 685

In the output we can see the username the shell and various others but there is nothing that
is suspicious here. However if you were to look up the username or another valiad variable
you will gain some clue as to how this dump has been created!

To find some more information about the process we can look at the bash history using the
linux_bash command.

CST3510 Week 3 Lab Exercises A 6 ©2024 [email protected]

Recovering Bash History

To recover the bash history for our previous example we had the process 685 then we can
use the linux_bash plugin:

$> volatility -f debian.dump --profile=LinuxDebian_4_9_0-12-

amd64_profilex64 linux_bash -p 685

Figure 11. List of commands issued at the bash shell with linux_bash plugin

What is also useful about the linux_bash plugin is that it provides a timestamp for the time
the command was executed, and this is not available via the file that is stored in the file
system. These are displayed in the output as most recent last. What is interesting in our
current dump is that every single command has exactly the same timestamp.

Exercise 3: Discuss with your colleagues what the implications are that every
command has been carried out at the same time. Does this appear strange?

The only exception to this is that this bash calls the sleep command as "sleep 100" as the last
command executed at the shell (circled red in fig. 11 above). The output of this function is
that it will force the system to pause the execution of the next command for the specified
number of seconds (can specify other time periods).

For this example we looked at just the history for one process and so we limited how much
we could see by specifying process 685. f you try to run without specifying the process then
you will see that for this dump it simply repeats the output, but this will not be the case on
other dumps you will study, where the history for relevant processes will be shown.

Solutions are on the next page

CST3510 Week 3 Lab Exercises A 7 ©2024 [email protected]

Solutions

Exercise 1: You just need to run the previous commands for the maps and file handlers.
Sleep points to /dev/tty1, which is the bash terminal.

Exercise 2: Apply dump_map to sleep by setting the process to 694.

Exercise 3: Ask your tutor if you cannot agree on the reasons and they will explain at the end
of the session.

CST3510 Week 3 Lab Exercises A 8 ©2024 [email protected]