Introduction

Windows 11 was released a few years ago, yet it has seen relatively weak enterprise adoption. According to statistics from our Global Emergency Response Team (GERT) investigations, as recently as early 2025, we found that Windows 7, which reached end of support in 2020, was encountered only slightly less often than the newest operating system. Most systems still run Windows 10.

Distribution of Windows versions in organizations’ infrastructure. The statistics are based on the Global Emergency Response Team (GERT) data (download)

The most widely used operating system was released more than a decade ago, and Microsoft discontinues its support on October 14, 2025. This means we are certainly going to see an increase in the number of Windows 11 systems in organizations where we provide incident response services. This is why we decided to offer a brief overview of changes to forensic artifacts in this operating system. The information should be helpful to our colleagues in the field. The artifacts described here are relevant for Windows 11 24H2, which is the latest OS version at the time of writing this.

What is new in Windows 11

Recall

The Recall feature was first introduced in May 2024. It allows the computer to remember everything a user has done on the device over the past few months. It works by taking screenshots of the entire display every few seconds. A local AI engine then analyzes these screenshots in the background, extracting all useful information, which is subsequently saved to a database. This database is then used for intelligent searching. Since May 2025, Recall has been broadly available on computers equipped with an NPU, a dedicated chip for AI computations, which is currently compatible only with ARM CPUs.

Microsoft Recall is certainly one of the most highly publicized and controversial features announced for Windows 11. Since its initial reveal, it has been the subject of criticism within the cybersecurity community because of the potential threat it poses to data privacy. Microsoft refined Recall before its release, yet certain concerns remain. Because of its controversial nature, the option is disabled by default in corporate builds of Windows 11. However, examining the artifacts it creates is worthwhile, just in case an attacker or malicious software activates it. In theory, an organization’s IT department could enable Recall using Group Policies, but we consider that scenario unlikely.

As previously mentioned, Recall takes screenshots, which naturally requires temporary storage before analysis. The raw JPEG images can be found at %AppData%\Local\CoreAIPlatform.00\UKP\{GUID}\ImageStore\*. The filenames themselves are the screenshot identifiers (more on those later).

Along with the screenshots, their metadata is stored within the standard Exif.Photo.MakerNote (0x927c) tag. This tag holds a significant amount of interesting data, such as the boundaries of the foreground window, the capture timestamp, the window title, the window identifier, and the full path of the process that launched the window. Furthermore, if a browser is in use during the screenshot capture, the URI and domain may be preserved, among other details.

Recall is activated on a per-user basis. A key in the user’s registry hive, specifically Software\Policies\Microsoft\Windows\WindowsAI\, is responsible for enabling and disabling the saving of these screenshots. Microsoft has also introduced several new registry keys associated with Recall management in the latest Windows 11 builds.

It is important to note that the version of the feature refined following public controversy includes a specific filter intended to prevent the saving of screenshots and text when potentially sensitive information is on the screen. This includes, for example, an incognito browser window, a payment data input field, or a password manager. However, researchers have indicated that this filter may not always engage reliably.

To enable fast searches across all data captured from screenshots, the system uses two DiskANN vector databases (SemanticTextStore.sidb and SemanticImageStore.sidb). However, the standard SQLite database is the most interesting one for investigation: %AppData%\Local\CoreAIPlatform.00\UKP\{GUID}\ukg.db, which consists of 20 tables. In the latest release, it is accessible without administrative privileges, yet it is encrypted. At the time of writing this post, there are no publicly known methods to decrypt the database directly. Therefore, we will examine the most relevant tables from the 2024 Windows 11 beta release with Recall.

• The App table holds data about the process that launched the application’s graphical user interface window.
• The AppDwellTime table contains information such as the full path of the process that initiated the application GUI window (WindowsAppId column), the date and time it was launched (HourOfDay, DayOfWeek, HourStartTimestamp), and the duration the window’s display (DwellTime).
• The WindowCapture table records the type of event (Name column):
  • WindowCreatedEvent indicates the creation of the first instance of the application window. It can be correlated with the process that created the window.
  • WindowChangedEvent tracks changes to the window instance. It allows monitoring movements or size changes of the window instance with the help of the WindowId column, which contains the window’s identifier.
  • WindowCaptureEvent signifies the creation of a screen snapshot that includes the application window. Besides the window identifier, it contains an image identifier (ImageToken). The value of this token can later be used to retrieve the JPEG snapshot file from the aforementioned ImageStore directory, as the filename corresponds to the image identifier.
  • WindowDestroyedEvent signals the closing of the application window.
  • ForegroundChangedEvent does not contain useful data from a forensics perspective.

  The WindowCapture table also includes a flag indicating whether the application window was in the foreground (IsForeground column), the window boundaries as screen coordinates (WindowBounds), the window title (WindowTitle), a service field for properties (Properties), and the event timestamp (TimeStamp).

• WindowCaptureTextIndex_content contains the text extracted with Optical Character Recognition (OCR) from the snapshot (c2 column), the window title (WindowTitle), the application path (App.Path), the snapshot timestamp (TimeStamp), and the name (Name). This table can be used in conjunction with the WindowCapture (the c0 and Id columns hold identical data, which can be used for joining the tables) and App tables (identical data resides in the AppId and Id columns).

Recall artifacts (if the feature was enabled on the system prior to the incident) represent a “goldmine” for the incident responder. They allow for a detailed reconstruction of the attacker’s activity within the compromised system. Conversely, this same functionality can be weaponized: as mentioned previously, the private information filter in Recall does not work flawlessly. Consequently, attackers and malware can exploit it to locate credentials and other sensitive information.

Updated standard applications

Standard applications in Windows 11 have also undergone updates, and for some, this involved changes to both the interface and functionality. Specifically, applications such as Notepad, File Explorer, and the Command Prompt in this version of the OS now support multi-tab mode. Notably, Notepad retains the state of these tabs even after the process terminates. Therefore, Windows 11 now has new artifacts associated with the usage of this application. Our colleague, AbdulRhman Alfaifi, researched these in detail; his work is available here.

The main directory for Notepad artifacts in Windows 11 is located at %LOCALAPPDATA%\Packages\Microsoft.WindowsNotepad_8wekyb3d8bbwe\LocalState\.
This directory contains two subdirectories:

• TabState stores a {GUID}.bin state file for each Notepad tab. This file contains the tab’s contents if the user did not save it to a file. For saved tabs, the file contains the full path to the saved content, the SHA-256 hash of the content, the content itself, the last write time to the file, and other details.
• WindowsState stores information about the application window state. This includes the total number of tabs, their order, the currently active tab, and the size and position of the application window on the screen. The state file is named either *.0.bin or *.1.bin.

The structure of {GUID}.bin for saved tabs is as follows:

Field	Type	Value and explanation
signature	[u8;2]	NP
?	u8	00
file_saved_to_path	bool	00 = the file was not saved at the specified path 01 = the file was saved
path_length	uLEB128	Length of the full path (in characters) to the file where the tab content was written
file_path	UTF-16LE	The full path to the file where the tab content was written
file_size	uLEB128	The size of the file on disk where the tab content was written
encoding	u8	File encoding: 0x01 – ANSI 0x02 – UTF-16LE 0x03 – UTF-16BE 0x04 – UTF-8BOM 0x05 – UTF-8
cr_type	u8	Type of carriage return: 0x01 — CRLF 0x02 — CR 0x03 — LF
last_write_time	uLEB128	The time of the last write (tab save) to the file, formatted as FILETIME
sha256_hash	[u8;32]	The SHA-256 hash of the tab content
?	[u8;2]	00 01
selection_start	uLEB128	The offset of the section start from the beginning of the file
selection_end	uLEB128	The offset of the section end from the beginning of the file
config_block	ConfigBlock	ConfigBlock structure configuration
content_length	uLEB128	The length of the text in the file
content	UTF-16LE	The file content before it was modified by the new data. This field is absent if the tab was saved to disk with no subsequent modifications.
contain_unsaved_data	bool	00 = the tab content in the {GUID}.bin file matches the tab content in the file on disk 01 = changes to the tab have not been saved to disk
checksum	[u8;4]	The CRC32 checksum of the {GUID}.bin file content, offset by 0x03 from the start of the file
unsaved_chunks	[UnsavedChunk]	A list of UnsavedChunk structures. This is absent if the tab was saved to disk with no subsequent modifications

For tabs that were never saved, the {GUID}.bin file structure in the TabState directory is shorter:

Field	Type	Value and explanation
signature	[u8;2]	NP
?	u8	00
file_saved_to_path	bool	00 = the file was not saved at the specified path (always)
selection_start	uLEB128	The offset of the section start from the beginning of the file
selection_end	uLEB128	The offset of the section end from the beginning of the file
config_block	ConfigBlock	ConfigBlock structure configuration
content_length	uLEB128	The length of the text in the file
content	UTF-16LE	File content
contain_unsaved_data	bool	01 = changes to the tab have not been saved to disk (always)
checksum	[u8;4]	The CRC32 checksum of the {GUID}.bin file content, offset by 0x03 from the start of the file
unsaved_chunks	[UnsavedChunk]	List of UnsavedChunk structures

Note that the saving of tabs may be disabled in the Notepad settings. If this is the case, the TabState and WindowState artifacts will be unavailable for analysis.

If these artifacts are available, however, you can use the notepad_parser tool, developed by our colleague Abdulrhman Alfaifi, to automate working with them.

This particular artifact may assist in recovering the contents of malicious scripts and batch files. Furthermore, it may contain the results and logs from network scanners, credential extraction utilities, and other executables used by threat actors, assuming any unsaved modifications were inadvertently made to them.

Changes to familiar artifacts in Windows 11

In addition to the new artifacts, Windows 11 introduced several noteworthy changes to existing ones that investigators should be aware of when analyzing incidents.

Changes to NTFS attribute behavior

The behavior of NTFS attributes was changed between Windows 10 and Windows 11 in two $MFT structures: $STANDARD_INFORMATION and $FILE_NAME.

The changes to the behavior of the $STANDARD_INFORMATION attributes are presented in the table below:

Event	Access file	Rename file	Copy file to new folder	Move file within one volume	Move file between volumes
Win 10 1903	The File Access timestamp is updated. However, it remains unchanged if the system volume is larger than 128 GB	The File Access timestamp remains unchanged	The copy metadata is updated	The File Access timestamp remains unchanged	The metadata is inherited from the original file
Win 11 24H2	The File Access timestamp is updated	The File Access timestamp is updated to match the modification time	The copy metadata is inherited from the original file	The File Access timestamp is updated to match the moving time	The metadata is updated

Behavior of the $FILENAME attributes was changed as follows:

Event	Rename file	Move file via Explorer within one volume	Move file to Recycle Bin
Win 10 1903	The timestamps and metadata remain unchanged	The timestamps and metadata remain unchanged	The timestamps and metadata remain unchanged
Win 11 24H2	The File Access and File Modify timestamps along with the metadata are inherited from the previous version of $STANDARD_INFORMATION	The File Access and File Modify timestamps along with the metadata are inherited from the previous version of $STANDARD_INFORMATION	The File Access and File Modify timestamps along with the metadata are inherited from the previous version of $STANDARD_INFORMATION

Analysts should consider these changes when examining the service files of the NTFS file system.

Program Compatibility Assistant

Program Compatibility Assistant (PCA) first appeared way back in 2006 with the release of Windows Vista. Its purpose is to run applications designed for older operating system versions, thus being a relevant artifact for identifying evidence of program execution.

Windows 11 introduced new files associated with this feature that are relevant for forensic analysis of application executions. These files are located in the directory C:\Windows\appcompat\pca\:

• PcaAppLaunchDic.txt: each line in this file contains data on the most recent launch of a specific executable file. This information includes the time of the last launch formatted as YYYY-MM-DD HH:MM:SS.f (UTC) and the full path to the file. A pipe character (|) separates the data elements. When the file is run again, the information in the corresponding line is updated. The file uses ANSI (CP-1252) encoding, so executing files with Unicode in their names “breaks” it: new entries (including the entry for running a file with Unicode) stop appearing, only old ones get updated.

• PcaGeneralDb0.txt and PcaGeneralDb1.txt alternate during data logging: new records are saved to the primary file until its size reaches two megabytes. Once that limit is reached, the secondary file is cleared and becomes the new primary file, and the full primary file is then designated as the secondary. This cycle repeats indefinitely. The data fields are delimited with a pipe (|). The file uses UTF-16LE encoding and contains the following fields:
  • Executable launch time (YYYY-MM-DD HH:MM:SS.f (UTC))
  • Record type (0–4):
    • 0 = installation error
    • 1 = driver blocked
    • 2 = abnormal process exit
    • 3 = PCA Resolve call (component responsible for fixing compatibility issues when running older programs)
    • 4 = value not set
  • Path to executable file. This path omits the volume letter and frequently uses environment variables (%USERPROFILE%, %systemroot%, %programfiles%, and others).
  • Product name (from the PE header, lowercase)
  • Company name (from the PE header, lowercase)
  • Product version (from the PE header)
  • Windows application ID (format matches that used in AmCache)
  • Message

Note that these text files only record data related to program launches executed through Windows File Explorer. They do not log launches of executable files initiated from the console.

Windows Search

Windows Search is the built-in indexing and file search mechanism within Windows. Initially, it combed through files directly, resulting in sluggish and inefficient searches. Later, a separate application emerged that created a fast file index. It was not until 2006’s Windows Vista that a search feature was fully integrated into the operating system, with file indexing moved to a background process.

From Windows Vista up to and including Windows 10, the file index was stored in an Extensible Storage Engine (ESE) database:
%PROGRAMDATA%\Microsoft\Search\Data\Applications\Windows\Windows.edb.

Windows 11 breaks this storage down into three SQLite databases:

• %PROGRAMDATA%\Microsoft\Search\Data\Applications\Windows\Windows-gather.db contains general information about indexed files and folders. The most interesting element is the SystemIndex_Gthr table, which stores data such as the name of the indexed file or directory (FileName column), the last modification of the indexed file or directory (LastModified), an identifier used to link to the parent object (ScopeID), and a unique identifier for the file or directory itself (DocumentID). Using the ScopeID and the SystemIndex_GthrPth table, investigators can reconstruct the full path to a file on the system. The SystemIndex_GthrPth table contains the folder name (Name column), the directory identifier (Scope), and the parent directory identifier (Parent). By matching the file’s ScopeID with the directory’s Scope, one can determine the parent directory of the file.
• %PROGRAMDATA%\Microsoft\Search\Data\Applications\Windows\Windows.db stores information about the metadata of indexed files. The SystemIndex_1_PropertyStore table is of interest for analysis; it holds the unique identifier of the indexed object (WorkId column), the metadata type (ColumnId), and the metadata itself. Metadata types are described in the SystemIndex_1_PropertyStore_Metadata table (where the content of the Id column corresponds to the ColumnId content from SystemIndex_1_PropertyStore) and are specified in the UniqueKey column.
• %PROGRAMDATA%\Microsoft\Search\Data\Applications\Windows\Windows-usn.db does not contain useful information for forensic analysis.

As depicted in the image below, analyzing the Windows-gather.db file using DB Browser for SQLite can provide us evidence of the presence of certain files (e.g., malware files, configuration files, files created and left by attackers, and others).

It is worth noting that the LastModified column is stored in the Windows FILETIME format, which holds an unsigned 64-bit date and time value, representing the number of 100-nanosecond units since the start of January 1, 1601. Using a utility such as DCode, we can see this value in UTC, as shown in the image below.

Other minor changes in Windows 11

It is also worth mentioning a few small but important changes in Windows 11 that do not require a detailed analysis:

• A complete discontinuation of NTLMv1 means that pass-the-hash attacks are gradually becoming a thing of the past.
• Removal of the well-known Windows 10 Timeline activity artifact. Although it is no longer being actively maintained, its database remains for now in the files containing user activity information, located at: %userprofile%\AppData\Local\ConnectedDevicesPlatform\ActivitiesCache.db.
• Similarly, Windows 11 removed Cortana and Internet Explorer, but the artifacts of these can still be found in the operating system. This may be useful for investigations conducted in machines that were updated from Windows 10 to the newer version.
• Previous research also showed that Event ID 4624, which logs successful logon attempts in Windows, remained largely consistent across versions until a notable update appeared in Windows 11 Pro (22H2). This version introduces a new field, called Remote Credential Guard, marking a subtle but potentially important change in forensic analysis. While its real-world use and forensic significance remain to be observed, its presence suggests Microsoft’s ongoing efforts to enhance authentication-related telemetry.
• Expanded support for the ReFS file system. The latest Windows 11 update preview made it possible to install the operating system directly onto a ReFS volume, and BitLocker support was also introduced. This file system has several key differences from the familiar NTFS:
  • ReFS does not have the $MFT (Master File Table) that forensics specialists rely on, which contains all current file records on the disk.
  • It does not generate short file names, as NTFS does for DOS compatibility.
  • It does not support hard links or extended object attributes.
  • It offers increased maximum volume and single-file sizes (35 PB compared to 256 TB in NTFS).

Conclusion

This post provided a brief overview of key changes to Windows 11 artifacts that are relevant to forensic analysis – most notably, the changes of PCA and modifications to Windows Search mechanism. The ultimate utility of these artifacts in investigations remains to be seen. Nevertheless, we recommend you immediately incorporate the aforementioned files into the scope of your triage collection tool.

Introduction

When it comes to digital forensics, AmCache plays a vital role in identifying malicious activities in Windows systems. This artifact allows the identification of the execution of both benign and malicious software on a machine. It is managed by the operating system, and at the time of writing this article, there is no known way to modify or remove AmCache data. Thus, in an incident response scenario, it could be the key to identifying lost artifacts (e.g., ransomware that auto-deletes itself), allowing analysts to search for patterns left by the attacker, such as file names and paths. Furthermore, AmCache stores the SHA-1 hashes of executed files, which allows DFIR professionals to search public threat intelligence feeds — such as OpenTIP and VirusTotal — and generate rules for blocking this same file on other systems across the network.

This article presents a comprehensive analysis of the AmCache artifact, allowing readers to better understand its inner workings. In addition, we present a new tool named “AmCache-EvilHunter“, which can be used by any professional to easily parse the Amcache.hve file and extract IOCs. The tool is also able to query the aforementioned intelligence feeds to check for malicious file detections, this level of built-in automation reduces manual effort and speeds up threat detection, which is of significant value for analysts and responders.

The importance of evidence of execution

Evidence of execution is fundamentally important in digital forensics and incident response, since it helps investigators reconstruct how the system was used during an intrusion. Artifacts such as Prefetch, ShimCache, and UserAssist offer clues about what was executed. AmCache is also a robust artifact for evidencing execution, preserving metadata that indicates a file’s presence and execution, even if the file has been deleted or modified. An advantage of AmCache over other Windows artifacts is that unlike them, it stores the file hash, which is immensely useful for analysts, as it can be used to hunt malicious files across the network, increasing the likelihood of fully identifying, containing, and eradicating the threat.

Introduction to AmCache

Application Activity Cache (AmCache) was first introduced in Windows 7 and fully leveraged in Windows 8 and beyond. Its purpose is to replace the older RecentFileCache.bcf in newer systems. Unlike its predecessor, AmCache includes valuable forensic information about program execution, executed binaries and loaded drivers.

This artifact is stored as a registry hive file named Amcache.hve in the directory C:\Windows\AppCompat\Programs. The metadata stored in this file includes file paths, publisher data, compilation timestamps, file sizes, and SHA-1 hashes.

It is important to highlight that the AmCache format does not depend on the operating system version, but rather on the version of the libraries (DLLs) responsible for filling the cache. In this way, even Windows systems with different patch levels could have small differences in the structure of the AmCache files. The known libraries used for filling this cache are stored under %WinDir%\System32 with the following names:

• aecache.dll
• aeevts.dll
• aeinv.dll
• aelupsvc.dll
• aepdu.dll
• aepic.dll

It is worth noting that this artifact has its peculiarities and limitations. The AmCache computes the SHA-1 hash over only the first 31,457,280 bytes (≈31 MB) of each executable, so comparing its stored hash online can fail for files exceeding this size. Furthermore, Amcache.hve is not a true execution log: it records files in directories scanned by the Microsoft Compatibility Appraiser, executables and drivers copied during program execution, and GUI applications that required compatibility shimming. Only the last category reliably indicates actual execution. Items in the first two groups simply confirm file presence on the system, with no data on whether or when they ran.

In the same directory, we can find additional LOG files used to ensure Amcache.hve consistency and recovery operations:

• C:\Windows\AppCompat\Programs\Amcache.hve.*LOG1
• C:\Windows\AppCompat\Programs\Amcache.hve.*LOG2

The Amcache.hve file can be collected from a system for forensic analysis using tools like Aralez, Velociraptor, or Kape.

Amcache.hve structure

The Amcache.hve file is a Windows Registry hive in REGF format; it contains multiple subkeys that store distinct classes of data. A simple Python parser can be implemented to iterate through Amcache.hve and present its keys:

#!/usr/bin/env python3

import sys
from Registry.Registry import Registry

hive = Registry(str(sys.argv[1]))
root = hive.open("Root")

for rec in root.subkeys():
    print(rec.name())

The result of this parser when executed is:

From a DFIR perspective, the keys that are of the most interest to us are InventoryApplicationFile, InventoryApplication, InventoryDriverBinary, and InventoryApplicationShortcut, which are described in detail in the following subsections.

InventoryApplicationFile

The InventoryApplicationFile key is essential for tracking every executable discovered on the system. Under this key, each executable is represented by its own uniquely named subkey, which stores the following main metadata:

• ProgramId: a unique hash generated from the binary name, version, publisher, and language, with some zeroes appended to the beginning of the hash
• FileID: the SHA-1 hash of the file, with four zeroes appended to the beginning of the hash
• LowerCaseLongPath: the full lowercase path to the executable
• Name: the file base name without the path information
• OriginalFileName: the original filename as specified in the PE header’s version resource, indicating the name assigned by the developer at build time
• Publisher: often used to verify if the source of the binary is legitimate. For malware, this subkey is usually empty
• Version: the specific build or release version of the executable
• BinaryType: indicates whether the executable is a 32-bit or 64-bit binary
• ProductName: the ProductName field from the version resource, describing the broader software product or suite to which the executable belongs
• LinkDate: the compilation timestamp extracted from the PE header
• Size: the file size in bytes
• IsOsComponent: a boolean flag that specifies whether the executable is a built-in OS component or a third-party application/library

With some tweaks to our original Python parser, we can read the information stored within this key:

#!/usr/bin/env python3

import sys
from Registry.Registry import Registry

hive = Registry(sys.argv[1])
root = hive.open("Root")

subs = {k.name(): k for k in root.subkeys()}
parent = subs.get("InventoryApplicationFile")

for rec in parent.subkeys():
   vals = {v.name(): v.value() for v in rec.values()}
   print("{}\n{}\n\n-----------\n".format(rec, vals))

We can also use tools like Registry Explorer to see the same data in a graphical way:

As mentioned before, AmCache computes the SHA-1 hash over only the first 31,457,280 bytes (≈31 MB). To prove this, we did a small experiment, during which we got a binary smaller than 31 MB (Aralez) and one larger than this value (a custom version of Velociraptor). For the first case, the SHA-1 hash of the entire binary was stored in AmCache.

For the second scenario, we used the dd utility to extract the first 31 MB of the Velociraptor binary:

When checking the Velociraptor entry on AmCache, we found that it indeed stored the SHA-1 hash calculated only for the first 31,457,280 bytes of the binary. Interestingly enough, the Size value represented the actual size of the original file. Thus, relying only on the file hash stored on AmCache for querying threat intelligence portals may be not enough when dealing with large files. So, we need to check if the file size in the record is bigger than 31,457,280 bytes before searching threat intelligence portals.

Additionally, attackers may take advantage of this characteristic to purposely generate large malicious binaries. In this way, even if investigators find that a malware was executed/present on a Windows system, the actual SHA-1 hash of the binary will still be unknown, making it difficult to track it across the network and gathering it from public databases like VirusTotal.

InventoryApplicationFile – use case example: finding a deleted tool that was used

Let’s suppose you are searching for a possible insider threat. The user denies having run any suspicious programs, and any suspicious software was securely erased from disk. But in the InventoryApplicationFile, you find a record of winscp.exe being present in the user’s Downloads folder. Even though the file is gone, this tells you the tool was on the machine and it was likely used to transfer files before being deleted. In our incident response practice, we have seen similar cases, where this key proved useful.

InventoryApplication

The InventoryApplication key records details about applications that were previously installed on the system. Unlike InventoryApplicationFile, which logs every executable encountered, InventoryApplication focuses on those with installation records. Each entry is named by its unique ProgramId, allowing straightforward linkage back to the corresponding InventoryApplicationFile key. Additionally, InventoryApplication has the following subkeys of interest:

• InstallDate: a date‑time string indicating when the OS first recorded or recognized the application
• MsiInstallDate: present only if installed via Windows Installer (MSI); shows the exact time the MSI package was applied, sourced directly from the MSI metadata
• UninstallString: the exact command line used to remove the application
• Language: numeric locale identifier set by the developer (LCID)
• Publisher: the name of the software publisher or vendor
• ManifestPath: the file path to the installation manifest used by UWP or AppX/MSIX apps

With a simple change to our parser, we can check the data contained in this key:

<...>
parent = subs.get("InventoryApplication")
<...>

When a ProgramId appears both here and under InventoryApplicationFile, it confirms that the executable is not merely present or executed, but was formally installed. This distinction helps us separate ad-hoc copies or transient executions from installed software. The following figure shows the ProgramId of the WinRAR software under InventoryApplicationFile.

When searching for the ProgramId, we find an exact match under InventoryApplication. This confirms that WinRAR was indeed installed on the system.

Another interesting detail about InventoryApplication is that it contains a subkey named LastScanTime, which is stored separately from ProgramIds and holds a value representing the last time the Microsoft Compatibility Appraiser ran. This is a scheduled task that launches the compattelrunner.exe binary, and the information in this key should only be updated when that task executes. As a result, software installed since the last run of the Appraiser may not appear here. The LastScanTime value is stored in Windows FileTime format.

InventoryApplication – use case example: spotting remote access software

Suppose that during an incident response engagement, you find an entry for AnyDesk in the InventoryApplication key (although the application is not installed anymore). This means that the attacker likely used it for remote access and then removed it to cover their tracks. Even if wiped from disk, this key proves it was present. We have seen this scenario in real-world cases more than once.

InventoryDriverBinary

The InventoryDriverBinary key records every kernel-mode driver that the system has loaded, providing the essential metadata needed to spot suspicious or malicious drivers. Under this key, each driver is captured in its own uniquely named subkey and includes:

• FileID: the SHA-1 hash of the driver binary, with four zeroes appended to the beginning of the hash
• LowerCaseLongPath: the full lowercase file path to the driver on disk
• DigitalSignature: the code-signing certificate details. A valid, trusted signature helps confirm the driver’s authenticity
• LastModified: the file’s last modification timestamp from the filesystem metadata, revealing when the driver binary was most recently altered on disk

Because Windows drivers run at the highest privilege level, they are frequently exploited by malware. For example, a previous study conducted by Kaspersky shows that attackers are exploiting vulnerable drivers for killing EDR processes. When dealing with a cybersecurity incident, investigators correlate each driver’s cryptographic hash, file path, signature status, and modification timestamp. That can help in verifying if the binary matches a known, signed version, detecting any tampering by spotting unexpected modification dates, and flagging unsigned or anomalously named drivers for deeper analysis. Projects like LOLDrivers help identify vulnerable drivers in use by attackers in the wild.

In addition to the InventoryDriverBinary, AmCache also provides the InventoryApplicationDriver key, which keeps track of all drivers that have been installed by specific applications. It includes two entries:

• DriverServiceName, which identifies the name of the service linked to the installed driver; and
• ProgramIds, which lists the program identifiers (corresponding to the key names under InventoryApplication) that were responsible for installing the driver.

As shown in the figure below, the ProgramIds key can be used to track the associated program that uses this driver:

InventoryDriverBinary – use case example: catching a bad driver

If the system was compromised through the abuse of a known vulnerable or malicious driver, you can use the InventoryDriverBinary registry key to confirm its presence. Even if the driver has been removed or hidden, remnants in this key can reveal that it was once loaded, which helps identify kernel-level compromises and supporting timeline reconstruction during the investigation. This is exactly how the AV Killer malware was discovered.

InventoryApplicationShortcut

This key contains entries for .lnk (shortcut) files that were present in folders like each user’s Start Menu or Desktop. Within each shortcut key, the ShortcutPath provides the absolute path to the LNK file at the moment of discovery. The ShortcutTargetPath shows where the shortcut pointed. We can also search for the ProgramId entry within the InventoryApplication key using the ShortcutProgramId (similar to what we did for drivers).

InventoryApplicationShortcut – use case example: confirming use of a removed app

You find that a suspicious program was deleted from the computer, but the user claims they never ran it. The InventoryApplicationShortcut key shows a shortcut to that program was on their desktop and was accessed recently. With supplementary evidence, such as that from Prefetch analysis, you can confirm the execution of the software.

AmCache key comparison

The table below summarizes the information presented in the previous subsections, highlighting the main information about each AmCache key.

Key	Contains	Indicates execution?
InventoryApplicationFile	Metadata for all executables seen on the system.	Possibly (presence = likely executed)
InventoryApplication	Metadata about formally installed software.	No (indicates installation, not necessarily execution)
InventoryDriverBinary	Metadata about loaded kernel-mode drivers.	Yes (driver was loaded into memory)
InventoryApplicationShortcut	Information about .lnk files.	Possibly (combine with other data for confirmation)

AmCache-EvilHunter

Undoubtedly Amcache.hve is a very important forensic artifact. However, we could not find any tool that effectively parses its contents while providing threat intelligence for the analyst. With this in mind, we developed AmCache-EvilHunter a command-line tool to parse and analyze Windows Amcache.hve registry hives, identify evidence of execution, suspicious executables, and integrate Kaspersky OpenTIP and VirusTotal lookups for enhanced threat intelligence.

AmCache-EvilHunter is capable of processing the Amcache.hve file and filter records by date range (with the options --start and --end). It is also possible to search records using keywords (--search), which is useful for searching for known naming conventions adopted by attackers. The results can be saved in CSV (--csv) or JSON (--json) formats.

The image below shows an example of execution of AmCache-EvilHunter with these basic options, by using the following command:

amcache-evilhunter -i Amcache.hve --start 2025-06-19 --end 2025-06-19 --csv output.csv

The output contains all applications that were present on the machine on June 19, 2025. The last column contains information whether the file is an operating system component, or not.

Analysts are often faced with a large volume of executables and artifacts. To narrow down the scope and reduce noise, the tool is able to search for known suspicious binaries with the --find-suspicious option. The patterns used by the tool include common malware names, Windows processes containing small typos (e.g., scvhost.exe), legitimate executables usually found in use during incidents, one-letter/one-digit file names (such as 1.exe, a.exe), or random hex strings. The figure below shows the results obtained by using this option; as highlighted, one svchost.exe file is part of the operating system and the other is not, making it a good candidate for collection and analysis if not deleted.

Malicious files usually do not include any publisher information and are definitely not part of the default operating system. For this reason, AmCache-EvilHunter also ships with the --missing-publisher and --exclude-os options. These parameters allow for easy filtering of suspicious binaries and also allow fast threat intelligence gathering, which is crucial during an incident.

Another important feature that distinguishes our tool from other proposed approaches is that AmCache-EvilHunter can query Kaspersky OpenTIP (--opentip ) and VirusTotal (--vt) for hashes it identifies. In this way, analysts can rapidly gain insights into samples to decide whether they are going to proceed with a full analysis of the artifact or not.

Binaries of the tool are available on our GitHub page for both Linux and Windows systems.

Conclusion

Amcache.hve is a cornerstone of Windows forensics, capturing rich metadata, such as full paths, SHA-1 hashes, compilation timestamps, publisher and version details, for every executable that appears on a system. While it does not serve as a definitive execution log, its strength lies in documenting file presence and paths, making it invaluable for spotting anomalous binaries, verifying trustworthiness via hash lookups against threat‐intelligence feeds, and correlating LinkDate values with known attack campaigns.

To extract its full investigative potential, analysts should merge AmCache data with other artifacts (e.g., Prefetch, ShimCache, and Windows event logs) to confirm actual execution and build accurate timelines. Comparing InventoryApplicationFile entries against InventoryApplication reveals whether a file was merely dropped or formally installed, and identifying unexpected driver records can expose stealthy rootkits and persistence mechanisms. Leveraging parsers like AmCache-EvilHunter and cross-referencing against VirusTotal or proprietary threat databases allows IOC generation and robust incident response, making AmCache analysis a fundamental DFIR skill.