8

I'm inspecting some files in my dedicated web server via linux cli after a hack attack and found some files have been modified with the 'touch' command to change the dates. I'm willing to get the exact file creation date for these specific files. I've already tried following

stat
ls -ld

Those didn’t deliver the file written date on disk (creation date)

Also is there any other way to get the file creation date? (actual date which the file wrote to the disk)

Improve this question
1
  • It seems odd that a hacker should randomly touch some files. In your shoes, I would wonder whether those files have been replaced by doctored versions allowing the attacker continuous access. Did you at least run software specialized in rootkit detection, like rkhunter and chkrootkit?
    – MariusMatutiae
    Dec 11, 2013 at 9:52

1 Answer 1

Reset to default
10

What you are looking for is on *nix called the file birth time.

Unfortunately, most *nix file systems don't keep track of that piece of information.

If it is available, then a recent version of stat should display it. Otherwise, your best bet would probably be to compare against file listing from backups (you do have backups, right?) to see which files have been added.

~$ stat .bashrc
  File: `.bashrc'
  Size: 3539            Blocks: 9          IO Block: 3584   regular file
Device: 24h/36d Inode: 204095      Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/ michael)   Gid: ( 1000/ michael)
Access: 2013-12-11 09:41:50.315475289 +0100
Modify: 2013-08-16 21:28:42.000000000 +0200
Change: 2013-09-14 01:55:27.167869741 +0200
 Birth: -
~$

As you can see, there is no "birth" timestamp, which means that the file system I'm using for my home directory (ZFS in my case) either does not store that information, or does not expose it through the Linux file system layer in a way that stat knows about. Either way the effect is largely the same: no information is available.

The above said, I wouldn't be particularly surprised if even on a system that does track file birth times, something like cp --copy-contents --preserve=timestamps /dev/null /tmp/somefile && cat ./somefile >> /tmp/somefile will effectively nullify anything like that. So even if birth times are available, you shouldn't rely on them for anything important, like evaluating the impact of a security breach.

The closest you can get on most systems is probably the file modification time or mtime, which stat does display and which most file systems do keep track of. However, as you have noticed, this is trivially changed using touch.

Improve this answer
4
  • Thanks for the detailed info and it saved my time. There are no bkps, due to this file has put by hacker. Also stat shows Birth as '-'
    – inckka
    Dec 11, 2013 at 9:25
  • @inckka If you know the file is not supposed to be there, just delete it. Just beware of anything else that may have been placed on your system. Very often with this sort of situation, unless you can prove (which is exceptionally difficult) that you can clean the system in a reasonable amount of time, it's best to just nuke from orbit and restore from a known good backup (which you really should have had, is about all I can say about that).
    – user
    Dec 11, 2013 at 9:27
  • Very useful information. Intruder has written files randomly, for create a back-door to my another important site hosted separately on another folder under same domain. I'm gonna perform a fresh installation from the latest backup files. Thanks
    – inckka
    Dec 11, 2013 at 12:37
  • @inckka Just be careful with exactly what you restore, so you don't inadvertantly open up any back doors in the fresh installation. If you feel this answer properly answers your question, please indicate so by upvoting and accepting. Thank you.
    – user
    Dec 11, 2013 at 13:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .