Join Us!

Identifying Files C...
 
Notifications
Clear all

Identifying Files Copied to External Media  

  RSS
JHassell
(@jhassell)
New Member

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!

Quote
Posted : 10/08/2019 8:19 pm
armresl
(@armresl)
Community Legend

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!

ReplyQuote
Posted : 10/08/2019 9:27 pm
JHassell
(@jhassell)
New Member

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!

ReplyQuote
Posted : 11/08/2019 6:01 am
randomaccess
(@randomaccess)
Active 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

ReplyQuote
Posted : 11/08/2019 8:02 am
athulin
(@athulin)
Community Legend

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

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

ReplyQuote
Posted : 11/08/2019 10:13 am
randomaccess
(@randomaccess)
Active 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.

ReplyQuote
Posted : 11/08/2019 12:33 pm
athulin
(@athulin)
Community Legend

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!

ReplyQuote
Posted : 11/08/2019 12:50 pm
jaclaz
(@jaclaz)
Community Legend

@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

ReplyQuote
Posted : 11/08/2019 1:04 pm
randomaccess
(@randomaccess)
Active 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

ReplyQuote
Posted : 11/08/2019 1:24 pm
jaclaz
(@jaclaz)
Community Legend

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

ReplyQuote
Posted : 11/08/2019 2:24 pm
athulin
(@athulin)
Community Legend

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 https://blogs.sans.org/computer-forensics/files/2012/06/SANS-Digital-Forensics-and-Incident-Response-Poster-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.

ReplyQuote
Posted : 11/08/2019 5:51 pm
Share: