MEMORY ANALYSIS
You decide to start with memory analysis in hopes that it will guide you to the correct places during your filesystem analysis. As always, there is nothing that stops you from switching back and forth between memory analysis and filesystem analysis. As before, we define an alias for Volatility in the .bashrc file as shown in Figure 9.7.
FIGURE 9.7
Adding an alias to .bashrc to more easily run Volatility.
Partial results from the Volatility linux_pslist command are shown in Figure 9.8. From these results we see that this system also has the Xing Yi Quan rootkit. The in.ftpd process being run with an invalid user ID of 4294936576 in the last line of Figure 9.8 also looks a bit suspicious.
FIGURE 9.8
Partial results from running the Volatility linux_pslist command against the PAS subject system. The highlighted portion shows a rootkit process. The last process listed also has a suspicious user ID.
Running the Volatility linux_psaux command provides some more detail on what is happening. As can be seen in Figure 9.9, in process 8019 the user with ID 1001 changed to the bogus mysqll user with the command su mysqll. This generated a bash shell with root privileges because mysqll has a user ID of zero (process 8021). The xingyi_bindshell is running with root privileges in process 8540. The rootkit was likely started from the shell in process 8021. This can be verified by running linux_pstree.
FIGURE 9.9
Partial results from running the Volatility linux_psaux command against the PAS subject system. The highlighted portion shows malicious activity.
We noticed a dropbear SSH backdoor listening on port 44965. We can use the Volatility linux_netstat command and pipe the results to grep TCP to discover the process ID for this process. Partial results from this command are shown in Figure 9.10. From the results we see that the dropbear process ID is 1284. This low process number suggests that dropbear has been set to automatically start. The linux_pstree results support this inference. Furthermore, the linux_pstree results reveal that the root shell in process 9210 was launched by xingyi_bindshell running in process 8540.
FIGURE 9.10
Partial results from running the Volatility linux_netstat command against the PAS subject system and piping the output to “grep TCP”.
The process maps for the two suspicious processes are captured with the linux_proc_maps command as shown in Figure 9.11. The process spaces for both programs are also dumped to disk for later analysis as shown in Figure 9.12.
FIGURE 9.11
Saving process maps for suspicious processes.
FIGURE 9.12
Saving process memory for suspicious processes.
The linux_bash command produces some very enlightening results. As shown in Figure 9.13 and Figure 9.14, the attacker is actively trying to become more deeply embedded in the system. A lot of malicious activity was recorded in the bash history for process 9210. The results from linux_pslist confirm that this is a root shell. Figure 9.13 shows the attacker downloading and installing the Weevely PHP backdoor. Later, in Figure 9.14, the attacker can be seen downloading the rockyou.txt password list and then performing an online password attack against the sue user account with Hydra.
FIGURE 9.13
Downloading and installing a rootkit.
FIGURE 9.14
Online password cracking with Hydra.
Hydra was used against the local FTP server. Before launching Hydra, the attacker copied both the /etc/passwd and /etc/shadow files. It isn’t clear why Hydra was used, instead of an offline password cracker like John the Ripper. Perhaps the attacker didn’t want to copy off the passwd and shadow files. Using the local FTP server for password cracking is somewhat fast and may not generate alerts if an installed Intrusion Detection System (IDS) isn’t configured to monitor this traffic.
The linux_psenv command run against processes 8540, 1284, and 9210 produces interesting results. Some of the results are shown in Figure 9.15. The highlighted portion shows that a hidden directory /usr/mysql/.hacked has been created. The process environment for the dropbear backdoor confirms that this program is automatically started when the system boots to run level 2 or higher.
FIGURE 9.15
Partial results from running the Volatility linux_psenv command against suspicious processes on the PAS subject system.
The entire suite of Volatility linux_check_xxxx commands was run against the PAS subject system. Only the linux_check_syscall command returned any results. Some of these results are displayed in Figure 9.16. From the results we can see that Xing Yi Quan has hooked the 64-bit system calls for open, lstat, dup, kill, getdents, chdir, rename, rmdir, and unlinkat. When viewed with the complete output for this command, the addresses for hooked system calls are noticeably different from the unaltered call handlers.
FIGURE 9.16
Partial results from the Volatility linux_check_syscall command run against the PAS subject system.
The Volatility linux_enumerate_files command was run against the PAS subject system and the results were saved to a file. Egrep was then used on the file to locate certain files in the filesystem cache. The partial results shown in Figure 9.17 reveal that the rockyou.txt password list and the Xing Yi Quan rootkit are both stored in the hidden directory /usr/local/mysql/.hacked.
FIGURE 9.17
Malicious files stored in a hidden directory.
While Volatility could be used to retrieve some files from the file cache, it is likely easier to just use the filesystem image for this purpose. If there is a need to retrieve more information from the memory image, the memory image is not going anywhere. We might return to using Volatility when performing malware analysis.