Hi
I am requesting your help to obtain opinions and testimonials in order to be be able to make my own opinion since I am definetly not a unix expert.
Say we have a UNIX server.
On this server there is a specific directory let us call it "DIR"
A security incident have been reported related to this server.
Expert in forensics analyzed it and wrote this (modified a bit for confidentiality reasons)
Files : File1 to File14
"The above files were known to have been present in the directory. File system timestamps indicate that they were last accessed arround HH:MM on D Month Year and deleted around HH:MM on D Month Year. Investigators have attempted carving these files from free space on the system to determine their contents, however the files were unrecoverable. Some of there files may have been present for legitimate purposes."
Files : File15 to File20
"Due to the files' metadata having been overwritten, the initial date of their presence and their deletion date are unknown."
Since all files (File1 to File20) are supposed to have been present in the same directory (DIR) is it possible to succeed in identifying access and deletion timestamp of only a subset? Also File1 to File14 are assumed to be created and deleted earliest than File15 to File20 (fwe month to several years for some files)
Please give me your opinion only if you master unix file system and how files timestamps are managed.
The many the best.
Any way thank you very much for your time and help.
"Metadata has been overwritten" means "that information is gone".
Thank you Corona688 for your reply,
I wasn't clear enough, I'll try again doing better.
My question is :
"In your opinion, is it normal and logic to see the metadata of a subset of files overwritten while other regarding other files the metada was available and conducted to identify last access time and deletion time"
What is amazing is that the identified subset are somehow legitimate files while the "unknow" subset are supposed to be offending files.
Thank you for your support
Understand that many different Unix filesystems exist. We don't know which one you are using. But in general...
"Since all files (File1 to File20) are supposed to have been present in the same directory (DIR) is it possible to succeed in identifying access and deletion timestamp of only a subset?"
Yes it it quite possible. Deleting a file frees an inode. The inode continues to have some useful info in it... until it happens to be re-used.
"Also File1 to File14 are assumed to be created and deleted earliest than File15 to File20 (fwe month to several years for some files)"
I don't know why you assume that. Files can be deleted wheneve the owner wants. No need to delete in the sequence they were created. Even if you have some rule in place and follow it closely... perhaps the bad guy who broke in did not follow your rule.
If you want to verify your experts opinions, hire a second set of experts to examine the same system. Do not tell the second set what the first set said.
Rapidly create and delete a tiny file 500 times -- will it use the same inode (metadata space) every time? Quite possibly. It picked a convenient location the first time, and the location remains convenient until something else snaps it up. On a busy filesystem it might juggle between a few nearby ones.
An old file on the other hand is liable to get boxed in, fragmented, difficult to expand -- less convenient. Delete those and it's harder for the system to find a good new use for those sectors.
So a recently deleted file is more likely to have its metadata overwritten than an old file just deleted. This of course isn't a rule however -- only true in statistical terms. Especially since exactly how a filesystem picks inodes and sectors depends on not just the exact operating system, but the exact filesystem and its tuning.
I don't find the results that amazing or hard to believe.
Thank you again Corona688, your explanation is quite logic
Now I have a subsequent question. For those recently deleted files which investigators wasn't able to recover contents nor MAC timestamps, is it normal and logic that they were able to fully recover filenames? Hence they were are able to find for each File15 to File16 its exact full name as it was supposed to exist on the file system.
I am just wondering if the filename is stored also at some address (offset and length) of the i-Node and how this info is near or far from MAC timestamps addresses and so how we can trust or not the fact that the filename was recoverable but not the MAC timestamps.
Many thanks to any one who can direct me to any official readings or statistical studies, will really appreciate
The inode table is a big table of filenames and other file attributes (mtime, reference count, etc). It generally isn't anywhere near the file contents themselves.
Again, this depends on the filesystem. Still, though, their results make sense to me.
From further readings and own understanding almost all NIX file systems doesn't store filenames in i-node. Many people seem saying that file names are not recoverable when restoring an i-node. I am a confused.
What I understood is when recovering the i-node one have a chance to recover MAC-timestamps and the i-node number. If there was a process using the i-node number then there is a backup of the file somewhere in the O.S. sub directories (related to the device number)
Coronn688 may be there is a NIX flavor you are aware about that keep filenames in the i-node?
thank you anyway
Oh, yes -- this is because of the way files can exist in multiple places on a UNIX filesystem, via hardlinks. It's effectively the exact same file but in multiple places (though they must all be on the same partition). Attributes in the inode(user, group, size, atime, mtime, and so forth) are all shared. Which means name plainly can't be in the inode.
They probably put it in the directory entry instead.
As you've been told many times by now, how the filesystem is laid out depends on what system and what filesystem is being used. If you're curious about an
"average" one, I suggest looking at the structures of the linux ext2 filesystem. (which definitely keeps the name in the directory entry.)
As far as I am aware, filenames are not stored in an inode table but in each directory.
Yes, my mistake. I gave too quick an answer.