Evidence of Execution: ShimCache and Amcache Forensics

 

In the high-stakes world of incident response and digital forensics, few artifacts provide as much immediate insight into an adversary’s actions as Windows application execution artifacts. When attackers breach a network, the tools they run — whether custom malware, living-off-the-land binaries, or post-exploitation frameworks — leave traces that can reveal their objectives, techniques, and timeline.

Among the most valuable and enduring of these artifacts are ShimCache (AppCompatCache) and Amcache.hve. Long trusted by veteran responders for rapid triage, these artifacts offer a lightweight yet remarkably persistent record of executable presence, file metadata, cryptographic hashes, and behavioral patterns. Despite schema changes across Windows versions and important interpretive caveats, they remain indispensable for modern threat hunting and compromise assessments.

In this comprehensive guide, we explore the inner workings of ShimCache and Amcache, their forensic strengths and limitations, optimal parsing strategies, and advanced analytical techniques that scale effectively across enterprise environments. Whether you are triaging a single compromised host or hunting across thousands of systems, mastering these artifacts will significantly enhance your ability to detect, understand, and respond to sophisticated intrusions.

Application Compatibility: ShimCache

Microsoft’s Application Compatibility Cache (AppCompatCache), commonly referred to as ShimCache, forms a core component of the Windows Application Compatibility Infrastructure (shim infrastructure). Introduced with Windows XP, it facilitates the detection and application of compatibility shims—user-mode fixes that enable legacy binaries to invoke behaviors associated with prior operating system versions, thereby mitigating compatibility issues during program execution.

This subsystem is frequently engaged by end users via the Program Compatibility Troubleshooter (compatibility wizard) and maintains an internal database of hundreds of built-in shims (as enumerated in files such as sysmain.sdb). The cache itself serves as a lookup mechanism to determine whether a given executable requires shimming. Critically, from a digital forensics perspective, entries are populated in the cache upon program launch attempts—regardless of whether a shim is ultimately applied—and may also be inserted when executables are merely browsed via Explorer.exe (particularly on Windows Vista through 8.1).

Forensic artifacts derived from ShimCache typically include the executable’s full path, the $STANDARD_INFORMATION last modification timestamp of the file at the time of cache insertion/update, and, depending on the OS version, additional metadata such as file size. On Windows XP 32-bit systems, entries further record file size and a last-update timestamp. Subsequent versions introduced execution flags (most reliable on pre-Windows 10 systems) and varying cache capacities (approximately 96 entries on XP 32-bit, up to 1,024 on modern Windows).

Key caveats for forensic practitioners: ShimCache constitutes strong evidence of file presence (or prior existence) on the system, including binaries executed from removable media or network paths. However, it does not record actual execution timestamps. The stored modification time reflects the file’s M-time at cache insertion rather than runtime. On Windows 10 and later, the artifact is best interpreted as evidence of presence rather than definitive proof of execution. Cache data resides in memory and is persisted to the registry (in the SYSTEM hive) only upon proper system shutdown or reboot, potentially resulting in the absence of the most recent entries in live or abruptly terminated systems. The cache operates as a rolling buffer, with older entries overwritten as new ones are added.

This artifact remains a high-value, relatively persistent source for reconstructing application execution history in incident response and forensic timelines, particularly when correlated with AmCache, Prefetch, or other execution artifacts. AppCompatCache (ShimCache) is persisted within the SYSTEM registry hive under the following paths, with implementation details and capacity varying by operating system version:

Windows 7 and Later (including Windows 8/8.1/10/11 and Server 2008–2022)

• Primary Registry Path: SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache\AppCompatCache
• Maximum Entries: 1,024 (rolling buffer; oldest entries are overwritten as new ones are added)
• Notable Metadata: Includes an InsertFlag (or execution flag) in certain versions (most informative on Windows 7–8.1/Server 2012 R2), which provides partial indication of execution but is not definitive, particularly on Windows 10 and newer, where the artifact is best regarded as evidence of file presence rather than conclusive proof of execution.

Windows XP (32-bit)

• Registry Path: SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatibility\AppCompatCache
• Maximum Entries: Limited to 96
• Additional Metadata: Includes file size and last-update timestamp alongside the full path and $STANDARD_INFORMATION last modification time

Windows Server 2003 (and XP 64-bit)

• Up to 512 entries
• Path generally aligns with the post-XP structure (AppCompatCache\AppCompatCache)

Forensic Note: The cache is maintained in kernel/memory during runtime and flushed to the registry only upon clean system shutdown or reboot. Analysts should examine historical ControlSets when possible and cross-reference with memory artifacts (e.g., via Volatility) for more recent activity. Entry ordering can support relative timeline construction, though absolute execution times are not recorded.

When parsing and interpreting AppCompatCache (ShimCache) output, forensic examiners should consider the following operational characteristics and limitations:

1. Entry Ordering: On modern Windows versions lacking explicit execution timestamps, the most recent entries appear at the top of the cache (reflecting the rolling insertion order).
2. Persistence Mechanics: New entries are committed to the registry only upon system shutdown or reboot. In Windows 10 and later, a reboot reliably flushes the in-memory cache. Consequently, executables processed or identified since the last clean shutdown/reboot exist solely in volatile memory and will be absent from the on-disk SYSTEM hive.
3. InsertFlag Interpretation: The InsertFlag (introduced in Windows Vista) does not provide a definitive guarantee of execution (or non-execution). While earlier research suggested that an unset flag indicated no execution, contemporary observations show inconsistencies—executables with corroborating Prefetch evidence may still exhibit a false InsertFlag. Certain execution methods or application types may update it more consistently, but further validation is required. Microsoft removed the InsertFlag entirely starting with Windows 10/Server 2016. Later community research found a different mechanism (the last bytes of the entry's Data field, interpreted as an execution indicator) was added to parsers like AppCompatCacheParser around March 2023—but this, too, proved unreliable in both directions (false positives and false negatives were observed even for well-known system binaries).

Post-InsertFlag Execution Indicators (Windows 10/11)

Microsoft removed the traditional InsertFlag beginning with Windows 10 and Server 2016. Subsequent research, notably ØSecurity’s “AppCompatCache Deep Dive” (August 2024), identified a replacement mechanism by examining both AppCompatCacheParser’s source code and raw hive data.

Current versions of the parser interpret the last 4 bytes of each cache entry’s data field as a 32-bit integer. An entry is flagged as executed when this value equals 01 00 00 00. This logic was added to Eric Zimmerman’s AppCompatCacheParser in March 2023 — earlier builds will display “NA” for the field.

Testing on Windows 11 has shown this indicator to be unreliable. Well-known executed binaries (e.g., lsass.exe, cmd.exe, explorer.exe) are sometimes flagged “No”, while others (e.g., msiexec.exe, conhost.exe, regsvr32.exe) are flagged “Yes”. Additional values such as 02 00, 4C 01, and 64 86 have been observed but remain unexplained.

Practical Takeaway: A “Yes” is a useful corroborating signal, but a “No” cannot be interpreted as evidence of non-execution. Treat this field exactly as the legacy InsertFlag — a supporting data point only. Always corroborate with stronger execution artifacts such as Prefetch, Event ID 4688, Sysmon ID 1, or EDR telemetry before asserting execution in any report or testimony.

One of the artifact’s greatest forensic utilities lies in its ability to preserve evidence of tool deployment even after deliberate cleanup. If an adversary removes their binaries and associated Prefetch (.pf) files, residual ShimCache entries may constitute one of the few remaining indicators of prior existence. Additionally, actions such as rewriting a binary to disk (e.g., PsExec behavior), modification, or renaming will trigger re-shimming, generating new or updated entries. This behavior is particularly valuable for detecting post-download renaming or timestomping attempts: discrepancies between the cache-recorded last modification time and the current file system metadata strongly suggest timestamp manipulation.

Beginning with Windows Vista, the mere presence of an entry in the AppCompatCache registry key no longer constitutes conclusive proof of execution. The operating system may populate the cache preemptively when directories containing executables are browsed via GUI components such as Explorer.exe. While this diminishes its purity as an execution artifact, it enhances its utility by capturing a broader snapshot of potential tools—including those downloaded or extracted but not fully executed. In contrast to Prefetch (which records only explicitly launched items), ShimCache can reveal an attacker’s full toolset, exposing artifacts that may have evaded the adversary’s awareness.

The underlying format changed significantly in Windows 10/11; updated parsers (e.g., Eric Zimmerman’s tools) now accommodate these revisions.

The SYSTEM hive may contain historical AppCompatCache data across multiple Control Sets. Examiners should review all available sets for extended historical context. On a live system, the active cache resides under SYSTEM\CurrentControlSet. When analyzing an offline image, determine the active ControlSet by inspecting the Current value under SYSTEM\Select.

AppCompatCacheParser, developed and maintained by SANS instructor Eric Zimmerman, is a robust, widely adopted utility for parsing ShimCache artifacts. It supports analysis of both offline SYSTEM registry hives and live systems. The tool is compatible with Windows 7 and later operating systems. When the -f switch (specifying a SYSTEM hive) is omitted, it automatically targets the live registry of the running system. By default, it enumerates and processes all ControlSets present in the hive, ensuring examiners do not overlook historical data retained in non-current Control Sets.

Key Usage Options

• -c : Specify a particular ControlSet to parse (defaults to all ControlSets)
• -d : Debug mode
• -f : Full path to the offline SYSTEM hive (if omitted, processes the live Registry)
• -t : Sort last-modified timestamps in descending order (generally not recommended for forensic timelines)
• -csv : Directory for output results
• -csvf : Filename for the CSV-formatted output
• -dt : Custom date/time format string for timestamp display

Another valuable complementary tool is Mandiant’s ShimCacheParser.py. This Python script is particularly useful for lightweight, large-scale collection: it can parse exported .reg files (produced via reg.exe export or similar methods), enabling efficient remote or scripted extraction of ShimCache data across enterprise environments without requiring full hive acquisition.

Forensic best practice recommends maintaining both tools in an examiner’s toolkit. AppCompatCacheParser offers comprehensive ControlSet handling and modern Windows support, while Mandiant’s script excels at rapid triage via registry exports. Always validate output against the original hive and cross-reference with other execution artifacts for defensibility.

Application Compatibility: Amcache.hve

Amcache.hve, introduced with Windows 8 and subsequently backported to patched Windows 7 systems, superseded the legacy RecentFileCache.bcf artifact as the primary Application Compatibility database for tracking program execution and related activity. This registry hive (located at C:\Windows\AppCompat\Programs\Amcache.hve) provides an exceptionally rich source of forensic metadata for executables, drivers, and installed applications.

Microsoft has substantially revised the database schema on multiple occasions, resulting in significant structural differences across patch levels. Notably, early Windows 8 implementations recorded first-execution timestamps that were later removed. Research by Blanche Lagny established that the data format is governed primarily by the version of the responsible DLLs (e.g., aeinv.dll) rather than the nominal operating system release. Consequently, the precise structure encountered during analysis is heavily dependent on the system’s patch level and update history. Examiners should consult Lagny’s comprehensive research document, which remains the authoritative reference for both legacy and contemporary formats. Amcache records extensive metadata, including:

• Full file paths
• File sizes
• Publisher and version information (for both executables and drivers)
• Multiple timestamps (including modification and PE compilation time)
• SHA-1 cryptographic hashes for executables and drivers

The inclusion of cryptographic hashes is rare among native Windows artifacts and enables definitive identification of known-good (e.g., Microsoft-signed binaries) or known-bad files (e.g., renamed malware such as mimikatz.exe), even when filenames have been altered. There is one limitation, however: SHA-1 hashing is performed only for files smaller than 31,457,280 bytes (≈31.4 MB). This threshold, likely implemented for performance reasons, encompasses the vast majority of executables. Larger files—such as certain installers or oversized malware—will lack hash values. Adversaries have increasingly adopted larger binaries to evade security tools with similar size restrictions, though this tactic may itself attract analyst attention. File size is recorded independently regardless of hashing.

Although frequently categorized under program execution artifacts, presence in Amcache does not reliably prove execution. According to Lagny’s analysis of the current schema, tracked files generally fall into three primary categories:

 

1. Executables that were run and required application compatibility shimming (GUI applications).
2. Binaries introduced to the system as part of an application installation or execution.
3. Executables present in directories periodically scanned by the Microsoft Compatibility Appraiser scheduled task (e.g., Program Files, Program Files (x86), and Desktop folders).

Only the first category has a direct link to execution, and even then it is limited to GUI applications requiring compatibility shimming. Differentiation between these categories often requires process-of-elimination analysis.

Treat Amcache primarily as a high-fidelity indicator of executable and driver presence on the system, leveraging its rich metadata (paths, hashes, sizes, and timestamps) for inventory, anomaly detection, and malware identification. Correlate with stronger execution artifacts—such as Prefetch, ShimCache, or process creation events—to establish actual runtime activity and timelines. Due to its schema volatility, always validate the encountered format against the system’s patch level and DLL versions before drawing conclusions.

The InventoryApplicationFile key serves as an excellent entry point when conducting forensic analysis of the Amcache.hve hive. It contains subkeys named according to a proprietary hashing algorithm (not publicly reversed) derived from the executable’s full path. This structure facilitates rapid identification of binaries of interest. Multiple entries sharing the same executable name but residing in different directories are common and should be examined individually. For each subkey, the following values provide substantial metadata:

• ProgramId: Unique identifier used to correlate the file with its associated application entry under the InventoryApplication key.
• FileID: Contains the SHA-1 hash of the executable, with the leading four zero bytes typically omitted (computed only for files under approximately 31.4 MB).
• LowerCaseLongPath: The full, case-normalized path to the file on disk.
• Size: The file size in bytes.
• BinaryType — Indicates whether the binary is 32-bit or 64-bit.
• PE Header Information (when available):
  • OriginalName
  • ProductName
  • BinFileVersion / BinProductVersion
  • LinkDate: The PE header compilation timestamp (a frequent indicator of compromise in malware analysis).

Important Note: Not all entries in InventoryApplicationFile will map to a corresponding application in the InventoryApplication key. Unassociated entries are often of high investigative value, as they may represent standalone tools or attacker-dropped binaries.

Additional context for many executables can be found under the InventoryApplication key within the same Amcache.hve hive. This key primarily contains metadata about applications that have been installed — and in some cases, uninstalled — on the system. Key Fields include:

• ProgramId — Unique identifier that links the application record to its associated executables and DLLs in the InventoryApplicationFile key.
• Source — Describes the installation method:
  • MSI — Installed via Windows Installer (MSI package)
  • AppxPackage — Modern MSIX package (typically Microsoft Store apps)
  • AddRemoveProgram — Installed through a traditional executable-based setup
• Publisher — Organization name derived from the digital signing certificate.
• RootDirPath — Root installation directory of the application.
• Name — Display name of the installed application.
• Version — Version string of the application.

This key represents only a subset of the files tracked in InventoryApplicationFile, as it focuses specifically on formally installed programs. When a match is found between the two keys, it provides valuable supplemental information, including:

• Installation date (with a granularity of one day)
• More detailed publisher and vendor information

Forensic Note: Because this key is tied to installed applications, entries in InventoryApplicationFile that lack a corresponding InventoryApplication record (unassociated files) are frequently of heightened interest to investigators, as they may indicate standalone tools or attacker-deployed binaries.

Correlation between the two keys is achieved via the ProgramId value. Entries under InventoryApplication are themselves named according to their ProgramId, enabling straightforward association.

Unlike earlier iterations of Amcache.hve (particularly Windows 8-era implementations), the last-write timestamps of registry keys in modern versions rarely correspond to execution time. These timestamps predominantly reflect when the Microsoft Compatibility Appraiser scheduled task last updated the database.

Presence in these keys reliably indicates that an executable or driver existed on the system at some point, but does not constitute proof of execution. Analysts should treat Amcache as a powerful artifact for presence, metadata enrichment, and hash-based identification, while relying on complementary sources (e.g., Prefetch, ShimCache, Security Event Logs) to corroborate actual runtime activity. Always account for patch-level variations in data structures when interpreting findings.

The InventoryDriverBinary key contains detailed metadata about drivers present on the system. It is primarily updated through the Microsoft Compatibility Appraiser scheduled task. Key Fields include:

• Key Name — Full path to the driver on disk.
• DriverID — SHA-1 hash of the driver (computed for the first ~30 MB).
• DriverSigned — Boolean value (1 = signed).
• DriverIsKernelMode — Boolean value (1 = kernel-mode driver).
• Service — Associated Windows service name.
• Product — Product name extracted from the PE header.
• DriverLastWriteTime — Last modification time of the driver file.

The InventoryDriverBinary key is of particular importance during investigations involving potential advanced persistent threats (APTs), rootkits, bootkits, or kernel-mode evasion techniques. Malicious drivers remain a favored vector for attackers seeking deep system access and security tool bypass. This key maintains one subkey per driver observed on the system, providing a rich dataset for anomaly detection. Forensic examiners should scrutinize entries based on:

• Cryptographic hashing: Comparison of SHA-1 values against known-good and known-bad repositories.
• Temporal analysis: Driver modification timestamps and PE LinkDate (compiler timestamp), correlated against broader intrusion timelines.
• Digital signature validation: On 64-bit Windows systems, all loaded drivers are expected to bear valid signatures. Unsigned, invalid, or suspiciously signed drivers warrant immediate scrutiny.
• PE header metadata: Examination of compiler timestamps, version resources, publisher strings, and other embedded attributes for inconsistencies.

A driver bearing a non-standard or obfuscated name, residing in an anomalous filesystem location (outside expected driver directories such as System32\drivers), or lacking typical PE metadata represents a classic red flag. In such cases, recommended follow-on actions include:

• Acquisition of the driver file for static and dynamic analysis.
• Verification of its digital signature chain.
• Correlation of modification/LinkDate timestamps with other artifacts (e.g., ShimCache, Prefetch, event logs, or MFT records).
• Hash-based lookups against threat intelligence platforms (such as VirusTotal) to identify prior analysis or known associations.

Such investigative steps may ultimately attribute the driver to a legitimate, albeit unusually deployed, forensic or administrative tool. Nevertheless, its atypical characteristics underscore the importance of rigorous, assumption-free verification rather than hasty dismissal.

The InventoryDriverBinary key constitutes a high-value resource for the identification of potentially malicious kernel-mode components. When analyzed in conjunction with ShimCache, Prefetch, process creation events, and other execution artifacts, it substantially enhances an examiner’s capability to detect sophisticated malware and reconstruct attacker toolchains. As with all Amcache data, findings must be validated against the system’s patch level and DLL versions, and robustly corroborated across multiple independent artifact classes to ensure forensic defensibility.

AmcacheParser, developed by Eric Zimmerman, is a highly effective command-line utility for parsing and analyzing Amcache.hve files. By default, the tool filters output to display only “unassociated” file entries—those not linked to a corresponding Program record in the hive. To extract comprehensive data encompassing both Programs and their associated files (providing fuller context), analysts should employ the -i (include associated) switch.

Key Parsed Metadata (Partial List)

• SHA-1 hash
• Full file path (LowerCaseLongPath)
• File size
• File version information
• File description and publisher strings
• Last modified timestamp
• PE compilation time (LinkDate)
• Language ID and additional PE header details

A particularly powerful capability of AmcacheParser is its support for allowlisting and blocklisting based on SHA-1 hashes. This feature enables targeted hunting for specific files of interest (e.g., known malware variants or internal tools) across large collections of Amcache.hve files from multiple systems, significantly streamlining triage and threat hunting workflows. When combined with other tools such as AppCompatCacheParser, RegRipper, or Eric Zimmerman’s Registry Explorer, AmcacheParser forms an essential part of a modern Windows forensic toolkit for efficient extraction and analysis of this rich artifact. As always, correlate results with the system’s patch level, as database schemas vary with updates.

AmcacheParser generates multiple CSV files to facilitate structured analysis of the Amcache.hve hive. As Microsoft periodically augments the database with new data structures, the tool focuses on extracting information from the most forensically relevant keys. Output filenames generally mirror the original registry key names, with minor exceptions for historical compatibility.

• Amcache_ProgramEntries.csv Contains parsed data from the InventoryApplication key (named differently in earlier Amcache.hve versions). This file provides metadata on installed applications, including installation dates, publisher details, and related program information.
• AssociatedFileEntries.csv and UnassociatedFileEntries.csv Data from the high-value InventoryApplicationFile key is intelligently split into two categories:
  • Associated: Files linked to recognized installed software/packages.
  • Unassociated: Files that do not correlate with known installed programs.

The UnassociatedFileEntries category is often of greatest interest to investigators. These entries represent executables present on the system that were not installed through standard application packages. Such files frequently include attacker-dropped tools—such as credential dumpers, network scanners, wiping utilities, or other standalone binaries. Their presence outside normal installation pathways makes them prime candidates for deeper scrutiny.

Prioritize review of unassociated entries when hunting for anomalous or malicious activity. Cross-reference SHA-1 hashes, paths, and timestamps with ShimCache, Prefetch, and other artifacts to build comprehensive execution timelines and tool inventories. As with all Amcache analysis, account for schema variations across Windows versions and patch levels. This structured output, combined with AmcacheParser’s allow/blocklisting capabilities, makes the tool exceptionally effective for both targeted investigations and large-scale enterprise triage.

The Amcache.hve hive stores structured information regarding applications, executables, and drivers through a series of registry keys and values. While it is possible to browse the hive manually using a registry analysis tool, the volume of entries—often numbering in the hundreds or thousands—renders this approach inefficient for comprehensive analysis. Specialized parsers such as AmcacheParser (by Eric Zimmerman) are strongly recommended, as they extract and normalize the data into multiple CSV files suitable for filtering, sorting, and pivoting in spreadsheet applications or timeline tools. Among the most forensically significant outputs are:

• Amcache_UnassociatedFileEntries.csv (or similar naming): Highlights executables present on the system that are not associated with recognized installed applications. These entries are particularly valuable for identifying attacker-dropped tools, standalone binaries, or anomalous files.
• Amcache_DriverBinaries.csv: Catalogs drivers observed on the system, enabling rapid detection of suspicious kernel-mode components through hash analysis, path anomalies, signature status, and PE metadata.
• Amcache_ProgramEntries.csv: Details installed applications, including installation timestamps, publisher information, and related metadata.

Given the richness of the dataset, effective triage typically involves targeted filtering on:

• Filenames and full paths (for anomalous locations)
• SHA-1 hashes (allow/blocklisting against known goods/bads)
• Non-Microsoft or unsigned drivers
• Installation and modification timestamps
• PE compilation times (LinkDate)

These techniques allow examiners to efficiently address key investigative questions, such as the presence of specific tools, indicators of lateral movement, or signs of persistence mechanisms.

Application execution artifacts remain a cornerstone of digital forensics and incident response, as they offer critical visibility into system activity and user (or adversary) behavior. In intrusion investigations, these artifacts are especially valuable for reconstructing attacker methodologies, including initial access, reconnaissance, credential access, lateral movement, and persistence.

Their utility is amplified in enterprise environments when collected and analyzed at scale. The primary databases—such as ShimCache (AppCompatCache), Amcache.hve, and Prefetch—are compact, readily accessible via the filesystem or registry, and relatively straightforward to normalize and parse. This enables efficient, automated collection through agent-based solutions, live response scripts, or enterprise forensic frameworks.

Effective triage and hunting often begin with pattern recognition derived from known adversary tradecraft:

• Anomalous executable naming: Short or randomized names (e.g., one- or two-character binaries).
• Suspicious execution paths: Activity originating from atypical locations such as $Recycle.Bin, System Volume Information, temporary directories, or user-writable paths.
• Known malicious toolsets: Searches for indicators such as pwdump, mimikatz, or other common post-exploitation utilities.
• Living-off-the-Land (LotL) techniques: Unusual invocations of native binaries, including psexec, wmic.exe, reg.exe, schtasks.exe, powershell.exe, or cmd.exe in non-standard contexts.

Once specific indicators of compromise (IOCs)—such as file paths, hashes, or command-line patterns—are identified from initial compromised hosts, they can be rapidly weaponized for network-wide hunting. This iterative approach allows analysts to quickly pivot from individual system triage to enterprise-scale detection of similar attack patterns.

For seasoned incident responders and digital forensic examiners, tools like appcompatprocessor.py (developed by Matias Bevilacqua) represent a significant force multiplier. Forged through real-world operational demands, this utility automates labor-intensive analysis of application execution artifacts, enabling rapid insight across large datasets. Appcompatprocessor.py ingests both AppCompatCache (ShimCache) and Amcache.hve artifacts, normalizing and storing the results in a SQLite database. It offers broad input flexibility, supporting raw SYSTEM and Amcache.hve registry hives; output from Mandiant’s ShimCacheParser.py; in-memory ShimCache extractions (e.g., via Volatility); and Zip archives containing multiple artifacts. This versatility streamlines evidence handling and minimizes preprocessing overhead.

The tool’s true strength emerges after data ingestion. A suite of specialized modules facilitates sophisticated analysis, allowing investigators to efficiently identify malicious activity and iteratively expand their understanding of the intrusion. Techniques employed include regular expression matching, temporal correlation, frequency stacking, and anomaly detection. Notable modules include:

• search: Performs regular expression matching across the database. Ships with over 100 pre-built patterns and supports easy extension via external text files.
• fsearch: Targeted field-specific searching (e.g., FileName, FilePath, Size, LastModified, ExecFlag).
• filehitcount: Provides frequency stacking of executables for quick identification of common versus rare binaries.
• tcorr (Temporal Correlation): Identifies files that consistently execute in close proximity, revealing operational patterns and additional artifacts of interest.
• reconscan: Detects clusters of common reconnaissance tools and generates a per-host score indicating the likelihood of recon activity.
• leven: Leverages Levenshtein distance to surface subtle filename anomalies (e.g., svchos.exe, lssass.exe, cssrs.exe) designed to masquerade as legitimate processes.
• stack: Advanced least-frequency-of-occurrence analysis across chosen fields.
• rndsearch: Attempts to identify randomly or procedurally generated filenames commonly used by attackers.

The modular architecture and diverse analytical perspectives distinguish appcompatprocessor.py as a standout tool. Experienced users frequently pivot between modules, progressively enriching their understanding of the adversary’s toolchain, timeline, and tradecraft.

Matias Bevilacqua’s recorded presentation from the SANS Threat Hunting Summit provides an excellent, in-depth walkthrough of the tool’s features and investigative workflows. For practitioners handling enterprise-scale intrusion data, appcompatprocessor.py is a highly recommended addition to the forensic arsenal.