Studying memory with the Volatility memory dump analyzer
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.
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
.
Listing 6
Strings with awk
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).
Listing 7
Mactime
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 .
Listing 8
Restored /etc/passwd
« Previous 1 2 3 4 Next »
Buy this article as PDF
(incl. VAT)