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
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
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