VOLATILITY CHECK COMMANDS

Volatility contains several commands that perform checks for various forms of malware. Many of these commands are of the form linux_check_xxxx. In general, Volatility commands can take a long time to run, and these check commands seem to take the longest time. How long is a long time? Figure 8.16 shows a screenshot from an attempt to run the linux_apihooks command, which is used to detect userland API hooks, against the PFE subject system. After three hours of processing the small (2 GB) RAM image on my i7 laptop with 8 GB of memory, the command still hadn’t completed.

FIGURE 8.16

A very long running Volatility command. The command was aborted after it had not completed in nearly three hours.

If you suspect that the function pointers for network protocols on a system have been modified, the linux_check_afinfo command will check these function pointers for tampering. This command returned no results when run against the PFE subject system. The linux_check_creds command is used to detect processes that are sharing credentials. Those familiar with Windows may have heard of pass-the-hash or pass-thetoken attacks, in which an attacker borrows credentials from one process to run another process with elevated privileges. This command checks for the Linux equivalent of this attack. Running this command against the PFE subject system also produced no results.

The linux_check_fop command can be used to check file operation structures that may have been altered by a rootkit. Once again, running this command against the PFE subject system produced no results. This is not surprising. The rootkit installed on this system hides itself with a method that doesn’t involve altering the file operation commands (rather, the directory information is modified).

Many readers are likely familiar with interrupts. These are functions that are called based on hardware and software events. The function that is called when a particular interrupt fires is determined by entries in the Interrupt Descriptor Table (IDT). The Volatility command linux_check_idt allows the IDT to be displayed. The results of running this command against the PFE subject system are shown in Figure 8.17. Notice how all of the addresses are close to each other. A significantly different address in any of these slots would be suspicious.

FIGURE 8.17

Results from running the Volatility linux_check_idt command against the PFE subject system.

The kernel mode counterpart to the linux_apihooks command is linux_check_inline_kernel. This command checks for inline kernel hooks. In other words, this verifies that kernel function calls aren’t being redirected to somewhere else. Running this command against the PFE subject system produced no results.

Volatility provides the linux_check_modules function which will compare the module list (stored in /proc/modules) against the modules found in /sys/module. Rootkits might be able to hide by altering the lsmod command or other internal structures, but they always must exist somewhere in a kernel structure. This command also produced no results when run against the PFE subject system.

While Windows uses an API, Linux computers utilize system calls for most operating system functions. Like interrupts, system calls are stored in a table and are referenced by number. The mapping of numbers to functions is stored in system headers. The linux_check_syscall command will check the system call table for alterations. If something has been changed, “HOOKED” is displayed after the index and the address. Otherwise, the normal function name is displayed. On 64-bit systems there are two system call tables. One table is for 64-bit calls and the other for 32-bit calls. Running this command against the PFE subject system revealed that the 64-bit open, lstat, dup, kill, getdents, chdir, rename, rmdir, and unlinkat system calls had all been hooked by the Xing Yi Quan rootkit.

Volatility provides two commands for detecting key logging: linux_check_tty and linux_keyboard_notifiers. Each of these checks for well-documented key logging techniques. The first checks for interception at the terminal device level, and the second verifies that all processes on the keyboard notifier list are in the kernel address space (user address space indicates malware). If a problem is detected, the word “HOOKED” is displayed. The results of running these two commands are shown in Figure 8.18. No keylogger was detected on the PFE subject system.

FIGURE 8.18

Running Volatility key logging detection commands against the PFE subject system.