TR1.3 Windows Evidence Volatility

Figure TR1.3 — Windows evidence volatility. Four categories: destroyed on reboot, overwritten on activity, persistent on disk, and attacker-controlled (can be destroyed at any time by the attacker's cleanup actions).

Tier 1-2: destroyed on reboot

These artifacts exist only while the system is running in its current state. A single reboot — whether initiated by the user, the attacker, or the triage responder — eliminates them permanently.

Memory (RAM)

The complete contents of physical memory: running process code and data, decrypted payloads, cached credentials (LSASS stores plaintext and hashed credentials in memory), network buffers, clipboard contents, and any data the attacker loaded but did not write to disk. Fileless attacks operate entirely in memory — the malicious code never touches the disk, so memory is the ONLY evidence source.

At NE, the CHAIN-ENDPOINT Cobalt Strike beacon loaded via DLL sideloading runs entirely in memory after initial execution. The beacon configuration (C2 server address, sleep interval, jitter, communication protocol) exists only in the beacon’s memory space. A memory dump captured during triage gives the investigation team the full beacon configuration — enabling them to identify the C2 infrastructure, check other systems for connections to the same C2, and understand the attacker’s capabilities. Without the memory dump, the investigation team must reverse-engineer the DLL from disk (if it still exists) to extract the configuration — a process that takes hours instead of minutes.

Capture tool: WinPMem (free, lightweight, command-line). Run from a USB drive or network share — do not install on the compromised system.

# WinPMem memory acquisition
winpmem_mini_x64.exe C:\IR\Evidence\%COMPUTERNAME%_memdump.raw

Expected output: a raw memory dump file equal in size to the system’s physical RAM (16 GB system → ~16 GB file). Capture time: 2-5 minutes depending on RAM size and output drive speed. Write to a USB drive or network share — not to the system’s local disk (writing a 16 GB file to the system disk modifies the disk evidence).

Alternative: KAPE includes a memory acquisition target that invokes a memory dumper. MemProcFS can also acquire memory on newer Windows systems. DumpIt is another lightweight option.

Running processes

The current process table: process ID, parent process, command line, loaded modules, user context, start time. This is the evidence that tells the triage responder: what is running on this system RIGHT NOW, and is any of it malicious?

Capture commands (PowerShell — native, no tools required):

1
2
3
4
5
6
7
8
9

# Process list with command lines and parent process
Get-CimInstance Win32_Process | Select ProcessId, ParentProcessId, Name, 
    CommandLine, CreationDate, ExecutablePath | 
    Export-Csv C:\IR\Evidence\processes.csv -NoTypeInformation

# Loaded modules for all processes (identifies DLL sideloading)
Get-Process | ForEach-Object { 
    $_.Modules | Select @{N='PID';E={$_.Id}}, ModuleName, FileName 
} | Export-Csv C:\IR\Evidence\modules.csv -NoTypeInformation

Visual alternative: Sysinternals Process Explorer shows the full process tree with colour-coded indicators for packed executables, unsigned DLLs, and VirusTotal matches. For triage, the process tree view immediately reveals suspicious parent-child relationships: cmd.exe spawned by winword.exe (macro execution), PowerShell spawned by mshta.exe (living-off-the-land), or rundll32.exe loading a DLL from %TEMP% (DLL sideloading).

Network connections

Active TCP and UDP connections: local address, remote address, state, owning process. This reveals: C2 communication (established connections to external IPs), lateral movement (connections to internal systems on SMB, RDP, WMI ports), and data exfiltration (connections to external IPs with sustained data transfer).

1
2
3
4
5

# Network connections with owning process
Get-NetTCPConnection | Where-Object State -eq 'Established' |
    Select LocalAddress, LocalPort, RemoteAddress, RemotePort, 
    OwningProcess, @{N='Process';E={(Get-Process -Id $_.OwningProcess).Name}} |
    Export-Csv C:\IR\Evidence\connections.csv -NoTypeInformation

The key triage check: any ESTABLISHED connection to an external IP that is NOT a known Microsoft, CDN, or business application endpoint warrants investigation. Cross-reference the remote IP against the attacker indicators from the cloud triage (TR1.2). If the endpoint has a connection to the same IP that appeared in the suspicious cloud sign-in, the cross-environment pivot is confirmed.

Active sessions and logged-in users

Who is currently logged in to this system, from where, and since when.

1
2
3
4
5
6

# Logged-in users
query user
# Active SMB sessions (who is connecting TO this system)
Get-SmbSession | Select ClientComputerName, ClientUserName, NumOpens
# Active RDP sessions
qwinsta

Tier 3: overwritten on activity

These artifacts persist on disk but are overwritten by normal system activity on a schedule the responder cannot predict.

Event logs

Windows event logs are the backbone of Windows forensics, but they rotate based on maximum size. The Security log (which contains logon events, process creation, privilege use, and policy changes) defaults to 20 MB — on a busy server, this may hold only 24-48 hours of events. The PowerShell Operational log (which contains script block logging and command execution) has a separate rotation. Sysmon (if installed) has its own log with its own rotation.

The triage responder should capture the critical event logs immediately. KAPE’s !SANS_Triage target collects all forensically relevant event logs in one pass.

1
2
3
4

# Export Security log (manual method if KAPE unavailable)
wevtutil epl Security C:\IR\Evidence\Security.evtx
wevtutil epl "Microsoft-Windows-PowerShell/Operational" C:\IR\Evidence\PowerShell.evtx
wevtutil epl "Microsoft-Windows-Sysmon/Operational" C:\IR\Evidence\Sysmon.evtx

Parsing during triage: Eric Zimmerman’s EvtxECmd parses EVTX files to CSV in seconds — enabling the triage responder to search for specific event IDs (4624 logon, 4672 special logon, 4688 process creation, 1102 log cleared) without manually browsing Event Viewer.

# EvtxECmd: parse Security log to searchable CSV
EvtxECmd.exe -f C:\IR\Evidence\Security.evtx --csv C:\IR\Evidence\ --csvf Security_parsed.csv

Prefetch files

Windows Prefetch records which executables ran and when — limited to 1,024 entries before the oldest entry is overwritten. On a busy system, this history covers 2-7 days. Prefetch provides evidence of execution even when the executable has been deleted — the prefetch file survives longer than the binary itself.

The triage check: are there prefetch files for suspicious executables? C:\Windows\Prefetch\MIMIKATZ.EXE-*.pf or PSEXEC.EXE-*.pf or WINPMEM-*.pf (indicating someone already captured memory — was it you, or the attacker staging tools?).

Scheduled tasks and autorun entries

Scheduled tasks and autorun registry keys are the primary persistence mechanisms on Windows. An attacker who creates a scheduled task to re-execute their payload on reboot has persistence that survives containment unless the task is removed.

1
2
3
4

# Scheduled tasks (CSV export)
schtasks /query /fo csv /v > C:\IR\Evidence\scheduled_tasks.csv
# Autorun entries (Sysinternals Autoruns — CSV export)
autorunsc.exe -a * -c -h > C:\IR\Evidence\autoruns.csv

Autoruns captures EVERY autostart entry: registry Run keys, scheduled tasks, services, drivers, WMI subscriptions, DLL hijacks, and more. The output is often 200+ lines — the triage responder filters for entries that are unsigned, recently created, or running from user-writable paths (AppData, Temp, Public).

Windows evidence sources the triage responder must know

Beyond the standard Tier 1-3 evidence, several Windows-specific evidence sources deserve triage-level awareness because they answer questions the standard commands do not:

Windows Event Forwarding (WEF). If the organisation uses WEF, critical events from the endpoint may already be collected on a central WEF server — even if the endpoint itself is compromised or its logs have been cleared. The triage responder should check: “Does our environment use WEF? If so, where is the WEF collector and do I have access?” The WEF collector’s forwarded event logs provide a tamper-resistant copy of the endpoint’s security events — the attacker who clears the local Security log cannot clear the forwarded copy because it resides on a different server.

Sysmon (System Monitor). If Sysmon is deployed (a Sysinternals tool that records detailed process, network, file, and registry events), the Sysmon event log provides FAR richer process telemetry than the default Windows event logs. Sysmon Event ID 1 (Process Create) captures the full command line, parent command line, file hashes, and user context for every process creation. Event ID 3 (Network Connection) captures every outbound connection with the owning process. Event ID 7 (Image Loaded) captures DLL loads — identifying DLL sideloading. Event ID 10 (ProcessAccess) captures cross-process access — identifying LSASS memory access.

If Sysmon is deployed, the triage responder’s Command 9 (event logs) should include the Sysmon log: wevtutil epl "Microsoft-Windows-Sysmon/Operational" "$env:TEMP\IR_Sysmon.evtx". Sysmon data provides the process tree, command lines, and DLL loads that the triage responder needs for the 5-check process assessment (TR3.4) — without requiring Process Explorer or MemProcFS.

Defender for Endpoint sensor data. The Defender for Endpoint sensor continuously streams telemetry to the Defender cloud — process events, network events, file events, registry modifications, and logon events. This telemetry is queryable in Sentinel (DeviceProcessEvents, DeviceNetworkEvents, DeviceFileEvents, DeviceRegistryEvents, DeviceLogonEvents) and in the Defender portal’s Advanced Hunting. The sensor data provides a CLOUD COPY of the endpoint’s volatile evidence — if the endpoint is destroyed (ransomware, wipe), the sensor data in the cloud preserves the pre-destruction state.

The triage responder should query DeviceProcessEvents and DeviceNetworkEvents for the affected endpoint as part of the triage workflow — this provides the cloud-side view that complements the local 10-command triage. Discrepancies between the local view and the cloud view (processes visible locally but not in Defender, or vice versa) indicate either ingestion delay (normal — Defender ingests with 5-15 minute delay) or telemetry evasion (the attacker is hiding from the Defender sensor — a high-confidence compromise indicator).

PowerShell transcription logs. If PowerShell transcription logging is enabled (Group Policy: “Turn on PowerShell Transcription”), every PowerShell session is recorded to a text file in a configured directory (commonly C:\PSTranscripts\). The transcription log captures the full input and output of every command — providing a complete record of the attacker’s PowerShell activity. The transcription logs are Tier 3 evidence (persists on disk, survives reboot) but may be overlooked by triage responders who are not aware of the feature.

KAPE’s !SANS_Triage target includes PowerShell transcription logs when present. If collecting manually, check: Get-ChildItem "C:\PSTranscripts" -Recurse -ErrorAction SilentlyContinue | Sort-Object LastWriteTime -Descending | Select-Object -First 20. The presence of transcription logs for the triage window provides a complete history of attacker PowerShell commands — one of the most valuable evidence sources for both triage classification and investigation analysis.

ETW (Event Tracing for Windows) providers. Advanced triage may involve querying ETW providers for specific subsystem data — network activity (Microsoft-Windows-TCPIP), DNS queries (Microsoft-Windows-DNS-Client), and security events that are not written to standard event logs. ETW is beyond triage scope for most responders, but awareness that ETW data exists (and that tools like SilkETW can capture it) is valuable context for the investigation handoff — the triage responder can note “ETW capture not performed, recommend for investigation phase” in the triage report.

The 5-minute Windows triage capture

Minute 0-1 (Tier 1 — native PowerShell): Process list with command lines → network connections with owning process → logged-in users → active SMB/RDP sessions. Four commands, four CSV files, 60 seconds.

Minute 1-3 (Tier 2 — memory): Start WinPMem: winpmem_mini_x64.exe C:\IR\Evidence\memdump.raw. This runs for 2-5 minutes in the background. While it runs, capture scheduled tasks and autoruns.

Minute 3-5 (Tier 3 — KAPE): kape.exe --tsource C: --tdest E:\IR\KAPE --target !SANS_Triage --vhdx Evidence. KAPE collects event logs, prefetch, registry hives, browser history, $MFT, and more into a single container. The !SANS_Triage target is pre-configured for forensic collection — the responder does not need to select individual artifacts.

Minute 5: Verify the memory dump completed (file size matches physical RAM). Verify KAPE output contains the expected directories. Document the collection: timestamp, tool versions, output locations, hashes of evidence files.

Worked artifact: Windows volatile evidence collection script

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

# Windows Triage Collection Script — Run as Administrator $out = "C:\IR\Evidence\$(hostname)_$(Get-Date -Format yyyyMMdd_HHmmss)" New-Item -ItemType Directory -Path $out -Force # Tier 1: Processes, connections, sessions Get-CimInstance Win32_Process | Select ProcessId, ParentProcessId, Name, CommandLine, ExecutablePath | Export-Csv "$out\processes.csv" -NoTypeInformation Get-NetTCPConnection | Where State -eq 'Established' | Select LocalAddress, LocalPort, RemoteAddress, RemotePort, OwningProcess | Export-Csv "$out\connections.csv" -NoTypeInformation query user > "$out\sessions.txt" # Tier 2: Memory (start in background) Start-Process -FilePath ".\winpmem_mini_x64.exe" -ArgumentList "$out\memdump.raw" -NoNewWindow # Tier 2: Persistence schtasks /query /fo csv /v > "$out\tasks.csv" # Tier 3: Event logs wevtutil epl Security "$out\Security.evtx" wevtutil epl "Microsoft-Windows-PowerShell/Operational" "$out\PowerShell.evtx" Write-Host "Collection complete. Verify memory dump file size."

Troubleshooting

“I cannot run PowerShell as administrator on the endpoint.” If you have Defender for Endpoint Live Response, use it to execute commands remotely with SYSTEM privileges. If not, request emergency admin access through your IT team’s break-glass procedure. Document the access request and approval — this becomes part of the chain of custody.

“KAPE is not pre-staged on the endpoint.” KAPE runs from a USB drive or network share — it does not need to be installed. Keep a KAPE-ready USB drive in the SOC (Module TR9.4 covers the “go bag” concept). If no USB is available, use the PowerShell commands from this subsection to capture Tier 1-2 evidence manually. KAPE is faster and more comprehensive, but native PowerShell captures the most critical artifacts.

“The memory dump fails with ‘access denied’ on some regions.” Windows Secure Kernel and Virtualization-Based Security (VBS) protect certain memory regions from user-mode access. The dump will be slightly smaller than physical RAM. This is expected — the unprotected regions still contain the vast majority of forensically relevant data.