Windows Forensic Artefacts Guide: Prefetch, Amcache and Shimcache

Windows forensic artefacts are routinely over-read: a ShimCache entry reported as proof that malware ran, an Amcache hash treated as an execution time, or a missing Prefetch file taken as proof that nothing ran. Each artefact (artifact in US spelling) was built by Microsoft for performance, compatibility or user convenience, not for investigators, so each records something narrower than analysts often claim. This guide goes artefact by artefact through evidence of execution, file and folder knowledge, registry hives, NTFS metadata, deleted and historic data and event log forensics, and states what each one does and does not prove. It is for incident responders, forensic examiners and detection engineers who need findings that survive peer review, a regulator's questions or cross-examination. For the wider picture, including evidence handling, memory acquisition and tool validation, see the Digital Forensics (DFIR) Guide.

Key takeaways

• Separate presence, execution and interaction. Amcache and ShimCache show a file existed; Prefetch, BAM and UserAssist point to execution; ShellBags, LNK files and Jump Lists show a user browsed or opened something.
• Much of this is undocumented. Microsoft documents registry hives, the MFT, the USN change journal and Volume Shadow Copies, but not the internals of ShimCache, Amcache, BAM, ShellBags or Prefetch files. Test behaviour on the build you examine.
• Corroborate every key finding. A defensible execution finding rests on at least two independent artefacts, ideally one file system and one execution or log source.
• Collect early and collect raw. The USN journal is trimmed, shadow copies are deleted oldest first, ShimCache is only written at shutdown and hives need their transaction logs.
• Artefacts are tied to identities. Most user artefacts are keyed to a SID, and the SAM and SECURITY hives describe local accounts and stored service credentials.

How to reason about evidence of execution

"Evidence of execution" is the question most investigations hinge on: did this binary run, when, and under which account? Group artefacts by what they can actually support before writing a finding.

Absence is weak evidence: Prefetch may be disabled, the USN journal may have rolled over and BAM entries age out. Record the Windows build too, because behaviour changes between releases; ANSSI's analysis of Amcache found that Windows 8 and 10 changed how that database works.

Evidence of execution artefacts

Prefetch

Microsoft describes Prefetch as loading "application data into memory before it is demanded", controlled by HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters\EnablePrefetcher: 0 disabled, 1 application launch, 2 boot, 3 both. Microsoft does not document the .pf format. Well-established behaviour: one file per executable and path combination; the file's creation time approximates the first recorded run and its modification time the last; the list of loaded files often reveals a dropped DLL or staging directory. Prefetch is commonly disabled on Windows Server, and the folder holds a bounded number of files, so old entries are lost on busy hosts.

ShimCache and Amcache

ShimCache is held in memory and written to the SYSTEM hive at shutdown or restart, so recent entries are missing on disk until the host reboots. On current Windows versions an entry means the file was present and evaluated, which still shows a tool existed in a folder that has since been cleaned. Amcache is populated both when programs run and when inventory tasks scan the disk, so it records files that never executed. Its value is the SHA-1, which matches a deleted binary to threat intelligence, and the publisher and link date, which expose renamed tools. ANSSI notes that interpreting AmCache data is complex because of many special cases.

File and folder knowledge: ShellBags, LNK files, Jump Lists and ActivitiesCache.db

These artefacts answer "did this user browse or open this item?", which matters in insider and data theft cases and when an attacker used a stolen interactive session.

• ShellBags: Explorer stores view settings for folders a user opened in UsrClass.dat (Local Settings\Software\Microsoft\Windows\Shell\BagMRU and Bags) and, for some items, NTUSER.DAT (Software\Microsoft\Windows\Shell). They persist after the folder is deleted and include removable drives, network shares and archive contents. They prove folder browsing, not file access.
• LNK files: Microsoft publishes the Shell Link format as [MS-SHLLINK]. Windows creates them in %APPDATA%\Microsoft\Windows\Recent when a user opens a file through the shell. Each records the target's path, size and creation, access and write times at the moment of opening, the drive type, volume serial number and label or network share, and a tracker block with the NetBIOS name of the machine. They survive deletion of the target and can tie a file to a specific USB device.
• Jump Lists: per-application recent and pinned items in Recent\AutomaticDestinations\<AppID>.automaticDestinations-ms (a compound file holding embedded LNK streams plus a DestList stream with access times and counts) and Recent\CustomDestinations. The AppID ties entries to an application, such as a remote desktop client's list of hosts.
• ActivitiesCache.db: a SQLite database under %LOCALAPPDATA%\ConnectedDevicesPlatform\<profile>\ behind Windows activity history. Microsoft says activity history covers "the apps and services you use, the files you open, and the websites you browse" and is "stored locally on your device". It is populated only while Store my activity history on this device is on, and Microsoft deprecated sending it to the cloud in Windows 11 from January 2024.

Registry forensics: hives and what they hold

Microsoft states that most hive files are in %SystemRoot%\System32\Config, that each user gets a separate user profile hive, and that a .LOG file is "a transaction log of changes to the keys and value entries in the hive". Recent changes may exist only in those logs, so always collect each hive with its .LOG1 and .LOG2 files and replay them before analysis.

Registry keys carry a last-written time but values do not, so a key time tells you something in the key changed, not which value. Read TimeZoneInformation first: registry and NTFS times are stored in UTC, while many viewers and some text logs display local time. Locked hives must be read from the raw NTFS volume or a shadow copy.

NTFS artefacts: MFT analysis and the USN journal

The Master File Table ($MFT) is the index of every file on an NTFS volume. Microsoft states that "there is at least one entry in the MFT for every file on an NTFS file system volume, including the MFT itself" and that deleted entries "are marked as free and may be reused". Until reuse, a deleted file's name, parent folder, timestamps and sometimes small resident content are recoverable from the $MFT.

• Two sets of timestamps: each record holds $STANDARD_INFORMATION ($SI) and $FILE_NAME ($FN) times. ATT&CK T1070.006 Timestomp notes that $SI can be changed through user-mode APIs while $FN is kernel-managed, and that attackers may "double timestomp" both. An $SI creation time earlier than $FN, or times with zeroed sub-second precision, warrants a closer look.
• Last access is unreliable: Microsoft says NTFS "delays updates to the last access time for a file by up to 1 hour after the last access", and last access updating can be disabled, so do not build an access timeline from it.
• USN journal: $Extend\$UsnJrnl:$J records each change to a file or directory with the name, the parent reference, a UTC timestamp and reason flags. It shows files created, renamed and deleted even after the MFT record is reused: the best source for tools that were staged, run and removed.
• Journal size: NTFS trims the journal once it exceeds its configured maximum size plus allocation delta, so a busy server may hold only hours or days. fsutil usn queryjournal C: shows the current settings. Collect $LogFile too: its short-term transaction records can cover the most recent activity.

Deleted and historic data: Recycle Bin and Volume Shadow Copies

• Recycle Bin forensics: files deleted through Explorer move to C:\$Recycle.Bin\<SID>\, where each item becomes a pair: $R holds the content and $I holds the original path, size and deletion time. The SID folder attributes the deletion to an account. Command line and programmatic deletions bypass it, so an empty Recycle Bin means little.
• Volume shadow copy forensics: Microsoft describes copy-on-write snapshots in which changed blocks are saved to a diff area, a maximum of 512 software shadow copies per volume, and that when space runs out "shadow copies for the volume are deleted, beginning with the oldest shadow copy". Earlier versions of hives, event logs, Prefetch files and the $MFT in each copy can show state from before the attacker cleaned up; process each copy read-only as a separate volume.
• Expect them to be gone: ransomware operators routinely delete shadow copies (ATT&CK T1490 Inhibit System Recovery). Their absence on a system where System Restore or scheduled snapshots were configured is itself a finding.

Event log forensics

Event logs often alone name the account and command line behind an execution. Configuration and forwarding are covered in the Windows Event Log Guide; the forensic points are these.

• EVTX analysis on copies: collect every channel from C:\Windows\System32\winevt\Logs, not only Security, and parse offline. Operational channels (Task Scheduler, PowerShell, remote desktop) often outlive a rolled-over Security log.
• Gaps and record numbers: event record IDs are sequential per channel, so a gap is a sign of tampering or loss. Security 1102 and System 104 record clearing (ATT&CK T1685.005, Clear Windows Event Logs); System 6005 and 6006 mark the event log service starting and stopping, which brackets boots and shutdowns.
• Clock changes: Security event 4616 records a system time change, which you need before trusting any timeline built on that host.

Triage collection and analysis workflow

1. Record context first: hostname, Windows build, clock offset from UTC, and whether the host has rebooted since the suspected activity.
2. Capture memory where execution is live or ShimCache matters, before anything that might restart the host.
3. Collect raw NTFS artefacts: $MFT, $UsnJrnl:$J and $LogFile per volume, read through raw volume access so locked files are included. Collect them first: the journal keeps trimming.
4. Collect hives with logs: SAM, SECURITY, SYSTEM, SOFTWARE, Amcache.hve, and every profile's NTUSER.DAT and UsrClass.dat, each with .LOG1 and .LOG2.
5. Collect execution and user artefacts: Prefetch, SRUDB.dat with its ESE log files, Recent, AutomaticDestinations, CustomDestinations, ActivitiesCache.db with its -wal and -shm files, $Recycle.Bin $I files, all .evtx files, and a list of shadow copies.
6. Hash and log the package (SHA-256) and store it outside the compromised environment, then work on copies.
7. Parse with validated parsers, recording versions, and spot-check decisive findings in a registry viewer or a second parser.
8. Build the timeline in UTC outwards from anchors such as an alert, a hash or a logon.

Pilot the collection set on a test ring first: measure time and size per host, confirm no service impact, and roll back by removing the collection policy or agent if it misbehaves.

Decision guidance

• Triage or full image: triage the artefacts above for scoping across many hosts; take a full image for patient zero, systems likely to go to litigation or HR proceedings, and hosts where deleted content recovery matters.
• Workstations or servers: servers often have Prefetch disabled and few interactive profiles, so rely more on Amcache, the USN journal and forwarded 4688 events.
• Small or large organisations: a small team should standardise one collection set and hand it to its retained provider; a large one should pre-deploy collection and parse centrally into one timeline.

Where identity fits

NTUSER.DAT, UsrClass.dat, Jump Lists, LNK files, BAM entries, SRUM records and Recycle Bin folders are all keyed to a profile or SID, which is how activity is attributed to a person or a service account. The SAM hive shows local accounts that were created or reused, and the SECURITY hive holds LSA secrets, which can include the passwords of services configured to run as domain accounts: if an attacker had administrative access, assume those service credentials are exposed and rotate them. A service account with its own interactive profile and Jump Lists on a server is evidence that someone logged on with it. See the Service Account Security Guide and the Local Administrator Password Solution (LAPS) Guide.

Detection of anti-forensics and measurement

Attackers who know these artefacts try to destroy them. Monitor and alert on:

• Shadow copy deletion or shrinking: vssadmin, WMI, wbadmin, diskshadow or bcdedit used with delete, resize or recovery-disabling arguments (T1490).
• USN journal deletion: fsutil run with the usn deletejournal subcommand.
• Log clearing and gaps: 1102, 104 and hosts that stop forwarding (T1685.005).
• Timestomping: SetFileTime use by unusual processes, $SI and $FN mismatches, and BASIC_INFO_CHANGE records on executables (T1070.006).
• Artefact tampering: mass deletion in the Prefetch folder, changes to EnablePrefetcher, and deletion of tools after use (T1070.004).

Metrics that show readiness is working:

• Collection coverage: percentage of Windows hosts from which the full triage set can be collected remotely.
• Journal retention: hours of USN history on the ten busiest file servers, compared with your median detection time.
• Time to first artefacts: median minutes from declaration to a hashed triage package from the first host.
• Corroboration rate: percentage of key report findings supported by two or more independent artefacts, checked at peer review.

Common failure patterns

• ShimCache as proof of execution: reporting that a tool "ran at" the ShimCache time, which is the file's modification time and may predate the intrusion by years.
• Hives without transaction logs: analysing a dirty hive without replaying .LOG1 and .LOG2 misses the most recent changes, which are usually the attacker's.
• Time zone confusion: mixing UTC registry and NTFS times with local times from a viewer or text log and producing a timeline that is out by hours.
• Collecting late: waiting for a full image while the USN journal trims itself and shadow copies are deleted.

Framework mapping

Practitioner checklist

• Classify each artefact as presence, execution, interaction or file system evidence, and require two independent artefacts per key finding.
• Collect $MFT, $J and $LogFile first, then hives with .LOG1 and .LOG2, then user and execution artefacts.
• Record Windows build, time zone, clock offset and last reboot for every host examined.
• Check EnablePrefetcher before interpreting an empty Prefetch folder, and enable Prefetch on in-scope servers after testing.
• Size the USN journal on file servers and measure how many hours it holds.
• Rotate credentials found in LSA secrets on any host where an attacker had administrative access.
• Alert on shadow copy deletion, USN journal deletion, log clearing and Prefetch tampering.
• Re-validate parsers against a reference image whenever a parser or Windows version changes.

Standards and references

• NIST: SP 800-86, Guide to Integrating Forensic Techniques into Incident Response
• Microsoft Learn: Registry Hives
• Microsoft Learn: Master File Table
• Microsoft Learn: USN_RECORD_V2 structure
• Microsoft Learn: Volume Shadow Copy Service
• Microsoft Support: Windows activity history and your privacy
• ANSSI: Analyse de l'AmCache
• MITRE ATT&CK: T1070.006 Indicator Removal: Timestomp

Related NHI Mgmt Group resources: Digital Forensics (DFIR) Guide · Windows Event Log Guide · Incident Response Guide · Threat Hunting Guide · Ransomware Response and Recovery Guide