I'm investigating a compromised Linux box where I found files with malicious code. The file system is too big to just make a copy of the whole block device and so far I'm only interested in the files of a not so big sub-directory.
While the last-modified timestamp (also called "mtime") of one example file is older, the so called ctime (inode change time) is rather new. So I want to also capture the ctime as it might be relevant.
JFTR: I know that neither timestamp needs to show time the file was created because a
chown command will also change the ctime and the last-modified date might be set by the downloading tool used to download the file, e.g.
wget, because—in contrary to the ctime—Linux allows the mtime of a file to be set to arbitrary times.
How do I capture the ctime properly when making forensic copies of such files?
I'm not aware of any archive format (e.g. tar, zip, rar) which captures the (potentially file-system-specific) ctime in addition to the mtime.
So far I came up with these of workarounds:
ls -l --time=ctime $filefor each captured file and save the out in a text file together with the files. (Did that for now.)
- Save the files onto a medium which also contains a file system which stores ctimes, e.g. an ext4 formatted USB stick, and set the system time to the ctime of the to be copied file immediately before copying so that the ctime of the copy is within seconds of the original ctime. (Should theoretically work, but likely has other side-effects on the OS; never actually tried it.)
Both workarounds are highly unsatisfying and I wonder if there are better methods to capture the ctime when making forensic copies of files (with Linux and preferably with open source software), e.g. a tool which can modify the ctime of a file or an archive format which can store more than one timestamp per file, etc.