TR1.3 Windows Evidence Volatility

Figure TR1.3 — The Windows 5-minute capture sequence. Tier 1 volatile state captures in 30 seconds. Tier 2 memory acquisition takes 3-5 minutes. Tier 3 KAPE collection runs 5-10 minutes. Hash everything at the end.

Tier 1 on Windows: what's running right now

The process table is the first thing the triage analyst captures on a Windows endpoint. It answers the immediate question: what is this system doing right now? The process ID, parent process, command line, and executable path together form a relationship chain that reveals how the suspicious activity started. A rundll32.exe process is normal. A rundll32.exe loading a DLL from C:\Users\Public\Libraries\ with a parent of explorer.exe and no documented scheduled task is not.

# Tier 1 capture: processes with parent chain and command line
Get-CimInstance Win32_Process |
    Select-Object ProcessId, ParentProcessId, Name,
    CommandLine, ExecutablePath, CreationDate |
    Export-Csv "C:\IR\Evidence\processes_$(hostname).csv" -NoTypeInformation
# Network connections with owning process
Get-NetTCPConnection | Where-Object { $_.State -eq 'Established' } |
    Select-Object LocalAddress, LocalPort, RemoteAddress,
    RemotePort, OwningProcess,
    @{N='Process';E={(Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue).ProcessName}} |
    Export-Csv "C:\IR\Evidence\connections_$(hostname).csv" -NoTypeInformation
# Active sessions — who is logged in
query user > "C:\IR\Evidence\sessions_$(hostname).txt"

These three commands run in under 30 seconds and capture the most volatile Windows artifacts. The process list shows every running executable with its full command line — the command line is where the attacker's intent is visible. A legitimate rundll32.exe has a documented DLL and exported function. An attacker's rundll32.exe loads a DLL from a user-writable directory with an unusual export name.

The network connections reveal which processes are communicating externally. Here's what the analyst sees on WS-FIN-042:

LocalAddress  LocalPort RemoteAddress    RemotePort OwningProcess Process
-----------   --------- -------------    ---------- ------------- -------
10.50.3.42    52841     185.220.101.34   443        8192          rundll32
10.50.3.42    52903     20.190.159.71    443        1204          svchost
10.50.3.42    52917     13.107.42.14     443        6840          msedge
10.50.3.42    53012     10.50.1.10       445        4             System
10.50.3.42    53089     10.50.1.20       135        9128          svchost

The first row is the finding: rundll32 (PID 8192) holding a persistent HTTPS connection to 185.220.101.34. The remaining rows are normal Windows traffic — svchost connecting to Microsoft authentication endpoints, Edge browsing, and SMB/RPC connections to domain controllers. The analyst needs the process export and the connection export together because the connection alone shows the suspicious IP, but the process export reveals the command line that identifies the loaded DLL, and the parent process that reveals how the DLL sideloading was triggered.

Active sessions complete the core Tier 1 capture. The query user output shows which users are logged in, their session type (console, RDP, disconnected), and idle time. During triage, this answers whether the compromised user is actively working on the system — which affects both the containment approach (you don't want to disrupt an active user without coordination) and the evidence interpretation (was the malicious process launched by the user or by an attacker who hijacked their session?).

Two additional Tier 1 artifacts are worth capturing in the same 30-second window. The DNS resolver cache (Get-DnsClientCache | Export-Csv) records recently resolved domain names — if the attacker's C2 uses a domain rather than a raw IP, the cache reveals it even after the connection closes. Loaded DLLs for suspicious processes (Get-Process -Id 8192 | Select-Object -ExpandProperty Modules) expose every library the process has loaded, which is where DLL sideloading evidence lives.

The legitimate msxml6r.dll ships at a known path with a known hash. The attacker's version lives in a user-writable directory and has a hash that matches nothing in Microsoft's catalog.

Tier 2: memory and the evidence it contains exclusively

Physical memory is the most valuable single artifact on a Windows endpoint. A RAM dump captures everything Tier 1 captures — processes, connections, sessions — plus evidence that exists nowhere else: decrypted payload code from fileless attacks, Cobalt Strike beacon configurations that reveal the attacker's C2 infrastructure, cached LSASS credentials (NTLM hashes and Kerberos tickets the attacker extracted via credential dumping), encryption keys for BitLocker volumes and encrypted communications, and command history from attacker tools that wrote nothing to disk.

WinPMem is the standard tool for Windows memory acquisition during triage. It's a single executable that runs from a USB drive or network share — never install an acquisition tool on the compromised system. The command is straightforward: winpmem_mini_x64.exe E:\IR\memdump.raw. The output is a raw memory dump file roughly equal to the system's physical RAM. A 16 GB system produces a ~16 GB dump file in 2–5 minutes depending on the output drive speed.

Write the dump to an external USB or network share, not the system's local disk — writing 16 GB to the system disk overwrites evidence in unallocated space.

Memory acquisition has one common failure mode that the triage responder must expect: Windows Secure Kernel and Virtualization-Based Security (VBS) protect certain memory regions from user-mode access. The resulting dump will be slightly smaller than physical RAM. This is normal. The protected regions contain kernel-mode security data, not the attacker's process memory. The dump is still forensically complete for process analysis, network reconstruction, and credential extraction.

The containment timing decision hinges on Tier 2. If the analyst starts the memory dump at 06:47 and it completes at 06:51, the automatic reboot at 07:00 gives nine minutes of margin. If the analyst delays to investigate other artifacts first and starts the dump at 06:55, the dump may not complete before the reboot destroys it. Start the memory dump as soon as Tier 1 capture is complete — it runs in the background while the analyst continues with Tier 3 collection.

Tier 3: event logs, prefetch, and the rotation problem

Windows Event Logs are Tier 3 because they persist on disk but have a size-based rotation policy that overwrites old entries when the log file reaches its maximum. The Security log defaults to 20 MB and overwrites the oldest entries when full. On a busy domain controller processing thousands of authentication events per hour, 20 MB of Security log can represent less than 24 hours of history. On a single-purpose application server, the same 20 MB might cover weeks.

The triage responder doesn't need to analyze the event logs during triage — that's the investigation team's job. The triage action is to preserve them before rotation overwrites the evidence. The fastest method is KAPE with the !SANS_Triage target, which collects event logs, prefetch files, registry hives, browser artifacts, the $MFT, AmCache, ShimCache, SRUM, and dozens of other forensic artifacts in a single automated pass.

If KAPE isn't pre-staged and can't be transferred quickly, native PowerShell captures the highest-value Tier 3 artifacts manually. wevtutil epl Security C:\IR\Security.evtx exports the complete Security log. wevtutil epl "Microsoft-Windows-Sysmon/Operational" C:\IR\Sysmon.evtx captures Sysmon events if the organization has deployed it — Sysmon records process creation, network connections, file creation, and registry modification with more detail than the native Security log. wevtutil epl "Microsoft-Windows-PowerShell/Operational" C:\IR\PowerShell.evtx preserves PowerShell script block logging, which records the full content of every PowerShell command the attacker executed.

These three log exports take under a minute and preserve the evidence most frequently needed by investigation teams.

Here's a Security Event Log entry the analyst might encounter on WS-FIN-042. This Event ID 4688 records the suspicious process creation:

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Event ID:      4688
TimeCreated:   2026-05-18T02:19:07.412Z
Computer:      WS-FIN-042.northgateeng.local
A new process has been created.
Subject:
    Account Name:  j.morrison
    Account Domain: NORTHGATEENG
    Logon ID:      0x4A8F12
Process Information:
    New Process ID:    0x2000
    New Process Name:  C:\Windows\System32\rundll32.exe
    Token Elevation:   %%1936
    Creator Process ID: 0x1B4C
    Creator Process Name: C:\Windows\explorer.exe
    Process Command Line: rundll32.exe
        C:\Users\Public\Libraries\msxml6r.dll,DllRegisterServer

This single event record contains the entire execution chain: explorer.exe (PID 0x1B4C) spawned rundll32.exe (PID 0x2000), which loaded msxml6r.dll from C:\Users\Public\Libraries\ and called DllRegisterServer. The DLL name mimics the legitimate msxml6r.dll that ships with Windows, but the path is wrong — the legitimate version lives in C:\Windows\System32\, not in a user-writable Public folder. This is textbook DLL sideloading. The event log preserves this evidence on disk, but only until rotation pushes it out of the 20 MB window.

Prefetch files add a second corroborating artifact. Windows maintains up to 1,024 prefetch entries that record application execution timestamps and loaded DLLs. The prefetch file for RUNDLL32.EXE-*.pf will show its last 8 execution times and every DLL it loaded during those executions — including msxml6r.dll. If the Security log rotates past the 4688 event, the prefetch file provides an independent record that rundll32.exe executed and loaded that specific DLL. KAPE's !SANS_Triage target collects prefetch files alongside event logs.

The 5-minute Windows collection sequence

The collection sequence is not a checklist — it's a time-boxed procedure the analyst executes under pressure while the automatic reboot clock ticks.

Minute 0–0.5: run the Tier 1 PowerShell commands from above. Processes, connections, sessions. Export to CSV on a network share or USB.

Minute 0.5–1: start WinPMem in the background. The memory dump runs for 2–5 minutes. Don't wait for it to finish — move to the next step immediately.

Minute 1–5: start KAPE with !SANS_Triage. KAPE collects event logs, prefetch, registry hives, $MFT, AmCache, ShimCache, SRUM, browser history, and scheduled tasks into a VHDX container on the output drive. The --vhdx Evidence flag creates a mountable container the investigation team can analyze without modifying the original artifacts. The command is: kape.exe --tsource C: --tdest E:\IR\KAPE --target !SANS_Triage --vhdx Evidence. Output size varies by system activity — a typical workstation produces 500 MB to 5 GB of collected artifacts.

While KAPE runs, the analyst can simultaneously capture scheduled tasks and autorun entries — persistence mechanisms the attacker may have established. schtasks /query /fo csv /v exports every scheduled task with its trigger, action, and last run time. Sysinternals autorunsc.exe -a * -c -h -v captures autostart entries across all locations (Run keys, services, drivers, scheduled tasks, WMI subscriptions) with hash verification and VirusTotal lookups if configured.

These artifacts sit between Tier 2 and Tier 3 — they persist on disk but the attacker can delete them at any time to remove their persistence mechanism before the analyst captures it.

Minute 5: verify the memory dump completed — the output file size should approximately match physical RAM. Check that KAPE output contains the expected subdirectories. If the memory dump is undersized, it was interrupted or encountered protected regions. Document the actual output file size.

Tier 4: what survives reboot

The triage responder's role with Tier 4 is protective. Registry hives (SAM, SYSTEM, SOFTWARE, NTUSER.DAT), the $MFT, filesystem timestamps, AmCache, ShimCache, and the SRUM database all survive reboot. They survive because they're written to disk as part of normal system operation, not because the analyst collected them. The KAPE !SANS_Triage collection captures these artifacts during the Tier 3 collection pass, so if KAPE runs successfully, the investigation team receives Tier 3 and 4 evidence in the same package.

The risk to Tier 4 is not reboot — it's reimaging. If the IT team reimages the endpoint before the investigation team acquires a forensic image, every Tier 4 artifact is destroyed. The triage responder's containment note must explicitly state: "Endpoint isolated via Defender. DO NOT reimage. Forensic image required by investigation team." That single sentence in the incident comment protects weeks of forensic evidence.

Defender for Endpoint provides a parallel telemetry stream that supplements local collection. DeviceProcessEvents captures process creation with command lines. DeviceNetworkEvents records network connections. DeviceFileEvents logs file creation and modification. This telemetry is invaluable — it provides a cloud-stored record of endpoint activity that survives both reboot and reimaging. But Defender doesn't capture full memory contents, doesn't record every event in the Security log (it selects high-value events), and doesn't preserve the complete registry state.

The investigation team that relies solely on Defender telemetry has excellent visibility into process and network behavior but limited visibility into memory-resident artifacts, complete event log sequences, and disk forensic metadata like $MFT timestamps. Local collection and Defender telemetry together provide full coverage. Either alone leaves gaps.