KAPE hash of $MFT not matching

[dptom24]

KAPE version

KAPE version 1.1.0.0

Describe the bug

Used KAPE to perform triage acquisition running kape.exe --tsource C: --tdest E:\Images\Working_Images\SHLD001\4-Triage --tflush --target !SANS_Triage

Used Hasher to calculate hashes over the collected C:\ volume.

Opened ConsoleLog.txt for collection. Value of sampled files matched hashes calculated by Hasher except the $MFT. See screenshot.

To Reproduce

Steps to reproduce the behavior: See steps noted above

Expected behavior

I expect the value of the sha1 base16 hash calculated by both PowerShell and Hasher to match the value noted in CopyLog.txt file. It doesn't.

Screenshots

Screenshot added above.

Additional context

None

[AndrewRathbun]

I provided a response here, for posterity. However, ultimately will defer to @EricZimmerman for guidance.

[EricZimmerman]

does it happen every time, or just once?

the data being hashed by KAPE is what is read during the copy. have you tried DIFFING the files to see what is different? use beyond compare or similar. youd obviously need to do this against an E01 vs live as a test.

why are you using TLE 1.3?

[EricZimmerman]

just did a test. worked fine

[dptom24]

Eric, Thanks. I’ll setup and run a few more tests when I’m back from a doctor’s appointment (approx 13:30 PDT). I have just made an extract by using target mode on KAPE over an E01 mounted with Arsenal Image Mounter. I’ll finish checking that when I get back.

On your question on TLE 1.3, this is a symptom of working for a State school with a State run IT department. I can only make changes to lab machines on the 1 Nov of each year. So I update the investigative platform environment that gets installed in the student lab. The IT guys freeze the image of the VM’s on that date. Then on about a bi-weekly basis, the systems reboot and return to their exact frozen state. I know this sound like an excuse, but the State of California is a nightmare to deal with. I also teach at UNLV and have superior control of the student labs.

I’ll follow up.

On Mon, Aug 21, 2023 at 10:23 Eric @.***> wrote:

just did a test. worked fine

[image: image] https://user-images.githubusercontent.com/4265254/262098088-e8f4153f-0eca-4411-aab5-cbfde7e92265.png

— Reply to this email directly, view it on GitHub https://github.com/EricZimmerman/KapeFiles/issues/858#issuecomment-1686736076, or unsubscribe https://github.com/notifications/unsubscribe-auth/AWXEYPTO3X5ANYRXW66FTOLXWOKQNANCNFSM6AAAAAA3YS7NTA . You are receiving this because you authored the thread.Message ID: @.***>

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

[dptom24]

Eric,

Here are the results of the test.

Test 1 steps: (1) Using FTK Imager, created full E01 of subject system. (2) Mounted E01 using Arsenal Image Mounter as drive volume F:. (3) Used kape to extract $MFT from drive F: Command line: --tsource F: --tdest "E:\Cases\SHLD001\Extracted Files" --target $MFT. (4) Opened Kape copy log and used powershell Get-FileHash to calculate the hash of the extracted $MFT. The image shows the hashes matched.

[image: E01-test.png]

Test-2 Live system extraction. (1) Connected USB drive to live subject system to collect triage image. (2) Collected triage image of the subject system using Kape running with --target !SANS_Triage. (3) opened up the copylog file and filtered to show only $MFT. (4) Use PowerShell Get-FileHash to calculate the hash of the $MFT collected as part of the triage. Hashes do not match.

[image: Live-TargetModeAcquisition.png]

After this second test, I randomly selected files from \Windows\System32\config and from \Windows\System32\winevt and from the Root. Here's a sample of the results. The files that I randomly selected and all of the C:\$ files had matching hashes, the $MFT looks like the only file that had an issue. I'm leaning heavily on the suggestion by Andrew that the dynamics of the $MFT are causing a problem, but is it reasonable that the copied out file changed from the time the Kape calculated the hash until it was actually copied? Here are a few more screenshots of my controlled testing. . .

[image: winevt-random-hashes-copyLog.png]

[image: winevt-random-hashes.png]

[image: Root$-random-hashes.png]

Hope this helps describe the issue. I'm running a diff of the E01 version and the Kape sourced version, but I'm not certain what this is going to show.

Best,

---

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

On Tue, Aug 22, 2023 at 11:35 AM Tom Arnold @.***> wrote:

Eric, Thanks. I’ll setup and run a few more tests when I’m back from a doctor’s appointment (approx 13:30 PDT). I have just made an extract by using target mode on KAPE over an E01 mounted with Arsenal Image Mounter. I’ll finish checking that when I get back.

On your question on TLE 1.3, this is a symptom of working for a State school with a State run IT department. I can only make changes to lab machines on the 1 Nov of each year. So I update the investigative platform environment that gets installed in the student lab. The IT guys freeze the image of the VM’s on that date. Then on about a bi-weekly basis, the systems reboot and return to their exact frozen state. I know this sound like an excuse, but the State of California is a nightmare to deal with. I also teach at UNLV and have superior control of the student labs.

I’ll follow up.

On Mon, Aug 21, 2023 at 10:23 Eric @.***> wrote:

just did a test. worked fine

[image: image] https://user-images.githubusercontent.com/4265254/262098088-e8f4153f-0eca-4411-aab5-cbfde7e92265.png

— Reply to this email directly, view it on GitHub https://github.com/EricZimmerman/KapeFiles/issues/858#issuecomment-1686736076, or unsubscribe https://github.com/notifications/unsubscribe-auth/AWXEYPTO3X5ANYRXW66FTOLXWOKQNANCNFSM6AAAAAA3YS7NTA . You are receiving this because you authored the thread.Message ID: @.***>

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

[EricZimmerman]

Won't be able to do anything else with this until you are using the latest version of kape.

1.1 is ancient. It was released in Nov of 2021.

You are at a significant disadvantage being able to update once a year. That's bad policy. 😞

[dptom24]

Updating to test my environment again. When we do the KAPE sections of the class, I'll have an updated version of the tool for the students. I'll be updating the other tools as well. Stand by.

---

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

On Tue, Aug 22, 2023 at 3:56 PM Eric @.***> wrote:

Won't be able to do anything else with this until you are using the latest version of kape.

1.1 is ancient. It was released in Nov of 2021.

You are at a significant disadvantage being able to update once a year. That's bad policy. 😞

— Reply to this email directly, view it on GitHub https://github.com/EricZimmerman/KapeFiles/issues/858#issuecomment-1689029468, or unsubscribe https://github.com/notifications/unsubscribe-auth/AWXEYPUUOCZSGHROBAEYZM3XWU2ILANCNFSM6AAAAAA3YS7NTA . You are receiving this because you authored the thread.Message ID: @.***>

[AndrewRathbun]

I'm curious what the console log states is the time of hashing and time of copying. Might need to use debug messages. If it's a bit of time, then I suppose it could be reasonable to say that activity occurred within the $MFT during the time. One way to test may be to use ProcMon while acquiring the $MFT with KAPE and look for relevant API calls or files that would support the theory that the $MFT was updated between time of hashing and acquisition.

[dptom24]

Eric and Andrew,

Sorry if I'm wasting your time on this. Just an update. I've upgraded all of the tools to the most current version for Kape and TLE. I just pulled a new copy of the $MFT from the subject system. This is a live triage-style acquisition and I only pulled the $MFT. As the image shows, the hashes do not match. I've included a dump of the console log as well to show the timestamps. I'm again drawing the assumption that the $MFT must be changing between the time it was deferred until the time of copy out.

[image: Live-TargetModeAcquisition.png]

---

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

On Tue, Aug 22, 2023 at 4:32 PM Andrew Rathbun @.***> wrote:

I'm curious what the console log states is the time of hashing and time of copying. Might need to use debug messages. If it's a bit of time, then I suppose it could be reasonable to say that activity occurred within the $MFT during the time. One way to test may be to use ProcMon while acquiring the $MFT with KAPE and look for relevant API calls or files that would support the theory that the $MFT was updated between time of hashing and acquisition.

— Reply to this email directly, view it on GitHub https://github.com/EricZimmerman/KapeFiles/issues/858#issuecomment-1689055200, or unsubscribe https://github.com/notifications/unsubscribe-auth/AWXEYPRFNRGRLG425E3OSUDXWU6SLANCNFSM6AAAAAA3YS7NTA . You are receiving this because you authored the thread.Message ID: @.***>

[AndrewRathbun]

Eric and Andrew,

Sorry if I'm wasting your time on this. Just an update. I've upgraded all of the tools to the most current version for Kape and TLE. I just pulled a new copy of the $MFT from the subject system. This is a live triage-style acquisition and I only pulled the $MFT. As the image shows, the hashes do not match. I've included a dump of the console log as well to show the timestamps. I'm again drawing the assumption that the $MFT must be changing between the time it was deferred until the time of copy out.

[image: Live-TargetModeAcquisition.png]

---

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

On Tue, Aug 22, 2023 at 4:32 PM Andrew Rathbun @.***> wrote:

I'm curious what the console log states is the time of hashing and time of copying. Might need to use debug messages. If it's a bit of time, then I suppose it could be reasonable to say that activity occurred within the $MFT during the time. One way to test may be to use ProcMon while acquiring the $MFT with KAPE and look for relevant API calls or files that would support the theory that the $MFT was updated between time of hashing and acquisition.

— Reply to this email directly, view it on GitHub https://github.com/EricZimmerman/KapeFiles/issues/858#issuecomment-1689055200, or unsubscribe https://github.com/notifications/unsubscribe-auth/AWXEYPRFNRGRLG425E3OSUDXWU6SLANCNFSM6AAAAAA3YS7NTA . You are receiving this because you authored the thread.Message ID: @.***>

No worries and we appreciate the discussion. Since this is all open to the public, anyone who stumbles upon this thread can benefit.

One thing you can do is acquire and parse the MFT from the live system, then parse the MFT again from the live system and diff the output to see what changed. I would recommend running KAPE from a USB drive and outputting the CSV to somewhere other than the live system itself so as to minimize the impact to the file system's content, which directly impacts the MFT.

So long as 99.9% of the output is similar, then I'd say you have a forensically defensible explanation for the hash mismatch. The exercise should give you comfort on the stand if you were ever asked about that particular data point.

[dptom24]

Agreed on the process. That is the method that I used. KAPE was run from a mounted response USB drive on the subject system and only performed the extract of the $MFT to that USB drive. The drive was unmounted and then examined in a separate system. Your suggestion of doing the DIFF between the two is very good and I'll examine that.

Thanks for the help.

---

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

On Thu, Aug 24, 2023 at 9:33 AM Andrew Rathbun @.***> wrote:

Eric and Andrew,

Sorry if I'm wasting your time on this. Just an update. I've upgraded all of the tools to the most current version for Kape and TLE. I just pulled a new copy of the $MFT from the subject system. This is a live triage-style acquisition and I only pulled the $MFT. As the image shows, the hashes do not match. I've included a dump of the console log as well to show the timestamps. I'm again drawing the assumption that the $MFT must be changing between the time it was deferred until the time of copy out.

[image: Live-TargetModeAcquisition.png]

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

On Tue, Aug 22, 2023 at 4:32 PM Andrew Rathbun @.***> wrote:

I'm curious what the console log states is the time of hashing and time of copying. Might need to use debug messages. If it's a bit of time, then I suppose it could be reasonable to say that activity occurred within the $MFT during the time. One way to test may be to use ProcMon while acquiring the $MFT with KAPE and look for relevant API calls or files that would support the theory that the $MFT was updated between time of hashing and acquisition.

— Reply to this email directly, view it on GitHub

858 (comment)

https://github.com/EricZimmerman/KapeFiles/issues/858#issuecomment-1689055200 , or unsubscribe

https://github.com/notifications/unsubscribe-auth/AWXEYPRFNRGRLG425E3OSUDXWU6SLANCNFSM6AAAAAA3YS7NTA . You are receiving this because you authored the thread.Message ID: @.***>

No worries and we appreciate the discussion. Since this is all open to the public, anyone who stumbles upon this thread can benefit.

One thing you can do is acquire and parse the MFT from the live system, then parse the MFT again from the live system and diff the output to see what changed. I would recommend running KAPE from a USB drive and outputting the CSV to somewhere other than the live system itself so as to minimize the impact to the file system's content, which directly impacts the MFT.

So long as 99.9% of the output is similar, then I'd say you have a forensically defensible explanation for the hash mismatch. The exercise should give you comfort on the stand if you were ever asked about that particular data point.

— Reply to this email directly, view it on GitHub https://github.com/EricZimmerman/KapeFiles/issues/858#issuecomment-1692035308, or unsubscribe https://github.com/notifications/unsubscribe-auth/AWXEYPQCQHVPPR4AEDBDMWLXW5635ANCNFSM6AAAAAA3YS7NTA . You are receiving this because you authored the thread.Message ID: @.***>

[AndrewRathbun]

Good deal, please report back and good luck!

[dptom24]

I ran again using the --target FileSystem compound object and all of the hashes matched. So I'm good and feel that this might be a timing or race condition on when the $MFT is copied. Just my two cents

---

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

On Thu, Aug 24, 2023 at 9:46 AM Andrew Rathbun @.***> wrote:

Good deal, please report back and good luck!

— Reply to this email directly, view it on GitHub https://github.com/EricZimmerman/KapeFiles/issues/858#issuecomment-1692061071, or unsubscribe https://github.com/notifications/unsubscribe-auth/AWXEYPURFZJ4SAGHYBIBOWLXW6AONANCNFSM6AAAAAA3YS7NTA . You are receiving this because you authored the thread.Message ID: @.***>

[AndrewRathbun]

Sounds good! Thanks for following up! Cheers