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.
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.
| Step | What to collect | Tool | Time |
|---|---|---|---|
| 1 | Memory image (RAM) | WinPmem, AVML, DumpIt, or EDR memory collection | 5-15 min (size = RAM size) |
| 2 | Running process list + parent/child | EDR, Tasklist /v, Get-Process, Volatility after memory capture | 30 seconds |
| 3 | Network connections with PIDs | netstat -anob, Get-NetTCPConnection | 30 seconds |
| 4 | Logged-in users and sessions | query session, qwinsta, Get-WinEvent 4624 (recent) | 30 seconds |
| 5 | Clipboard | Get-Clipboard (PowerShell) | 5 seconds |
| 6 | Event logs (Security, System, Application, PowerShell, Sysmon) | wevtutil epl, EDR log pull | 2-5 min |
| 7 | KAPE triage artifacts (prefetch, Amcache, MFT, registry hives, LNK files) | KAPE with triage targets | 5-15 min |
| 8 | Isolate the host | EDR isolation command | Instant |
# 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.
| Scenario | Acquire memory? | Reason |
|---|---|---|
| Fileless malware (no disk artifact) | Yes — immediately | Memory is the only copy of the payload. Without it, you have only behavioral artifacts, no malware sample. |
| Active C2 connection, decrypted comms | Yes | C2 encryption keys and decrypted traffic are in memory. Invaluable for attribution and traffic decryption. |
| Ransomware actively encrypting | No — isolate first | Every second of delay means more encrypted files. Memory can often wait; active encryption cannot. |
| Malware sample is on disk and known | Optional | Value is lower if you already have the binary. Still worth it for credential artifacts in LSASS. |
| 16+ GB RAM, limited time window | Depends on criticality | A 32 GB memory image takes 15+ minutes. Balance against risk of attacker destroying other evidence. |
| Potential legal action (criminal or civil) | Yes | Memory image may contain direct evidence of attacker commands. Necessary for legal proceedings. |
# 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.
| Field | What to document |
|---|---|
| Exhibit ID | Unique identifier (e.g., IR-2026-001-E01) for each piece of evidence |
| Description | What it is (memory image, disk image, log export), from what system, at what time |
| Collected by | Full name and title of the person who collected it |
| Collection time | UTC timestamp of when collection started and completed |
| Hash (MD5/SHA256) | Cryptographic hash immediately after collection — proves evidence was not modified later |
| Storage location | Where the evidence is stored (which system, which path, physical media label) |
| Transfer log | Every time evidence changes hands: from/to, date/time, reason — maintained as a log, not overwritten |
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
| Action | Why it destroys evidence | What to do instead |
|---|---|---|
| Kill the malicious process | Destroys runtime state in memory — decrypted payload, C2 keys, heap artifacts | Acquire memory first, then isolate the host (process will stop when network is cut) |
| Reboot the machine | Destroys all volatile evidence — memory, network connections, running processes | Do not reboot before memory acquisition. After isolation, acquire memory before rebooting. |
| Run antivirus scan | Modifies file timestamps (access time) and may delete the malware sample you need for analysis | Collect the sample first, quarantine only after |
| Use the compromised machine for investigation | A compromised machine may have a keylogger, screen capture, or file modification capability — using it contaminates evidence and exposes your IR credentials | Collect artifacts remotely; investigate on a clean analysis machine |
| Copy files to the compromised machine | Modifies the MFT, changes directory timestamps, may alert the attacker | Collect 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.