top of page

Evidence of Program Existence - Amcache

A fairly newer artifact, but extremely valuable and important, is the "Amcache" hive. Much like "Shimcache", the Amcache hive can be used to prove that a file had presence or existed on a system. Again, much like Shimcache, there is a lot of confusion surrounding this artifact, though I'm hoping this brief post will help make sense of this fantastic Windows artifact!


The Rundown

  • It's purpose is to provide information regarding installed applications, drivers, and executables; this includes install dates, versions, etc.

  • Used for compatibility on newer Windows systems

  • Despite the "category" that books/courses place this artifact in, it cannot and should not be used for proof that an application/program was executed

  • From a forensics perspective, it's used to show that a file/program had presence on a system

  • Can provide the SHA1 hash of a file, if recorded

  • Records the full path of a file, last modified time, publisher information, size, and potentially the compilation time

  • Replaced the previous Windows artifact 'RecentFileCache.bcf'

  • Found on Windows 7+ (Originally was on Windows 8+, but can now be found on Windows 7+)

  • Information is contained in a registry hive file

  • Requires a forensics tool to parse

  • Located in C:\Windows\AppCompat\Programs

    • Amcache.hve

  • Entries within this hive file can be updated by automated tasks and scanning conducted by the OS, hence why this cannot be used to prove program execution

    • Microsoft Compatibility Appraiser (scheduled task)


Confused yet?! Hopefully not! As mentioned though, this artifact can be very misunderstood with the amount of information and categorization that blogs/courses/videos place around this. To make matters worse, this artifact has been updated a number of times by Microsoft! Which has changed a bit of the information contained within this hive. With this said, let's jump right in!


Let us get this part out of the way up front. The Amcache hive cannot be used to 100% confirm that an application was executed and at what time it was executed. Why is this? Well.. In order for your Operating System (OS) to determine if an application is compatibible or not, an automated scheduled task is executed to gather information regarding files found within the Program Files, Program Files x86 and your Desktop directories in an effort to gather and record information regarding these files; once scanned, the entries are placed within the Amcache hive; with this said, the timestamps you're looking at, may be timestamps of when the file was scanned by this task. The file may not have ever been executed, but maintained presence on the system and was scanned by this task. Don't believe me? Open up your Windows Task Scheduler and navigate to Microsoft > Windows > Application Experience. Here, you'll see a task named 'Microsoft Compatibility Appraiser'.



As mentioned, this artifact was originally found on Windows 8 and newer systems; however, with recent updates, this artifact can now be found on Windows 7 systems, of course depending on which update/patch is present on the Operating System (OS). From a forensics perspective, this hive can contain very useful information, specifically, the SHA1 hash, which is a very unique attribute in terms of Windows forensics artifacts.


So, why do we care about installed applications and drivers? Well... I'm glad you asked! From a forensics perspective, this information can contribute to the overall threat intelligence collection to assist with scoping/hunting efforts. For example, if a malicious tool/program was installed, we may be able to collect the hash of that file which can be fed into endpoint tools to assist with scoping efforts! This is particularly applicable to instances where you are collecting "triage" captures and may not be collecting a full disk image or all files on the system; Additionally, as an analyst, you'll be creating a timeline of findings that will help tell the story of the incident; with this said, having timestamps of when the program/file was installed, can contribute to this timeline. Maybe a file was renamed? Well, with having the publisher information and the SHA1 hash, we may be able to determine that the file we actually thought was a legitimate version of 'svchost', is actually malware!

Let's briefly jump into what is being recorded with the Amcache artifact:

  • Installed applications/programs

  • Programs that may have been executed

  • Loaded drivers

  • Product name

  • Binary type

  • File Name

  • Product version

  • Publisher information

  • SHA1 hash

  • Modified timestamp of driver

  • Is the driver signed?

  • Metadata of driver

  • path

  • file size

  • Compilation time

  • Language ID

  • and more!


See what I mean when I say how fantastic and useful this artifact is?! It contains many unique indicators that might not be recorded with other Windows artifacts. For example, you need to check if a file named "AnyDesk" was installed and when? Check the Amcache! Think that malicious drivers were loaded with installed software? Amcache! Curious what version of software was running to help theorize that a potential exploit was used? Amcache again!


Let's take a look at this artifact! As mentioned earlier, you'll need a forensics tool to more easily parse this hive. You also won't be able to analyze this on a live system, as it's going to be locked by the OS and in use. So how can we analyze this then? Well, you can collect this with a forensics tool such as Autopsy or you can collect this via the amazing tool "KAPE", by Eric Zimmerman from Kroll. KAPE has the capability to bypass and collect locked files that are in use by the OS. So let's run KAPE and collect this hive to analyze it. Note that just like a standard registry hive, such as Security, Software, System, SAM, you'll want to grab the "LOG" files as well, as this can be replayed by most tools to ensure you have the most up-to-date data.



Perfect! Although we'll discuss easier ways to analyze this data, let's start by manually reviewing it with a registry forensics tool called "Registry Explorer", also by Eric Zimmerman!



Let's first take a look at the common "InventoryApplicationFile" key, as this contains subkeys regarding the installed applications. Let's open one of these subkeys for an installed application and take a look at what data is shown.



Again, please take caution when analyzing the timestamps associated with these subkeys. As mentioned, the registry key last modified timestamps could be represented by when the earlier mentioned scheduled task scanning the file.



Remember that I mentioned that Amcache can record information regarding drivers? Well.. what do we think that the "InventoryDriverBinary" subkey contains? Driver information!



Feel free to parse through the remaining keys and subkeys to see what other goodies you can find here! However, as mentioned, there's a much easier way to parse this artifact. Enter, yet ANOTHER Eric Zimmerman tool, 'Amcache Parser'. Let's run this tool against the collected Amcache hive by running the following command:


Amcacheparser.exe -i -f AmcacheHiveHere.hve --csv C:\location_here

We'll quickly break down this syntax for informational purposes.

  • -i will tell the tool to include full information on installed applications

  • -f is the hive to parse

  • --csv is the format type

  • C:\Location_here represents the output location of where you want to send the output CSV files


Take a look at the created CSV files. The tool will attempt to categorize many of the identified data into various files. Although all of these files should be reviewed, here, we'll focus on the Program Entries, Associated File Entries, and Unassociated file entries files, as these contain information regarding observed programs. Please note that the "Associated file entries" are often listed as installed applications, whereas "Unassociated" is often related to files not part of an installation file, such as standalone executables.



From here, we can use this data to pivot and guide our analysis; for example, timestamps, bad file hashes, unsigned drivers/binaries, suspicious paths, etc.


If not added already, be sure to add this artifact to your collections!




Comentarios


bottom of page