Third-Party Exim Server and Netcat Connections

As Listing 5 and Figure 2 show, a local attacker has uninstalled the installed Exim4 version on the demo system and replaced it with another one that is not from the repository. They probably used the Netcat connection they found to transfer the contents of the /dev/sda1 partition and RAM.

Figure 2: The Yarascan Volatility tool has found a spawned shell, which the attacker apparently used to transfer data.

A glance at the logfiles from the mail server would be meaningful for further evaluation. Unfortunately, they cannot be reconstructed from memory. Fortunately, we also have the hard drive from the compromised system, the memory dump, and the Honeynet 2011 case, which gives us, for example, the Bash history.

However, we can see from the memory dump – even using standard Unix tools – that the attacker has used wget to inject malicious software: The strings command searches for suspicious entries such as wget, .tar.gz, or .tgz:

strings -td victoria-v8.memdump.img | egrep '(\.tar|\.tgz|.\tar\.gz)'

This step returns a fair number of matches and their byte offsets, including rk.tar. Listing 6 searches an offset range, which often reveals information of further interest; strangely, that is not the case here. If you have access to the tangible physical filesystem, you can inspect the files that surround rk.tar.

Reconstructing Files

The linux_mount command can also provide enlightening information that is very useful to see whether the system used tmpfs, which is taken for granted today. The temporary filesystem almost always keeps a copy of the filesystem as a cache in RAM.

With a little luck, files such as rk.tar in this example can be reconstructed from memory. In Volatility, the linux_dentry_cache command does exactly that:

vol.py  linux_dentry_cache > bodyfile

The output file uses the forensic bodyfile format, as the name suggests. Mactime, a program from Sleuth Kit [13], helps in this case and converts the file into a readable format (Listing 7).

Incorrect Implementation

Unfortunately, the reconstructed bodyfile format still shows an error in recovering the date – February 11, 2080, is unlikely to be the creation date. Proceed with caution, if you intend to use this file as evidence. The developers are already aware of this issue, but reconstructing rk.tar currently fails, at least if you do not have the filesystem.

At least you can restore /etc/passwd as a proof of concept (Listing 8). The virtual inode on the cached system is 0xcf033e48. Calling

vol.py linux_find_file -i 0xcf033e48 -O /tmp/passwd

creates a copy of the reconstructed passwd file in the /tmp directory .