Windows Forensic Investigations: Guidelines and Methodology

• Windows Forensic Investigations: Guidelines and Methodology
  • Order of Volatility
  • Evidence Acquisition
    • Live Response vs. Dead-Box
    • Disk Imaging
    • Memory Acquisition
    • KAPE: Triage Collection
  • Volatile Data Sources
    • pagefile.sys
    • swapfile.sys
    • hiberfil.sys
  • Volume Shadow Copies (VSS)
    • Forensic Value
    • Accessing Shadow Copies
    • Anti-Forensics Note
  • Modern Windows Artifacts
    • SRUM (System Resource Usage Monitor)
    • Amcache.hve
    • ShimCache (AppCompatCache)
    • Jump Lists
    • BAM/DAM (Background/Desktop Activity Moderator)
    • Windows Timeline (ActivitiesCache.db)
    • PowerShell Logging
    • WMI Repository Persistence
    • Windows Search Index
    • BITS Queue Database
    • Scheduled Tasks
    • Windows Notification Database
  • Anti-Forensics Detection
    • Timestomping
    • Log Clearing
    • Secure Deletion Tools
    • BitLocker
  • Investigation Workflow
    • Initial Response
    • Triage Phase
    • Common Scenarios
    • Timeline Construction
  • Key Event IDs
  • Tool Summary
  • Further Reading

This page covers the investigative methodology and workflow for Windows forensic investigations, including evidence acquisition, modern Windows artifacts, and anti-forensics awareness. For specific artifact locations (Registry, event logs, link files, Recycle Bin, browser history, etc.), see the companion Windows Forensics page. For NTFS file system internals, see NTFS Analysis.

Order of Volatility

Evidence must be collected in order of decreasing volatility. Data that disappears first must be captured first. This ordering comes from RFC 3227 and is reinforced by NIST SP 800-86:

The practical consequence: if the system is running, capture memory before touching the disk.

Evidence Acquisition

Live Response vs. Dead-Box

Live response collects volatile data from a running system. It is essential when:

• The volume is encrypted (BitLocker, VeraCrypt) – keys exist only in memory while the volume is mounted
• Fileless malware is running entirely in memory with no on-disk artifacts
• Network connections, running processes, or open file handles are needed as evidence

The tradeoff is that every action on a live system alters it. Run portable tools from external media, never install anything on the evidence system, and document everything you do.

Dead-box acquisition images the disk from a powered-off system (or via a forensic boot environment). It preserves disk state with no risk of alteration, but all volatile data is lost. Preferred when the system is already off or when full-disk integrity is the priority.

Best practice: capture memory first (live response), then shut down and image the disk (dead-box).

Disk Imaging

Always write the image to external media. Hash the image immediately (SHA-256) and record the hash in your notes. Verify the hash after any copy or transfer.

For virtual machines, prefer hypervisor-level snapshots (.vmem, .vmsn, .vmdk) over in-guest imaging tools – they are faster, more complete, and do not alter the guest.

Memory Acquisition

Always dump to external media. Memory images are analyzed with Volatility, Rekall, or commercial tools.

KAPE: Triage Collection

KAPE (Kroll Artifact Parser and Extractor), created by Eric Zimmerman, is designed for rapid targeted artifact collection rather than full-disk imaging. It is the standard triage tool when time or bandwidth does not allow a full image.

Architecture:

• Targets: YAML files that define what to collect – file paths, registry hives, specific directories. Examples: RegistryHives, EventLogs, Amcache, SRUM, Prefetch. Compound targets reference other targets.
• Modules: YAML files that define what parsing tools to run against collected artifacts. Each module wraps an external tool (AmcacheParser, RegRipper, PECmd, etc.) and produces parsed output (CSV, JSON).
• Workflow: Collect with Targets, then process with Modules. Can run both in sequence.

The community-maintained target and module repository lives at github.com/EricZimmerman/KapeFiles.

KAPE is not a substitute for a full disk image – it collects only what its targets specify. But for initial triage, incident response, or situations where full imaging is impractical, it provides structured, repeatable artifact collection in minutes.

Volatile Data Sources

These exist on disk but contain data that originated in memory and may be partially or fully overwritten at any time.

pagefile.sys

Location: C:\pagefile.sys

The Windows page file contains memory pages that have been swapped out of physical RAM. It is not structured – there is no index or table of contents. Contents include fragments of running processes, credentials, URLs, chat messages, document content, and anything else that was in memory.

Analysis approach: string searches, YARA rule scans, bulk_extractor. You are looking for specific data (IP addresses, passwords, filenames) rather than trying to reconstruct the page file’s structure.

swapfile.sys

Location: C:\swapfile.sys

Introduced in Windows 8. Dedicated to UWP (Microsoft Store) applications. When a UWP app is suspended, its state is paged here. Same analysis approach as pagefile.sys, but content is limited to Store apps.

hiberfil.sys

Location: C:\hiberfil.sys

Contains a compressed snapshot of physical memory captured at hibernation time. This includes running processes, logged-in credentials, encryption keys, open documents, browser sessions, and everything else in RAM at the moment of hibernation.

Important: Windows 8 and later use “Fast Startup” by default, which performs a partial hibernation on every normal shutdown. Even on a system where the user has never deliberately hibernated, hiberfil.sys contains a kernel-session memory image from the last shutdown. This makes hiberfil.sys relevant on virtually all modern Windows systems.

Format: PO_MEMORY_IMAGE header followed by Xpress-compressed data blocks. Tools for analysis include Volatility (with the hibernation layer), Arsenal Hibernation Recon, and vol.py -f hiberfil.sys --profile=<profile> imagecopy to convert to a raw memory image for further analysis.

Volume Shadow Copies (VSS)

Volume Shadow Copies are point-in-time snapshots of NTFS volumes managed by the Volume Shadow Copy Service. Introduced in Windows XP SP1, they became comprehensive block-level snapshots starting with Vista. System Restore points and Windows Backup both create shadow copies.

Forensic Value

• Recover deleted files: a file deleted from the live volume may still exist in a prior shadow copy
• View previous states of registry hives: compare NTUSER.DAT across shadow copies to see what changed and when
• Detect anti-forensics: if the current disk shows no evidence but a shadow copy from last week contains it, the suspect deleted evidence between then and now

Accessing Shadow Copies

On a live system (admin required):

vssadmin list shadows

This lists all shadow copies with creation timestamps and shadow copy IDs.

To mount a specific shadow copy:

mklink /d C:\vss_mount \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy3\

From a forensic image:

• Arsenal Image Mounter: mount the forensic image as a SCSI device; Windows automatically exposes all VSCs
• vshadowmount (libvshadow, Linux): mount individual shadow copies from raw or E01 images using byte offsets
• FTK Imager: browse mounted VSCs after Arsenal mounts the image

Anti-Forensics Note

Attackers and knowledgeable suspects may delete shadow copies to destroy historical evidence:

vssadmin delete shadows /all /quiet

The execution of vssadmin.exe will appear in Prefetch (vssadmin.exe-*.pf) and potentially in Sysmon or command-line audit logs. The absence of any shadow copies on a system that should have them (System Restore enabled, regular backup schedule) is itself suspicious.

Modern Windows Artifacts

These artifacts supplement the Registry, event logs, and file system artifacts covered in Windows Forensics. Many were introduced in Windows 8 or 10 and are not yet widely known.

SRUM (System Resource Usage Monitor)

Introduced in Windows 8.

• Location: C:\Windows\System32\sru\SRUDB.dat (ESE database)
• Interim data (not yet flushed to database): HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SRUM\Extensions

SRUM records per-application resource usage:

Retention is approximately 30 days for application data and 60 days for network data. Data is written hourly and at shutdown.

Tools: SrumECmd (Eric Zimmerman), srum-dump (Mark Baggett).

Forensic significance: SRUM can prove that a specific application sent a specific number of bytes over the network while connected to a specific WiFi network. This is powerful for data exfiltration investigations – even if the application has been uninstalled and the browser history cleared, SRUM retains the record.

Amcache.hve

Introduced in Windows 8.

• Location: C:\Windows\AppCompat\Programs\Amcache.hve (registry hive)

Records application execution with rich metadata:

• First execution timestamp
• Full file path
• File size
• SHA-1 hash of the executable (enables VirusTotal lookups for files no longer on disk)
• Publisher metadata and PE header information

Tools: AmcacheParser (Eric Zimmerman), Registry Explorer.

Forensic significance: the SHA-1 hash is the key value. Even if a malicious executable has been deleted, the Amcache retains its hash, allowing you to identify the malware family or confirm it was present.

ShimCache (AppCompatCache)

Present from Windows XP through current versions.

• Location: HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache (AppCompatCache value)

Records file path, file size, and last modified time for executables that the Application Compatibility shim engine has processed. The cache is held in memory and written to the registry at shutdown.

Critical caveat: a ShimCache entry does not prove execution. It proves the file was present and was scanned by the shim engine, which can happen when a directory listing is displayed or a file is accessed without execution. In Windows 10, an execution flag exists (last 4 bytes = 1), but it is not conclusive.

Tools: AppCompatCacheParser (Eric Zimmerman), ShimCacheParser (Mandiant).

Jump Lists

Introduced in Windows 7.

• Location: C:\Users\<user>\AppData\Roaming\Microsoft\Windows\Recent\AutomaticDestinations\ (*.automaticDestinations-ms) and ...\CustomDestinations\ (*.customDestinations-ms)

Jump Lists record recently opened files per application, linked by an application ID. Each entry includes the file path, timestamps, and an access count. They are stored as OLE compound files.

Tools: JumpListExplorer, JLECmd (Eric Zimmerman).

Forensic significance: Jump Lists persist after files are deleted and after Recent Items are cleared. They provide per-user, per-application file access history.

BAM/DAM (Background/Desktop Activity Moderator)

Introduced in Windows 10 version 1709.

• Location: HKLM\SYSTEM\CurrentControlSet\Services\bam\UserSettings\{SID} and ...\dam\UserSettings\{SID}

Records the full path of executed binaries with a last execution timestamp, attributed to a specific user by SID.

Limitation: entries clear on reboot or after approximately 7 days.

Windows Timeline (ActivitiesCache.db)

Introduced in Windows 10 version 1803.

• Location: C:\Users\<user>\AppData\Local\ConnectedDevicesPlatform\<folder>\ActivitiesCache.db (SQLite)

Records application usage, files opened, websites browsed, and duration of activity. If the user has a Microsoft account, this data syncs across devices.

Tools: WxTCmd (Eric Zimmerman).

PowerShell Logging

PowerShell supports three logging mechanisms, controlled by Group Policy or registry settings:

Event ID 4104 (Script Block Logging) is the most forensically valuable because it captures the actual code after all layers of obfuscation have been resolved. Logs are written to Microsoft-Windows-PowerShell/Operational.

Registry path prefix for all three: HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\

WMI Repository Persistence

• Location: C:\Windows\System32\wbem\Repository\ (OBJECTS.DATA, INDEX.BTR, MAPPING*.MAP)

Attackers create WMI Event Subscriptions (an EventFilter + EventConsumer + FilterToConsumerBinding) for fileless persistence that survives reboots. The malicious payload lives entirely within the WMI repository – no files on disk.

Detection: Event ID 5861 in the Microsoft-Windows-WMI-Activity/Operational log records permanent event consumer registration.

Tools: PyWMIPersistenceFinder (Mandiant), flare-wmi (Mandiant).

Windows Search Index

• Location: C:\ProgramData\Microsoft\Search\Data\Applications\Windows\Windows.edb (ESE database, Vista through Windows 10). Windows 11 migrated to SQLite.

Contains indexed file metadata, partial file content, email subjects and bodies, and file paths – including paths to files that have since been deleted. If the search indexer indexed a file before it was deleted, the index entry persists.

Tools: WinSearchDBAnalyzer, SIDR, ESEDatabaseView.

BITS Queue Database

• Location: %ALLUSERSPROFILE%\Microsoft\Network\Downloader\
  • Pre-Windows 10: qmgr0.dat and qmgr1.dat (proprietary format)
  • Windows 10+: qmgr.db (ESE database) with edb.log transaction logs

BITS (Background Intelligent Transfer Service) manages background downloads and uploads. Legitimate uses include Windows Update and application patching. Attackers use BITS jobs for persistent, resumable file downloads and C2 communication – BITS jobs survive reboots and resume automatically.

Tools: BitsParser (Mandiant/FireEye), bits_parser (ANSSI-FR).

Scheduled Tasks

• File system: C:\Windows\System32\Tasks\ – each task is an individual XML file containing the action (command or script), triggers, principal (user context), and creation metadata
• Registry: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks\{GUID} and ...\Tree\
• Event Log: Event ID 106 (task registered) and Event ID 140 (task updated) in Microsoft-Windows-TaskScheduler/Operational

Windows Notification Database

• Location: %LOCALAPPDATA%\Microsoft\Windows\Notifications\wpndatabase.db (SQLite, per-user)

Contains push notifications in XML format, including application names, notification content, and timestamps. May contain previews of chat messages, email subjects, calendar reminders, and other notification content from applications that the user may not have otherwise saved.

Anti-Forensics Detection

Timestomping

Timestomping modifies the $STANDARD_INFORMATION (SI) timestamps in NTFS MFT entries to disguise when a file was actually created or modified. Common tools include Timestomp, PowerShell Set-ItemProperty, and NirSoft BulkFileChanger.

Detection methods:

1. SI vs. FN timestamp comparison: the $FILE_NAME (FN) attribute timestamps are set by the kernel and are not modified by standard timestomping tools. If the SI timestamps are older than the FN timestamps (file appears to have been created before it existed), timestomping has occurred.
2. USN Journal ($UsnJrnl:$J): the USN Journal records file creation, modification, rename, and deletion events with independent timestamps. These entries contradict falsified SI timestamps.
3. Automated detection: MFTECmd (Eric Zimmerman) automatically flags entries where SI timestamps precede FN timestamps.

Limitation: advanced tools exist that can also modify FN timestamps, and some legitimate installers set SI timestamps during installation. Context matters.

Log Clearing

• Security Event ID 1102: “The audit log was cleared.” Records the account that cleared the log and the timestamp. This event is always generated unless the Event Log service itself has been tampered with.
• System Event ID 104: “The System log file was cleared.”

The presence of Event ID 1102 with no preceding security events is a strong indicator of deliberate evidence destruction.

Mitigation: forward event logs to a centralized SIEM or syslog server so that remote copies survive local clearing.

Secure Deletion Tools

Detection approach: check the USN Journal for rapid rename-overwrite-delete sequences. Check Prefetch for secure deletion tool executables. Check Amcache for SHA-1 hashes of deletion tools.

BitLocker

BitLocker provides full-volume encryption. If the system is live and the volume is unlocked, the data is accessible – image the live system or capture the encryption keys from memory.

If the system is powered off and the volume is locked, the data is unrecoverable without the recovery key. Recovery keys may be stored in:

• Active Directory (domain-joined machines)
• The user’s Microsoft account (personal machines)
• A printed or saved key file

This makes live acquisition critical for encrypted systems. If you encounter a running system with BitLocker, capture memory and image the disk before powering off.

Investigation Workflow

Initial Response

1. Document the scene: photograph the system, note what is on screen, record the system clock time and its offset from actual time
2. Decide: live response or power off? If the system is encrypted, running malware, or has active network connections of interest – live response first
3. If live: capture memory (WinPmem/DumpIt to external USB), then capture volatile network state:

   ipconfig /all
   netstat -anob
   arp -a
   tasklist /v
   net session
   net use
   

4. Image the disk: power off (pull the plug for desktops to avoid shutdown scripts; hold power for laptops), then image via write-blocked connection or forensic boot environment
5. Hash everything: SHA-256 the memory dump and disk image immediately

Triage Phase

If time or circumstances do not allow full imaging, use KAPE to collect:

• Registry hives (SAM, SYSTEM, SOFTWARE, SECURITY, NTUSER.DAT, UsrClass.dat)
• Event logs (C:\Windows\System32\winevt\Logs\)
• Prefetch (C:\Windows\Prefetch\)
• Amcache (C:\Windows\AppCompat\Programs\Amcache.hve)
• SRUM (C:\Windows\System32\sru\SRUDB.dat)
• Jump Lists, Recent Items, ShimCache
• Browser databases
• PowerShell transcription logs (if enabled)

Common Scenarios

Malware incident: Memory analysis (Volatility: process list, DLL injection, network connections) -> Prefetch and Amcache for execution evidence -> SRUM for network activity -> Event Logs (PowerShell Event ID 4104, Sysmon if present) -> Scheduled Tasks and WMI repository for persistence -> BITS queue for download staging -> Timeline reconstruction via $MFT and USN Journal.

Insider threat: USB device history (HKLM\SYSTEM\CurrentControlSet\Enum\USBSTOR and setupapi.dev.log) -> Jump Lists and Recent Items for file access -> SRUM for network exfiltration volume -> Browser history and downloads -> BAM/DAM for execution attribution -> Windows Timeline for activity duration -> Email and notification databases for intent.

Data exfiltration: SRUM (bytes sent per application, connected SSID) -> Event Logs for RDP/VPN sessions (Event ID 4624/4625 for logon, Event ID 1149 for RDP) -> USB history -> Cloud storage client artifacts (OneDrive, Dropbox sync logs) -> Browser downloads -> BITS queue for staged transfers.

Timeline Construction

Integrate all artifact timestamps into a unified chronological timeline. Tools:

• plaso / log2timeline: ingests event logs, registry, PCAP, browser data, Prefetch, MFT, syslog, and more into a unified “super timeline”
• mactime (The Sleuth Kit): file system timeline from MFT timestamps
• Timeline Explorer (Eric Zimmerman): GUI for browsing plaso output

Normalize all timestamps to UTC before integrating. Verify the system clock offset against known time sources (NTP logs, domain controller logs) to correct for clock skew.

Key Event IDs

Tool Summary

Further Reading

• NIST SP 800-86: Guide to Integrating Forensic Techniques into Incident Response
• NIST SP 800-61: Computer Security Incident Handling Guide
• SANS FOR500: Windows Forensic Analysis course materials
• Eric Zimmerman’s tools – the standard open-source toolkit for Windows artifact parsing
• SANS Windows Forensic Analysis poster – single-page artifact reference
• Windows Forensic Artifacts handbook – community-maintained artifact reference on GitHub