I've had an opportunity to examine some Windows 10 systems lately, and recently got a chance to examine a Windows 2012 server system. While I was preparing to examine the Windows 2012 system, I extracted a number of files from the image, in order to incorporate the data in those files into a timeline for analysis. I also grabbed the AmCache.hve file (I've blogged about this file previously...), and parsed it using the amcache.pl RegRipper plugin. What I'm going to do in this post is walk through an example of something I found after the initial analysis,
From the ShimCache data from the system, I found the following reference:
SYSVOL\Users\Public\Downloads\badfile.exe Fri Jan 13 11:16:40 2017 Z
Now, we all know that the time stamp associated with the entry in the ShimCache data is the file system last modification time of the file (NOT the execution time), and that if you create a timeline, this data would be best represented by an entry that includes "M..." to indicate the context of the information.
I then looked at the output of the amcache.pl plugin to see if there was an entry for this file, and I found the following:
File Reference : 720000150e1
LastWrite : Sun Jan 15 07:53:53 2017 Z
Path : C:\Users\Public\Downloads\badfile.exe
Company Name : FileManger
Product Name : Fileppp
File Descr : FileManger
Lang Code : 0
SHA-1 : 00002861a7c280cfbb10af2d6a1167a5961cf41accea
Last Mod Time : Fri Jan 13 11:16:40 2017 Z
Last Mod Time2: Fri Jan 13 11:16:40 2017 Z
Create Time : Sun Jan 15 07:53:26 2017 Z
Compile Time : Fri Jan 13 03:16:40 2017 Z
We know from Yogesh's research that the "File Reference" is the file reference number from the MFT; that is, the sequence number and the MFT record number. In the above output, the "LastWrite" entry is the LastWrite time for the key with the name referenced in the "File Reference" entry. You'll also notice some additional information that could be pretty useful...some of it (Lang Code, Product Name, File Descr) were values that I added to the plugin today (I also updated the plugin repository on GitHub, as well).
You'll also notice that there are a few time stamps, in addition to the key LastWrite time. I thought that it would be interesting to see what effect those time stamps would have on a timeline; so, I wrote a new plugin (amcache_tln.pl, also uploaded to the repository today) that would allow me to add data to my timeline. After adding the AmCache.hve time stamp data to my timeline, I went looking for
Sun Jan 15 07:53:53 2017 Z
AmCache - Key LastWrite - 720000150e1:C:\Users\Public\Downloads\badfile.exe
REG User - [Program Execution] UserAssist - C:\Users\Public\Downloads\badfile.exe (1)
Sun Jan 15 07:53:26 2017 Z
AmCache - ...B 720000150e1:C:\Users\Public\Downloads\badfile.exe
FILE - .A.B [286208] C:\Users\Public\Downloads\badfile.exe
Fri Jan 13 11:16:40 2017 Z
FILE - M... [286208] C:\Users\Public\Downloads\badfile.exe
AmCache - M... 720000150e1:C:\Users\Public\Downloads\badfile.exe
Fri Jan 13 03:16:40 2017 Z
AmCache - PE Compile time - 720000150e1:C:\Users\Public\Downloads\badfile.exe
Clearly, a great deal more analysis and testing needs to be performed, but this timeline excerpt illustrates some very interesting findings. For example, the AmCache entries for the M and B dates line up with those from the MFT.
Something else that's very interesting is that the AmCache key LastWrite time appears to correlate to when the file was executed by the user.
For the sake of being complete, let's take the parsed MFT entry for the file:
86241 FILE Seq: 114 Links: 1
[FILE],[BASE RECORD]
.\Users\Public\Downloads\badfile.exe
M: Fri Jan 13 11:16:40 2017 Z
A: Sun Jan 15 07:53:26 2017 Z
C: Fri Feb 10 11:37:25 2017 Z
B: Sun Jan 15 07:53:26 2017 Z
FN: badfile.exe Parent Ref: 292/1
Namespace: 3
M: Sun Jan 15 07:53:26 2017 Z
A: Sun Jan 15 07:53:26 2017 Z
C: Sun Jan 15 07:53:26 2017 Z
B: Sun Jan 15 07:53:26 2017 Z
[$DATA Attribute]
File Size = 286208 bytes
We know we have the right file...if we convert the MFT record number (86241) to hex, and prepend it with the sequence number (also converted to hex), we get the file reference number from the AmCache.hve file. We also see that the creation date for the file is the same in both the $STANDARD_INFORMATION and $FILE_NAME attributes from the MFT record, and they're also the same as the value extracted from the AmCache.hve file.
There definitely needs to be more research and work done, but it appears that the AmCache data may be extremely valuable with respect to files that no longer exist on the system, particularly if (and I say "IF") the key LastWrite time corresponds to the first time that the file was executed. Review of data extracted from a Windows 10 system illustrated similar findings, in that the key LastWrite time for a specific file reference number correlated to the same time that an "Application Popup/1000" event was recorded in the Application Event Log, indicating that the application had an issue; four seconds later, events (EVTX, file system) indicated an application crash. I'd like to either work an engagement where process creation information is also available, or conduct testing and analysis of a Win2012 or Win10 system that has Sysmon installed, as it appears that this data may indicate/correlate to a program execution finding.
Now, clearly, the AmCache.hve file can contain a LOT of data, and you might not want it all. You can minimize what's added to the timeline by using the reference to the "Public\Downloads" folder, for example, as a pivot point. You can run the plugin and pipe the output through the find command to get just those entries that include files in the "Public\Downloads" folder in the following manner:
rip -r amcache.hve -p amcache_tln | find "public\downloads" /i
An alternative is to run the plugin, output all of the entries to a file, and then use the type command to search for specific entries:
rip -r amcache.hve -p amcache_tln > amcache.txt
type amcache.txt | find "public\downloads" /i
Either one of these two methods will allow you to minimize the data that's incorporated into a timeline and create overlays, or simply create micro-timelines solely from data within the AmCache.hve file.
Oh, and hey...more information on language ID codes can be found here and here.
Addendum: Additional Sources
So, I'm not the first one to mention the use of AmCache.hve entries to illustrate program execution...others have previously mentioned this artifact category:
Digital Forensics Survival Podcast episode #020
Willi's amcache.py parser
hello Harlan
ReplyDeleteI also have a parser and more info here:
https://binaryforay.blogspot.com/2015/07/amcacheparser-reducing-noise-finding.html
I have done a webinar with a ton more details here:
https://www.youtube.com/watch?v=iTchBtRr6TA
Thanks for the post!
Hi Harlan,
ReplyDeleteAny plan for an updated version of the amcache plugin to support Win8 / Win10 / Win2K16 ?
Would be very useful.
I'm not sure how it doesn't support Win10 now.
ReplyDeleteFor the other OS versions, I don't have any sample data because I don't have access to such systems. Until that happens, I can't test such a plugin to ensure it works correctly.
Thanks!
windows 10 has added at least 1 additional, massive change to amcache.hve. only very old windows 10 systems will be using the old format. the new format is way different. no more MFT info for example in the key names, etc.
ReplyDeleteif you have a newer win10 box or win11, try amacacheparser.exe and it will determine if its old or new format and dump the appropriate CSVs.
loading the hives into Registry Explorer will also show the differences.
here is a blog post of mine explaining the differences
https://binaryforay.blogspot.com/2017/10/amcache-still-rules-everything-around.html
and amcacheparser is open source on my github profile as well.
Eric,
ReplyDeleteDo you have sample data available somewhere for testing?
Thanks!