Tampered Evidence

Howdy,

He believes that they have inserted images, adjusted the timestamps, and then copied that tampered drive to a second drive to make the Encase “Evidence” files from.

What makes the defendant think this? Has a forensic expert been allowed to analyse the process/procedures and the resulting evidence files?

Have you supervised access to the original drive the evidence files were created from? If so can you ask the prosecution to create new evidence under your supervision?

Does the original HDD correspond to that which was seized? Photos, serial number, model etc from the initial acquisition should assist in identifying the drive.

I'm not sure that I get you.

It would be practically impossible to alter the Encase evidence file in the way that you mention, and get a result which would verify and behave as a normal evidence file so as to avoid detection. Moreover, it would be pointless.

It would be much simpler to alter the evidence, itself, and then re-image it.

If this was what was done, then unless you have a hash of the drive as your client last saw it, it would take a bit of effort to prove evidence tampering, but the process would be no different than any other evidence tampering investigation and your conclusions would likely be based upon circumstantial evidence.

Simple fix. MD5 the original exhibit, then compare the hash to the Encase image file. Do your own hash of the image file and compare with the documented hash.

Combined with what Ronan said about checking the chain of custody documentation and photos etc should help.

Insertion of files into a filesystem after seizure with no trace requires a really high level of skill. Check also for references outside of just the filesystem such as MRUs. Getting a file inserted is one thing, but getting the file inserted, and then having OS artifacts created that point to the file, and that themselves aren't obviously tampered with would be a hell of a feat.

Simple fix. MD5 the original exhibit, then compare the hash to the Encase image file. Do your own hash of the image file and compare with the documented hash.

That doesn't do it if they altered the suspect drive before imaging and did not document that in the chain of custody form.

Basically, the problem is the "theory" which is too slight, and sometimes conflicted, on details. Why would they alter the suspect drive and then copy it before imaging? That would be riskier than just altering the subject drive and imaging it, directly.

Simple fix. MD5 the original exhibit, then compare the hash to the Encase image file. Do your own hash of the image file and compare with the documented hash.

That doesn't do it if they altered the suspect drive before imaging and did not document that in the chain of custody form.

Basically, the problem is the "theory" which is too slight, and sometimes conflicted, on details. Why would they alter the suspect drive and then copy it before imaging? That would be riskier than just altering the subject drive and imaging it, directly.

I'm responding to the original post where he says that they altered the Encase image, restored to a 2nd drive, then imaged that to create a new Encase image. You can determine that specific scenario since it doesn't allege alteration of the original HDD. Obviously, alteration of the source is a different issue, which is why I went further in my post to discuss tampering with the original filesystem.

Edit actually, I may have misread his post.

I'm responding to the original post where he says that they altered the Encase image, restored to a 2nd drive, then imaged that to create a new Encase image. You can determine that specific scenario since it doesn't allege alteration of the original HDD. Obviously, alteration of the source is a different issue, which is why I went further in my post to discuss tampering with the original filesystem.

Well, considering that they were supposed to have messed with the Encase image sufficient to insert images (meaning whole files) and alter dates and times (which means tampering with MFT entries), then adjust the CRCs for each altered block and all of this in such a way that Encase would not complain. I'd call that a near impossible feat and a collosal waste of time.

But if they managed to do that, why would they be stupid enough to keep the original evidence around so that you could walk up, grab an MD5 hash, and send them to prison for evidence tampering?

My point, Tony, is that nobody would do it that way.

If you are going to tamper with evidence (and I wouldn't, by the way), then why would you leave such an obvious trail?

If the drive has been viewed on a PC WITHOUT a write blocker device, then it is possible that the MD5 value for the drive could be changed, without any significant change being made. A single bit different, and a new hash value

Is there a log (ideally with file hashes) of the drive as originally obtained?

To try and insert files would probably require the system clock to be changed on the PC, then adding the files. You will need to view all the 'suspect' files with emphasis on create and modify dates. Do they make sense? If a file is added to a PC, then the creation date is the of adding, and not related to the modify date, which is the date the data was last changed.

If someone has been careless, the creation date could be after the drive was seized which could point to tampering.

Subdirectory dates are harder to modify with knowledge.

Another area to investigate is unused MFT entries

Overall, I fear that unless you can find a solid case of tampering, then defense could argue that it was skillfully done in a way that could not be detected. However, defense would also have to prove that the defender could not have come across the files in the first place.

To try and insert files would probably require the system clock to be changed on the PC, then adding the files. You will need to view all the 'suspect' files with emphasis on create and modify dates. Do they make sense? If a file is added to a PC, then the creation date is the of adding, and not related to the modify date, which is the date the data was last changed.

Agreed. And as you mentioned the MFT later on, you'd still have the issue of likely artefacts in the MFT which would point to a time skew (I'm assuming that the drive was not the boot drive when it was alleged to have been altered).

If I were the defense, I'd be looking for malware. Much easier to blame the Ukranians twisted

Here's what threw me in my original response. Why would you tamper with a drive, copy it to another drive, and then create your image from that? I'm not familiar with EnCase's imaging tool, but I know that FTK Imager actually reports the drive make/model and serial number in the imaging log. Therefore if the image comes from a different drive, when you examine the original exhibit, the serial number won't match the SNo in your imaging log. That's going to be a dead giveaway.

You are certainly going to need to revise your theory of the tampering. As Sean said, the most logical way if you were unscrupulous (which I'm not just like Sean) would be to tamper with the evidence on the original drive, and make your image from that. No additional images, no additional drives.

Of course, a really good tampering job would take hours because of having to clean up so many digital footprints made on the way in. With the backlogs most govt forensic labs have these days, I can't see them wasting the time when there are so many other low hanging fruit out there to catch.