±Forensic Focus Partners

Become an advertising partner

±Your Account


Username
Password

Forgotten password/username?

Site Members:

New Today: 0 Overall: 36738
New Yesterday: 0 Visitors: 134

±Follow Forensic Focus

Forensic Focus Facebook PageForensic Focus on TwitterForensic Focus LinkedIn GroupForensic Focus YouTube Channel

RSS feeds: News Forums Articles

±Latest Articles

±Latest Videos

±Latest Jobs

Identifying Files Copied to External Media

Forensic software discussion (commercial and open source/freeware). Strictly no advertising.
Reply to topicReply to topic Printer Friendly Page
Forum FAQSearchView unanswered posts
Page Previous  1, 2 
  

jaclaz
Senior Member
 

Re: Identifying Files Copied to External Media

Post Posted: Aug 11, 19 12:04

@randomaccess
@athulin
Most probably I am missing something, but it seems to me that there is a pre-requisite that it is missing, the actual drive Z:

- JHassell
I have a report from another examiner in which he claims (User X copied file Y to external drive Z on date abc."


Can we state that without the "drive Z:" there is no way on earth to know if someone simply copied a file Y from internal disk?

Now, if from the Registry and some other artifacts on the internal disk filesystem we find that in a matter of minutes:
1) a USB drive/stick has been connected to the machine
2) that USB/drive stick has been assigned drive letter Z:
3) a file C:\mysecretdata.txt has been opened/accessed
4) after a short time, compatible with the time needed to copy a file of the size of C:\mysecretdata.txt
5) a file Z:\mysecretdata.txt has been opened/accessed

one may reasonably presume that the file C:\mysecretdata.txt has been copied to Z:\mysecretdata.txt. but it would be anyway a presumption, logical as much as you want, but nothing that could pass as a statement of fact.

As a matter of fact if all above five points are verified, all that can be said is:
"User X on dd-mm-yyyy at hh-mm-ss accessed file C:\mysecretdata.txt and soon after at hh-mm-yyyy he/she accessed the file Z:\mysecretdata.txt"

I.e. without the source and the destination files, and the possibility to compare them, there is no actual proof that the file is actually the same, at the most it could be a file with the same filename and extension.

But without #3, #4 or #5 even the presumption would be void of any basis.


jaclaz
_________________
- In theory there is no difference between theory and practice, but in practice there is. - 
 
  

randomaccess
Senior Member
 

Re: Identifying Files Copied to External Media

Post Posted: Aug 11, 19 12:24

- athulin

Well, ... that's no testing, that's just a number of statements. You can't even say for what Windows release these statements are valid, and you can't be sure you can repeat the tests to check them.


It is based on testing though
and a number of the instructors will demonstrate the time rules during the class (whilst Im not an instructor yet I do demonstrate this in the link file section for example)

Similarly others, Cyber Forensicator and Sandor Tokesi at Forensic Exchange have done similar testing and posted it online for you to review.

I dont know if the rules have even had to change over the years.

I would like to see more people testing out the rules, perhaps Anders you have some use cases you'd like to work through and publish. I'd be happy to post it as a guest post.


- jaclaz
"User X on dd-mm-yyyy at hh-mm-ss accessed file C:\mysecretdata.txt and soon after at hh-mm-yyyy he/she accessed the file Z:\mysecretdata.txt"


user = user profile from Link/Jumplists/Index.dat/Webcache.dat
dd-mm-yyy at hh-mm-ss - file record creation, lnk file created and/or modified, jumplist dest list entry
location of file when it was last accessed = lnk/jumplist entry

You probably wont get the C:\mysecretdata.txt unless you carve for lnk files. You may find it in webcache.dat but I haven't tested to confirm. The metadata is written in when the file is last accessed.

- jaclaz
at the most it could be a file with the same filename and extension.

You have a little more than that because of shell items (if the file was accessed)
If you assume that OP has the file of interest on the host, you can compare the file name, the modified timestamp, and the size with that found in the shell items for the similarly accessed file on the external media and you'll have a good indication that that file was copied. It becomes increasingly less likely that a file has the *exact* same size and last modified date.

Yes, it would be good to get the suspect media, but bringing it back to the original question, how could another examiner determine based on forensic artefacts indications of file copy, then you hope that the suspect has accessed those files in a method that would create shell items on your host.

Either way, I would implore people to test it, and document what they find  
 
  

jaclaz
Senior Member
 

Re: Identifying Files Copied to External Media

Post Posted: Aug 11, 19 13:24

- randomaccess

You have a little more than that because of shell items (if the file was accessed)
If you assume that OP has the file of interest on the host, you can compare the file name, the modified timestamp, and the size with that found in the shell items for the similarly accessed file on the external media and you'll have a good indication that that file was copied. It becomes increasingly less likely that a file has the *exact* same size and last modified date.


If
. and surely less likely, still ...

Let's say that the file was actually C:\boot\BCD and had 256 KB size.

Would you still be confident to state on a court bench that the file was surely copied to Z: ?

jaclaz
_________________
- In theory there is no difference between theory and practice, but in practice there is. - 
 
  

athulin
Senior Member
 

Re: Identifying Files Copied to External Media

Post Posted: Aug 11, 19 16:51

- randomaccess
It is based on testing though
and a number of the instructors will demonstrate the time rules during the class (whilst Im not an instructor yet I do demonstrate this in the link file section for example)


It may be based on some form of testing, but as long as the test protocol isn't published, it isn't good enough. What sources of errors were present during the test? How was testing managed to reduce those errors to minimum? Were null tests performed? (In this case, this probably includes tests where the copy didn't actually take place, but all other motions up to then were performed. Consider: back in XP days, just moving the cursor over a Windows shell file icon caused its last access time to change. What similar source of errors and misinterpretation are present today?)

All forensic sciences need to be sciences -- and that means designing, performing and publishing tests in a manner that follows scientific principles. (And one of those is that a test should be described in sufficient detail that it can be repeated by someone else.)
When that hasn't happened, the claim of junk science cannot be adequately countered. That's where a number of forensic fields have ended up, and where organizations such as FBI and others have to back off from their earlier statements used and accepted in court, and in some cases helped to produce convictions on bad forensic science. Those are usually the 'wet forensic science', most or all of which are based on medical science. And that's far more science-based than computer forensics has been so far.

See the 'Rules of Time on NTFS' that I mentioned before: that's much closer to what I expect. It's not great on sources of errors, and I have some additional issues with it, but those are more room for improvements than total failures.

Perhaps the SANS results are from some student paper? If so, we're on better grounds -- we have something to read and criticize. But if I recall, the results were just published on the SANS blog with no further details. That's not how computer forensic science should be done. That's not what forensic analysts should be trained to base their work on.


I dont know if the rules have even had to change over the years.


The SANS results changed some years back, I recall. (compare blogs.sans.org/compute...r-2012.pdf .) And as long as Windows is a black box to us, we have to assume that any update may change things, and we have to repeat all our testing to make sure that the platform we're examining have test results. (The option to open the black box may exist, if source code access to Windows still is possible to purchase.)

Please note: this includes Windows Shell, the 'GUI', not just NTFS or other file systems. If a computer has installed some other shell software (CairoShell? SharpEnviro -- probably dead by now? WinNc?) it's up to us as forensic analysts to identify this, and to have test results that show what traces and artifacts user-level copying produces. Interpreting artifacts from WinNc as if they were from Windows Shell may not be a good idea.  
 

Page 2 of 2
Page Previous  1, 2