Skip to content

Windows Forensic Artifacts I: Registry, Event Logs and Prefetch

Registry hives, EVTX event logs, and Prefetch as proof of execution: a working examiner's reference for Module 2, with the Eric Zimmerman toolset and the Indian SFSL triage workflow.

Last updated:

Share

Windows forensic examiners extract evidence from three interdependent artefact families: the registry (hierarchical configuration database recording execution history and USB connections), EVTX event logs (binary-XML files capturing system and security events with precise timestamps), and Prefetch files (per-executable .pf records proving a binary loaded into memory and began executing). Working from a forensic image, the examiner parses physical hive files directly rather than the live registry, reads EVTX channels with EvtxECmd rather than Event Viewer, and processes .pf files with PECmd to extract the last eight execution timestamps and the list of files and DLLs touched. A finding corroborated across all three families carries the strongest evidential weight in a Windows case because each artefact answers a different question: registry records configuration and scheduled launches, EVTX records what the OS observed, and Prefetch records what actually executed.

Windows leaves traces of almost everything it does. A program is launched, the registry records it; a user logs in, the Security event log captures the 4624; a binary executes, the Prefetch subsystem writes a .pf file with timestamps and referenced libraries. For a digital forensic examiner in an Indian SFSL cyber wing, Windows is the platform under examination in roughly four out of five computer cases, and the three artefact families covered here, the registry, the EVTX event logs, and Prefetch, account for the majority of triage findings on a typical job. They are also the artefacts that hold up under BSA Section 63 cross-examination because the data structures are documented, the tooling is mature, and the timestamps are forensically meaningful.

Key takeaways

  • The Windows registry has five logical roots, each mapping to specific physical files on disk, and for an offline forensic image the examiner loads those hive files directly into a tool like Registry Explorer rather than mounting the live registry.
  • A small set of high-value registry keys, including NTUSER.DAT UserAssist, the Run and RunOnce keys, MUICache, and the USB device history in SYSTEM\CurrentControlSet\Enum\USBSTOR, account for the majority of triage findings in CFSL cyber wing casework.
  • Windows Security event log ID 4624 records every successful logon with logon type, source IP, and account name, making it the primary artefact for reconstructing who accessed the machine and from where.
  • The Prefetch subsystem writes a .pf file for each executed binary, recording the first and last eight run timestamps and the list of DLLs and files loaded, which provides execution proof even after the binary itself is deleted.
  • Windows event logs are stored in the binary EVTX format under C:\Windows\System32\winevt\Logs, and an examiner must use tools like EvtxECmd or Event Log Explorer rather than the Windows Event Viewer to work on a forensic image.

This topic is the working reference for Module 2 Topic 1. It assumes the examiner already has a verified image of the disk and is past the first-responder workflow covered in The digital first responder. The companion topic Windows artifacts: ShellBags, ADS, LNK, hibernation, slack covers the rest of the Windows artefact universe.

By the end of this topic you will be able to:

  • Identify the five Windows registry roots, map each to its physical hive file path, and explain why an examiner parses the physical files rather than the live logical view.
  • Locate and interpret the high-value registry keys most commonly used in triage: UserAssist, Run/RunOnce, USBStor, MountedDevices, AppCompatCache, and Amcache.
  • Explain the structure of EVTX event logs, name the four forensically significant channels, and interpret the key event IDs (4624, 4625, 4672, 4720, 7045, 4104) for session, privilege, and account-lifecycle analysis.
  • Describe what a Prefetch .pf file records, under what conditions Prefetch may be absent, and how the referenced-file list inside a .pf can corroborate or extend findings from the registry and event logs.
  • Outline the KAPE-based triage workflow used in Indian SFSLs, from image mounting through artefact collection, parsing, and timeline review, and identify the documentation requirements for a BSA Section 63 certificate.
Key terms
Registry hive
A binary file on disk that holds part of the Windows registry. The five logical roots map to physical hive files at C:\Windows\System32\config and in each user profile.
EVTX
The XML-based binary event log format introduced in Windows Vista. Files live under C:\Windows\System32\winevt\Logs and are parsed with the Windows Event Viewer or EvtxECmd.
Prefetch
A Windows performance subsystem that records executable launches and the files they touch in the first 10 seconds of execution. The .pf files prove an executable ran.
UserAssist
A registry-tracked, ROT13-obfuscated record of GUI program launches per user, with run count and last-execution timestamp.
Amcache.hve
A registry hive that records application install and execution metadata, including SHA-1 of executables, useful long after the original file is deleted.
KAPE
Kroll Artifact Parser and Extractor: a triage framework that selectively collects forensic artefacts from a live or imaged system and parses them with downstream tools.

The registry: five hives, many physical files

The Windows registry is a hierarchical database that holds configuration, user state, and a surprising amount of execution history. Logically it has five roots; physically each root maps to one or more files on disk. An examiner working from an image always parses the physical files, never the live logical view, because the live view aggregates and abstracts in ways that hide useful detail.

Logical rootPhysical file(s)LocationForensic value
HKLM\SAMSAMC:\Windows\System32\configLocal account names, RID, password hash metadata
HKLM\SYSTEMSYSTEMC:\Windows\System32\configServices, drivers, USB history, ComputerName, TimeZone
HKLM\SOFTWARESOFTWAREC:\Windows\System32\configInstalled applications, Run keys, network profiles
HKLM\SECURITYSECURITYC:\Windows\System32\configLSA Secrets, cached domain credentials
HKU\<SID>NTUSER.DATC:\Users\<user>\Per-user state, UserAssist, RecentDocs, TypedURLs
HKU\<SID>_ClassesUsrClass.datC:\Users\<user>\AppData\Local\Microsoft\Windows\Per-user shell extensions, ShellBags
HKCU, HKCR, HKCC(virtual)(maps onto the above)Logical views; examiner uses the underlying files

The physical hives are not the only copies. Each hive on a healthy system has a .LOG1 and .LOG2 transaction log written next to it. On a dirty shutdown those logs hold writes that had not yet been merged into the hive proper. Modern parsers (RegRipper 3.0 from Harlan Carvey, Registry Explorer and RECmd from Eric Zimmerman) will replay the transaction logs onto the hive image before parsing, which sometimes surfaces values that vanish when only the bare hive is read. Older tools that ignore the logs miss those values; cross-examining defence experts know this and ask about it.

Beyond the active hives, Windows keeps Volume Shadow Copy snapshots of the hives at a daily or near-daily cadence (vssadmin list shadows). Each shadow copy holds a registry state from an earlier point in time. An examiner who only parses the current hives sees the present; an examiner who mounts each shadow and parses the hives within sees the history. This is how registry keys that were deleted from the current hive reappear in evidence.

High-value registry keys for an examiner

Windows registry hive map with on-disk paths, plus Prefetch execution-history paths and Event Log channel-to-EVTX file mappin
Windows registry hive map with on-disk paths, plus Prefetch execution-history paths and Event Log channel-to-EVTX file mapping. The three source families answer overlapping questions: registry says what ran, Prefetch proves what actually executed, Event Logs record what the OS observed and when.

A registry hive has thousands of keys; only a small set carries reliable forensic value. The CFSL cyber wing triage list, aligned with the SANS Windows forensics artefact poster and the RegRipper plugin catalogue, converges on this dozen.

  • Run, RunOnce, RunOnceEx at HKLM\Software\Microsoft\Windows\CurrentVersion\Run and the equivalent under HKCU. These hold autorun entries: programs that launch on logon. The standard malware persistence location, but also the standard place to find legitimate update agents that confuse a novice.
  • UserAssist at HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist\<GUID>\Count. Records GUI-launched programs per user, with run count and last execution time stored in a 72-byte binary structure. Value names are ROT13-encoded, so ZHFGRA.RKR is MUSTAN.EXE after decoding. RegRipper and Registry Explorer decode automatically.
  • MUICache at HKCU\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\MuiCache. Stores executable friendly names for programs the user has run. Lacks timestamps but proves a program was launched by that user.
  • RecentDocs at HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs. Recently opened documents, broken down by file extension. A .docx subkey lists recent Word documents, .pdf lists recent PDFs, and so on. The last-write time of each subkey is the most-recent-access timestamp for that extension.
  • TypedURLs at HKCU\Software\Microsoft\Internet Explorer\TypedURLs. URLs the user has typed into Internet Explorer or Edge legacy. On Windows 10/11 the parallel value TypedURLsTime carries timestamps. Edge Chromium history lives in SQLite, not the registry; see the email and browser forensics topic for that.
  • MountedDevices at HKLM\SYSTEM\MountedDevices. Maps drive letters to volume signatures. Useful for proving that a specific USB device was mounted as E: at a specific time.
  • USBStor at HKLM\SYSTEM\CurrentControlSet\Enum\USBSTOR. Records every USB mass-storage device ever connected, by vendor, product, and serial number. The serial number is the silver bullet; it matches against a physical device the police later seize.
  • EMDMgmt at HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\EMDMgmt. ReadyBoost candidate records that include drive serial and a first-connection timestamp. The classic cross-check for USBStor.
  • LSA Secrets in the SECURITY hive. Cached credentials for services and scheduled tasks. Extracted with mimikatz, secretsdump from Impacket, or commercial Passware Kit. A goldmine in domain-joined enterprise cases.
  • AppCompatCache (Shimcache) at HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache. The Application Compatibility shim records executables seen by the system, with file size and last-modified time. Written to disk at shutdown, so a hard power-off can lose the most recent entries.
  • Amcache.hve at C:\Windows\AppCompat\Programs\Amcache.hve. A standalone hive with rich install and execution metadata including SHA-1 hash of each executable, first-run time, and parent install info. Often the only place where a deleted malware sample's SHA-1 still lives.
  • TimeZoneInformation at HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation. The system's configured time zone, bias, and daylight rule. Critical for converting every other timestamp on the image into IST or UTC for the report.

EVTX event logs: what to read first

Windows Vista replaced the legacy .evt log format with EVTX, an XML-structured binary format. The files live at C:\Windows\System32\winevt\Logs\ and are organised by channel. A modern Windows 11 install has more than 400 channels, but for forensic triage four channels and roughly a dozen event IDs do most of the work.

ChannelFileKey eventsForensic use
SecuritySecurity.evtx4624, 4625, 4634, 4672, 4720, 4724, 4738Logon, logoff, privilege use, account changes
SystemSystem.evtx6005, 6006, 1074, 41, 7045Boot, shutdown, BSOD, service install, time change
ApplicationApplication.evtx1000, 11707, 1033App crashes, MSI installs, .NET errors
PowerShell OperationalMicrosoft-Windows-PowerShell%4Operational.evtx4103, 4104Pipeline execution, script block logging
Sysmon OperationalMicrosoft-Windows-Sysmon%4Operational.evtx1, 3, 7, 11, 22Process create, network connect, image load, file create, DNS query

The Security log carries the events an Indian cyber-cell triage almost always touches:

  • 4624 logon success. The Logon Type sub-field distinguishes interactive (type 2), network (type 3), unlock (type 7), RDP (type 10) and cached-credential (type 11) logons.
  • 4625 logon failure, with status and sub-status codes that say why (wrong password, expired account, locked out).
  • 4634 and 4647 logoff (4647 is user-initiated, 4634 is the system view).
  • 4672 assignment of special privileges, the classic "an admin logged in" indicator.
  • 4720 user account created; 4724 password reset; 4738 account changed. These three together are the audit trail for insider account abuse.

System.evtx is where boot and shutdown sequences live (6005 event log service started, 6006 event log service stopped, 1074 user-initiated restart with the actual binary that triggered it, 41 unexpected restart). Service installations are 7045, a key event for tracking malware that installs itself as a Windows service. Time-change events are buried in the System log at event 1; an examiner who sees one of those flags the case as potentially anti-forensic.

PowerShell Operational at event 4104 records the full script block of every PowerShell command if script block logging is enabled (the default on Windows 10+ with the right policy). This is where attacker Invoke-Mimikatz and Invoke-WebRequest calls land, deobfuscated by Windows itself before logging, which is one of the best gifts to a defender that Microsoft has ever shipped.

Sysmon is not installed by default. When it is, the operational log captures every process creation with command line, parent process, image hash and parent image hash. CERT-In's CSIRT-Fin playbook for banking incidents recommends Sysmon deployment on critical endpoints, and several Indian PSU networks now ship it as standard.

Prefetch: proof of execution

Prefetch is a Windows performance optimisation that watches the first ten seconds of execution of every program and writes a .pf file recording the executable's name, a hash of its path, the time of execution, the count of executions, and the list of DLLs and data files it touched. The files live in C:\Windows\Prefetch\ with the naming convention <EXE>-<8-character-path-hash>.pf.

For an examiner the Prefetch file is the strongest execution proof the operating system provides. Registry execution traces can be argued to reflect scheduling rather than actual launch; a Prefetch entry exists only if the binary was loaded into memory and began executing.

PECmd from Eric Zimmerman is the standard parser, producing CSV output that includes the executable name, the last eight run times, the run count, the referenced file list, the volume serial of the source disk, and the path-hash check. RegRipper plugins parse the related registry references. KAPE targets the Prefetch directory by default in its BasicCollection profile.

A subtlety that catches new examiners: Prefetch is disabled on SSDs by default in some Windows builds and tunings, controlled by HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters\EnablePrefetcher. A value of 0 means disabled, 3 means enabled for boot and applications. On servers Prefetch is disabled by default. The examiner always checks the EnablePrefetcher value before drawing conclusions from an absence of .pf files; an absent file does not mean the program did not run if Prefetch was off.

The referenced-file list inside a .pf is itself evidence. A malicious binary's .pf will list the libraries it imported and any data files it touched in those first ten seconds. Ransomware such as cryptolocker variants leaves a Prefetch entry whose referenced-file list includes the first documents it encrypted, sometimes the only remaining record of victim files when the ransomware has deleted its own logs.

The toolset: Eric Zimmerman, RegRipper, KAPE

The Windows artefact tooling that Indian SFSLs converge on is predominantly free and is primarily maintained by Eric Zimmerman (the EZ Tools suite) and Harlan Carvey (RegRipper). KAPE, originally written by Eric Zimmerman, is the triage orchestrator that pulls artefacts off a live or imaged system and feeds them to the parsers.

ToolPurposeInputOutput
Registry ExplorerInteractive registry browse with bookmark pluginsHive file with .LOG1/.LOG2GUI navigation, CSV export
RECmdCommand-line registry parser, plugin-drivenHive file or mounted imageCSV per plugin
RegRipper 3.0Command-line plugin engine in PerlHive fileText or CSV report per plugin
EvtxECmdEVTX parser with Maps for normalised fieldsEVTX file or directoryCSV with named fields per event
PECmdPrefetch parser.pf file or directoryCSV with last-8 times and referenced files
KAPETriage orchestratorLive system or mounted imageCollected artefacts plus parsed CSVs
SysmonLive process and network telemetry, not a parserLive systemOperational EVTX channel

A typical Indian SFSL triage timeline on a Windows seizure runs as follows.

  1. Hour 0 to 1: image verification
    Mount the E01 image read-only with Arsenal Image Mounter, verify the MD5 and SHA-256 in the BSA Sec 63 certificate match.
  2. Hour 1 to 2: KAPE collection
    Run KAPE against the mounted image with the !BasicCollection target. KAPE pulls registry hives, EVTX files, Prefetch, Amcache, LNK, ShellBags, and browser history into a structured output directory.
  3. Hour 2 to 4: KAPE modules
    Run KAPE modules to parse the collected artefacts: RECmd_BatchExamples, EvtxECmd, PECmd, AmcacheParser, LECmd, SBECmd. Output is per-artefact CSV plus a master timeline.
  4. Hour 4 to 6: timeline review
    Load the master CSV into Timeline Explorer or Elastic. Pivot on user, executable, USB device serial, and remote IP. The first triage report is drafted from this view.
  5. Hour 6+: targeted analysis
    Specific findings drive targeted analysis: malware sample carving, decryption of suspicious archives, memory analysis with Volatility on the RAM dump from acquisition.

The whole pipeline is documented on the analyst worksheet with command-line invocations and output file hashes, so that the BSA Sec 63(4) certificate can identify exactly which version of which tool produced each piece of derived evidence. CFSL Hyderabad maintains a frozen toolset version per case, which is the cleanest way to handle long-running investigations where Eric Zimmerman ships a tool update mid-case.

The Windows artefact triangle: registry hives, EVTX event logs and Prefetch each answer a different question. Registry says w
The Windows artefact triangle: registry hives, EVTX event logs and Prefetch each answer a different question. Registry says what was configured and what was launched; EVTX says what the system observed and when; Prefetch says what actually ran. A finding corroborated across all three is the strongest finding in a Windows case.

An end-to-end Windows triage in an Indian context

Consider a case that lands at a state SFSL cyber wing in Pune: a private-bank employee is alleged to have copied a customer database to a personal USB stick over a weekend and shared it with a competitor. The seized laptop is a Windows 10 Pro machine; the suspect has admitted using a USB stick but denies copying any customer data. The cyber cell wants confirmation, within 24 hours, that (a) a specific Kingston USB was plugged in over the weekend, (b) Microsoft Excel and a particular query tool were launched while it was plugged in, and (c) files of a customer-database shape were written to the USB.

The examiner mounts the E01, runs KAPE, and pivots through the triangle:

  • USBStor under HKLM\SYSTEM confirms a Kingston DataTraveler with serial 08...A3F was first connected three weeks ago and last connected on Saturday at 14:22 IST. MountedDevices confirms it was mounted as drive E:. EMDMgmt carries the same serial, which corroborates the entry.
  • UserAssist under HKCU NTUSER.DAT decodes a launch of EXCEL.EXE at 14:24 IST and SQLQUERYTOOL.EXE at 14:31, both on Saturday, with run counts incremented by one.
  • Prefetch shows EXCEL.EXE-<hash>.pf with the most recent of its eight timestamps at 14:24:07 and SQLQUERYTOOL.EXE-<hash>.pf at 14:31:12. The referenced-file list inside the SQLQUERYTOOL.pf includes a path that begins with E:\ and ends in customer_export.csv.
  • Security.evtx 4624 events on Saturday show an interactive logon (type 2) at 14:18 by the suspect's domain account; 4647 logoff at 16:05. System.evtx 1074 records a clean shutdown at 16:06.
  • Microsoft-Windows-PowerShell/Operational has nothing relevant. Sysmon was not installed.
  • RecentDocs under the .csv subkey shows the customer-export filename, with the subkey last-write at 14:32 IST.

The three pillars agree: a registry trail of USB connection and program launches, an event-log trail of session start and clean shutdown, a Prefetch trail of execution with the USB path embedded. The BSA Sec 63(4) certificate cites each artefact, the parser version, and the dual-hash on the source E01. The PECmd output for SQLQUERYTOOL.EXE is attached to the report as Annexure B.

Cross-artefact corroboration carries greater evidential weight than any single source. An individual artefact can be argued to be coincidental or misconfigured; findings consistent across all three families are substantially harder to challenge.

Practice
Question 1 of 5· 0 answered

Which physical file holds the per-user portion of the Windows registry, including UserAssist and RecentDocs?

Frequently asked questions

What are the five Windows registry hives and where are they stored?
Logically: HKLM\SAM, HKLM\SYSTEM, HKLM\SOFTWARE, HKLM\SECURITY (all under C:\Windows\System32\config) and HKU per user (NTUSER.DAT in C:\Users\<user> with UsrClass.dat in AppData\Local\Microsoft\Windows). HKCU, HKCR and HKCC are logical views that map onto the above. Each active hive also has .LOG1 and .LOG2 transaction logs that modern parsers replay before reading the hive proper.
What is UserAssist and why is it ROT13-encoded?
UserAssist is a per-user registry record at HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist\<GUID>\Count of GUI-launched programs, with run count and a Windows FILETIME last-execution timestamp inside a 72-byte binary value. Value names are ROT13-encoded for trivial obfuscation; the encoding does not provide security but prevents casual registry browsing from immediately revealing every program a user has launched. RegRipper and Registry Explorer decode automatically.
Which event IDs in Security.evtx are most useful for forensic triage?
4624 (logon success, with Logon Type telling interactive, network, RDP, cached), 4625 (logon failure with status and sub-status), 4634 and 4647 (logoff), 4672 (special privileges, the admin indicator), 4720 (account created), 4724 (password reset) and 4738 (account changed). These cover the session, the privilege escalation, and the account-lifecycle audit.
How is Prefetch different from the Run keys in the registry?
Run keys list programs configured to start at logon but do not prove that any specific program actually ran. Prefetch is generated by the Windows prefetcher only after a binary is loaded into memory and begins executing, so a .pf file is direct evidence of execution. The two are complementary: Run says what was scheduled to launch, Prefetch says what truly launched.
Where does the Amcache.hve file live and what does it record?
Amcache.hve sits at C:\Windows\AppCompat\Programs\Amcache.hve. It is a standalone registry hive (separate from the main hives in System32\config) that records application install and execution metadata, including a SHA-1 hash of each executable, first-run time and parent install information. The SHA-1 is the gold-standard cross-reference because it survives even after the original executable is deleted, which makes Amcache the place where a malware sample's identifier often remains long after the binary itself is gone.
What tools do Indian SFSLs use for Windows artefact parsing?
Eric Zimmerman's EZ Tools suite (Registry Explorer, RECmd, EvtxECmd, PECmd, AmcacheParser, LECmd, SBECmd), Harlan Carvey's RegRipper 3.0, and KAPE as the triage orchestrator. KAPE pulls artefacts from a live or imaged system using target definitions and then runs module-defined parsers to produce CSV output. Sysmon, when installed on the source system, produces the Microsoft-Windows-Sysmon/Operational EVTX channel that EvtxECmd parses with named fields.
Can chain-of-custody concerns from Crime Scene Management apply to Windows artefacts?
Yes, in two ways. First, the chain-of-custody discipline covered in /topics/crime-scene-management/chain-of-custody applies to the device and its image from seizure to court. Second, BSA Sec 63 requires a certificate identifying the device and the manner of production of the electronic record; parser version, command-line arguments, and output hashes are part of that production manner and are recorded on the analyst worksheet attached to the certificate.

Test yourself on Digital Forensics with free, timed mocks.

Practice Digital Forensics questions

Found this useful? Pass it along.

Share

Spotted an error in this page? Report a correction or read our editorial standards.

Your journey to becoming a forensic professional starts here.

Practice with mock tests, learn from structured notes, and get your questions answered by a global forensic community, all in one place.