📒

Ch.9 Malicious Activity

Detection
Investigating network activity
before going on to investigate network connections, it would be a good
idea to find out which network interfaces were used on our host and how
they were configured.

1. we can use the Volatility linux_ifconfig plugin, which provides all the
necessary information in the following way:

2. We can now start investigating active network connections using

linux_netstat plugin , and it is better to redirect the output to a text file:

Ch.9 Malicious Activity Detection 1

 3. Another way to check the network activity is to use Bulk Extractor

The output will contain the packets.pcap file, which is a dump of network
traffic.

Here, we can see active use of port 4444 used by Metasploit

Ch.9 Malicious Activity Detection 2

 Analyzing malicious activity
Scenario1
We saw that we had several SSH connections.

1. let's use the linux_pstree plugin and add sshd process identifiers – 29897
and 23251:

💡 we can see that the child processes of sshd are bash as well as sudo,
which means that elevated privileges were used.

2. we can search the bash history through linux_bash plugin as well as dump
and analyze the memory of these processes.

we can see that someone was working with MySQL and WordPress, and we
can see the interaction with the site-info.php file, as well as the nyan-cat.gif
download associated with the bash process with the 30112 PID.

3. We can check which user ran bash in this case through linux_psenv

Volatility plugin.

Ch.9 Malicious Activity Detection 3

 as you see that this activity was performed within the SSH connection from
the 192.168.110.40 IP address by the user admin.

4. use the linux_recover_filesystem plugin and try to recover the filesystem from
memory
$ vol.py --plugins=profiles -f /mnt/hgfs/flash/ubuntu-server.vmem --profile=Linuxubuntu-
server_17_47_52-profilex64 linux_recover_filesystem -D /mnt/hgfs/flash/recovered/

As you can see in the figure, the /etc directory failed to recover; nevertheless,
we have /var/log where we can find the auth.log file , which show that admin
user was created at the time of the attack.

Ch.9 Malicious Activity Detection 4

 We also see that the picture was uploaded to /var/www/wordpress.

4. Let's add the network traffic dump extracted from the memory dump to our
investigation. To extract the traffic, we run Bulk Extractor:

Now, we open the packets.pcap file in Wireshark

This means that this request was made using the WPScan tool, used to
search for vulnerabilities in the content management system WordPress.

5. Similar information should be logged in the nginx access log file.

Ch.9 Malicious Activity Detection 5

 💡 a POST request was sent with a comment; possibly, a vulnerability
related to comment sending was used for the initial access.

6. You cab extract that file using NetworkMiner or WireShark , and it seemed that
the attacker left a comment on the blog with a link accessing the same
192.168.110.40 IP address.

If we consider the situation from the point of view of WordPress, the

comments sent by users must be saved in the database.

7. you can look for information about them in the MySQL logs or in the
memory of this process so, we will dump the process using linux_dump_map
plugin

Ch.9 Malicious Activity Detection 6

 8. we will do strings on every file in the directory
for file in /mnt/hgfs/flash/mysql/*; do strings "$file" >> /
mnt/hgfs/flash/mysql_strings.txt; done

Bingo! Here , we can see the payload that was used,we can also note the
interaction with the site-info.php file in the footer directory .

Ch.9 Malicious Activity Detection 7

 we can conclude that after accessing the host, the attacker
changed the source code of the site so that now when users
visit the compromised resource, they will see a picture
instead of a blog.

Scenario 2
This is an example worthy of special attention because this type of payload is
most often found on Linux-based systems involved in incidents. So, we have
information that some connections were made using port 4444 through
Meterpreter.

1. check the network connections and look for connections to ports and
addresses we know

2. look for the process that established the connection.

3. injections into processes are often related to Meterpreter, as attackers

need to somehow put the payload into memory , so we will use
linux_malfind

We have a rules_for_emplo process, associated with the

rules_for_employees file, which is located in the it-sec user downloads.

The inject found there starts with ELF, so we are dealing with something
executable.

Ch.9 Malicious Activity Detection 8

 💡 Executable and Linkable Format (ELF) is a binary file format used in
many modern UNIX-like operating systems, such as Ubuntu,
FreeBSD, Linux, and Solaris.

4. we can either calculate the hash of the executable and check it in cyber
threat intelligence platforms or try to run the file in a controlled
environment and find out what it does. Of course, if you have reverse
engineering skills or have a dedicated malware analysis team, they are
good options as well.

5. Another way is to extract the memory of this process with the

linux_dump_map plugin , then you can run strings to find ips, ports,…

6. so , let’s try to look a little bit more into what happened after the
rules_for_emplo process started , through linux_pstree

7. so lets see the names of the running programs and their locations and the
arguments passed to them at startup through linux_psaux plugin

Ch.9 Malicious Activity Detection 9

 8. we can use the linux_bash plugin to see what commands were executed:

💡 From the output of this plugin, we can see that the attacker was
trying to install a cron job to get persistence , We can also notice that
the /tmp directory was used as a working directory for creating and
storing temporary files.

On Linux-based systems, such activity should be logged to

/var/log/cron.log

9. in Linux philosophy, everything is a file , if the process used text files,

sockets, or pipes, all of those things can be found in the output of
linux_lsof .

Ch.9 Malicious Activity Detection 10

 /dev/ptmx is a character file used to create a pseudo-terminal master and
slave pair.

/dev/null is a special file, which is a so-called empty device.

/dev/pts is a special directory that is created dynamically by the Linux

kernel.

/dev/tty stands for the controlling terminal for the current process.

Examining kernel objects

rootkits are loaded kernel modules. Accordingly, we need methods to
detect loaded modules.

1. linux_lsmod , which enumerates kernel modules

2. linux_hidden_modules , which carves memory to find hidden kernel modules.

Ch.9 Malicious Activity Detection 11

 3. In order to analyze them, we can try to extract them with the Volatility
linux_moddump plugin.

vol.py --plugins=profiles -f /mnt/hgfs/flash/it-sec. lime --profile=Linuxubuntu_it-secx64

linux_moddump -b 0xffffffffc0521970 -D /mnt/hgfs/flash/

rootkits will not always try to hide their module; instead,

they may use masquerading and try to look like legitimate
modules. In this case, to find the rootkit, it is possible to
extract all modules found with linux_lsmod and compare them
with their legitimate counterparts.

rootkits often use hooking to perform their activities,There are many

hooking techniques, but the most common are IDT and syscall hooks.

💡 Interrupt Descriptor Table (IDT) stores pointers to interrupt service

routines. When an interrupt occurs, the processor stops its activity
and calls the interrupt service routine, which handles the interrupt.
Such interrupts can be triggered by button presses, mouse
movements, or other events.
Syscalls or system calls are calls from an application program to the
operating system kernel to perform some operation. The Linux kernel
header file has a syscall function that allows such calls to be made
directly, and the Linux system call table itself is part of that operating
system's API.

4. Volatility provides the linux_check_idt and linux_check_syscall plugins to

detect IDT and syscall hooks , and we would have seen the word HOOKED
in the output.

Ch.9 Malicious Activity Detection 12

 5. Volatility provides a few more plugins for analyzing other types of hooks:

6. linux_apihooks – Checks for userland apihooks

2. linux_check_evt_arm – Checks the exception vector table to look for syscall

table hooking

8. linux_check_inline_kernel – Checks for inline kernel hooks

9. linux_check_tty – Checks the tty devices for hooks

10. find files that are opened from within the kernel with the
linux_kernel_opened_files

11. check file operation structures for rootkit modifications with the
linux_check_fop plugin.

Ch.9 Malicious Activity Detection 13