Incident Response 102: Evidence Preservation: Stop Touching Things

1 November 2026

1

Series: Incident Response | Reading time: ~14 minutes | Author: Tech Corsair

Introduction: The Crime Scene Analogy That Never Gets Old

Imagine a crime scene. Police arrive. They cordon off the area. They put on gloves. They photograph everything. They bag and tag evidence. They maintain a meticulous chain of custody so that when the case reaches court, no defence barrister can argue that the evidence was contaminated, tampered with, or fabricated.

Now imagine the cybersecurity equivalent. A server has been compromised. The sysadmin arrives. They log in as root. They run top to "just have a quick look." They notice a suspicious process and kill it. They check a few log files, accidentally overwriting timestamps. They think it might be malware, so they run an antivirus scan that modifies half the files on the disk. Then they reboot the server because "that usually fixes things." Finally, they call the security team and say, "I think something happened, but it looks fine now."

Every piece of volatile evidence -- gone. The memory contents -- overwritten. The network connections -- severed. The running processes -- terminated. The timestamps -- contaminated. The forensic investigator who arrives next might as well be examining an Etch A Sketch that someone has shaken.

This article is about how not to be that person.

The Order of Volatility: A Hierarchy of Disappearing Evidence

RFC 3227 (Guidelines for Evidence Collection and Archiving) establishes the order of volatility -- the principle that evidence should be collected in order from most volatile (disappears fastest) to least volatile (persists longest). This is not a suggestion. It is the fundamental rule of digital evidence collection, and violating it means losing evidence that cannot be recovered.

The Volatility Pyramid

From most volatile to least:

1. CPU Registers and Cache

Measured in nanoseconds. Unless conducting live analysis with specialist hardware, this data is effectively inaccessible during incident response. Acknowledged for completeness, but not a practical collection target in most scenarios.

2. Memory (RAM)

This is the crown jewel of volatile evidence. RAM contains:

Running processes and their complete memory space
Network connections (established, listening, recently closed)
Loaded DLLs and injected code
Encryption keys (including BitLocker, TrueCrypt, and -- crucially -- ransomware keys)
Clipboard contents
Chat messages and browser sessions not yet written to disk
Malware that exists only in memory (fileless malware)

When the power goes off, or the system reboots, all of this is gone. Permanently. Irretrievably. Like tears in rain, if tears in rain contained forensic evidence of a threat actor's lateral movement toolkit.

3. Network State

Current network connections, ARP cache, DNS cache, routing tables. Transient and overwritten as new connections are established. Captured with tools like netstat, arp -a, and ipconfig /displaydns on Windows.

4. Running Processes

Process listings, open file handles, loaded modules. Use tasklist /v, wmic process list full, or better yet, tools that capture this as part of a memory acquisition.

5. Disk Contents

File system data, including:

Files (including deleted files recoverable from unallocated space)
Registry hives
Event logs
Prefetch files
Browser history and cache
$MFT (Master File Table) entries

Disk data is persistent but can be modified. Every action on a live system potentially alters disk evidence -- writing to the pagefile, updating the registry, modifying log files, changing file access timestamps (NTFS $STANDARD_INFORMATION timestamps update on access in many configurations).

6. Remote Logging and Monitoring Data

SIEM logs, network flow data, proxy logs, firewall logs, email gateway logs. These exist on separate systems and are the most durable form of evidence -- provided the retention policy has not helpfully deleted them.

7. Archival Media

Backup tapes, offsite storage, cloud backups. The most persistent but also the most difficult to access quickly.

Memory Acquisition: RAM First, Questions Later

The single most important evidence collection action in any incident response is acquiring a RAM dump from affected systems before anything else happens. Before containment. Before remediation. Before anyone "has a quick look." Before the system is rebooted.

Why Memory Matters So Much

Modern threat actors increasingly operate in memory. Fileless malware, reflective DLL injection, PowerShell-based attacks that never touch the disk, process hollowing -- all of these leave minimal disk artefacts but are fully visible in a memory dump.

A RAM dump can reveal:

The exact malware running on the system, even if it is fileless
Command and control (C2) infrastructure addresses
Credentials harvested by the attacker (Mimikatz output, for instance)
The attacker's tools and techniques
Timeline of activity through process creation times
Encryption keys that could recover encrypted data

Without a memory dump, the investigation proceeds with incomplete evidence. With one, an analyst using tools like Volatility or Rekall can reconstruct a detailed picture of attacker activity.

Memory Acquisition Tools

Several tools are commonly used for memory acquisition:

WinPmem: Open-source memory acquisition driver for Windows. Part of the Rekall framework. Creates a raw memory dump.
DumpIt (Comae/Magnet): Single executable, no installation required. Double-click and it creates a raw memory dump in the current directory. Possibly the simplest tool for first responders.
FTK Imager (Exterro): GUI-based tool that can capture memory as well as disk images. More cumbersome but widely available.
Magnet RAM Capture: Free tool from Magnet Forensics. Minimal footprint, straightforward operation.
AVML (Acquire Volatile Memory for Linux): For Linux systems, because they get compromised too.

The Memory Acquisition Process

Prepare the tool on removable media. USB drive, pre-loaded with the acquisition tool. The tool should not be installed on the target system -- running an installer on a compromised system modifies the evidence.
Connect the removable media to the target system.
Run the acquisition tool. Direct the output to the removable media, not to the target system's disk.
Record the hash of the memory dump immediately upon completion (SHA-256 at minimum).
Document everything: Time of acquisition, tool used, tool version, system hostname, IP address, logged-in users, who performed the acquisition.

The entire process should modify the target system as little as possible. It will modify it somewhat -- running any program on a system changes memory -- but the goal is to minimise the footprint. This is an acceptable trade-off: a slightly modified memory dump is infinitely more valuable than no memory dump at all.

Disk Imaging: Making the Perfect Copy

After memory has been acquired, the next priority is creating a forensic image of the disk. A forensic image is a bit-for-bit copy of the entire storage device, including deleted files, unallocated space, and slack space.

Forensic Image vs. Logical Copy

A logical copy (e.g., copying files and folders) captures only the visible file system contents. A forensic image captures everything -- including:

Deleted files that have not been overwritten
File fragments in unallocated space
Data in file slack space (the gap between the end of a file and the end of its allocated cluster)
Alternate data streams (NTFS)
The Master File Table itself

The difference between a logical copy and a forensic image is the difference between photographing the contents of a room and photographing the room, the walls, the floorboards, and everything hidden behind the plasterboard.

Imaging Principles

1. Use a write blocker. A hardware or software write blocker prevents any data from being written to the source drive during imaging. This is non-negotiable for evidentiary imaging. Without a write blocker, the act of connecting the drive to an imaging workstation can modify evidence (Windows, for example, will helpfully update timestamps, mount points, and registry entries when a new drive is connected).

2. Create a verified forensic image. The imaging tool should calculate a cryptographic hash (SHA-256 or MD5+SHA-1) of both the source and the image during acquisition. These hashes must match. If they do not, the image is not a faithful copy and cannot be relied upon.

3. Image formats matter. Common forensic image formats include:

E01 (EnCase Evidence File): Compressed, supports metadata, splits into manageable segments. The industry standard.
Raw/dd: A pure bit-for-bit copy. No compression, no metadata. Simple and universally compatible but large.
AFF4 (Advanced Forensic Format): Open-source alternative with compression and metadata support.

4. Work from the image, never the original. All analysis is performed on a copy of the forensic image. The original image is preserved as evidence. If the analysis copy is accidentally modified, create another copy from the original.

Imaging Tools

FTK Imager: Free, supports E01 and raw formats, calculates hashes, widely accepted in legal proceedings.
dc3dd / dcfldd: Enhanced versions of the Unix dd command with built-in hashing and logging. Suitable for Linux-based imaging.
Guymager: Open-source GUI-based imaging tool for Linux. Fast and reliable.
Magnet ACQUIRE: Supports physical and logical imaging across multiple platforms.

Log Preservation: The Evidence Nobody Thinks About Until It Is Gone

Logs are the CCTV footage of the digital world. And like CCTV footage, they are only useful if:

The cameras were actually recording
The footage has not been overwritten
Someone knows how to review it

Critical Logs to Preserve

Windows Event Logs:

Security.evtx: Authentication events (4624/4625), privilege escalation (4672), account management (4720/4722/4726)
System.evtx: Service installations (7045), system time changes, unexpected shutdowns
PowerShell Operational: Script block logging (4104), module logging
Sysmon (if installed): Process creation, network connections, file creation, registry modifications -- the gold standard for endpoint telemetry
Terminal Services logs: Remote Desktop connection records

Network Logs:

Firewall logs (connection allow/deny)
Proxy logs (HTTP/HTTPS requests with URLs)
DNS query logs
VPN authentication logs
NetFlow/IPFIX data

Application Logs:

Web server access logs (Apache/IIS)
Email server logs
Database audit logs
Authentication service logs (RADIUS, LDAP, Azure AD sign-in logs)

Log Preservation Actions

Export and hash Windows Event Logs immediately. Use wevtutil epl Security C:\evidence\Security.evtx or copy the .evtx files directly from C:\Windows\System32\winevt\Logs\.
Copy SIEM data to a separate, read-only store. SIEM retention policies may age out critical evidence.
Preserve network device logs. Routers, switches, firewalls -- these often have limited local log storage and may overwrite evidence within hours.
Screenshot active monitoring dashboards if they display relevant data that is not captured elsewhere.
Check log rotation schedules. If logs rotate daily and the incident was detected on the rotation day, the previous day's logs may already be gone.

Chain of Custody: Proving the Evidence Is the Evidence

Chain of custody is the documented trail that records who had possession of evidence, when they had it, and what they did with it. Without it, evidence is just data. With it, evidence is admissible, defensible, and trustworthy.

Why It Matters

In any legal proceeding -- criminal prosecution, civil litigation, regulatory investigation, insurance claim -- the opposing party will challenge the integrity of digital evidence. The questions are predictable:

How do you know this evidence has not been modified?
Who had access to it between collection and analysis?
Can you prove it is the same data that was collected from the original system?

Chain of custody answers these questions. Without it, the answers are "we don't," "we're not sure," and "not really." These are not answers that inspire confidence in a courtroom.

Chain of Custody Documentation

Every piece of evidence should have a chain of custody record that includes:

Field	Purpose
Evidence identifier	Unique reference number
Description	What the evidence is (e.g., "RAM dump from server PROD-WEB-01")
Date/time of collection	When it was collected (with timezone)
Collected by	Name and role of the person who collected it
Collection method	Tool used, version, command-line parameters
Hash values	SHA-256 (minimum) calculated at time of collection
Storage location	Where the evidence is stored
Access log	Every person who accessed the evidence, when, and why

Practical Chain of Custody

Hash everything. Every memory dump, disk image, log file, and evidence artefact should be hashed at the time of collection. SHA-256 is the minimum. Record the hash in the chain of custody document and separately (e.g., in a case management system).
Use tamper-evident storage. Physical evidence (hard drives, USB devices) should be stored in tamper-evident bags with signed seals.
Limit access. The fewer people who handle evidence, the simpler the chain of custody. Designate an evidence custodian.
Document transfers. Every time evidence changes hands, both parties sign and record the date, time, and reason for the transfer.

The First Responder Checklist: What To Do (and What Not To Do)

For the person who first discovers a potentially compromised system, the rules are straightforward:

Do:

Document the current state. Photograph the screen. Note what is displayed, what is running, who is logged in.
Note the date and time (including timezone) of discovery.
Leave the system powered on if it is on. Do not shut it down. Do not reboot it.
Isolate the system from the network by disconnecting the network cable or disabling the network adapter. Do not use the system to disable its own network -- use a switch port shutdown or EDR network isolation instead if possible.
Call the incident response team. Immediately. Not after "having a quick look."
Record your actions. Everything done to or on the system from the moment of discovery should be documented.

Do Not:

Do not reboot the system. This destroys volatile memory evidence.
Do not "clean up" the system. No antivirus scans. No malware removal. No deleting suspicious files. Every one of these actions modifies the evidence.
Do not log into the system unless absolutely necessary, and if so, document the credentials used and the actions taken.
Do not copy files using normal methods. Dragging and dropping files, or using copy, modifies file access timestamps and potentially overwrites deleted data.
Do not run unnecessary programs on the system. Every program execution modifies memory and disk.
Do not discuss the incident on the compromised system's communication channels. If the attacker has access to email or messaging, they can see the response plans.
Do not shut down the system. It is on this list twice because it is that important.

Tools of the Trade: A Quick Reference

Purpose	Tool	Platform	Notes
Memory acquisition	DumpIt	Windows	Simple, single executable
Memory acquisition	WinPmem	Windows	Open source, flexible
Memory acquisition	AVML	Linux	Microsoft's open-source tool
Memory analysis	Volatility 3	Cross-platform	The gold standard for memory forensics
Disk imaging	FTK Imager	Windows	Free, widely accepted
Disk imaging	dc3dd	Linux	Enhanced dd with hashing
Triage collection	KAPE	Windows	Rapid evidence collection and processing
Triage collection	CyLR	Cross-platform	Rapid forensic artefact collection
Hashing	HashCalc / sha256sum	Cross-platform	Evidence integrity verification
Log collection	Velociraptor	Cross-platform	Scalable endpoint triage and collection

Evidence Preservation in the Cloud

A note for the modern era: cloud environments present unique challenges for evidence preservation.

There is no disk to image. Virtual machines may have snapshots, but these are not the same as forensic images.
Memory acquisition requires different tools. Some cloud providers offer memory dump capabilities; others do not.
Logs are the primary evidence source. Cloud audit logs (AWS CloudTrail, Azure Activity Log, GCP Cloud Audit Logs) become the primary evidentiary record.
Volatile data includes API sessions and temporary credentials. STS tokens, session cookies, and temporary access keys are the cloud equivalent of RAM -- they disappear when they expire.
Preserve cloud logs immediately. Cloud provider log retention varies, and in some cases defaults are shorter than expected.

The principles remain the same. The tools change. The order of volatility still applies -- collect what will disappear first.

Key Takeaways

RAM first. Always. Before anything else. Before containment. Before remediation. Before "just having a quick look."
Do not modify the system. Every action on a compromised system potentially destroys evidence. Minimise the footprint.
Hash everything. SHA-256 at minimum, recorded immediately upon collection.
Maintain chain of custody. Evidence without chain of custody is just interesting data.
Work from copies. Never analyse original evidence.
The first thing most people do is the wrong thing. The instinct to "fix it" must be suppressed until evidence is collected. Restarting a server because "it'll probably be fine" has destroyed more forensic evidence than any advanced threat actor.

Next in the series: Incident Response 103: Ransomware Response, or "So Someone Encrypted Everything" -- a practical playbook for scoping, investigating, and recovering from ransomware incidents, including finding Patient Zero and assessing data exfiltration.

Previously: Incident Response 101: PICERL, or "The Six Stages of Cyber Grief" -- the PICERL framework and why Lessons Learned is the phase everyone skips.

Tags: incident-response, digital-forensics, evidence-preservation, chain-of-custody, memory-acquisition, order-of-volatility

Category: Incident Response

Series: Incident Response Fundamentals