It seems to me like there is a misunderstanding, maybe these parts
(page S72)
Thus, Unix based filesystems do not distinguish copying a file from other forms of accessing it;
both are done via read(), and both update the file’s access timestamp. (This was experimentally confirmed using the cp command on a Linux 2.6.25 ext3 system.)Windows, however, distinguishes between the two at the system level. Our experiments (performed on a Microsoft Windows XP Professional 5.1.2600 system) confirm that Windows indeed does not update the access timestamp of the source file when copying it, making file copying seemingly invisible.
(bottom of page S73)
Fig. 1 e The left side shows the access timestamp updates that would occur upon copying folder Project Aurora. Updates that would occur on Linux but not on Windows are shown in gray. The right side shows updates thatmight occur during typical user activity, which, unlike folder copying, is selective, temporally irregular, and randomly ordered (see Table 1).
were overlooked. .
What the author says is - as I understand it and in a nutshell
- "most" copy operations are done by selecting as source ENTIRE directories AND a number of subdirectories contained in them
- the mere act of "preparing for copy" will list the contents of each folder in the selected directory tree and this operation does update the timestamp of source folders (NOT files)
- by analyzing the timestamps of the folders and subfolders (NOT of the files) in directory tree it is possible to detemine if that directory tree has been selected for copy
This recursive nature of copying results in an additional trait. To copy a folder, the the system must enumerate the folder’s contents. Modern filesystems implement folders as special types of files called directories; to enumerate a folder’s contents, the system accesses and reads the directory file.
Thus, copying will invariably access a directory before accessing its files and subfolders. What’s more, since this is a data read and not a file copy,Windows NTFS does update the access time of the directory when its contents are enumerated
[/listo]
This behaviour is easily reproducible, and I verified it allright on a test system (still XP Professional).
The flaw in the reasoning is - IMHO - that if you do a
DIR C /Syou will have ALL directories on the volume get a modified Last Access Time, making the whole thing m00t. roll
Same thing is if you do a Search on a whole volume for (say) *.txt, so the article may be valid for a system that is not used "interactively" or that is used to run some very "vertical" apps ONLY.
I.e the issue, even on XP, is in this part
We generally expect a folder to have a number of rarely accessed subfolders, which cause the
cutoff cluster to remain detectable for several weeks ormonths (or until the next act of copying). Conversely, in the absence of copying (or other nonselective, recursive access), we expect to find some folders with access timestamps extending far back in time, consistent with a heavy-tailed distribution.
jaclaz
Good discussion so far )
Agreed.
Based on section 2, I think the testing in the paper was done using Windows XP. It seems the paper does recognize (in section 9) the limitations in newer versions of Windows - even quoting prior work from a certain 'Carvey' 😉
That's the issue…"I think". With the thoroughly academic approach to the paper, one would think that this information would have been clearly stated. Not to take anything away from the work that the author put into the paper, but specifying the OS used it something that we enforce upon the newest analyst when they're writing reports.
Fully agree with the observed shortcomings of the method. In general I still very much like the approach of not looking only at an individual artifact but also at wider trends/patterns - but surely not the holy grail to the 'find evidence button' (yet?)…
I wholeheartedly agree with and support the concept of not relying on a single, individual artifact…always have. If I *think* that something happened because of one artifact, why not confirm with 4 or 5 more, particularly if they're extremely trivial to collect? Or, what if what I *think* happened really didn't, as confirmed by the additional artifacts I found?
I'm an advocate for finding and developing new methods of analysis, particularly because it helps us in the face of counter-forensics techniques that may be employed, no matter how unintentional they may be.
That's the issue…"I think". With the thoroughly academic approach to the paper, one would think that this information would have been clearly stated. Not to take anything away from the work that the author put into the paper, but specifying the OS used it something that we enforce upon the newest analyst when they're writing reports.
Keydet, we probably cross-posted, the used system was XP Professional clearly stated on top left of page S72 of the paper, see my previous post.
jaclaz
jaclaz,
You're absolutely correct, thanks for catching that. I stand corrected regarding the author's identification of the testing platform.
Thanks.
You're absolutely correct, thanks for catching that.
I was referring to the same section - but added to the confusion by using 'I think' 😉
I have sent a quick note to the author of the paper pointing him to this thread - maybe he can add some more clarification or share new insights from his side.
I have re-read the paper, and I did catch where he specified Windows XP Professional. So, we have a method that may help us if the computer is running Windows XP—for what that’s worth…
I see another major shortcoming to this method
Copying a directory to a location appears to update the last accessed time. So, if a user copies a folder structure down off a network drive to their computer, it will leave the same traces this paper is discussing as evidence that files were copied from the computer.
Like everyone else has said–this method can be used in conjunction with other methods (assuming last accessed time is reliable on the system), but it needs to be backed up by other methods to verify.
So, we have a method that may help us if the computer is running Windows XP—for what that’s worth…
I will re-state how the may is actually VERY theoretical, running a DIR /S or using Search to look for a file is something that is normally done on a XP system, if not every day, every other day or weekly.
The approach is IMHO very interesting ) but it may cause in itself any number of "false positives" or be applicable only on a very restricted number of actually running systems/filesystems.
As an example it could be useful on some "server like" machine.
I used to have in the office a small server that was used exclusively to hold (on a RAID) a copy of every day's work, basically each workstation before being shut off ran a robocopy script that synchronized the workstation to the the user folder on the server, thus directory were mainly "written once and forever", and since the only occasion where the data was copied back form the server to a workastation would have been in case of a hard disk failure of the workstation or the user senselessly deleting a file and needing it back, I presume that the directory Last Access Times on this "server" were fairly suitable to an approach like the one depicted in the paper.
(provided that the robocopy routine did not modify Last Access Time of the directories, something that I do not recall nor I have possibility right now to test)
jaclaz
I was discussing this paper with my boss yesterday, and she brought up another good point.
She was working opposite another forensic expert trying to use access times to prove that files had been copied. This was on a Windows XP machine. Through her own testing and after discussions with a Microsoft engineer familiar with this, she determined that even Windows XP access times are not very accurate. Windows XP updates those access times when it feels like it, as much as a full hour after the actual access of the file.
I was discussing this paper with my boss yesterday, and she brought up another good point.
She was working opposite another forensic expert trying to use access times to prove that files had been copied. This was on a Windows XP machine. Through her own testing and after discussions with a Microsoft engineer familiar with this, she determined that even Windows XP access times are not very accurate.
Windows XP updates those access times when it feels like it, as much as a full hour after the actual access of the file.
I haven't personally experimented this type of delay, but it doesn't actually inficiate the approach which is about finding a bunch of subdirectories with the same (or very near) last access time.
I.e. even if the time is not "absolutely" accurate when compared to "real day time", a set of sub-directories with the same (or near) is an indication of
copying (or other nonselective, recursive access)
Right now it seems to me that the approach could be perhaps useful as a "negative proof", in the RARE IMHO cases when - by any chance - a system is found having "only"
folders with access timestamps extending far back in time, consistent with a heavy-tailed distribution.
I.e. the above could be a sign that NO copy activity was performed, but still, if the copy has been made through a method that does not access directory records, we are back exactly at square #1.
jaclaz
[…] Windows XP updates those access times when it feels like it, as much as a full hour after the actual access of the file.
See section 9 in the paper which mentions
Systems may, for performance reasons, defer writing updates of access timestamps to the filesystem. Even when filesystems do maintain accurate access timestamps, they may cache the updates in memory before writing them to a disk (Microsoft Corporation, 2003b).