Chapter 4

Evidence Preservation During IR

The evidence-versus-speed tension, volatile data lost on reboot, what to collect before isolating, and the memory acquisition decision — the choices you make in the first 30 minutes determine what you can prove for the next 30 days.

Scenario

The help desk calls. A user's machine is acting strangely — lots of disk activity, slow. The on-call analyst remotes in and immediately sees a suspicious process in Task Manager. Instinct says: kill it. But killing the process destroys the malware's runtime state — the decrypted payload in memory, the C2 connection details, the command history. Then someone reboots the machine to "clear" it. Now the prefetch entry for the malicious process is gone, the memory is gone, the network connections are gone. What remains: the file on disk (if it wasn't fileless) and whatever made it into SIEM before the reboot. The analyst made the worst possible sequence of decisions in the first five minutes and handed the attacker a clean getaway. This chapter explains what to do instead.

Volatile vs Non-Volatile Evidence

Evidence falls into two categories. Volatile evidence exists only while the machine is running and is lost on power-off or reboot. Non-volatile evidence persists on disk. Volatile evidence is almost always more valuable — and almost always the first thing destroyed.

  Evidence Volatility Spectrum (most → least volatile)
  ═══════════════════════════════════════════════════════════════════

  1. CPU registers, caches            Destroyed on process termination
  2. RAM (physical memory)            Destroyed on shutdown/reboot
     ├── Decrypted malware payload
     ├── C2 encryption keys
     ├── Injected shellcode
     ├── Cleartext credentials (WDigest, Kerberos tickets)
     └── Process heap (command history, runtime state)
  3. Active network connections       Lost when connection closes
  4. Running process list             Changes constantly
  5. Logged-in user sessions          Cleared on logoff
  6. Clipboard contents               Cleared on logoff
  7. Temp files, recent artifacts     May be cleared by OS or attacker
  ───────────────────────────────
  8. Event logs (on-host)             Survives reboot; can be cleared
  9. NTFS timestamps ($I30)           Survives reboot; can be modified
  10. Registry (hives on disk)        Survives reboot
  11. Files on disk                   Survive reboot; can be deleted
  12. SIEM / log forwarding           Survive machine loss entirely

  Priority: collect volatile evidence BEFORE any action that would
  lose it (isolation, reboot, killing the process).

Order of Operations Before Isolation

Before isolating a host, collect volatile evidence in order of volatility. This takes 10-20 minutes on a live host and produces the artifacts that will anchor the entire investigation.

StepWhat to collectToolTime
1Memory image (RAM)WinPmem, AVML, DumpIt, or EDR memory collection5-15 min (size = RAM size)
2Running process list + parent/childEDR, Tasklist /v, Get-Process, Volatility after memory capture30 seconds
3Network connections with PIDsnetstat -anob, Get-NetTCPConnection30 seconds
4Logged-in users and sessionsquery session, qwinsta, Get-WinEvent 4624 (recent)30 seconds
5ClipboardGet-Clipboard (PowerShell)5 seconds
6Event logs (Security, System, Application, PowerShell, Sysmon)wevtutil epl, EDR log pull2-5 min
7KAPE triage artifacts (prefetch, Amcache, MFT, registry hives, LNK files)KAPE with triage targets5-15 min
8Isolate the hostEDR isolation commandInstant
PowerShellvolatile-collection.ps1
# Run before isolating — collect volatile evidence snapshot
$outputDir = "C:\IR_Collection_$(Get-Date -Format yyyyMMdd_HHmmss)"
New-Item -ItemType Directory -Path $outputDir -Force | Out-Null

# 1. Running processes with full path and parent
Get-Process | ForEach-Object {
    [PSCustomObject]@{
        PID      = $_.Id
        Name     = $_.Name
        Path     = $_.Path
        CPU      = $_.CPU
        Started  = $_.StartTime
        ParentPID = (Get-WmiObject Win32_Process -Filter "ProcessId=$($_.Id)").ParentProcessId
    }
} | Export-Csv "$outputDir\processes.csv" -NoTypeInformation

# 2. Network connections with owning process
Get-NetTCPConnection | ForEach-Object {
    $p = Get-Process -Id $_.OwningProcess -EA 0
    [PSCustomObject]@{
        State      = $_.State
        Local      = "$($_.LocalAddress):$($_.LocalPort)"
        Remote     = "$($_.RemoteAddress):$($_.RemotePort)"
        PID        = $_.OwningProcess
        Process    = if ($p) { $p.Name } else { "?" }
        Path       = if ($p) { $p.Path } else { "?" }
    }
} | Export-Csv "$outputDir\network_connections.csv" -NoTypeInformation

# 3. Active sessions
query session | Out-File "$outputDir\sessions.txt"

# 4. Export event logs
foreach ($log in @("Security","System","Application",
                   "Microsoft-Windows-PowerShell/Operational",
                   "Microsoft-Windows-Sysmon/Operational")) {
    $safe = $log -replace "[/\\]","_"
    wevtutil epl $log "$outputDir\$safe.evtx" 2>$null
}

# 5. Loaded modules per process (for injection detection)
Get-Process | ForEach-Object {
    $pid = $_.Id; $pname = $_.Name
    $_.Modules | ForEach-Object {
        [PSCustomObject]@{
            ProcessName = $pname; PID = $pid
            Module = $_.FileName
        }
    }
} 2>$null | Export-Csv "$outputDir\loaded_modules.csv" -NoTypeInformation

Write-Host "Collection complete: $outputDir" -ForegroundColor Green

The Memory Acquisition Decision

Memory acquisition is not always the right call. Understand the trade-offs before you decide.

ScenarioAcquire memory?Reason
Fileless malware (no disk artifact)Yes — immediatelyMemory is the only copy of the payload. Without it, you have only behavioral artifacts, no malware sample.
Active C2 connection, decrypted commsYesC2 encryption keys and decrypted traffic are in memory. Invaluable for attribution and traffic decryption.
Ransomware actively encryptingNo — isolate firstEvery second of delay means more encrypted files. Memory can often wait; active encryption cannot.
Malware sample is on disk and knownOptionalValue is lower if you already have the binary. Still worth it for credential artifacts in LSASS.
16+ GB RAM, limited time windowDepends on criticalityA 32 GB memory image takes 15+ minutes. Balance against risk of attacker destroying other evidence.
Potential legal action (criminal or civil)YesMemory image may contain direct evidence of attacker commands. Necessary for legal proceedings.
PowerShellmemory-acquisition.ps1
# WinPmem memory acquisition (requires winpmem.exe in PATH or specified path)
# Run as Administrator

$outputPath = "D:\IR\memory_$(hostname)_$(Get-Date -Format yyyyMMdd_HHmmss).raw"

# Acquire full physical memory
.\winpmem_mini_x64_rc2.exe $outputPath
# or: winpmem --output $outputPath --format raw

# Verify the file was created and get its hash
if (Test-Path $outputPath) {
    $hash = Get-FileHash $outputPath -Algorithm SHA256
    Write-Host "Memory acquired: $outputPath"
    Write-Host "SHA256: $($hash.Hash)"
    # Record the hash for chain of custody documentation
    "$($hash.Hash)  $outputPath" | Out-File "$outputPath.sha256"
} else {
    Write-Warning "Memory acquisition failed — check winpmem output"
}

# Alternative: via EDR (CrowdStrike example — if EDR supports remote memory collection)
# Most enterprise EDRs have a built-in memory collection action that doesn't
# require deploying a separate tool to the endpoint

Chain of Custody

Chain of custody is the documented record of who had access to evidence and when. Without it, evidence may be inadmissible in legal proceedings. For incidents that may lead to prosecution or litigation, chain of custody documentation starts at the moment of first collection.

FieldWhat to document
Exhibit IDUnique identifier (e.g., IR-2026-001-E01) for each piece of evidence
DescriptionWhat it is (memory image, disk image, log export), from what system, at what time
Collected byFull name and title of the person who collected it
Collection timeUTC timestamp of when collection started and completed
Hash (MD5/SHA256)Cryptographic hash immediately after collection — proves evidence was not modified later
Storage locationWhere the evidence is stored (which system, which path, physical media label)
Transfer logEvery time evidence changes hands: from/to, date/time, reason — maintained as a log, not overwritten
Why hash every artifact immediately

A hash taken at collection time is the proof that the evidence is unchanged from the moment you collected it. If you collect a memory image at 3:15 AM and provide it to external counsel at 9 AM, the hash proves that nobody modified it between those times. Without a collection-time hash, opposing counsel in litigation can argue the evidence was tampered with after collection. This is especially critical for memory images, which can be trivially modified with a hex editor — a hash makes post-collection modification detectable.

What Not to Do

ActionWhy it destroys evidenceWhat to do instead
Kill the malicious processDestroys runtime state in memory — decrypted payload, C2 keys, heap artifactsAcquire memory first, then isolate the host (process will stop when network is cut)
Reboot the machineDestroys all volatile evidence — memory, network connections, running processesDo not reboot before memory acquisition. After isolation, acquire memory before rebooting.
Run antivirus scanModifies file timestamps (access time) and may delete the malware sample you need for analysisCollect the sample first, quarantine only after
Use the compromised machine for investigationA compromised machine may have a keylogger, screen capture, or file modification capability — using it contaminates evidence and exposes your IR credentialsCollect artifacts remotely; investigate on a clean analysis machine
Copy files to the compromised machineModifies the MFT, changes directory timestamps, may alert the attackerCollect to external media or a network share the compromised machine cannot reach

Q & A

Q: Ransomware is actively encrypting files. Do you collect memory first?

No. When ransomware is actively spreading, every second of collection delay means more files encrypted. Isolate immediately — use EDR host isolation which takes under 5 seconds via the console. The network isolation stops the spread. After isolation, the ransomware process on the isolated host continues running (it still has local access) but cannot reach other machines. You can then acquire memory from the isolated host while the ransom process is still running, capturing the decryption key that may be in memory. This is the right sequence: isolate first (stop spread), then collect memory (get decryption keys).

Q: The attacker deleted the malware binary before you could collect it. Is it gone?

The file entry in the MFT is deleted, but the data blocks may remain on disk until overwritten by new files. File carving tools (Autopsy, Recuva, PhotoRec) can recover deleted files from unallocated space. More usefully: if the malware ran, the Prefetch directory may have an entry for it, AmCache/Shimcache may record its path and hash, and process creation events (Sysmon Event 1 or Event 4688) may have the command line and image hash. If the attacker connected to the machine and deleted the file, VSS shadow copies may have a copy — check with vssadmin list shadows. And if you're lucky, the hash is in EDR telemetry from process creation, allowing VirusTotal lookup even without the binary.

Q: Legal says all evidence must be preserved. The IT team wants to wipe and re-image immediately. Who wins?

Legal wins, and this is a common conflict. The re-image request typically comes from an IT team trying to restore service quickly. The right resolution is: collect a forensic image of the disk first (takes 30-60 minutes per machine via KAPE for targeted artifacts, or 2-4 hours for a full disk image), then re-image. This satisfies both requirements — service restoration proceeds and legal hold is honored. Make this part of the IR runbook so the decision doesn't get re-litigated during every incident. Document in writing that evidence collection precedes re-imaging, signed off by legal and CISO before the incident occurs.