GETTING FILESYSTEM INFORMATION

The previous, quite lengthy, chapter dealt with filesystems. You might wonder why you would use a memory analysis tool to inspect filesystems. There are a couple of reasons for doing this. First of all, knowing what filesystems have been mounted can be helpful. Secondly, many modern Linux systems make use of temporary filesystems that go away when the system is shut down. A tool like Volatility may be the only way to recover these temporary filesystems.

The Volatility linux_mount command lists all mounted filesystems complete with mount options. The results from this command allow you to detect extra things that have been mounted, and also filesystems that have been remounted by an attacker with new options. Partial results from running this command against the PFE subject system are shown in Figure 8.24. The FAT (/dev/sdb1) and ext4 (/dev/sdb2) partitions from my response drive used to load LiME can be seen in the figure.

FIGURE 8.24

Partial results from running the Volatility linux_mount command against the PFE subject system.

Not surprisingly, Linux caches recently accessed files. The Volatility linux_enumerate_files command allows you to get a list of the files in the cache. This can help you more easily locate interesting files when performing your filesystem analysis. As can be seen from Figure 8.25, the john user has a lot of files associated with the rootkit in his Downloads folder. This command produces a lot of output. To home in on particular directories, you might want to pipe the results to egrep ‘^’, i.e. egrep ‘^/tmp/’. The “^” in the regular expression anchors the search pattern to the start of the line which should eliminate the problem of other directories and files that contain the search string appearing in your results. Note that egrep (extended grep) must be used for the anchor to work properly. Partial results from piping the command output to egrep ‘^/tmp/’ are shown in Figure 8.26. Notice there are several files associated with the rootkit here, including #657112, #657110, and #657075 which are inode numbers associated with the rootkit files.

FIGURE 8.25

Rootkit files in the filesystem cache.

FIGURE 8.26

Partial results of running the Volatility linux_enumerate_files command against the PFE subject system and piping the output to egrep ‘^/tmp/’.

Once files in the cache have been discovered using linux_enumerate_files, the Volatility linux_find_file command can be used to print out the inode information.

This command can also be used to extract the file. To get the inode information the -F option must be used. Unfortunately, the -F option doesn’t appear to support wildcards. Once the inode number and address is found, linux_find_file can be rerun with the -i

-O options. The full process of recovering the /tmp/xingyi_bindshell_port file is shown in Figure 8.27. From the figure we can see that this file stores the value 7777, which corresponds to our earlier discovery in the networking section of this chapter.

FIGURE 8.27

Recovering a file with Volatility.

results matching ""

    No results matching ""