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.