# Windows Forensic Artifacts Reference

**Total Artifacts:** 61 | **Generated:** 2026-03-07

---

## Authentication & Access

### Security Event Log (4624/4625/4688)
**Location:** `C:\Windows\System32\winevt\Logs\Security.evtx`

**Also Known As:** Security.evtx, 4624, 4625, 4688

Primary Windows security audit log capturing logon events (4624 success, 4625 failure), process creation (4688), privilege escalation, and object access.

**Forensic Value:** Correlating Event ID 4624 logon types (e.g., Type 3 network, Type 10 RDP) with source IPs reveals lateral movement. Failed logon bursts (4625) expose brute-force and password-spray campaigns. Process creation events (4688) with command-line auditing enabled provide a full execution timeline even when EDR is absent.

**Tools:** KAPE, EvtxECmd (Eric Zimmerman), Event Log Explorer, Chainsaw

**Collection Commands:**
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target EventLogs`
- **PowerShell:** `Get-WinEvent -Path "C:\Windows\System32\winevt\Logs\Security.evtx" -MaxEvents 1000 | Export-Csv security_events.csv`
- **EvtxECmd:** `EvtxECmd.exe -f "C:\Windows\System32\winevt\Logs\Security.evtx" --csv C:\output --csvf Security.csv`
- **Chainsaw:** `chainsaw hunt "C:\Windows\System32\winevt\Logs\Security.evtx" -s sigma/ --mapping mappings/sigma-event-logs-all.yml`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.
- Centralized log copies may normalize, truncate, or drop fields relative to the original on-host artifact. Preserve the local source when scope and access permit.

### SAM Registry Hive
**Location:** `C:\Windows\System32\config\SAM`

Security Accounts Manager hive containing local user accounts, group memberships, password policy settings, and NTLM password hashes.

**Forensic Value:** Enumerating local accounts reveals rogue admin accounts created for persistence. Comparing last password change timestamps against known compromise windows identifies accounts likely tampered with by adversaries. Extracted NTLM hashes (with SYSTEM hive as decryption key) confirm whether pass-the-hash was feasible.

**Tools:** KAPE, RegRipper, Impacket secretsdump, Registry Explorer (Eric Zimmerman)

**Collection Commands:**
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target RegistryHives`
- **reg.exe:** `reg save HKLM\SAM C:\output\SAM.hiv`
- **Impacket:** `python3 secretsdump.py -sam SAM.hiv -system SYSTEM.hiv LOCAL`
- **RegRipper:** `rip.exe -r C:\output\SAM.hiv -p samparse`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.

### Terminal Services / RDP Event Logs
**Location:** `C:\Windows\System32\winevt\Logs\Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx`

Remote Desktop Services event logs capturing RDP session lifecycle events. Event 1149 records successful network-level authentication with source IP and username. Events 21/22/23/24/25 track session logon, reconnect, and disconnect states.

**Forensic Value:** RDP is the most common lateral movement mechanism in enterprise breaches. Event 1149 provides the remote IP address of every successful RDP authentication, directly proving which machine an attacker pivoted from. Session disconnect and reconnect events reconstruct the duration of attacker interactive access on each host. Correlating these with Security 4624 Type 10 events validates the complete lateral movement chain.

**Tools:** KAPE, EvtxECmd (Eric Zimmerman), Event Log Explorer, Chainsaw

**Collection Commands:**
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target EventLogs`
- **EvtxECmd:** `EvtxECmd.exe -f "C:\Windows\System32\winevt\Logs\Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx" --csv C:\output --csvf RDP_LocalSession.csv`
- **PowerShell:** `Get-WinEvent -LogName "Microsoft-Windows-TerminalServices-LocalSessionManager/Operational" | Where-Object {$_.Id -eq 1149} | Export-Csv C:\output\rdp_auth.csv`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.
- Centralized log copies may normalize, truncate, or drop fields relative to the original on-host artifact. Preserve the local source when scope and access permit.

### Kerberos Authentication Events (4768/4769/4771)
**Location:** `C:\Windows\System32\winevt\Logs\Security.evtx (Domain Controllers)`

Kerberos protocol events from domain controller Security logs: Event 4768 (TGT requested), Event 4769 (service ticket requested), Event 4771 (Kerberos pre-authentication failed), and Event 4770 (TGT renewed).

**Forensic Value:** Kerberos events are essential for detecting identity-based attacks in Active Directory environments. Event 4769 with encryption type 0x17 (RC4) for service accounts indicates Kerberoasting attacks harvesting crackable service tickets. Event 4768 with unusual encryption types or from unexpected IPs detects Golden Ticket usage. Event 4771 failure codes identify password spray campaigns targeting domain accounts. These events are only logged on domain controllers.

**Tools:** KAPE, EvtxECmd (Eric Zimmerman), Event Log Explorer, Chainsaw, DeepBlueCLI

**Collection Commands:**
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target EventLogs`
- **EvtxECmd:** `EvtxECmd.exe -f "C:\Windows\System32\winevt\Logs\Security.evtx" --csv C:\output --csvf Security_Kerberos.csv`
- **PowerShell:** `Get-WinEvent -FilterHashtable @{LogName="Security"; Id=4768,4769,4771} | Export-Csv C:\output\kerberos_events.csv`
- **DeepBlueCLI:** `powershell .\DeepBlue.ps1 "C:\Windows\System32\winevt\Logs\Security.evtx"`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.
- Centralized log copies may normalize, truncate, or drop fields relative to the original on-host artifact. Preserve the local source when scope and access permit.

### Credential Guard / LSASS Protection Logs
**Location:** `C:\Windows\System32\winevt\Logs\Microsoft-Windows-LSA%4Operational.evtx and C:\Windows\System32\winevt\Logs\Microsoft-Windows-Wininit%4Operational.evtx`

LSA operational and Wininit logs record Credential Guard status, LSASS process protection (RunAsPPL) enforcement, credential isolation events, and attempts to access protected credentials. These logs indicate whether hardware-based credential isolation was active during the incident.

**Forensic Value:** These logs confirm whether Credential Guard and LSASS protection were active at the time of compromise, directly impacting the scope of credential exposure. If Credential Guard was enabled, NTLM hashes and Kerberos TGTs were isolated in a hardware-secured container, meaning standard credential dumping tools like Mimikatz would have failed. Event ID 5004 in the LSA operational log records when a caller was denied access to LSA secrets, providing evidence of credential theft attempts. The Wininit log captures LSASS initialization including whether PPL (Protected Process Light) was enforced, and any events showing PPL was disabled or bypassed are critical indicators of a sophisticated attack targeting credential stores.

**Tools:** KAPE, EvtxECmd (Eric Zimmerman), PowerShell, Event Log Explorer

**Collection Commands:**
- **EvtxECmd:** `EvtxECmd.exe -d "C:\Windows\System32\winevt\Logs\" --inc "LSA,Wininit" --csv C:\output\ --csvf lsa_cred_guard.csv`
- **PowerShell:** `Get-WinEvent -LogName "Microsoft-Windows-LSA/Operational" | Export-Csv C:\output\lsa_operational.csv -NoTypeInformation`
- **PowerShell:** `Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" | Select-Object RunAsPPL,LsaCfgFlags | Format-List`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.
- Centralized log copies may normalize, truncate, or drop fields relative to the original on-host artifact. Preserve the local source when scope and access permit.

### SECURITY Hive (LSA Secrets & Cached Logons)
**Location:** `C:\Windows\System32\config\SECURITY`

**Also Known As:** SECURITY hive, LSA secrets, NL$KM

Registry hive storing Local Security Authority policy data including cached domain logon information, service account secrets, DPAPI-related secret material, and policy settings tied to local security configuration.

**Forensic Value:** The SECURITY hive helps determine whether domain credentials, service passwords, or other LSA-protected secrets were present and potentially exposed on the host. Offline parsing in conjunction with the SYSTEM hive can recover cached logon metadata and secret blobs that reveal service-account use, scheduled task credentials, and prior administrative authentication patterns. This is especially valuable when scoping credential access or confirming whether an endpoint held reusable authentication material after a compromise.

**Tools:** KAPE, reg.exe, Impacket secretsdump, Registry Explorer (Eric Zimmerman)

**Collection Commands:**
- **reg.exe:** `reg save HKLM\SECURITY C:\output\SECURITY.hiv`
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target RegistryHives`
- **Impacket:** `python3 secretsdump.py -security SECURITY.hiv -system SYSTEM.hiv LOCAL`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.
- Interpreting secret material usually requires the paired SYSTEM hive and administrative or offline access. Secret presence and recoverability vary with Credential Guard, RunAsPPL, domain usage, and whether cached logons were enabled.

## Execution Evidence

### Sysmon Event Log
**Location:** `C:\Windows\System32\winevt\Logs\Microsoft-Windows-Sysmon%4Operational.evtx`

Microsoft Sysinternals System Monitor log capturing process creation with hashes (Event 1), network connections (Event 3), file creation (Event 11), registry modifications (Event 13), and DNS queries (Event 22).

**Forensic Value:** Sysmon provides process-level granularity that native Windows logs lack. Process GUIDs allow reconstructing full parent-child execution trees even across reboots. Network connection events tie processes to C2 IPs and beaconing intervals. File-create-time changes (Event 2) expose timestomping attempts.

**Tools:** KAPE, EvtxECmd (Eric Zimmerman), Chainsaw, Sysmon View

**Collection Commands:**
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target EventLogs`
- **EvtxECmd:** `EvtxECmd.exe -f "C:\Windows\System32\winevt\Logs\Microsoft-Windows-Sysmon%4Operational.evtx" --csv C:\output --csvf Sysmon.csv`
- **PowerShell:** `Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" -MaxEvents 5000 | Export-Csv sysmon_events.csv`
- **Chainsaw:** `chainsaw hunt "C:\Windows\System32\winevt\Logs\Microsoft-Windows-Sysmon%4Operational.evtx" -s sigma/ --mapping mappings/sigma-event-logs-all.yml`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.
- Centralized log copies may normalize, truncate, or drop fields relative to the original on-host artifact. Preserve the local source when scope and access permit.

### PowerShell Script Block & Operational Logs
**Location:** `C:\Windows\System32\winevt\Logs\Microsoft-Windows-PowerShell%4Operational.evtx`

PowerShell Operational log and Script Block Logging (Event 4104) capturing the full text of executed scripts, including those decoded at runtime from Base64 or obfuscation layers.

**Forensic Value:** Script Block Logging defeats obfuscation by recording scripts after all decoding layers are resolved, exposing the final plaintext payload. This is often the only artifact that reveals encoded download cradles, credential harvesting, and in-memory-only tools like Invoke-Mimikatz. Module logging (Event 4103) adds pipeline execution details for reconstruction.

**Tools:** KAPE, EvtxECmd (Eric Zimmerman), Chainsaw, PowerShell

**Collection Commands:**
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target EventLogs`
- **EvtxECmd:** `EvtxECmd.exe -f "C:\Windows\System32\winevt\Logs\Microsoft-Windows-PowerShell%4Operational.evtx" --csv C:\output --csvf PowerShell.csv`
- **PowerShell:** `Get-WinEvent -FilterHashtable @{LogName="Microsoft-Windows-PowerShell/Operational"; Id=4104} | Export-Csv ps_scriptblocks.csv`
- **Chainsaw:** `chainsaw hunt "C:\Windows\System32\winevt\Logs\Microsoft-Windows-PowerShell%4Operational.evtx" -s sigma/`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.
- Centralized log copies may normalize, truncate, or drop fields relative to the original on-host artifact. Preserve the local source when scope and access permit.

### AmCache.hve
**Location:** `C:\Windows\appcompat\Programs\Amcache.hve`

Application compatibility cache hive tracking program execution with SHA1 hashes, file paths, publisher metadata, and first-execution timestamps.

**Forensic Value:** AmCache provides SHA1 hashes for executed binaries, enabling immediate VirusTotal lookups even after the attacker deletes the original file. First-execution timestamps establish when a tool was first introduced to the system. Entries persist across reboots and are harder to anti-forensic than Prefetch.

**Tools:** KAPE, AmcacheParser (Eric Zimmerman), Registry Explorer (Eric Zimmerman)

**Collection Commands:**
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target Amcache`
- **AmcacheParser:** `AmcacheParser.exe -f "C:\Windows\appcompat\Programs\Amcache.hve" --csv C:\output --csvf Amcache.csv`
- **Registry Explorer:** `Open Amcache.hve in Registry Explorer and navigate to Root\InventoryApplicationFile`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.

### Prefetch Files
**Location:** `C:\Windows\Prefetch\*.pf`

**Also Known As:** .pf

Windows Prefetch files recording application execution with the executable name, run count, last eight execution times, and all files/directories referenced during the first ten seconds of execution.

**Forensic Value:** Prefetch proves program execution even after the binary is deleted. The last eight execution timestamps create a usage pattern timeline. Referenced files and directories reveal what the tool accessed at launch, such as configuration files or credential stores. The existence of prefetch for tools like psexec.exe, mimikatz.exe, or rclone.exe is a strong indicator of compromise.

**Tools:** KAPE, PECmd (Eric Zimmerman), WinPrefetchView (NirSoft)

**Collection Commands:**
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target Prefetch`
- **PECmd:** `PECmd.exe -d "C:\Windows\Prefetch" --csv C:\output --csvf Prefetch.csv`
- **PowerShell:** `Copy-Item "C:\Windows\Prefetch\*.pf" -Destination C:\output\Prefetch\`
- **WinPrefetchView:** `WinPrefetchView.exe /folder "C:\Windows\Prefetch" /scomma C:\output\prefetch_parsed.csv`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.

### ShimCache (AppCompatCache)
**Location:** `SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache`

Application Compatibility Cache stored in the SYSTEM registry hive, recording file path, size, and last modification timestamp for executables the OS considered for compatibility shimming.

**Forensic Value:** ShimCache records executables that existed on disk even if they were never executed (on Windows 10+, execution flag is no longer set). Entries are ordered chronologically and written to the registry only at shutdown, making the insertion order a coarse timeline. Useful for confirming an attacker tool was present on disk at a particular time.

**Tools:** KAPE, AppCompatCacheParser (Eric Zimmerman), RegRipper

**Collection Commands:**
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target RegistryHives`
- **AppCompatCacheParser:** `AppCompatCacheParser.exe -f C:\output\SYSTEM --csv C:\output --csvf ShimCache.csv`
- **RegRipper:** `rip.exe -r C:\output\SYSTEM -p appcompatcache`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.

### Windows Defender Operational Log
**Location:** `C:\Windows\System32\winevt\Logs\Microsoft-Windows-Windows Defender%4Operational.evtx`

Windows Defender antivirus operational log recording threat detections (Event 1116), remediation actions (Event 1117), real-time protection state changes (Event 5001/5004), and exclusion modifications.

**Forensic Value:** Defender logs reveal what the attacker deployed that triggered detection and what they did to evade it. Event 1116 contains the detected threat name, file path, and process that accessed it. Event 5001 timestamps when real-time protection was disabled, marking the window of unmonitored activity. Exclusion additions in the log show which paths or processes the attacker whitelisted to avoid future detection.

**Tools:** KAPE, EvtxECmd (Eric Zimmerman), Event Log Explorer, Chainsaw

**Collection Commands:**
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target EventLogs`
- **EvtxECmd:** `EvtxECmd.exe -f "C:\Windows\System32\winevt\Logs\Microsoft-Windows-Windows Defender%4Operational.evtx" --csv C:\output --csvf Defender.csv`
- **PowerShell:** `Get-WinEvent -FilterHashtable @{LogName="Microsoft-Windows-Windows Defender/Operational"; Id=1116,1117,5001} | Export-Csv C:\output\defender_detections.csv`
- **Chainsaw:** `chainsaw hunt "C:\Windows\System32\winevt\Logs\Microsoft-Windows-Windows Defender%4Operational.evtx" -s sigma/`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.
- Centralized log copies may normalize, truncate, or drop fields relative to the original on-host artifact. Preserve the local source when scope and access permit.

### BAM/DAM (Background/Desktop Activity Moderator)
**Location:** `SYSTEM\CurrentControlSet\Services\bam\State\UserSettings\<SID> (Windows 10 1709+)`

Background Activity Moderator (BAM) and Desktop Activity Moderator (DAM) registry keys recording executable paths with their last execution UTC timestamp, attributed to specific user SIDs.

**Forensic Value:** BAM/DAM provides user-attributable execution evidence with timestamps, filling a gap left by Prefetch (which does not record the executing user) and AmCache (which may not have accurate execution times). Each entry links a specific executable path to the user SID that ran it and the UTC time of last execution. This is particularly valuable for identifying which user account was used to run attacker tools on shared systems.

**Tools:** KAPE, Registry Explorer (Eric Zimmerman), RegRipper, RECmd (Eric Zimmerman)

**Collection Commands:**
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target RegistryHives`
- **Registry Explorer:** `Open SYSTEM hive in Registry Explorer and navigate to ControlSet001\Services\bam\State\UserSettings`
- **RegRipper:** `rip.exe -r C:\output\SYSTEM -p bam`
- **RECmd:** `RECmd.exe -f C:\output\SYSTEM --kn "ControlSet001\Services\bam\State\UserSettings" --csv C:\output --csvf BAM.csv`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.

### SRUM Database (SRUDB.dat)
**Location:** `C:\Windows\System32\sru\SRUDB.dat`

System Resource Usage Monitor ESE database tracking per-application resource consumption over 30-60 days, including network bytes sent/received, CPU time, energy usage, and associated user SID.

**Forensic Value:** SRUM provides historical quantitative evidence of application network usage that no other artifact captures. It can prove that rclone.exe transferred 50GB outbound to a specific network profile, or that a cryptominer consumed excessive CPU over weeks. Network usage per-app records persist even after the application is deleted. The user SID attribution enables identifying which account was responsible for the data transfer.

**Tools:** KAPE, SrumECmd (Eric Zimmerman), srum-dump, ESEDatabaseView (NirSoft)

**Collection Commands:**
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target SRUM`
- **SrumECmd:** `SrumECmd.exe -f "C:\Windows\System32\sru\SRUDB.dat" -r C:\output\SOFTWARE --csv C:\output --csvf SRUM.csv`
- **srum-dump:** `python3 srum_dump2.py -i "C:\Windows\System32\sru\SRUDB.dat" -t SRUM_TEMPLATE2.xlsx -o C:\output\srum_report.xlsx`
- **PowerShell:** `Copy-Item "C:\Windows\System32\sru\SRUDB.dat" -Destination C:\output\`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.

### Windows Defender Quarantine & DetectionHistory
**Location:** `C:\ProgramData\Microsoft\Windows Defender\Quarantine\ and C:\ProgramData\Microsoft\Windows Defender\Scans\History\Service\DetectionHistory\`

Windows Defender quarantine directory containing encrypted copies of detected malware (ResourceData) and detection metadata (DetectionHistory) recording threat name, file path, detection time, user context, and remediation action taken.

**Forensic Value:** Defender quarantine preserves the original malware sample even after it was removed from its original location, enabling full malware analysis. The ResourceData files can be decrypted to recover the exact binary for reverse engineering and hash-based threat intelligence correlation. DetectionHistory files provide structured detection metadata showing what was detected, where, and when. This is invaluable when the attacker deletes the original malware after detection.

**Tools:** KAPE, Defender Quarantine Decryptor, PowerShell, mplog-parser

**Collection Commands:**
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target DefenderQuarantine`
- **PowerShell:** `Copy-Item "C:\ProgramData\Microsoft\Windows Defender\Quarantine\*" -Recurse -Destination C:\output\Quarantine\`
- **Defender Quarantine Decryptor:** `python3 defender_quarantine_decryptor.py -i C:\output\Quarantine\ResourceData -o C:\output\recovered_samples\`
- **mplog-parser:** `python3 mplog-parser.py -i "C:\ProgramData\Microsoft\Windows Defender\Support\MPLog-*.log" -o C:\output\mplog_parsed.csv`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.

### ETW/ETL Trace Files (DiagTrack/AutoLogger)
**Location:** `C:\Windows\System32\WDI\LogFiles\ and C:\ProgramData\Microsoft\Diagnosis\ETLLogs\AutoLogger\`

Event Tracing for Windows (ETW) binary trace files (.etl) generated by AutoLogger sessions and diagnostic providers. Includes AutoLogger-DiagTrack-Listener.etl and various WDI trace files containing detailed system telemetry.

**Forensic Value:** ETL trace files contain process execution evidence, network connection data, and system diagnostic information that is rarely cleaned by attackers because these files are not well-known forensic artifacts. AutoLogger-DiagTrack-Listener.etl may contain evidence of executed processes including their paths and command lines. These traces persist across reboots and can fill gaps when standard event logs have been cleared.

**Tools:** KAPE, tracerpt, xperf (Windows Performance Toolkit), ETLParser, SilkETW

**Collection Commands:**
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target ETW`
- **tracerpt:** `tracerpt "C:\ProgramData\Microsoft\Diagnosis\ETLLogs\AutoLogger\AutoLogger-DiagTrack-Listener.etl" -o C:\output\etl_report.xml -of XML`
- **PowerShell:** `Copy-Item "C:\ProgramData\Microsoft\Diagnosis\ETLLogs\AutoLogger\*.etl" -Destination C:\output\ETL\`
- **xperf:** `xperf -i "C:\output\AutoLogger-DiagTrack-Listener.etl" -o C:\output\etl_parsed.txt`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.

### Windows Error Reporting (WER)
**Location:** `C:\ProgramData\Microsoft\Windows\WER\ReportArchive\ and C:\ProgramData\Microsoft\Windows\WER\ReportQueue\`

Windows Error Reporting stores crash and fault data for every application or system crash, including process name, crash module, exception code, and memory snapshots. Reports persist in ReportArchive (submitted) and ReportQueue (pending) directories.

**Forensic Value:** WER reports capture the exact moment a process crashes, providing the faulting module name, exception offset, and timestamps that can reveal exploitation attempts or malware injection failures. The Report.wer text files include full command-line arguments and loaded module lists at crash time, making them useful for identifying malicious DLL side-loading or code injection. Memory minidumps (.mdmp) attached to reports may contain process memory at the time of the crash, potentially preserving credentials, decrypted payloads, or shellcode. Attackers rarely clear WER data, making it a valuable secondary evidence source when primary logs have been wiped.

**Tools:** KAPE, WER Parser, Volatility (for minidumps), PowerShell

**Collection Commands:**
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target WER`
- **PowerShell:** `Get-ChildItem "C:\ProgramData\Microsoft\Windows\WER\ReportArchive" -Recurse | Copy-Item -Destination C:\output\WER\Archive\`
- **PowerShell:** `Get-Content "C:\ProgramData\Microsoft\Windows\WER\ReportArchive\*\Report.wer" | Out-File C:\output\WER\all_reports.txt`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.

### Defender MPLog (Malware Protection Log)
**Location:** `C:\ProgramData\Microsoft\Windows Defender\Support\MPLog-*.log`

Microsoft Defender Malware Protection logs record detailed operational telemetry including real-time scan results, threat detection events, exclusion changes, tamper protection status, and resource scan timing for every file scanned by the engine.

**Forensic Value:** MPLog files contain timestamped records of every file scanned by Defender, including the file hash, path, and scan result, providing a near-complete execution timeline even when process logs are unavailable. The logs record when Defender exclusions are added or modified, which is a critical indicator of defense evasion since attackers often add exclusions for their malware directories. Tamper protection events in MPLog reveal attempts to disable or modify Defender configuration. The OriginalFileName field in detection entries can expose renamed executables, helping identify masquerading techniques.

**Tools:** KAPE, mplog-parser, PowerShell, Timeline Explorer

**Collection Commands:**
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target DefenderMPLog`
- **mplog-parser:** `python3 mplog-parser.py -i "C:\ProgramData\Microsoft\Windows Defender\Support\MPLog-*.log" -o C:\output\mplog_parsed.csv`
- **PowerShell:** `Copy-Item "C:\ProgramData\Microsoft\Windows Defender\Support\MPLog-*.log" -Destination C:\output\MPLog\`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.

### AppLocker / WDAC Event Logs
**Location:** `C:\Windows\System32\winevt\Logs\Microsoft-Windows-AppLocker%4EXE and DLL.evtx and C:\Windows\System32\winevt\Logs\Microsoft-Windows-CodeIntegrity%4Operational.evtx`

AppLocker and Windows Defender Application Control (WDAC / Code Integrity) event logs record policy enforcement decisions for executable, DLL, script, and packaged app execution. AppLocker generates Event IDs 8003-8007 for blocked/allowed/audit events; Code Integrity logs capture WDAC violations.

**Forensic Value:** AppLocker audit-mode logs (Event ID 8003) provide a complete record of every executable, script, and DLL that ran on the system, serving as a comprehensive execution history even when Sysmon is not deployed. Blocked execution events (Event ID 8004) reveal attempted execution of unauthorized binaries, which may indicate attacker tools that were prevented from running. WDAC Code Integrity events (Event ID 3089, 3099) detect unsigned or improperly signed code execution attempts, catching tampered system binaries and malicious drivers. The combination of path, hash, and publisher information in these events enables rapid identification of anomalous executables across an enterprise.

**Tools:** KAPE, EvtxECmd (Eric Zimmerman), Event Log Explorer, PowerShell

**Collection Commands:**
- **EvtxECmd:** `EvtxECmd.exe -d "C:\Windows\System32\winevt\Logs\" --inc "AppLocker,CodeIntegrity" --csv C:\output\ --csvf applocker_wdac.csv`
- **PowerShell:** `Get-WinEvent -LogName "Microsoft-Windows-AppLocker/EXE and DLL" | Export-Csv C:\output\applocker_exe_dll.csv -NoTypeInformation`
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target EventLogs`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.
- Centralized log copies may normalize, truncate, or drop fields relative to the original on-host artifact. Preserve the local source when scope and access permit.

### PowerShell Transcription Logs
**Location:** `Policy-defined transcript directory or default user Documents path such as C:\Users\<username>\Documents\PowerShell_transcript.*.txt`

**Also Known As:** PowerShell transcript, PowerShell_transcript

Text transcript files created when PowerShell transcription logging is enabled by Group Policy or Start-Transcript. Each transcript records the host, user, start and stop times, and the commands and output displayed during the session.

**Forensic Value:** Transcripts preserve both the commands entered and the output returned to the operator, making them one of the highest-value artifacts for reconstructing attacker intent and interactive decision making. They frequently capture remote administration sessions, credential checks, encoded command decoding, and the success or failure of each action in a way that script block logging alone does not. Host and username headers also help tie activity to a specific workstation and operator context.

**Tools:** KAPE, PowerShell, type, Velociraptor

**Collection Commands:**
- **PowerShell:** `Get-ChildItem -Path C:\Users\*\Documents -Filter "PowerShell_transcript*.txt" -Recurse -ErrorAction SilentlyContinue | Copy-Item -Destination C:\output\Transcripts\`
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target PowerShell`
- **PowerShell:** `Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\Transcription" | Format-List OutputDirectory,EnableTranscripting,EnableInvocationHeader`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.
- Transcription is not enabled by default and the output path may be redirected by policy to a central share or custom folder. Absence is not meaningful unless you verified the logging policy.

## System Configuration

### SYSTEM Registry Hive
**Location:** `C:\Windows\System32\config\SYSTEM`

SYSTEM hive storing hardware configuration, service entries, network interface settings, mounted devices, and the boot key needed to decrypt SAM hashes.

**Forensic Value:** Services registered under ControlSet\Services expose malicious services used for persistence and privilege escalation. The ComputerName and TimeZoneInformation keys anchor timeline analysis. MountedDevices reveals USB storage that was connected, supporting data exfiltration investigations.

**Tools:** KAPE, RegRipper, Registry Explorer (Eric Zimmerman)

**Collection Commands:**
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target RegistryHives`
- **reg.exe:** `reg save HKLM\SYSTEM C:\output\SYSTEM.hiv`
- **RegRipper:** `rip.exe -r C:\output\SYSTEM.hiv -p services`
- **Registry Explorer:** `Open SYSTEM.hiv in Registry Explorer and navigate to ControlSet001\Services`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.

### SOFTWARE Registry Hive
**Location:** `C:\Windows\System32\config\SOFTWARE`

Machine-wide SOFTWARE hive recording installed applications, OS version, network profiles, Windows Defender exclusions, and Group Policy settings.

**Forensic Value:** Installed application entries with timestamps reveal attacker tool installation. Windows Defender exclusion paths (Policies\Microsoft\Windows Defender\Exclusions) show folders adversaries whitelisted to avoid detection. NetworkList\Profiles records every Wi-Fi and LAN network the host connected to with first/last connection times.

**Tools:** KAPE, RegRipper, Registry Explorer (Eric Zimmerman)

**Collection Commands:**
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target RegistryHives`
- **reg.exe:** `reg save HKLM\SOFTWARE C:\output\SOFTWARE.hiv`
- **RegRipper:** `rip.exe -r C:\output\SOFTWARE.hiv -p networklist`
- **RECmd:** `RECmd.exe -f C:\output\SOFTWARE.hiv --bn BatchExamples\RECmd_Batch_MC.reb --csv C:\output --csvf SOFTWARE_RECmd.csv`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.

### Windows Firewall Connection Log
**Location:** `C:\Windows\System32\winevt\Logs\Microsoft-Windows-Windows Firewall With Advanced Security%4Firewall.evtx and C:\Windows\System32\LogFiles\Firewall\pfirewall.log`

Windows Firewall event log capturing Events 5156/5157 (allowed/blocked connections) with process ID, application path, source/destination IP and port. Also includes pfirewall.log text file when logging is enabled.

**Forensic Value:** Windows Firewall logs provide per-process network connection visibility without requiring Sysmon. Event 5156 records every allowed connection with the responsible application path, enabling detection of unusual processes making outbound connections. Event 5157 blocked connection logs reveal port scanning and lateral movement attempts that were stopped. When Sysmon Event 3 is unavailable, these logs are the best alternative for process-to-network attribution.

**Tools:** KAPE, EvtxECmd (Eric Zimmerman), Event Log Explorer, Log Parser

**Collection Commands:**
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target EventLogs,FirewallLogs`
- **EvtxECmd:** `EvtxECmd.exe -f "C:\Windows\System32\winevt\Logs\Microsoft-Windows-Windows Firewall With Advanced Security%4Firewall.evtx" --csv C:\output --csvf Firewall.csv`
- **PowerShell:** `Copy-Item "C:\Windows\System32\LogFiles\Firewall\pfirewall.log" -Destination C:\output\`
- **Log Parser:** `LogParser.exe "SELECT * FROM C:\Windows\System32\LogFiles\Firewall\pfirewall.log" -i:W3C -o:CSV > C:\output\firewall_parsed.csv`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.
- Centralized log copies may normalize, truncate, or drop fields relative to the original on-host artifact. Preserve the local source when scope and access permit.

### Group Policy Event Logs
**Location:** `C:\Windows\System32\winevt\Logs\Microsoft-Windows-GroupPolicy%4Operational.evtx`

The Group Policy operational event log records GPO processing events including policy application, CSE (Client-Side Extension) processing, script execution, and Group Policy refresh results with the specific GPO names and their processing status.

**Forensic Value:** Group Policy logs reveal when and which GPOs were applied to a compromised system, which is critical because attackers who gain domain admin privileges often deploy malicious Group Policy Objects for code execution across the domain. Event IDs 4016 and 5016 show the start and end of each CSE processing cycle, and the GPO display name identifies exactly which policy was applied, helping detect rogue GPOs. Logon script execution triggered by GPO is recorded with the script path, providing evidence of persistence via domain-level scheduled scripts. Failed GPO processing events can indicate network isolation attempts or tampering with domain communication, both relevant to lateral movement containment analysis.

**Tools:** KAPE, EvtxECmd (Eric Zimmerman), Event Log Explorer, PowerShell

**Collection Commands:**
- **EvtxECmd:** `EvtxECmd.exe -f "C:\Windows\System32\winevt\Logs\Microsoft-Windows-GroupPolicy%4Operational.evtx" --csv C:\output\ --csvf gpo_events.csv`
- **PowerShell:** `Get-WinEvent -LogName "Microsoft-Windows-GroupPolicy/Operational" -MaxEvents 1000 | Export-Csv C:\output\gpo_operational.csv -NoTypeInformation`
- **PowerShell:** `gpresult /H C:\output\gpresult_report.html /F`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.
- Centralized log copies may normalize, truncate, or drop fields relative to the original on-host artifact. Preserve the local source when scope and access permit.

### Startup Repair / Boot Configuration Data (BCD)
**Location:** `C:\Boot\BCD, C:\Windows\System32\LogFiles\SRT\SRTTrail.txt, and C:\Windows\Panther\setupact.log`

Boot Configuration Data (BCD) stores boot manager settings, OS loader configuration, and boot-time driver entries. Startup Repair Tool (SRT) trail logs and Panther setup logs record boot failures, repair actions, and boot-time component modifications.

**Forensic Value:** The BCD store reveals boot-level persistence mechanisms such as malicious bootkit entries, modified boot drivers, and Secure Boot policy changes that execute before the operating system loads. Ransomware operations frequently modify BCD settings to disable recovery mode (bcdedit /set recoveryenabled No) and delete shadow copies to prevent restoration, and these changes persist in the BCD hive. SRTTrail.txt logs capture boot failure details including the root cause analysis, which can reveal corrupted system files from destructive malware or bootkit installation. Comparing the BCD against a known-good baseline can identify unauthorized kernel-mode drivers or modified integrity checking policies that indicate a rootkit.

**Tools:** KAPE, bcdedit, Registry Explorer (Eric Zimmerman), PowerShell

**Collection Commands:**
- **bcdedit:** `bcdedit /enum all > C:\output\bcd_enum.txt`
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target BootConfig`
- **PowerShell:** `Copy-Item "C:\Windows\System32\LogFiles\SRT\SRTTrail.txt" -Destination C:\output\; Copy-Item "C:\Windows\Panther\setupact.log" -Destination C:\output\`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.

### SetupAPI Device Installation Logs
**Location:** `C:\Windows\inf\setupapi.dev.log and C:\Windows\inf\setupapi.app.log`

**Also Known As:** setupapi.dev.log, setupapi.app.log

SetupAPI text logs that record device and driver installation activity, including hardware identifiers, driver package selection, install result codes, and timestamps for device setup operations.

**Forensic Value:** SetupAPI logs are a high-confidence source for reconstructing when USB storage, smart cards, phones, and other plug-and-play devices were first installed or reconfigured on a host. They capture device instance IDs, INF names, and driver selection details that complement registry-based USB history and help distinguish an actual device install from later usage. In data theft or rogue peripheral investigations, these logs frequently provide the earliest timestamp tying a device class to the machine.

**Tools:** KAPE, type, findstr, PowerShell

**Collection Commands:**
- **PowerShell:** `Copy-Item "C:\Windows\inf\setupapi.dev.log","C:\Windows\inf\setupapi.app.log" -Destination C:\output\SetupAPI\ -ErrorAction SilentlyContinue`
- **findstr:** `findstr /I /C:"USBSTOR" /C:"VID_" /C:"PID_" C:\Windows\inf\setupapi.dev.log > C:\output\setupapi_usb_hits.txt`
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target USBDevices`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)
- [SetupAPI Device Installation Log Entries](https://learn.microsoft.com/en-us/windows-hardware/drivers/install/setupapi-device-installation-log-entries)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.
- These logs track installation and driver setup events, not every subsequent device use. Older entries may roll out on long-lived systems with heavy device churn.

## User Activity

### NTUSER.DAT
**Location:** `C:\Users\<username>\NTUSER.DAT`

**Also Known As:** NTUSER.DAT

Per-user registry hive containing user-specific settings including recently opened files (RecentDocs), typed URLs, Run/RunOnce persistence keys, UserAssist encoded program execution records, and shell bags.

**Forensic Value:** UserAssist entries (ROT13-encoded) record every GUI program a user launched with execution count and last-run timestamp, providing evidence of interactive attacker tool usage. Run/RunOnce keys reveal per-user persistence mechanisms. RecentDocs and typed paths reconstruct the files and directories the user accessed.

**Tools:** KAPE, RegRipper, Registry Explorer (Eric Zimmerman), ShellBags Explorer

**Collection Commands:**
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target RegistryHives`
- **reg.exe:** `reg save HKU\<SID> C:\output\NTUSER.DAT`
- **RegRipper:** `rip.exe -r C:\output\NTUSER.DAT -p userassist`
- **RECmd:** `RECmd.exe -f C:\output\NTUSER.DAT --bn BatchExamples\RECmd_Batch_MC.reb --csv C:\output --csvf NTUSER_RECmd.csv`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.

### Browser History & Downloads
**Location:** `C:\Users\<username>\AppData\Local\Google\Chrome\User Data\Default\History`

SQLite databases for Chrome, Edge, and Firefox storing visited URLs with timestamps, download records with source URL and target path, search queries, and form autofill data.

**Forensic Value:** Browser history reveals initial access vectors such as phishing URLs and drive-by download sites. Download records link a malicious file to the exact URL it was fetched from and the time of download. Search queries may show attacker reconnaissance activity (searching for sensitive shares, admin portals). Multiple browser profiles may need to be checked.

**Tools:** KAPE, Hindsight (Chrome), BrowsingHistoryView (NirSoft), DB Browser for SQLite

**Collection Commands:**
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target WebBrowsers`
- **Hindsight:** `hindsight.py -i "C:\Users\<username>\AppData\Local\Google\Chrome\User Data\Default" -o C:\output\chrome_history`
- **BrowsingHistoryView:** `BrowsingHistoryView.exe /scomma C:\output\browser_history.csv`
- **SQLite:** `sqlite3 "C:\Users\<username>\AppData\Local\Google\Chrome\User Data\Default\History" "SELECT url, title, datetime(last_visit_time/1000000-11644473600,'unixepoch') FROM urls ORDER BY last_visit_time DESC"`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.

### Jump Lists
**Location:** `C:\Users\<username>\AppData\Roaming\Microsoft\Windows\Recent\AutomaticDestinations\`

Application-specific Jump List files (.automaticDestinations-ms) recording recently and frequently accessed files per application, with timestamps and full file paths including network shares.

**Forensic Value:** Jump Lists persist evidence of file access even after the files themselves are deleted. They record full UNC paths for network shares, directly supporting data exfiltration investigations by showing which remote file shares a user accessed and when. The embedded LNK metadata within each entry provides additional MAC timestamps and volume serial numbers.

**Tools:** KAPE, JLECmd (Eric Zimmerman), JumpList Explorer

**Collection Commands:**
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target JumpLists`
- **JLECmd:** `JLECmd.exe -d "C:\Users\<username>\AppData\Roaming\Microsoft\Windows\Recent\AutomaticDestinations" --csv C:\output --csvf JumpLists.csv`
- **PowerShell:** `Copy-Item "C:\Users\*\AppData\Roaming\Microsoft\Windows\Recent\AutomaticDestinations\*" -Destination C:\output\JumpLists\`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.

### UsrClass.dat / ShellBags
**Location:** `C:\Users\<username>\AppData\Local\Microsoft\Windows\UsrClass.dat`

Per-user registry hive containing ShellBag entries that record folder view preferences for every folder a user browsed in Windows Explorer, including network shares, ZIP archives, removable media, and deleted folders.

**Forensic Value:** ShellBags persist evidence of folder access even after the folders are deleted. They record the full path of every directory browsed, including UNC paths for network shares, providing a map of what file locations the attacker explored. ShellBag timestamps include first and last interaction dates. This artifact is separate from NTUSER.DAT and often overlooked during collection. ZIP archive browsing entries prove the user opened archive files that may have contained malicious payloads.

**Tools:** KAPE, ShellBags Explorer (Eric Zimmerman), Registry Explorer (Eric Zimmerman), RegRipper

**Collection Commands:**
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target RegistryHives`
- **SBECmd:** `SBECmd.exe -d C:\output --csv C:\output --csvf ShellBags.csv`
- **ShellBags Explorer:** `Load UsrClass.dat in ShellBags Explorer (GUI) for interactive analysis`
- **RegRipper:** `rip.exe -r "C:\Users\<username>\AppData\Local\Microsoft\Windows\UsrClass.dat" -p shellbags`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.

### Terminal Server Client Registry (RDP History)
**Location:** `NTUSER.DAT\Software\Microsoft\Terminal Server Client\Servers and NTUSER.DAT\Software\Microsoft\Terminal Server Client\Default`

Per-user registry keys recording the hostname or IP address of every RDP server the user connected to from this machine, along with the username hint used for each connection.

**Forensic Value:** This artifact maps the outbound RDP connection history for each user account, revealing the lateral movement path from the attacker perspective. Each subkey under Servers represents a destination host with a UsernameHint value showing the account name used to authenticate. The Default\MRU list records the order of most recently connected servers. This complements the inbound RDP event logs on destination machines and is critical for reconstructing lateral movement chains.

**Tools:** KAPE, Registry Explorer (Eric Zimmerman), RegRipper, RECmd (Eric Zimmerman)

**Collection Commands:**
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target RegistryHives`
- **RegRipper:** `rip.exe -r C:\output\NTUSER.DAT -p rdphint`
- **reg.exe:** `reg query "HKCU\Software\Microsoft\Terminal Server Client\Servers" /s`
- **RECmd:** `RECmd.exe -f C:\output\NTUSER.DAT --kn "Software\Microsoft\Terminal Server Client\Servers" --csv C:\output --csvf RDP_History.csv`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.

### LNK Files (Windows Shortcut Files)
**Location:** `C:\Users\<username>\AppData\Roaming\Microsoft\Windows\Recent\ and C:\Users\<username>\Desktop\`

Windows shortcut files (.lnk) created automatically when a user opens a file or manually for desktop shortcuts. Each LNK file contains rich metadata including target path, MAC timestamps, volume serial number, volume name, machine MAC address, and network share path.

**Forensic Value:** LNK files persist as evidence of file access even after the target file is deleted. The embedded metadata provides the original file path, all three timestamps of the target at the time the LNK was created, and the volume serial number and MAC address of the machine where the target resided. For files accessed over network shares, the LNK preserves the full UNC path. LNK creation timestamps in the Recent folder establish when a user first opened a specific file.

**Tools:** KAPE, LECmd (Eric Zimmerman), LNK Parser, Autopsy

**Collection Commands:**
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target LnkFiles`
- **LECmd:** `LECmd.exe -d "C:\Users\<username>\AppData\Roaming\Microsoft\Windows\Recent" --csv C:\output --csvf LNKFiles.csv`
- **PowerShell:** `Copy-Item "C:\Users\*\AppData\Roaming\Microsoft\Windows\Recent\*.lnk" -Destination C:\output\LNK\`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.

### Thumbcache Database
**Location:** `C:\Users\<username>\AppData\Local\Microsoft\Windows\Explorer\thumbcache_*.db`

Per-user thumbnail cache databases storing preview images of files that were displayed in Windows Explorer. Multiple databases exist for different thumbnail sizes (32, 96, 256, 1024, etc.).

**Forensic Value:** Thumbcache entries persist after the original files are deleted, providing visual evidence that specific files existed on the system. In insider threat and data theft cases, thumbnail previews can prove that sensitive documents, images, or other files were present even when the originals have been wiped. The thumbcache_idx.db index maps cache entries to file paths for attribution.

**Tools:** KAPE, Thumbcache Viewer, Thumbs Viewer, Autopsy

**Collection Commands:**
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target ThumbCache`
- **Thumbcache Viewer:** `thumbcache_viewer.exe (GUI - open thumbcache_*.db files for visual inspection)`
- **PowerShell:** `Copy-Item "C:\Users\*\AppData\Local\Microsoft\Windows\Explorer\thumbcache_*.db" -Destination C:\output\ThumbCache\`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.

### RDP Persistent Bitmap Cache
**Location:** `C:\Users\<username>\AppData\Local\Microsoft\Terminal Server Client\Cache\bcache*.bmc and cache*.bin`

Cached 64x64 pixel bitmap tiles from Remote Desktop Protocol sessions stored locally on the RDP client machine. These tiles represent fragments of the remote desktop display that can be reconstructed into partial screenshots.

**Forensic Value:** RDP bitmap cache provides visual evidence of what an attacker saw and did during remote desktop sessions, even if the remote server has been wiped or encrypted by ransomware. Tiles can be reconstructed into partial screenshots showing open applications, file listings, command prompts, and sensitive data displayed on the remote desktop. This evidence survives on the source machine regardless of the state of the destination machine.

**Tools:** bmc-tools, RDP Bitmap Cache Parser, KAPE, Autopsy

**Collection Commands:**
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target RDPCache`
- **bmc-tools:** `python3 bmc-tools.py -s "C:\Users\<username>\AppData\Local\Microsoft\Terminal Server Client\Cache\" -d C:\output\rdp_bitmaps -b`
- **PowerShell:** `Copy-Item "C:\Users\*\AppData\Local\Microsoft\Terminal Server Client\Cache\*" -Destination C:\output\RDP_Cache\`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.

### ActivitiesCache.db (Windows Timeline)
**Location:** `C:\Users\<username>\AppData\Local\ConnectedDevicesPlatform\<folder>\ActivitiesCache.db`

SQLite database powering Windows Timeline (Win10 1803+) tracking application usage, file access with full paths, URLs visited, and clipboard content history with base64-encoded payloads retained for approximately 12 hours.

**Forensic Value:** ActivitiesCache.db provides a detailed timeline of user activity across applications with precise timestamps. It records which applications were in focus, which files were opened (with full paths), and browser URLs visited. The clipboard history feature stores base64-encoded clipboard content for approximately 12 hours, potentially capturing copied passwords, commands, or sensitive data. Activity entries persist across reboots and are not cleared by standard history deletion methods.

**Tools:** KAPE, WxTCmd (Eric Zimmerman), DB Browser for SQLite, Autopsy

**Collection Commands:**
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target ActivitiesCache`
- **WxTCmd:** `WxTCmd.exe -f "C:\Users\<username>\AppData\Local\ConnectedDevicesPlatform\<folder>\ActivitiesCache.db" --csv C:\output --csvf ActivitiesCache.csv`
- **SQLite:** `sqlite3 "ActivitiesCache.db" "SELECT AppId, ActivityType, datetime(LastModifiedTime,'unixepoch'), Payload FROM Activity ORDER BY LastModifiedTime DESC"`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.

### Windows Search Index Database
**Location:** `C:\ProgramData\Microsoft\Search\Data\Applications\Windows\Windows.edb (Win10) or C:\ProgramData\Microsoft\Search\Data\Applications\Windows\Windows.db (Win11)`

Windows Search indexing database containing metadata and partial content of indexed files, emails, and browser history. The ESE database (Windows.edb) or SQLite database (Windows.db) contains file properties, text excerpts, and path information.

**Forensic Value:** The Windows Search index contains metadata and content snippets of files that may have been deleted, providing evidence of their former existence. Indexed email content can supplement Exchange/M365 investigations. Browser history entries in the index may survive browser history clearing. File property records include modification timestamps, sizes, and partial content that can prove sensitive documents existed on the system.

**Tools:** KAPE, SIDBParser, ESEDatabaseView (NirSoft), DB Browser for SQLite, Autopsy

**Collection Commands:**
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target WindowsSearchIndex`
- **ESEDatabaseView:** `ESEDatabaseView.exe (GUI - open Windows.edb for table browsing)`
- **SIDBParser:** `python3 sidb_parser.py -i "C:\ProgramData\Microsoft\Search\Data\Applications\Windows\Windows.edb" -o C:\output\search_index`
- **PowerShell:** `Stop-Service WSearch; Copy-Item "C:\ProgramData\Microsoft\Search\Data\Applications\Windows\Windows.edb" -Destination C:\output\`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.

### WLAN AutoConfig Event Log
**Location:** `C:\Windows\System32\winevt\Logs\Microsoft-Windows-WLAN-AutoConfig%4Operational.evtx`

The WLAN AutoConfig operational event log records wireless network connection events including SSID names, connection success/failure, authentication types (WPA2, WPA3, Open), disconnect reasons, and BSSID (access point MAC) information.

**Forensic Value:** WLAN logs establish the physical location context of a device by recording which wireless networks it connected to and when, which is critical for placing a suspect device at a specific location during an incident. The logs capture the authentication method used, helping identify connections to rogue or open access points that may indicate a man-in-the-middle attack. Failed connection attempts and frequent SSID switching can reveal reconnaissance behavior or attempts to connect to attacker-controlled networks. These logs persist even when the network profile is deleted and provide timestamps that correlate with other forensic artifacts.

**Tools:** KAPE, EvtxECmd (Eric Zimmerman), Event Log Explorer, PowerShell

**Collection Commands:**
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target EventLogs`
- **EvtxECmd:** `EvtxECmd.exe -f "C:\Windows\System32\winevt\Logs\Microsoft-Windows-WLAN-AutoConfig%4Operational.evtx" --csv C:\output\ --csvf wlan_events.csv`
- **PowerShell:** `Get-WinEvent -LogName "Microsoft-Windows-WLAN-AutoConfig/Operational" | Export-Csv C:\output\wlan_events.csv -NoTypeInformation`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.

### RDP Shared Drives & Clipboard (Drive Redirection)
**Location:** `HKCU\Software\Microsoft\Terminal Server Client\Default and C:\Windows\System32\winevt\Logs\Microsoft-Windows-TerminalServices-RDPClient%4Operational.evtx`

When RDP drive redirection is enabled, the client maps local drives to the remote session (appearing as \\tsclient\C). Registry keys record server hostnames and IPs, and RDP client operational logs capture connection details including drive and clipboard redirection events.

**Forensic Value:** RDP drive redirection (tsclient) is a primary data exfiltration vector in lateral movement scenarios, allowing attackers to copy files between compromised hosts without touching the network in a detectable way. The TerminalServices-RDPClient operational log records Event ID 1024 (drive redirection enabled) and Event ID 1026 (clipboard redirection), providing direct evidence of data transfer capability. Registry entries under Terminal Server Client\Default and Servers subkeys preserve the history of RDP connections with server hostnames, even after the RDP session ends. Correlating tsclient file access timestamps from the USN journal with RDP session logs can reconstruct the exact files moved during lateral movement.

**Tools:** KAPE, Registry Explorer (Eric Zimmerman), EvtxECmd, PowerShell

**Collection Commands:**
- **Registry Explorer:** `RECmd.exe --hive NTUSER.DAT --key "Software\Microsoft\Terminal Server Client" --csv C:\output\ --csvf rdp_client_reg.csv`
- **EvtxECmd:** `EvtxECmd.exe -f "C:\Windows\System32\winevt\Logs\Microsoft-Windows-TerminalServices-RDPClient%4Operational.evtx" --csv C:\output\ --csvf rdp_client_events.csv`
- **PowerShell:** `Get-ItemProperty "HKCU:\Software\Microsoft\Terminal Server Client\Default" | Format-List *`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.

### PSReadLine Console History
**Location:** `C:\Users\<username>\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt and C:\Users\<username>\Documents\PowerShell\PSReadLine\ConsoleHost_history.txt`

**Also Known As:** ConsoleHost_history.txt, PSReadLine history

Per-user PSReadLine history file that records commands entered in interactive PowerShell consoles. Windows PowerShell and PowerShell 7+ can maintain separate ConsoleHost_history.txt files depending on the host and profile path.

**Forensic Value:** PSReadLine history captures operator-entered PowerShell commands even when no script file was written to disk. It commonly preserves download cradles, encoded command launchers, reconnaissance commands, credential access attempts, and one-liners used during hands-on-keyboard activity. Because entries are appended as commands are accepted, the history can survive partial session cleanup and provide evidence even when the standard event logs are noisy or incomplete.

**Tools:** KAPE, PowerShell, Velociraptor, type

**Collection Commands:**
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target PowerShell`
- **PowerShell:** `Get-ChildItem "$env:APPDATA\Microsoft\Windows\PowerShell\PSReadLine","$HOME\Documents\PowerShell\PSReadLine" -Filter ConsoleHost_history.txt -ErrorAction SilentlyContinue | Copy-Item -Destination C:\output\PSReadLine\`
- **Velociraptor:** `velociraptor artifacts collect Windows.Forensics.PowerShell -o C:\output\velociraptor_psreadline.zip`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)
- [about_PSReadLine](https://learn.microsoft.com/en-us/powershell/module/psreadline/about/about_psreadline?view=powershell-7.5)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.
- History availability depends on PSReadLine being present and the user not disabling or truncating the history file. Non-interactive runspaces and some remoting hosts do not populate ConsoleHost_history.txt.

### Windows Notification Database
**Location:** `C:\Users\<username>\AppData\Local\Microsoft\Windows\Notifications\wpndatabase.db (Windows 10/11) or appdb.dat on older releases`

**Also Known As:** wpndatabase.db, appdb.dat, Windows notifications

Per-user notification store used by Action Center / Notification Center to retain recent toast notifications, app identifiers, payload fragments, timestamps, and notification grouping metadata.

**Forensic Value:** The notification database can preserve transient user-facing content that never appears in email or messaging stores, such as MFA prompts, messaging previews, download alerts, security-tool detections, and collaboration notifications. It is especially useful for reconstructing what the user was shown on screen around a critical time window and for validating whether a phishing lure, approval request, or malware detection alert was surfaced to the user. This store can also expose app identifiers and timing relationships that corroborate browser, email, and authentication artifacts.

**Tools:** KAPE, DB Browser for SQLite, PowerShell, Velociraptor

**Collection Commands:**
- **PowerShell:** `Get-ChildItem "C:\Users\*\AppData\Local\Microsoft\Windows\Notifications" -Include wpndatabase.db,appdb.dat -Recurse -ErrorAction SilentlyContinue | Copy-Item -Destination C:\output\Notifications\`
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target AppCompat`
- **Velociraptor:** `velociraptor artifacts collect Windows.Forensics.SQLiteHunter -o C:\output\velociraptor_notifications.zip`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)
- [App Notifications Overview](https://learn.microsoft.com/en-us/windows/apps/develop/notifications/app-notifications/)
- [Windows Notification Database Forensics](https://www.mdpi.com/2673-6756/2/1/7)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.
- Schema and storage format differ between Windows versions, and retention is limited because notifications are routinely cleared or aged out. Older systems may use appdb.dat instead of wpndatabase.db.

## Filesystem & Timeline

### $MFT (Master File Table)
**Location:** `\\.\C:\$MFT`

**Also Known As:** $MFT

NTFS Master File Table containing a record for every file and directory on the volume, including timestamps (created, modified, accessed, entry-modified), file size, parent directory reference, and resident data for small files.

**Forensic Value:** Comparing $STANDARD_INFORMATION and $FILE_NAME timestamps detects timestomping -- if SI timestamps are older than FN timestamps, manipulation is confirmed. Deleted file records remain in the MFT until overwritten, enabling recovery of attacker-deleted tools. The full directory tree can be reconstructed even from a dead disk.

**Tools:** KAPE, MFTECmd (Eric Zimmerman), Autopsy, analyzeMFT

**Collection Commands:**
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target NTFS`
- **MFTECmd:** `MFTECmd.exe -f "C:\$MFT" --csv C:\output --csvf MFT.csv`
- **RawCopy:** `RawCopy.exe /FileNamePath:C:0 /OutputPath:C:\output /OutputName:$MFT`
- **analyzeMFT:** `python analyzeMFT.py -f C:\output\$MFT -o C:\output\MFT_parsed.csv -e`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.

### $UsnJrnl (USN Change Journal)
**Location:** `\\.\C:\$Extend\$UsnJrnl:$J`

**Also Known As:** $UsnJrnl:$J, USN Change Journal

NTFS Update Sequence Number journal logging every file system change including creates, deletes, renames, data overwrites, and security descriptor changes.

**Forensic Value:** The USN journal captures a chronological record of every filesystem change, providing a high-fidelity timeline even for files that have been deleted. Rename chains expose attacker attempts to disguise malicious binaries (e.g., renaming svchost.exe to a temp path). Rapid bulk deletes indicate evidence destruction or ransomware encryption.

**Tools:** KAPE, MFTECmd (Eric Zimmerman), NTFS Log Tracker

**Collection Commands:**
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target NTFS`
- **MFTECmd:** `MFTECmd.exe -f "C:\$Extend\$UsnJrnl:$J" --csv C:\output --csvf UsnJrnl.csv`
- **ExtractUsnJrnl:** `ExtractUsnJrnl.exe /DevicePath:C: /OutputPath:C:\output`
- **NTFS Log Tracker:** `Load $UsnJrnl:$J in NTFS Log Tracker for timeline analysis`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.

### USB Device History (USBSTOR / MountPoints2)
**Location:** `SYSTEM\CurrentControlSet\Enum\USBSTOR and NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2`

Registry keys recording USB mass storage device connections. USBSTOR stores device vendor, product, serial number, and connection timestamps. MountPoints2 records user-specific drive letter mappings for mounted devices.

**Forensic Value:** USB device history is critical for data exfiltration and insider threat investigations. USBSTOR entries prove a specific USB device (by serial number) was connected to the system with first and last connection timestamps. MountPoints2 provides user attribution showing which account accessed the device. Cross-referencing device serial numbers across multiple systems maps the path of a USB device through the environment. Combined with file access artifacts, this proves what data was transferred to removable media.

**Tools:** KAPE, Registry Explorer (Eric Zimmerman), USBDeview (NirSoft), RegRipper

**Collection Commands:**
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target RegistryHives`
- **RegRipper:** `rip.exe -r C:\output\SYSTEM -p usbstor`
- **USBDeview:** `USBDeview.exe /scomma C:\output\usb_devices.csv`
- **Registry Explorer:** `Open SYSTEM hive and navigate to ControlSet001\Enum\USBSTOR for device details`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.

### Recycle Bin ($I/$R Files)
**Location:** `C:\$Recycle.Bin\<SID>\`

Windows Recycle Bin containing $I files (metadata with original path, deletion timestamp, and file size) and $R files (actual deleted file content). Each user SID has a separate subfolder providing user attribution.

**Forensic Value:** The Recycle Bin preserves both metadata and content of deleted files attributed to specific user accounts. $I files record the original full file path, exact deletion timestamp, and file size even when $R content files are emptied. Attackers deleting tools or staging files often forget to empty the Recycle Bin. Recovering $R files can retrieve deleted malware samples, exfiltration scripts, or sensitive documents the attacker tried to destroy.

**Tools:** KAPE, RBCmd (Eric Zimmerman), Autopsy, Recycle Bin Explorer

**Collection Commands:**
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target RecycleBin`
- **RBCmd:** `RBCmd.exe -d "C:\$Recycle.Bin" --csv C:\output --csvf RecycleBin.csv`
- **PowerShell:** `Get-ChildItem "C:\$Recycle.Bin" -Recurse -Force | Select-Object FullName, Length, LastWriteTime | Export-Csv C:\output\recycle_bin_listing.csv`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.

### $LogFile (NTFS Transaction Log)
**Location:** `\\.\C:\$LogFile`

NTFS transaction log recording redo and undo operations for filesystem metadata changes. Provides more granular detail than $UsnJrnl for recent operations including incomplete and rolled-back transactions.

**Forensic Value:** $LogFile contains detailed redo/undo pairs for every NTFS metadata change in the most recent hours to days, providing finer granularity than the USN journal. It captures partial and failed operations that other artifacts miss, such as an incomplete file copy or a rolled-back rename. For recent activity, $LogFile can recover file creation, deletion, and rename operations with full timestamps even when $UsnJrnl has wrapped.

**Tools:** KAPE, NTFS Log Tracker, LogFileParser, Autopsy

**Collection Commands:**
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target NTFS`
- **RawCopy:** `RawCopy.exe /FileNamePath:C:2 /OutputPath:C:\output /OutputName:$LogFile`
- **NTFS Log Tracker:** `Load $LogFile alongside $MFT and $UsnJrnl in NTFS Log Tracker for correlated timeline analysis`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.

### Volume Shadow Copies (VSS)
**Location:** `System Volume Information (accessed via vssadmin or mklink)`

Point-in-time volume snapshots created by Windows Volume Shadow Copy Service for System Restore, backup, and application use. Contains complete copies of files and registry hives as they existed at snapshot creation time.

**Forensic Value:** VSS snapshots are forensic gold because they preserve the state of files and registry hives from before the attack. Comparing pre-attack and post-attack registry hives reveals exactly what persistence the attacker added. Deleted malware samples may still exist in older shadow copies. Ransomware variants attempt to delete VSS (vssadmin delete shadows) but if this fails, encrypted files can potentially be recovered from snapshots.

**Tools:** vssadmin, vshadowinfo/vshadowmount (libvshadow), Arsenal Image Mounter, KAPE

**Collection Commands:**
- **vssadmin:** `vssadmin list shadows`
- **cmd:** `mklink /d C:\vss_mount \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\`
- **vshadowmount:** `vshadowmount <image_file> /mnt/vss/`
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target VSSFiles --vss`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.

### Zone.Identifier (Mark of the Web)
**Location:** `<downloaded_file>:Zone.Identifier (NTFS Alternate Data Stream)`

NTFS alternate data stream automatically applied to files downloaded from the internet or received via email. Contains the ZoneId (3 = Internet, 4 = Restricted), ReferrerUrl, and HostUrl identifying the download source.

**Forensic Value:** Zone.Identifier provides definitive evidence of where a file was downloaded from. The ReferrerUrl field records the webpage that initiated the download, while HostUrl records the actual download server. This directly links a malicious executable to the phishing page or compromised website that delivered it. The ZoneId persists even if the file is moved within the NTFS volume, though it is lost when copied to non-NTFS media or extracted from ZIP archives.

**Tools:** KAPE, PowerShell (Get-Content -Stream Zone.Identifier), Autopsy, streams (Sysinternals)

**Collection Commands:**
- **PowerShell:** `Get-Content -Path "C:\Users\<username>\Downloads\<file>" -Stream Zone.Identifier`
- **streams:** `streams.exe -s "C:\Users\<username>\Downloads\"`
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target ZoneIdentifier`
- **cmd:** `more < "C:\Users\<username>\Downloads\<file>:Zone.Identifier"`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.

### SDelete / Secure Deletion Evidence
**Location:** `$MFT, $UsnJrnl, $LogFile, and C:\Windows\Prefetch\SDELETE*.pf`

Evidence of secure file deletion using Sysinternals SDelete or similar tools can be recovered from NTFS metadata artifacts. SDelete renames files sequentially (AAA, AAB, AAC..., ZZZ) before deletion, leaving distinctive patterns in the MFT and USN journal.

**Forensic Value:** The sequential rename pattern (AAA through ZZZ) left by SDelete in the $MFT and $UsnJrnl is a reliable signature of anti-forensic secure deletion, as no legitimate application produces this naming pattern. The $UsnJrnl captures the rename operations with timestamps, allowing analysts to determine exactly when secure deletion occurred and correlate it with other suspicious activity. Prefetch files for SDELETE.EXE reveal execution count, timestamps, and the volumes accessed, confirming tool usage even after the binary is removed. The original filename and parent directory can sometimes be recovered from $MFT resident data or $UsnJrnl entries preceding the rename sequence.

**Tools:** MFTECmd (Eric Zimmerman), KAPE, Prefetch Parser, UsnJrnl Parser

**Collection Commands:**
- **MFTECmd:** `MFTECmd.exe -f "C:\$MFT" --csv C:\output\ --csvf mft_sdelete.csv`
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target FileSystem --mdest C:\output\modules --module MFTECmd,PECmd`
- **PowerShell:** `Get-ChildItem "C:\Windows\Prefetch\SDELETE*" | Copy-Item -Destination C:\output\Prefetch\`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.

## Persistence Mechanisms

### BITS Transfer Jobs
**Location:** `C:\ProgramData\Microsoft\Network\Downloader\qmgr.db`

Background Intelligent Transfer Service database tracking all BITS jobs including download URL, destination path, creation time, and job owner SID.

**Forensic Value:** Adversaries abuse BITS jobs for stealthy file downloads and persistence because BITS transfers survive reboots and run under the SYSTEM context. Parsing qmgr.db reveals download URLs for second-stage payloads, staging paths, and the exact user account that initiated the transfer. BITS jobs do not appear in standard proxy logs if the system uses direct connections.

**Tools:** KAPE, BitsParser, BITS-parser (ANSSI)

**Collection Commands:**
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target BITSDb`
- **BitsParser:** `python3 BitsParser.py -i "C:\ProgramData\Microsoft\Network\Downloader\qmgr.db" -o C:\output\bits_parsed.csv`
- **PowerShell:** `Get-BitsTransfer -AllUsers | Format-List *`
- **BITS-parser:** `python3 bits_parser.py "C:\ProgramData\Microsoft\Network\Downloader\qmgr.db" -o C:\output`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.

### Scheduled Tasks
**Location:** `C:\Windows\System32\Tasks\`

XML-based scheduled task definitions containing the trigger schedule, action command line, run-as account, creation timestamp, and author.

**Forensic Value:** Scheduled tasks are a top persistence mechanism. Each task XML contains the exact command line and arguments the task executes, the user context it runs under, and when it was created. Comparing task creation timestamps against the intrusion timeline isolates attacker-created tasks. Tasks running as SYSTEM with encoded PowerShell or unusual binary paths are high-confidence indicators.

**Tools:** KAPE, Autoruns (Sysinternals), PowerShell

**Collection Commands:**
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target ScheduledTasks`
- **PowerShell:** `Get-ScheduledTask | Where-Object {$_.State -ne "Disabled"} | Export-Csv C:\output\scheduled_tasks.csv`
- **Autoruns:** `autorunsc.exe -a t -ct -h -s -v -vt > C:\output\autoruns_tasks.csv`
- **cmd:** `schtasks /query /fo CSV /v > C:\output\schtasks_output.csv`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.

### WMI Event Subscriptions (OBJECTS.DATA)
**Location:** `C:\Windows\System32\wbem\Repository\OBJECTS.DATA`

WMI repository containing permanent event subscriptions (EventFilter, EventConsumer, FilterToConsumerBinding) that execute arbitrary commands or scripts in response to system events.

**Forensic Value:** WMI event subscriptions are a stealthy persistence mechanism favored by advanced adversaries because they do not appear in traditional autoruns locations. Parsing OBJECTS.DATA reveals the trigger condition (e.g., system startup, user logon, interval timer) and the exact command or script payload. This persistence survives reboots and does not require files on disk if using ActiveScriptEventConsumer.

**Tools:** KAPE, PyWMIPersistenceFinder, Autoruns (Sysinternals), wmi-parser

**Collection Commands:**
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target WMI`
- **PyWMIPersistenceFinder:** `python3 PyWMIPersistenceFinder.py "C:\Windows\System32\wbem\Repository\OBJECTS.DATA"`
- **PowerShell:** `Get-WMIObject -Namespace root\Subscription -Class __EventFilter; Get-WMIObject -Namespace root\Subscription -Class __EventConsumer; Get-WMIObject -Namespace root\Subscription -Class __FilterToConsumerBinding`
- **Autoruns:** `autorunsc.exe -a w -ct -h -s > C:\output\autoruns_wmi.csv`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.

### System Event Log (Service Installation)
**Location:** `C:\Windows\System32\winevt\Logs\System.evtx`

System event log capturing Event ID 7045 for new service installations, recording the service name, binary path, service type, and start type. Also captures Event 7034 (crash) and 7040 (start type change).

**Forensic Value:** Event 7045 detects attacker tool deployment via service creation, which is the mechanism used by PsExec, Cobalt Strike, Metasploit, and many ransomware variants. The ImagePath field reveals the exact binary or command line executed as SYSTEM. Services with random names, paths to temp directories, or encoded PowerShell commands are high-confidence indicators. Correlating service installation timestamps with lateral movement events builds the attack progression timeline.

**Tools:** KAPE, EvtxECmd (Eric Zimmerman), Event Log Explorer, Chainsaw

**Collection Commands:**
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target EventLogs`
- **EvtxECmd:** `EvtxECmd.exe -f "C:\Windows\System32\winevt\Logs\System.evtx" --csv C:\output --csvf System.csv`
- **PowerShell:** `Get-WinEvent -FilterHashtable @{LogName="System"; Id=7045} | Export-Csv C:\output\service_installs.csv`
- **Chainsaw:** `chainsaw hunt "C:\Windows\System32\winevt\Logs\System.evtx" -s sigma/ --mapping mappings/sigma-event-logs-all.yml`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.
- Centralized log copies may normalize, truncate, or drop fields relative to the original on-host artifact. Preserve the local source when scope and access permit.

### Task Scheduler Operational Log
**Location:** `C:\Windows\System32\winevt\Logs\Microsoft-Windows-TaskScheduler%4Operational.evtx`

Task Scheduler operational log capturing task lifecycle events: Event 106 (task registered), Event 140 (task updated), Event 141 (task deleted), Event 200/201 (task execution started/completed).

**Forensic Value:** Task Scheduler events complement the XML task definitions in C:\Windows\System32\Tasks by providing exact timestamps for when tasks were created, modified, and executed. Event 106 timestamps pinpoint when an attacker installed a scheduled task for persistence. Event 141 detects anti-forensic deletion of tasks after execution. Correlating Event 200/201 execution times with other artifact timelines confirms which tasks actually ran.

**Tools:** KAPE, EvtxECmd (Eric Zimmerman), Event Log Explorer, Chainsaw

**Collection Commands:**
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target EventLogs`
- **EvtxECmd:** `EvtxECmd.exe -f "C:\Windows\System32\winevt\Logs\Microsoft-Windows-TaskScheduler%4Operational.evtx" --csv C:\output --csvf TaskScheduler.csv`
- **PowerShell:** `Get-WinEvent -FilterHashtable @{LogName="Microsoft-Windows-TaskScheduler/Operational"; Id=106,141,200,201} | Export-Csv C:\output\task_scheduler_events.csv`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.
- Centralized log copies may normalize, truncate, or drop fields relative to the original on-host artifact. Preserve the local source when scope and access permit.

### BITS-Client Event Log
**Location:** `C:\Windows\System32\winevt\Logs\Microsoft-Windows-Bits-Client%4Operational.evtx`

Background Intelligent Transfer Service client log capturing Event 59 (transfer initiated with full URL) and Event 60 (transfer completed with byte count). Supplements the qmgr.db database with timestamped event records.

**Forensic Value:** BITS-Client events provide timestamped evidence of file downloads that BITS jobs initiated, including the full remote URL and local destination path. Event 59 records the URL at transfer start, proving the download source for malicious payloads. Event 60 confirms successful completion with total bytes transferred. These events persist even after BITS job cleanup and complement qmgr.db analysis for complete BITS activity reconstruction.

**Tools:** KAPE, EvtxECmd (Eric Zimmerman), Event Log Explorer, Chainsaw

**Collection Commands:**
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target EventLogs`
- **EvtxECmd:** `EvtxECmd.exe -f "C:\Windows\System32\winevt\Logs\Microsoft-Windows-Bits-Client%4Operational.evtx" --csv C:\output --csvf BITSClient.csv`
- **PowerShell:** `Get-WinEvent -FilterHashtable @{LogName="Microsoft-Windows-Bits-Client/Operational"; Id=59,60} | Export-Csv C:\output\bits_client_events.csv`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.
- Centralized log copies may normalize, truncate, or drop fields relative to the original on-host artifact. Preserve the local source when scope and access permit.

### WMI-Activity Operational Log
**Location:** `C:\Windows\System32\winevt\Logs\Microsoft-Windows-WMI-Activity%4Operational.evtx`

WMI Activity operational log capturing Event 5861 (new permanent WMI event subscription created) and Event 5857-5860 (provider loading and query execution errors).

**Forensic Value:** Event 5861 is the timestamped companion to OBJECTS.DATA persistence analysis, recording exactly when a new WMI event subscription was created and the subscription details including the consumer command. This timestamps the WMI persistence installation whereas OBJECTS.DATA alone does not contain creation timestamps. Provider load events (5857) can reveal malicious WMI providers loaded from unusual paths.

**Tools:** KAPE, EvtxECmd (Eric Zimmerman), Event Log Explorer, Chainsaw

**Collection Commands:**
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target EventLogs`
- **EvtxECmd:** `EvtxECmd.exe -f "C:\Windows\System32\winevt\Logs\Microsoft-Windows-WMI-Activity%4Operational.evtx" --csv C:\output --csvf WMI_Activity.csv`
- **PowerShell:** `Get-WinEvent -FilterHashtable @{LogName="Microsoft-Windows-WMI-Activity/Operational"; Id=5857,5858,5859,5860,5861} | Export-Csv C:\output\wmi_activity.csv`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.
- Centralized log copies may normalize, truncate, or drop fields relative to the original on-host artifact. Preserve the local source when scope and access permit.

### Run / RunOnce Persistence Keys
**Location:** `NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Run (per-user) and SOFTWARE\Microsoft\Windows\CurrentVersion\Run (machine-wide)`

Registry Run and RunOnce keys that specify programs to execute at user logon (NTUSER.DAT) or system startup (SOFTWARE hive). RunOnce entries are deleted after execution. Both per-user and machine-wide variants exist.

**Forensic Value:** Run keys are the most common registry persistence mechanism used by malware and attackers. Entries contain the full command line executed at every logon, revealing persistence payloads including encoded PowerShell, mshta calls, or paths to dropped binaries. RunOnce entries execute once and self-delete, but may still be recovered from registry transaction logs or VSS snapshots. Comparing current entries against a known-good baseline immediately identifies attacker additions.

**Tools:** KAPE, Registry Explorer (Eric Zimmerman), RegRipper, Autoruns (Sysinternals)

**Collection Commands:**
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target RegistryHives`
- **reg.exe:** `reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" && reg query "HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run"`
- **Autoruns:** `autorunsc.exe -a l -ct -h -s -v -vt > C:\output\autoruns_logon.csv`
- **RegRipper:** `rip.exe -r C:\output\NTUSER.DAT -p run`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.

### Image File Execution Options (IFEO)
**Location:** `SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\<executable>`

Registry keys that allow specifying a debugger to attach to any executable at launch. Attackers abuse the Debugger value to redirect accessibility tool execution (sethc.exe, utilman.exe, narrator.exe) to backdoor commands.

**Forensic Value:** IFEO debugger hijacking is a persistence and privilege escalation technique that replaces the execution of a legitimate binary with an attacker-controlled one. The classic attack sets sethc.exe (Sticky Keys) Debugger to cmd.exe, providing a SYSTEM command prompt at the Windows login screen via five Shift key presses. Checking all IFEO entries with a Debugger value set reveals these backdoors. GlobalFlag modifications can also be used for silent process monitoring.

**Tools:** KAPE, Registry Explorer (Eric Zimmerman), RegRipper, Autoruns (Sysinternals)

**Collection Commands:**
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target RegistryHives`
- **reg.exe:** `reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options" /s /v Debugger`
- **Autoruns:** `autorunsc.exe -a i -ct -h -s > C:\output\autoruns_ifeo.csv`
- **RegRipper:** `rip.exe -r C:\output\SOFTWARE -p imagefile`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.

### Startup Folder
**Location:** `C:\Users\<username>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\ and C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\`

Per-user and all-users startup folders containing shortcuts, scripts, or executables that run automatically at user logon. Items can be LNK files, batch scripts, VBS scripts, or direct executables.

**Forensic Value:** The Startup folder is a simple but effective persistence mechanism. Any file placed here executes at user logon with the privileges of the logging-on user. Per-user folders provide user attribution for the persistence mechanism. File creation timestamps on items in the Startup folder indicate when persistence was installed. Comparing contents against a known-good baseline or across multiple systems identifies attacker-added persistence items.

**Tools:** KAPE, Autoruns (Sysinternals), PowerShell, dir /s

**Collection Commands:**
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target StartupFolders`
- **Autoruns:** `autorunsc.exe -a l -ct -h -s > C:\output\autoruns_startup.csv`
- **PowerShell:** `Get-ChildItem "C:\Users\*\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\" -Force; Get-ChildItem "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\" -Force`
- **cmd:** `dir /s /b "C:\Users\*\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\" "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\"`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.

### COM Object Hijacking Registry Keys
**Location:** `HKCU\Software\Classes\CLSID\ and HKLM\SOFTWARE\Classes\CLSID\`

Component Object Model (COM) hijacking abuses the Windows COM object registry lookup order by placing malicious DLLs in per-user CLSID entries (HKCU) that take precedence over machine-wide entries (HKLM). Legitimate applications then load the attacker-controlled DLL when instantiating the hijacked COM object.

**Forensic Value:** COM hijacking is a stealthy persistence mechanism because the malicious DLL executes within the context of a legitimate process, bypassing application whitelisting and blending into normal system activity. Entries in HKCU\Software\Classes\CLSID that have InprocServer32 or LocalServer32 subkeys pointing to unusual DLL paths are strong indicators of compromise. Comparing HKCU CLSID entries against the baseline HKLM entries reveals hijacked objects, since legitimate per-user COM registrations are rare. The timestamps on these registry keys can establish when the persistence was planted, and the referenced DLL can be extracted for malware analysis.

**Tools:** Registry Explorer (Eric Zimmerman), KAPE, Autoruns (Sysinternals), PowerShell

**Collection Commands:**
- **Autoruns:** `autorunsc.exe -a * -ct -h -s -nobanner > C:\output\autoruns_all.csv`
- **Registry Explorer:** `RECmd.exe --hive NTUSER.DAT --key "Software\Classes\CLSID" --csv C:\output\ --csvf com_hijack_hkcu.csv`
- **PowerShell:** `Get-ChildItem "HKCU:\Software\Classes\CLSID" -Recurse | Where-Object { $_.GetSubKeyNames() -contains "InprocServer32" } | ForEach-Object { Get-ItemProperty "$($_.PSPath)\InprocServer32" }`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.

## Memory & Live State

### Full Memory Dump
**Location:** `Acquired via live capture (RAM)`

Complete physical memory image of the running system capturing all active processes, kernel structures, network connections, loaded DLLs, injected code, and decrypted data.

**Forensic Value:** Memory analysis is the only reliable method to detect fileless malware, process injection, and reflective DLL loading that leave no disk artifacts. Active network connections with owning process context, decrypted credential material from LSASS, and in-memory-only scripts are all recoverable. Volatility profiles can reconstruct the full process tree, open handles, and loaded modules.

**Tools:** Volatility 3, Rekall, WinPmem, DumpIt, Magnet RAM Capture

**Collection Commands:**
- **DumpIt:** `DumpIt.exe /OUTPUT C:\output\memory.dmp`
- **WinPmem:** `winpmem_mini_x64.exe C:\output\memory.raw`
- **Magnet RAM Capture:** `MagnetRAMCapture.exe (GUI - select output path and capture)`
- **Volatility 3:** `vol.py -f memory.raw windows.pslist.PsList`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.
- Live-state evidence is volatile. Collect it before reboot, containment, or power loss whenever legal and operational constraints allow.

### Pagefile.sys & Hiberfil.sys (Virtual Memory)
**Location:** `C:\pagefile.sys and C:\hiberfil.sys`

Pagefile.sys contains memory pages swapped to disk by the Windows memory manager. Hiberfil.sys contains a compressed copy of all physical memory written during hibernation or Fast Startup shutdown, effectively serving as a full memory snapshot.

**Forensic Value:** Virtual memory files contain fragments of process memory that were paged to disk, including credentials, decrypted content, command-line arguments, and malware code. Hiberfil.sys is particularly valuable as it represents a complete RAM capture at the last hibernation, recoverable even from a dead system. Strings analysis and carving can extract passwords, URLs, encryption keys, and remnants of in-memory-only malware that left no disk artifacts.

**Tools:** Volatility 3, strings, bulk_extractor, Hibernation Recon (Arsenal), KAPE

**Collection Commands:**
- **KAPE:** `kape.exe --tsource C: --tdest C:\output --target MemoryFiles`
- **Hibernation Recon:** `HibernationRecon.exe -f C:\hiberfil.sys -o C:\output\hiberfil_decompressed.bin`
- **strings:** `strings -el C:\pagefile.sys > C:\output\pagefile_strings_unicode.txt && strings C:\pagefile.sys > C:\output\pagefile_strings_ascii.txt`
- **bulk_extractor:** `bulk_extractor -o C:\output\pagefile_carved C:\pagefile.sys`

**Official References:**
- [Windows PowerShell Logging](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows_powershell?view=powershell-5.1)
- [NTFS Change Journals](https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals)
- [Additional LSA Protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)

**Collection Constraints:**
- Availability, retention, and field coverage depend on the Windows release, SKU, per-host audit policy, and user activity. Treat absence as inconclusive unless you verified the feature was enabled.
- Live-state evidence is volatile. Collect it before reboot, containment, or power loss whenever legal and operational constraints allow.

---
*Generated by DFIR Assist*