search

AndrewRathbun / Awesome-KAPE

A curated list of KAPE-related resources
MIT License
158 stars 15 forks source link

KAPE hash on $MFT not matching #5

Closed dptom24 closed 1 year ago

dptom24 commented 1 year ago

After performing triage collection, used Hasher to calculate hashes on the $MFT and then compared to CopyLog. Values do not match. KAPE-MFT-Hashes

AndrewRathbun commented 1 year ago

Hello. Since this is related to EZ Tools, you may want to make an Issue in the appropriate repo, which you can find here.

For KAPE-related issues, you can use this repo here.

AndrewRathbun commented 1 year ago

That being said, consider that when KAPE hashes the $MFT may be earlier than when the file is actually copied from disk, and in the time, however brief it may be, there may be changes to the $MFT at the time of hashing and the time of copying. The $MFT is a live file that is constantly being accessed, written to, read from, etc, so that may explain the delta here.

dptom24 commented 1 year ago

Thanks Andrew. That is my general belief that the copying is actually deferred and the MFT may actually change during the process. Any thoughts on ways to prove this.

Tom Arnold,CISSP, ISSMP, CFS, CISA, GCFE-GOLD, GNFA, GBFA Lecturer, Digital Evidence Digital Forensics San Jose State University Justice Studies E: @.***

On Mon, Aug 21, 2023 at 8:59 AM Andrew Rathbun @.***> wrote:

That being said, consider that when KAPE hashes the $MFT may be earlier than when the file is actually copied from disk, and in the time, however brief it may be, there may be changes to the $MFT at the time of hashing and the time of copying. The $MFT is a live file that is constantly being accessed, written to, read from, etc, so that may explain the delta here.

— Reply to this email directly, view it on GitHub https://github.com/AndrewRathbun/Awesome-KAPE/issues/5#issuecomment-1686600491, or unsubscribe https://github.com/notifications/unsubscribe-auth/AWXEYPQLSN4YXX7BL5OHZEDXWOAXNANCNFSM6AAAAAA3YSVY5E . You are receiving this because you authored the thread.Message ID: @.***>

AndrewRathbun commented 1 year ago

Thanks Andrew. That is my general belief that the copying is actually deferred and the MFT may actually change during the process. Any thoughts on ways to prove this. … -- -- Tom Arnold,CISSP, ISSMP, CFS, CISA, GCFE-GOLD, GNFA, GBFA Lecturer, Digital Evidence Digital Forensics San Jose State University Justice Studies E: @. On Mon, Aug 21, 2023 at 8:59 AM Andrew Rathbun @.> wrote: That being said, consider that when KAPE hashes the $MFT may be earlier than when the file is actually copied from disk, and in the time, however brief it may be, there may be changes to the $MFT at the time of hashing and the time of copying. The $MFT is a live file that is constantly being accessed, written to, read from, etc, so that may explain the delta here. — Reply to this email directly, view it on GitHub <#5 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AWXEYPQLSN4YXX7BL5OHZEDXWOAXNANCNFSM6AAAAAA3YSVY5E . You are receiving this because you authored the thread.Message ID: @.***>

One option could be to take a forensic image of the host and then acquire the $MFT from the image because that'll be a static dataset.

dptom24 commented 8 months ago

I've included a screenshot as an example. The first record in hasher, is a hash of the $MFT extracted with FTK imager from a full image of the subject disk. The second hash in hasher, is the hash from the kape target extracted $MFT and the final image in Timeline Explorer is the KAPE reported hash.

Any thoughts on how I can explain this.

Tom Arnold,CISSP, ISSMP, CFS, CISA, GCFE-GOLD, GNFA, GBFA Lecturer, Digital Evidence Digital Forensics San Jose State University Justice Studies E: @.***

AndrewRathbun commented 8 months ago

I've included a screenshot as an example. The first record in hasher, is a hash of the $MFT extracted with FTK imager from a full image of the subject disk. The second hash in hasher, is the hash from the kape target extracted $MFT and the final image in Timeline Explorer is the KAPE reported hash.

Any thoughts on how I can explain this.

Tom Arnold,CISSP, ISSMP, CFS, CISA, GCFE-GOLD, GNFA, GBFA Lecturer, Digital Evidence Digital Forensics San Jose State University Justice Studies E: @.***

I would suggest taking the MFT from FTK and MFT from KAPE and see if they're the exact same file. Is FTK extracting the file using the same method KAPE does? As we all know, if one single bit is different, then the hashes won't match. That very well could be the explanation. As long as the MFT records of interest are both present and you can testify that they're from the same image using different methods, then that's really all you can do IMHO. Thoughts?