Identifying Files C...
 
Notifications
Clear all

Identifying Files Copied to External Media

11 Posts
5 Users
0 Likes
6,269 Views
(@jhassell)
Posts: 9
Active Member
Topic starter
 

I have a report from another examiner in which he claims (User X copied file Y to external drive Z on date abc." Because of some issues in the case, I can't demand that they tell me how they got that conclusion.

My question how can you find information about a file being copied to an external drive, including date. I thought it might be in shellbags or usb connections, but what I need is not in either report.

Since this is a common request, especially in my typical client, I'd like to know how they did it. Did I miss a class in forensic school?

Thanks!

 
Posted : 10/08/2019 7:19 pm
(@armresl)
Posts: 1011
Noble Member
 

Too many variables which you can't answer to get help.
You can't tell why or how they arrived at the conclusion they arrived at.
You aren't saying what you have done to try and validate the dates they have (with or without a PC or the image)

If you can post more details you can probably get some help.

I have a report from another examiner in which he claims (User X copied file Y to external drive Z on date abc." Because of some issues in the case, I can't demand that they tell me how they got that conclusion.

My question how can you find information about a file being copied to an external drive, including date. I thought it might be in shellbags or usb connections, but what I need is not in either report.

Since this is a common request, especially in my typical client, I'd like to know how they did it. Did I miss a class in forensic school?

Thanks!

 
Posted : 10/08/2019 8:27 pm
(@jhassell)
Posts: 9
Active Member
Topic starter
 

I cannot ask them and I don't have the image. If I did, I'd probably be able to figure it out.

So my basic question is "Is there a way to find what files were copied to external media?"

I've searched on drive letters, reviewed shellbags and attached USB devices, looked in the event log, along with usual things like find email addresses (just in case he emailed the files), and tried INFO2 files (just in case he deleted after copying).

I'm wondering if they took several artifacts and were reasoning something about them collectively to get their conclusion.

Thanks!

 
Posted : 11/08/2019 5:01 am
(@randomaccess)
Posts: 385
Reputable Member
 

When a user copies a file to a USB device the modified date will predate the creation date.
If the user then accesses those files then the targets MAC times are copied into the link file (note, if you dont want to get caught dont access the files)

A simple method is to extract all the shell items from LNK/Jumplists, filter for external media, look at all the files that were accessed where mod < create and then the create date is the when the file was copied

Similarly when a file is accessed its folder get a link file as well. If mod < create then the whole folder was copied.

Highly recommend testing this out to see how it works in your specific scenario

 
Posted : 11/08/2019 7:02 am
(@athulin)
Posts: 1156
Noble Member
 

A simple method is to extract all the shell items from LNK/Jumplists, filter for external media, look at all the files that were accessed where mod &lt; create and then the create date is the when the file was copied

This seems backwards.

You start from the 'rule' that if file copy is done to external storage, M precedes C in the resulting file copy. (I'm not questioning this for the moment, although I'm not sure there are any published tests done on modern releases of Windows. But that's another issue.)

However, the method you describe goes the other way it says 'if you find files where M < C, then you have a file that has been copied. And that case is not covered by the rule. You have not shown that if M precedes C it can *only* have happened through a file copy, nor even that the *predominantly* do so, if you happen to believe in applying statistic criteria to single cases. (In terms of logic, the implication covered by the rule cannot be extended to the equivalence suggested by your method.)

You may have something that may be a lead and that is worth investigating further, but you do not have enough information to draw a conclusion that these files were copied.

A very old (perhaps even too old, as it refers to tests made on XP SP2 only) paper (Rules of Time on NTFS file system) does have the M < C situation among its rules, but it says

Rule No. 3 In a folder, if files’ M times are before C times and the files have “very close” C times, the files have been
1) copied from one system to the same or another system in a batch or
2) moved from one partition to another partition in a batch or
3) extracted from a compressed file.

However, this 'rule' is valid only within the conditions of the tests they made, described in that paper; it involved only file copy and file move (and some additional operations such as file archive extraction) on a single system (and actually did not clearly involve external storage at all … )

A rule 3 reformulated for general use should include a fourth point "4) or was written to the folder by methods we have not covered in this paper".

 
Posted : 11/08/2019 9:13 am
(@randomaccess)
Posts: 385
Reputable Member
 

I'm not sure there are any published tests done on modern releases of Windows.

There's this
And then my own testing for copying and cutting

According to the poster, the files creation date is set at the creation of the file, and in the event of a copy it's modified date is retained, but the creation is the time of the copy. If the file is cut the created date is inherited but then that wouldn't be shown using the method i described.

As per the document you described, yes the files could have come from a compressed archive, they could also have come from elsewhere and have the same names. You would need to correlate them with the files on the host that are suspected to have been copied.

 
Posted : 11/08/2019 11:33 am
(@athulin)
Posts: 1156
Noble Member
 

There's this

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's on par with the forensic analyst mentioned by the original poster – perhaps this is what he uses for his conclusions.

@OP Don't use that SANS stuff. Not until they publish sufficient information that you can repeat any tests exactly as stated.

And then my own testing for copying and cutting

That looks more like it. Thanks for posting!

 
Posted : 11/08/2019 11:50 am
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

@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

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

 
Posted : 11/08/2019 12:04 pm
(@randomaccess)
Posts: 385
Reputable Member
 

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.

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

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

 
Posted : 11/08/2019 12:24 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

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

 
Posted : 11/08/2019 1:24 pm
Page 1 / 2
Share: